Reward Evidence Reconciliation Dashboard Specification

Reward Evidence Reconciliation Dashboard Specification

# Reward Evidence Reconciliation Dashboard Specification

**Version:** 1.0
**Published:** April 28, 2026
**Status:** Active — Implementation-Ready
**Author:** Post Fiat Institutional Working Group
**Scope:** Task Node operators, maintainers, and reviewers responsible for auditing the durable evidence backing rewarded network tasks

---

## 1. Purpose and Scope

This specification defines a reconciliation dashboard that enables maintainers to audit whether rewarded network tasks possess durable, fetchable, scope-matched evidence. Its purpose is to surface artifact health problems before large reward outflows compound — detecting broken links, private artifacts, scope drift, stale evidence, and concentrated reward exposure across under-audited contributors.

### 1.1 Governing Principle

**Reward integrity requires evidence integrity.** A rewarded task whose backing artifact is missing, inaccessible, scope-mismatched, or never audited represents an adjudication blind spot. This dashboard treats evidence reconciliation as an ongoing operational discipline, not a one-time check.

### 1.2 Scope Boundaries

This specification governs:

- The canonical schema for rewarded-task evidence records
- Dashboard surfaces for evidence health, shipment visibility, reward concentration, and exception routing
- Scoring formulas and threshold-based exception triggers
- Operator actions and state transitions for evidence exceptions
- Worked mock readouts demonstrating dashboard usage with anonymized contributor archetypes

This specification does **not** govern:

- Contributor cooldown or rate-limiting policy (see Contributor Reliability & Source Credibility Framework)
- Reward calculation or settlement mechanics (see Signal Reward and Economic Settlement Standard)
- Reviewer calibration or gold-set management (see Reviewer Calibration Sprint Playbook)
- Signal content quality scoring (see Alpha Review Rubric)

### 1.3 Relationship to Adjacent Standards

The dashboard ingests data from the Reward and Economic Settlement Standard (reward events), the Signal Lifecycle State Machine (task states), the Evidence Weighting Standard (evidence scores), and the Contributor Reliability Framework (risk flags). It produces outputs consumed by the Exception Handling Operational Decision Tree (escalation routing) and the Reviewer Performance Dashboard (maintainer workload balancing).

---

## 2. Rewarded-Task Evidence Schema

Every rewarded task that has progressed to a payout-eligible state must carry a complete evidence record conforming to this schema. The schema is the single source of truth for reconciliation and powers all dashboard surfaces, exception triggers, and audit trails.

### 2.1 Canonical Field Definitions

| # | Field Name | Type | Description |
|---|-----------|------|-------------|
| 1 | `evidence_id` | UUID v4 | Unique identifier for the evidence record, generated at evidence attachment time. Immutable after creation. |
| 2 | `task_id` | UUID v4 | Foreign key to the rewarded task. One task may carry multiple evidence records; each is reconciled independently. |
| 3 | `artifact_type` | Enum | Classification of the backing artifact. Values: `GIST`, `COMMIT`, `PULL_REQUEST`, `DOCUMENT`, `DEPLOYMENT`, `DATASET`, `EXTERNAL_URL`, `SCREENSHOT`, `LOG_EXTRACT`, `OTHER`. |
| 4 | `artifact_uri` | URI string | The canonical fetch URI for the artifact. Must resolve to a publicly accessible resource without authentication. URIs that require login, VPN, or invitation are flagged as non-public. |
| 5 | `public_fetch_status` | Enum | Result of the most recent automated fetch attempt. Values: `REACHABLE`, `UNREACHABLE`, `AUTH_REQUIRED`, `RATE_LIMITED`, `TIMEOUT`, `NOT_TESTED`. Updated by the evidence crawler on each reconciliation cycle. |
| 6 | `last_fetch_timestamp` | ISO 8601 datetime | Timestamp of the most recent automated fetch attempt against `artifact_uri`. Null if never tested. |
| 7 | `scope_match_grade` | Float [0.00–1.00] | Automated assessment of how closely the artifact's content aligns with the task's stated scope and acceptance criteria. Computed by the scope-match evaluator; values below the threshold trigger an exception. |
| 8 | `scope_match_method` | Enum | Method used to compute `scope_match_grade`. Values: `KEYWORD_OVERLAP`, `SEMANTIC_EMBEDDING`, `MANUAL_OVERRIDE`, `HYBRID`. Logged for audit trail fidelity. |
| 9 | `reviewer_decision` | Enum | The reviewer's assessment of this evidence record. Values: `APPROVED`, `APPROVED_WITH_NOTES`, `FLAGGED`, `REJECTED`, `PENDING_REVIEW`, `OVERRIDDEN`. |
| 10 | `reviewer_id` | String | Identifier of the reviewer who rendered `reviewer_decision`. Used for concentration and override tracking. |
| 11 | `reviewer_override_count` | Integer ≥ 0 | Number of times the reviewer has overridden an automated flag or prior reviewer decision on this specific evidence record. Incremented on each override event; never decremented. |
| 12 | `maintainer_owner` | String | Identifier of the maintainer responsible for this evidence record's project lane. Determines routing for exceptions and acknowledgment requirements. |
| 13 | `maintainer_ack_status` | Enum | Whether the assigned maintainer has acknowledged the evidence record post-reward. Values: `ACKNOWLEDGED`, `PENDING`, `DECLINED`, `EXPIRED`. |
| 14 | `maintainer_ack_timestamp` | ISO 8601 datetime | Timestamp of the maintainer's most recent acknowledgment action. Null if `maintainer_ack_status` = `PENDING` or `EXPIRED`. |
| 15 | `project_lane` | String | The project lane or workstream to which the rewarded task belongs (e.g., `signal-infra`, `reviewer-tooling`, `contributor-onboarding`). Used for lane-level health aggregation. |
| 16 | `reward_amount_band` | Enum | Bucketed reward size for the associated task. Values: `MICRO` (< 50 PFT), `SMALL` (50–199 PFT), `MEDIUM` (200–999 PFT), `LARGE` (1,000–4,999 PFT), `CRITICAL` (≥ 5,000 PFT). Higher bands receive tighter audit scrutiny. |
| 17 | `contributor_id` | String (anonymized) | The contributor who submitted the evidence. Anonymized in dashboard display; de-anonymized only in escalation workflows with appropriate access controls. |
| 18 | `contributor_risk_flags` | Array of Enum | Active risk flags on the contributor at the time of evidence attachment. Values: `NEW_ACCOUNT`, `HIGH_VELOCITY`, `PRIOR_REJECTION_STREAK`, `CONCENTRATION_ALERT`, `COOLDOWN_ACTIVE`, `OVERRIDE_HISTORY`, `SYBIL_WATCH`, `NONE`. |
| 19 | `last_audited_timestamp` | ISO 8601 datetime | Timestamp of the most recent manual or automated audit of this evidence record. Null if never audited. Used by the staleness trigger. |
| 20 | `evidence_state` | Enum | Current reconciliation state of this evidence record. Values: `NORMAL`, `AUDIT_NEEDED`, `MAINTAINER_REVIEW`, `CONTRIBUTOR_REMEDIATION`, `REWARD_HOLD_RECOMMENDED`, `CLEARED`, `ESCALATED`. See Section 5 for state transition rules. |
| 21 | `exception_codes` | Array of String | Active exception codes from the trigger engine (Section 4). Empty array when no exceptions are active. Multiple codes may coexist. |
| 22 | `created_at` | ISO 8601 datetime | Timestamp of evidence record creation. Immutable. |

### 2.2 Schema Invariants

- Every evidence record must have a non-null `artifact_uri` before transitioning to any post-reward state.
- `evidence_state` must equal `NORMAL` or `CLEARED` for the associated reward to remain in settled status. Any other state triggers a hold advisory to the settlement layer.
- `contributor_risk_flags` is a snapshot captured at evidence attachment time; it is not retroactively updated. Downstream risk changes are tracked via the Contributor Reliability Framework and surfaced through separate dashboard triggers.
- `reviewer_override_count` ≥ 3 on any single evidence record automatically escalates to maintainer review regardless of other trigger states.

---

## 3. Dashboard Surfaces

The dashboard presents four primary surfaces. Each surface serves a distinct operator persona and audit cadence.

### 3.1 Surface 1 — Evidence Health Overview

**Primary audience:** Task Node operators, network-level maintainers
**Refresh cadence:** Every reconciliation cycle (default: 6 hours)
**Purpose:** Provide a network-wide snapshot of evidence integrity across all rewarded tasks.

#### Metrics Displayed

- **Total evidence records** in scope (trailing 30/60/90-day windows, selectable)
- **Fetch reachability rate:** Percentage of records where `public_fetch_status` = `REACHABLE`, trended over time
- **Scope match distribution:** Histogram of `scope_match_grade` values across all in-scope records, with the exception threshold (0.40) marked
- **Evidence state breakdown:** Count and percentage of records in each `evidence_state` value, displayed as a stacked bar
- **Mean time to first audit:** Average elapsed time between `created_at` and `last_audited_timestamp` for records that have been audited, segmented by `reward_amount_band`
- **Unaudited backlog:** Count of records where `last_audited_timestamp` is null, segmented by `reward_amount_band` and age
- **Trend sparklines:** 7-day rolling averages for reachability rate, scope match median, and exception creation rate

#### Interaction Model

Operators can drill down from any aggregate metric to the filtered evidence table (Surface 4). Clicking a reachability rate segment opens the exception queue pre-filtered to the corresponding `public_fetch_status` values. Time-window selection persists across surface navigation within a session.

### 3.2 Surface 2 — Maintainer Shipment Visibility

**Primary audience:** Project-lane maintainers
**Refresh cadence:** Real-time (event-driven updates via webhook)
**Purpose:** Give each maintainer a clear view of the evidence records they own, their acknowledgment status, and pending actions.

#### Metrics Displayed

- **My open records:** Count of evidence records where `maintainer_owner` = current user and `evidence_state` ∉ {`NORMAL`, `CLEARED`}
- **Acknowledgment backlog:** Records in `maintainer_ack_status` = `PENDING`, sorted by age descending, with `reward_amount_band` badge
- **Shipment timeline:** Chronological view of evidence records entering and exiting the maintainer's queue, with state-transition annotations
- **Lane health score:** Composite score for the maintainer's `project_lane`, computed as: `(reachability_rate × 0.30) + (scope_match_median × 0.30) + (ack_completion_rate × 0.20) + (exception_clearance_rate × 0.20)`
- **Peer comparison (anonymized):** Maintainer's lane health score relative to network median (shown as percentile rank, not named peers)
- **Escalation exposure:** Count of records in `ESCALATED` state within the maintainer's lane, with cumulative reward value at risk

#### Interaction Model

Maintainers can bulk-acknowledge records, transition records to `CLEARED` with a one-click attestation plus optional note, or route records to `CONTRIBUTOR_REMEDIATION` with a structured remediation request template. All actions are logged with timestamp and maintainer ID.

### 3.3 Surface 3 — Reward Concentration by Evidence Quality

**Primary audience:** Task Node operators, risk/compliance reviewers
**Refresh cadence:** Daily (batch computation overnight)
**Purpose:** Identify reward concentration risk — scenarios where large reward outflows correlate with low evidence quality, untested artifacts, or under-audited contributors.

#### Metrics Displayed

- **Reward-weighted evidence quality matrix:** Two-axis heatmap. X-axis: `reward_amount_band`. Y-axis: evidence quality tier (derived from `scope_match_grade` and `public_fetch_status`). Cell color intensity = cumulative PFT value. Hot cells (high reward, low quality) are highlighted with alert borders.
- **Top 10 contributors by unaudited reward exposure:** Ranked list of contributors (anonymized) whose total settled reward value across records with `last_audited_timestamp` = null exceeds the concentration threshold
- **Reviewer approval concentration:** Heatmap showing which reviewers approved which proportion of high-band rewards, flagging single-reviewer bottlenecks
- **Override density by reward band:** Bar chart showing `reviewer_override_count` > 0 records per `reward_amount_band`, normalized as percentage of band total
- **Project lane reward distribution:** Treemap showing reward allocation by `project_lane`, with sub-segments colored by average evidence quality within each lane

#### Interaction Model

Clicking any heatmap cell or list entry opens the filtered exception queue. The contributor concentration list supports "Create audit task" action, which generates a batch audit assignment for the selected contributor's unaudited records and routes it to the appropriate maintainer.

### 3.4 Surface 4 — Exception Queue

**Primary audience:** All operator personas
**Refresh cadence:** Real-time
**Purpose:** Central worklist for all evidence records that have active exception codes. This is the operational backbone of the reconciliation workflow.

#### Queue Layout

Each exception queue entry displays:

- `evidence_id` (linked to full record detail view)
- `task_id` (linked to task detail)
- `contributor_id` (anonymized, with risk flag badges)
- `artifact_type` and truncated `artifact_uri`
- Active `exception_codes` (as color-coded chips)
- `evidence_state` (current)
- `reward_amount_band` (badge)
- `maintainer_owner`
- Age in queue (time since first exception trigger)
- Severity score (composite; see Section 4.3)

#### Sorting and Filtering

- Default sort: severity score descending, then age descending
- Filterable by: `exception_codes`, `evidence_state`, `reward_amount_band`, `project_lane`, `maintainer_owner`, `contributor_risk_flags`, `artifact_type`
- Saved filter presets per operator
- Bulk action toolbar: select multiple records for batch state transitions

#### Queue Actions

Each entry supports inline actions mapped to the state transition model (Section 5): Acknowledge, Begin Review, Request Remediation, Recommend Hold, Clear, Escalate, Reassign Maintainer.

---

## 4. Scoring Formulas and Threshold-Based Exception Triggers

The trigger engine evaluates every evidence record on each reconciliation cycle and attaches exception codes when thresholds are breached. Multiple triggers may fire simultaneously on a single record; all active codes are stored in `exception_codes`.

### 4.1 Exception Trigger Definitions

#### Trigger 1 — Broken or Unreachable Link (`EX-LINK-001`)

**Condition:** `public_fetch_status` ∈ {`UNREACHABLE`, `TIMEOUT`} for two or more consecutive reconciliation cycles.

**Scoring formula:**
```
link_severity = base_severity × band_multiplier × age_factor

where:
  base_severity       = 6.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
  age_factor          = 1.0 + (0.1 × days_since_first_failure), capped at 2.0
```

**Threshold:** Fires when `public_fetch_status` ≠ `REACHABLE` persists across ≥ 2 consecutive cycles. First failure logs a warning; second failure attaches the exception code.

**Rationale:** A single transient failure should not trigger operator action. Persistent unreachability indicates a deleted artifact, changed permissions, or link rot that must be remediated.

#### Trigger 2 — Private or Auth-Gated Artifact (`EX-AUTH-002`)

**Condition:** `public_fetch_status` = `AUTH_REQUIRED`

**Scoring formula:**
```
auth_severity = base_severity × band_multiplier

where:
  base_severity       = 7.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
```

**Threshold:** Fires immediately on first detection. Auth-gated artifacts are categorically non-compliant with the public-fetch requirement.

**Rationale:** Evidence that cannot be independently verified by any network participant without credentials fails the durable-public-evidence test. No grace period.

#### Trigger 3 — Artifact/Task Scope Mismatch (`EX-SCOPE-003`)

**Condition:** `scope_match_grade` < 0.40

**Scoring formula:**
```
scope_severity = base_severity × (1.0 - scope_match_grade) × band_multiplier

where:
  base_severity       = 5.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
```

**Threshold:** Fires when `scope_match_grade` drops below 0.40. Records between 0.40 and 0.55 are tagged with a non-blocking advisory (`ADV-SCOPE-SOFT`) for reviewer awareness but do not enter the exception queue.

**Rationale:** An artifact that has less than 40% topical alignment with its declared task scope suggests either a mislabeled artifact or scope drift in the original task definition. Both require investigation.

#### Trigger 4 — Repeated Reviewer Override (`EX-OVERRIDE-004`)

**Condition:** `reviewer_override_count` ≥ 3 on a single evidence record, OR `reviewer_override_count` ≥ 2 AND `reward_amount_band` ∈ {`LARGE`, `CRITICAL`}

**Scoring formula:**
```
override_severity = base_severity × override_count × band_multiplier

where:
  base_severity       = 4.0
  override_count      = reviewer_override_count
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
```

**Threshold:** 3 overrides for standard bands; 2 overrides for LARGE/CRITICAL bands.

**Rationale:** Repeated overrides on a single evidence record indicate disagreement between automated checks and human judgment. While the reviewer may be correct, the pattern warrants maintainer visibility — especially at high reward bands where incorrect overrides compound exposure.

#### Trigger 5 — High Reward Concentration on Low-Quality Evidence (`EX-CONC-005`)

**Condition:** A single contributor's trailing-90-day cumulative reward across records where `scope_match_grade` < 0.55 OR `public_fetch_status` ≠ `REACHABLE` exceeds the concentration threshold.

**Scoring formula:**
```
concentration_severity = base_severity × (contributor_low_quality_reward / concentration_threshold)

where:
  base_severity            = 8.0
  concentration_threshold  = 2,000 PFT (configurable per network epoch)
```

**Threshold:** Fires when `contributor_low_quality_reward` ≥ `concentration_threshold`. The trigger attaches to all of the contributor's evidence records that individually meet the low-quality criteria.

**Rationale:** Systemic evidence quality issues from a single contributor, combined with significant reward outflows, represent the highest-risk blind spot this dashboard is designed to catch. The threshold is deliberately set to flag patterns early rather than after irrecoverable reward distribution.

#### Trigger 6 — Aged Unaudited Evidence (`EX-STALE-006`)

**Condition:** `last_audited_timestamp` is null AND `created_at` is older than the staleness window, scaled by reward band.

**Scoring formula:**
```
staleness_severity = base_severity × band_multiplier × age_factor

where:
  base_severity       = 3.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
  age_factor          = days_past_staleness_threshold / 7, capped at 3.0
```

**Staleness windows by reward band:**
| Band | Staleness Threshold |
|------|-------------------|
| MICRO | 30 days |
| SMALL | 21 days |
| MEDIUM | 14 days |
| LARGE | 7 days |
| CRITICAL | 3 days |

**Threshold:** Fires when a record has never been audited and exceeds the band-appropriate staleness window.

**Rationale:** Higher-value rewards demand faster audit coverage. CRITICAL-band records that go 3 days without any audit represent an unacceptable gap in reconciliation discipline.

#### Trigger 7 — Missing Maintainer Acknowledgment (`EX-MACK-007`)

**Condition:** `maintainer_ack_status` ∈ {`PENDING`, `EXPIRED`} AND `created_at` is older than the acknowledgment window.

**Scoring formula:**
```
mack_severity = base_severity × band_multiplier × overdue_factor

where:
  base_severity       = 4.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
  overdue_factor      = 1.0 + (0.15 × days_past_ack_deadline), capped at 2.5
```

**Acknowledgment windows by reward band:**
| Band | Ack Deadline |
|------|-------------|
| MICRO | 14 days |
| SMALL | 10 days |
| MEDIUM | 7 days |
| LARGE | 3 days |
| CRITICAL | 1 day |

**Threshold:** Fires when the acknowledgment deadline passes without `maintainer_ack_status` = `ACKNOWLEDGED`.

**Rationale:** Maintainer acknowledgment is the human-in-the-loop checkpoint that confirms a rewarded task's evidence was seen by the responsible party. Missing acknowledgment means no human with project context has validated that the reward was appropriate.

#### Trigger 8 — Single-Reviewer Approval Bottleneck (`EX-BOTTLENECK-008`)

**Condition:** A single reviewer accounts for ≥ 60% of `APPROVED` or `APPROVED_WITH_NOTES` decisions across a project lane's LARGE or CRITICAL band records within a trailing 30-day window.

**Scoring formula:**
```
bottleneck_severity = base_severity × reviewer_share × lane_reward_exposure_factor

where:
  base_severity                = 5.0
  reviewer_share               = (reviewer_approvals_in_lane / total_approvals_in_lane)
  lane_reward_exposure_factor  = total_lane_reward_value / 10,000, capped at 3.0
```

**Threshold:** Fires when `reviewer_share` ≥ 0.60 for LARGE/CRITICAL bands within a lane.

**Rationale:** Single-reviewer concentration in high-value lanes creates a key-person risk and potential blind spot — whether through fatigue, bias, or insufficient adversarial review diversity. This trigger does not imply reviewer error; it surfaces structural risk.

#### Trigger 9 — Contributor Risk Flag Compound (`EX-RISK-009`)

**Condition:** `contributor_risk_flags` contains ≥ 3 active flags simultaneously, OR contains both `SYBIL_WATCH` and any one of {`HIGH_VELOCITY`, `PRIOR_REJECTION_STREAK`, `OVERRIDE_HISTORY`}.

**Scoring formula:**
```
risk_compound_severity = base_severity × flag_count × band_multiplier

where:
  base_severity       = 6.0
  flag_count          = len(contributor_risk_flags), minimum 2
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
```

**Threshold:** Fires on the compound condition described above.

**Rationale:** Individual risk flags are informational. Compound flags — especially `SYBIL_WATCH` paired with behavioral indicators — represent a qualitatively different risk profile that demands proactive audit rather than passive monitoring.

#### Trigger 10 — Evidence State Regression (`EX-REGRESS-010`)

**Condition:** An evidence record transitions from `CLEARED` back to any non-terminal exception state due to a subsequent reconciliation cycle detecting a new issue (e.g., a previously reachable link becoming unreachable after clearance).

**Scoring formula:**
```
regression_severity = base_severity × band_multiplier × recurrence_factor

where:
  base_severity       = 7.0
  band_multiplier     = {MICRO: 1.0, SMALL: 1.2, MEDIUM: 1.5, LARGE: 2.0, CRITICAL: 3.0}
  recurrence_factor   = 1.0 + (0.5 × prior_regression_count), capped at 3.0
```

**Threshold:** Fires on any regression from `CLEARED`.

**Rationale:** Evidence that was once cleared and then fails again indicates either a fragile artifact host, deliberate removal, or an overly permissive initial clearance. Repeat regressions escalate severity rapidly to prevent clear-then-break cycles.

### 4.2 Advisory Codes (Non-Exception)

Advisory codes are informational flags logged on the evidence record but not routed to the exception queue. They provide ambient awareness without generating operator workload:

| Advisory Code | Condition |
|--------------|-----------|
| `ADV-SCOPE-SOFT` | `scope_match_grade` between 0.40 and 0.55 |
| `ADV-FRESH-WARN` | `last_fetch_timestamp` older than 48 hours but record not yet in exception |
| `ADV-NEW-CONTRIB` | `contributor_risk_flags` contains `NEW_ACCOUNT` as sole flag |
| `ADV-OVERRIDE-1` | `reviewer_override_count` = 1 (below exception threshold) |

### 4.3 Composite Severity Score

The composite severity score for an evidence record with multiple active exception codes is:

```
composite_severity = max(individual_severities) + (0.15 × sum(remaining_severities))

Interpretation:
  The worst trigger dominates, with compounding from additional triggers.
  Range: theoretically 0 to ~80; practical range 3.0–35.0
```

Queue sort order uses `composite_severity` descending as the primary key.

---

## 5. Operator Actions and State Transitions

Evidence records move through a defined state machine. Every transition is logged with operator ID, timestamp, source state, target state, and optional operator note.

### 5.1 State Definitions

| State | Description | Who Can Enter | Terminal? |
|-------|------------|---------------|-----------|
| `NORMAL` | No active exceptions. Evidence is reachable, scope-matched, acknowledged, and audited within thresholds. | System (automatic on clean reconciliation) | No (can regress) |
| `AUDIT_NEEDED` | One or more exception triggers have fired. The record requires operator attention. | System (automatic on trigger fire) | No |
| `MAINTAINER_REVIEW` | A maintainer has claimed the record and is actively investigating. | Maintainer (manual claim) | No |
| `CONTRIBUTOR_REMEDIATION` | The maintainer has determined the contributor must fix the evidence (e.g., re-publish artifact, correct scope). A remediation request has been issued. | Maintainer (after review) | No |
| `REWARD_HOLD_RECOMMENDED` | The maintainer recommends that the associated reward be held pending resolution. Advisory to the settlement layer; does not unilaterally freeze funds. | Maintainer (after review) | No |
| `CLEARED` | All exceptions resolved. Evidence verified as durable, fetchable, and scope-matched. | Maintainer (after successful remediation or false-positive determination) | No (can regress) |
| `ESCALATED` | The issue exceeds maintainer authority or involves systemic risk. Routed to Task Node operators or governance. | Maintainer or System (on specific trigger compounds) | No |

### 5.2 Permitted State Transitions

```
NORMAL ──[trigger fires]──► AUDIT_NEEDED
AUDIT_NEEDED ──[maintainer claims]──► MAINTAINER_REVIEW
AUDIT_NEEDED ──[auto-resolve: all triggers clear]──► NORMAL
MAINTAINER_REVIEW ──[remediation needed]──► CONTRIBUTOR_REMEDIATION
MAINTAINER_REVIEW ──[hold recommended]──► REWARD_HOLD_RECOMMENDED
MAINTAINER_REVIEW ──[false positive / resolved]──► CLEARED
MAINTAINER_REVIEW ──[exceeds authority]──► ESCALATED
CONTRIBUTOR_REMEDIATION ──[contributor fixes evidence]──► MAINTAINER_REVIEW (re-review)
CONTRIBUTOR_REMEDIATION ──[remediation window expires]──► REWARD_HOLD_RECOMMENDED
REWARD_HOLD_RECOMMENDED ──[resolved after hold]──► CLEARED
REWARD_HOLD_RECOMMENDED ──[unresolvable]──► ESCALATED
CLEARED ──[regression detected]──► AUDIT_NEEDED (with EX-REGRESS-010)
ESCALATED ──[governance resolves]──► CLEARED or REWARD_HOLD_RECOMMENDED
```

### 5.3 Transition Rules and Guards

- **No skip transitions:** A record cannot move from `AUDIT_NEEDED` directly to `CLEARED` without passing through `MAINTAINER_REVIEW`. The maintainer must explicitly claim and review before clearance.
- **Auto-resolve:** If all exception triggers clear on a subsequent reconciliation cycle before a maintainer claims the record, the system transitions it back to `NORMAL`. This prevents stale queue entries for transient issues.
- **Remediation window:** Contributors have 7 days (configurable) to remediate after entering `CONTRIBUTOR_REMEDIATION`. Expiry auto-transitions to `REWARD_HOLD_RECOMMENDED`.
- **Escalation compounds:** If a record in `MAINTAINER_REVIEW` has `composite_severity` ≥ 25.0 or carries both `EX-CONC-005` and `EX-RISK-009`, the system auto-escalates regardless of maintainer action.
- **Cleared regression:** Any regression from `CLEARED` re-enters `AUDIT_NEEDED` with `EX-REGRESS-010` attached. The prior clearance operator and note are preserved in the audit log for context.

### 5.4 Operator Action Reference

| Action | Available In States | Target State | Required Fields |
|--------|-------------------|--------------|----------------|
| **Claim for Review** | `AUDIT_NEEDED` | `MAINTAINER_REVIEW` | operator ID |
| **Clear Exception** | `MAINTAINER_REVIEW` | `CLEARED` | operator ID, clearance note (min 20 chars) |
| **Request Remediation** | `MAINTAINER_REVIEW` | `CONTRIBUTOR_REMEDIATION` | operator ID, remediation description, deadline (default 7 days) |
| **Recommend Reward Hold** | `MAINTAINER_REVIEW`, `CONTRIBUTOR_REMEDIATION` | `REWARD_HOLD_RECOMMENDED` | operator ID, hold justification, affected reward IDs |
| **Escalate** | `MAINTAINER_REVIEW`, `REWARD_HOLD_RECOMMENDED` | `ESCALATED` | operator ID, escalation reason, recommended governance action |
| **Resolve Escalation** | `ESCALATED` | `CLEARED` or `REWARD_HOLD_RECOMMENDED` | governance operator ID, resolution note, disposition |
| **Reassign Maintainer** | Any non-terminal | (unchanged) | new `maintainer_owner`, reassignment reason |
| **Bulk Acknowledge** | `NORMAL` (pending ack) | `NORMAL` (ack'd) | operator ID |

---

## 6. Worked Mock Readouts

The following scenarios use anonymized contributor archetypes to demonstrate how evidence records flow through the dashboard and how maintainers prioritize the exception queue.

### 6.1 Scenario 1 — "The Ghost Link"

**Archetype:** Contributor Alpha, a moderate-volume contributor with no prior risk flags.

**Setup:** Contributor Alpha completed a MEDIUM-band task (450 PFT reward) in the `signal-infra` lane. The evidence artifact is a GitHub Gist linked via `artifact_uri`. Three weeks after reward settlement, the contributor deletes the Gist.

**Dashboard Flow:**

1. **Cycle N:** Evidence crawler attempts fetch. `public_fetch_status` transitions from `REACHABLE` to `UNREACHABLE`. Warning logged. No exception code yet (first failure, single-cycle grace period per Trigger 1).

2. **Cycle N+1 (6 hours later):** Second consecutive fetch failure. `EX-LINK-001` fires. Severity = `6.0 × 1.5 (MEDIUM band) × 1.0 (age_factor at day 0)` = **9.0**. Record transitions from `NORMAL` to `AUDIT_NEEDED`. Appears in exception queue.

3. **Surface 1 impact:** Fetch reachability rate decreases. The `signal-infra` lane's health score drops on Surface 2 for the lane maintainer.

4. **Maintainer action:** Lane maintainer for `signal-infra` sees the record on Surface 2's open-records list. Claims it → `MAINTAINER_REVIEW`. Confirms the Gist is deleted. Issues remediation request to Contributor Alpha: "Re-publish the artifact at a stable URI within 7 days."

5. **Resolution path A — Contributor remediates:** Alpha re-publishes the Gist, updates `artifact_uri` via remediation response. Next cycle confirms `REACHABLE`. Maintainer re-reviews, verifies scope match, clears → `CLEARED`.

6. **Resolution path B — Contributor does not respond:** 7-day remediation window expires. Auto-transition to `REWARD_HOLD_RECOMMENDED`. Settlement layer receives hold advisory for the 450 PFT reward.

**Prioritization note:** At severity 9.0, this record sorts below auth-gated or concentration alerts but above staleness exceptions. The maintainer would encounter it in the top third of a typical queue.

### 6.2 Scenario 2 — "The Scope Drifter"

**Archetype:** Contributor Beta, a high-volume contributor with `HIGH_VELOCITY` flag active.

**Setup:** Contributor Beta completes three SMALL-band tasks (150 PFT each) in the `contributor-onboarding` lane over 48 hours. All three artifacts are publicly reachable, but the scope-match evaluator scores them at 0.32, 0.38, and 0.29 — well below the 0.40 threshold.

**Dashboard Flow:**

1. **Trigger fires:** `EX-SCOPE-003` fires on all three records. Severity for the worst: `5.0 × (1.0 - 0.29) × 1.2` = **4.26**. Individually moderate.

2. **Compound effect:** Because Beta has `HIGH_VELOCITY` flag and three simultaneous exceptions, the queue shows them clustered. Surface 3's contributor concentration view highlights Beta: 450 PFT across 3 records, all with scope < 0.40.

3. **Maintainer action:** Maintainer reviews the three artifacts. Determines that two are genuine scope drift (the contributor delivered work related to a different task) and one is a false positive (the keyword-overlap method underscored a valid but unconventionally structured artifact).

4. **Resolution:**
   - Record with `scope_match_grade` = 0.29: Request remediation — contributor should submit correct artifact.
   - Record with `scope_match_grade` = 0.32: Request remediation — same issue.
   - Record with `scope_match_grade` = 0.38: Maintainer overrides scope assessment (`reviewer_decision` = `OVERRIDDEN`, `scope_match_method` updated to `MANUAL_OVERRIDE`). Clears exception → `CLEARED`.

5. **Downstream effect:** Two open remediation requests lower Beta's lane health score and generate an `ADV-SCOPE-SOFT` pattern alert for the contributor-onboarding lane on Surface 1.

### 6.3 Scenario 3 — "The Bottleneck Reviewer"

**Archetype:** Reviewer Gamma, an experienced reviewer who has been the sole active reviewer in the `reviewer-tooling` lane for 25 days.

**Setup:** Over the trailing 30 days, Reviewer Gamma has approved 14 out of 16 LARGE-band evidence records in the `reviewer-tooling` lane (87.5% share). Total lane reward value: 28,000 PFT.

**Dashboard Flow:**

1. **Trigger fires:** `EX-BOTTLENECK-008` fires. `reviewer_share` = 0.875, well above the 0.60 threshold. `lane_reward_exposure_factor` = 28,000 / 10,000 = 2.8. Severity = `5.0 × 0.875 × 2.8` = **12.25**. This attaches to all 14 of Gamma's approved records in the lane.

2. **Surface 3 visibility:** The reviewer approval concentration heatmap shows a hot cell at the intersection of `reviewer-tooling` and Reviewer Gamma. The override density chart shows 0 overrides (Gamma is thorough, not careless — this is structural risk, not quality risk).

3. **Maintainer action:** Task Node operator sees the cluster on Surface 3. This is not an individual evidence issue but a structural one. Operator does not transition individual records but instead:
   - Creates a governance note recommending a second reviewer be assigned to `reviewer-tooling` for LARGE/CRITICAL bands
   - Tags the 14 records with an advisory code requesting spot-check re-review by a second reviewer on 3 randomly selected records

4. **Resolution:** Once a second reviewer is active in the lane and the 30-day window rolls forward, the concentration drops below 0.60. `EX-BOTTLENECK-008` auto-clears on the next cycle.

**Prioritization note:** Severity 12.25 places this above most individual link or scope exceptions. The cluster of 14 records sharing the same exception code makes it visually prominent in the queue, signaling a structural issue rather than 14 independent problems.

### 6.4 Scenario 4 — "The Compound Risk Contributor"

**Archetype:** Contributor Delta, flagged with `NEW_ACCOUNT`, `HIGH_VELOCITY`, and `PRIOR_REJECTION_STREAK`.

**Setup:** Delta has been active for 12 days, submitted 9 tasks (high velocity for a new account), and had 4 prior rejections. Despite this, Delta's most recent LARGE-band task (2,500 PFT) was approved by a reviewer with `reviewer_decision` = `APPROVED`. The evidence artifact is reachable and has a `scope_match_grade` of 0.62 (above threshold). However, the compound risk flag trigger fires.

**Dashboard Flow:**

1. **Trigger fires:** `EX-RISK-009` fires. Three active flags (`NEW_ACCOUNT`, `HIGH_VELOCITY`, `PRIOR_REJECTION_STREAK`) ≥ 3 compound threshold. Severity = `6.0 × 3 × 2.0 (LARGE band)` = **36.0**. This is an extremely high severity score.

2. **Concurrent trigger check:** `last_audited_timestamp` is null (new record). Created 4 days ago. LARGE-band staleness threshold is 7 days, so `EX-STALE-006` has not fired yet — but it will in 3 days if not audited.

3. **Composite severity:** Only one trigger active, so composite = 36.0. This sorts to near the top of the exception queue.

4. **Auto-escalation:** Composite severity ≥ 25.0 triggers the auto-escalation guard (Section 5.3). Even though a maintainer could claim it, the system simultaneously flags it for Task Node operator visibility.

5. **Maintainer action:** Maintainer claims the record and performs a deep review of the artifact. Two outcomes:
   - **If artifact is genuine and scope-matched:** Maintainer clears with a detailed note explaining why the compound flags do not indicate fraud in this case. The risk flags remain on the contributor's profile (managed by the Contributor Reliability Framework) but this evidence record moves to `CLEARED`.
   - **If artifact quality is questionable:** Maintainer recommends reward hold. The 2,500 PFT reward enters advisory hold. Escalation follows if the contributor cannot remediate.

**Prioritization note:** At severity 36.0, this record dominates the queue. The dashboard correctly prioritizes it — a high-value reward to a compound-risk contributor with no prior audit history is exactly the adjudication blind spot this system is built to catch.

### 6.5 Scenario 5 — "The Regression Loop"

**Archetype:** Contributor Epsilon, a long-tenured contributor with clean history. Maintainer Zeta owns the `signal-infra` lane.

**Setup:** Epsilon completed a CRITICAL-band task (7,500 PFT) 60 days ago. The evidence was audited, cleared by Maintainer Zeta, and settled. The artifact is hosted on a personal domain. On day 45, the domain's SSL certificate expired, causing fetch failures. Maintainer Zeta cleared it again after Epsilon renewed the certificate. On day 58, the domain's hosting lapsed entirely.

**Dashboard Flow:**

1. **First regression (day 45):** `EX-LINK-001` fires after two consecutive fetch failures. Record moves from `CLEARED` to `AUDIT_NEEDED`. `EX-REGRESS-010` also fires (regression from CLEARED). `prior_regression_count` = 0.

   Regression severity = `7.0 × 3.0 (CRITICAL band) × 1.0 (first regression)` = **21.0**
   Link severity = `6.0 × 3.0 × 1.0` = **18.0**
   Composite = `max(21.0, 18.0) + 0.15 × min(21.0, 18.0)` = `21.0 + 2.7` = **23.7**

2. **First resolution (day 48):** Epsilon renews SSL. Fetch succeeds. Maintainer Zeta re-reviews, clears again with note: "SSL renewal confirmed. Recommend contributor migrate to stable hosting."

3. **Second regression (day 58):** Domain fully offline. `EX-LINK-001` fires again. `EX-REGRESS-010` fires with `prior_regression_count` = 1.

   Regression severity = `7.0 × 3.0 × 1.5 (recurrence factor)` = **31.5**
   Link severity = `6.0 × 3.0 × 1.0` = **18.0**
   Composite = `31.5 + 0.15 × 18.0` = **34.2**

4. **Auto-escalation:** Composite ≥ 25.0 triggers auto-escalation. Even though Epsilon is a trusted contributor and Zeta already cleared once, the system correctly flags a pattern — the evidence hosting is structurally fragile for a CRITICAL-band reward.

5. **Task Node operator action:** Operator reviews the regression history. Determines this is not fraud but an unacceptable hosting risk for a 7,500 PFT reward. Issues a remediation request requiring Epsilon to re-host the artifact on network-approved durable storage (e.g., a pinned Gist or IPFS) within 7 days. Until migrated, the reward remains in hold advisory.

6. **Resolution:** Epsilon migrates the artifact to a GitHub Gist. Fetch confirms `REACHABLE`. Operator clears with governance note establishing a policy recommendation: CRITICAL-band evidence should require durable hosting at submission time, not just at audit time.

**Prioritization note:** The regression loop scenario demonstrates why `CLEARED` is not a terminal state. The escalating recurrence factor (31.5 severity on second regression vs. 21.0 on first) ensures that repeat failures receive disproportionate attention, preventing a clear-then-break cycle from exhausting maintainer capacity.

---

## 7. Implementation Notes

### 7.1 Reconciliation Cycle Cadence

The default reconciliation cycle is 6 hours. Operators may configure per-lane or per-band overrides:

| Band | Recommended Cycle |
|------|------------------|
| MICRO | 24 hours |
| SMALL | 12 hours |
| MEDIUM | 6 hours |
| LARGE | 3 hours |
| CRITICAL | 1 hour |

### 7.2 Evidence Crawler Requirements

The evidence crawler must:

- Respect rate limits on target hosts (configurable per-domain backoff)
- Log full HTTP response codes, not just reachable/unreachable binary
- Distinguish between 404 (deleted), 403 (auth-gated), 5xx (server error), and timeout
- Support retry with exponential backoff before marking a second consecutive failure
- Cache successful fetch content hashes for scope-match evaluation

### 7.3 Data Retention

- Evidence records: retained indefinitely (immutable audit trail)
- State transition logs: retained for 2 years
- Crawler fetch logs: retained for 90 days (raw), 1 year (aggregated)
- Operator action logs: retained for 2 years

### 7.4 Access Control

- **Task Node operators:** Full read/write access across all surfaces and all lanes
- **Lane maintainers:** Read/write access to records within their assigned `project_lane`; read-only access to network-wide aggregates on Surfaces 1 and 3
- **Reviewers:** Read-only access to records they reviewed; no state-transition authority
- **Contributors:** Read-only access to their own evidence records and remediation requests; no access to other contributors' records or aggregate views

---

## 8. Appendix: Exception Code Quick Reference

| Code | Short Name | Trigger Section | Base Severity |
|------|-----------|----------------|---------------|
| `EX-LINK-001` | Broken Link | 4.1 Trigger 1 | 6.0 |
| `EX-AUTH-002` | Private Artifact | 4.1 Trigger 2 | 7.0 |
| `EX-SCOPE-003` | Scope Mismatch | 4.1 Trigger 3 | 5.0 |
| `EX-OVERRIDE-004` | Repeated Override | 4.1 Trigger 4 | 4.0 |
| `EX-CONC-005` | Reward Concentration | 4.1 Trigger 5 | 8.0 |
| `EX-STALE-006` | Aged Unaudited | 4.1 Trigger 6 | 3.0 |
| `EX-MACK-007` | Missing Maintainer Ack | 4.1 Trigger 7 | 4.0 |
| `EX-BOTTLENECK-008` | Reviewer Bottleneck | 4.1 Trigger 8 | 5.0 |
| `EX-RISK-009` | Compound Risk Flags | 4.1 Trigger 9 | 6.0 |
| `EX-REGRESS-010` | Evidence Regression | 4.1 Trigger 10 | 7.0 |