Elnor Repo Reader

DOC23_ADDENDA_B_ADJUDICATION_CARD_REVIEW.md

Active Working and Red Team/DOC23 Working/DOC23 Red Teaming/Add B Adj Card Review 5.29/DOC23_ADDENDA_B_ADJUDICATION_CARD_REVIEW.md

Generated 2026-06-09T01:23:58.539Z from commit dbaa25962edc11ab30e8d4ca1715f9ae5bf77331. Worktree: clean.

Open text page · Open raw txt · Open path URL

# DOC23 Addenda B — Independent Review of the Consolidated Adjudication Card

**What this is.** A single, self-contained independent review of `DOC23_ADDENDA_B_RT_ADJUDICATION_CARD_CONSOLIDATED.md` (126 adjudicated items deduped from ~228 raw reviewer assertions). It consolidates three passes: (1) a per-row correctness review, (2) a dedup-completeness coverage matrix against the source review, and (3) a deeper cross-row interaction/redundancy pass. Findings are **verified against the live operative specs**, not against the card's line anchors.

**Verified against (GitHub `wbrody/Elnor-Specs`, branch `main`, `Current Specs/DOC23/DOC23 Addenda B/`):** Outcome Evaluator+Revisor V3.3.1; Feedback Delivery V1.0.1; Source Workspace V1.0.1; Task Forum + Run Board V1.0.1; Evaluation Common Contracts V1.1.1; Addenda B Core R0.7.1; plus base Task System Modular Architecture R3.1. Source review cross-walked: `Active Working and Red Team/DOC23 Working/DOC23 Red Teaming/DOC 23 Add B RT Reviews 1 (5.28).md`.

**Convention note.** Section anchors `§x` are to the operative specs unless prefixed "card." "RT" = the source review. Schemas in `ts` blocks are proposed spec inserts. Where a finding is a defect **in the card's fix** (vs in the spec), it is marked **[CARD BUG]**; where it is a confirmed defect in the spec, **[SPEC BUG]**.

---

## 0. Executive summary

The package is fundamentally sound and worth shipping into an R0.4 amendment — but verification changes several dispositions and surfaces a set of fix-bugs the reviewers and the card missed, most of which only appear when you look **across** rows.

The single biggest theme: the card's own disciplines — the TypeOwnerRegistry (A-09), governance envelopes, and the finding match-key (A-26) — are applied **locally** where they need to be applied **exhaustively**. Run as global sweeps they would mechanically catch most of the new bugs below.

**Treat as build-blockers:**
- **A-01 / A-05 — lossy basis collapse.** Folding `authority_basis` into `assurance_basis` silently loses the `user_instruction` and `saved_criteria` blocking bases (neither exists in `AssuranceBasis`). Keep both arrays.
- **A-01 — `FeedbackFindingView` strips governance.** The projection that reaches UI/forum/delivery drops `taint_class`/`matter_id`/`privileged`/`data_class`, re-opening exactly the laundering paths D-01 and D-24 close.
- **A-01 — no migration** for a `schema_version 1 → "2.0"` change (basis singular→array, confidence string→numeric, new required `finding_kind`).

**Dispositions that should flip:**
- **A-11 → DECLINED** — the enum already exists (§6.16.1) and the card's proposed value (`cross_calibration`) is wrong (real value: `calibration`).
- **B-25 → DECLINED** — `depends_on_step_ids` already exists on `RevisionPlanStepBase` (§7.5) and §6.11.1 already does cycle detection; the card's proposed minimal base would also delete ~8 real fields.
- **B-15 → DECLINED / OP-A-only** — `RoomKind.plan_review` is registered by **DOC12** (`OBL-DOC12-FORUM-01`); the card's fix adds it to the wrong registry.

**Partial misreads (real but mis-scoped/mis-framed):** **B-03** (artifact path already protected; real gap is the Source Workspace write path), **B-24** (a loop breaker already exists at §6.7.3; this is a refinement, not a void), **D-04** (the "remove tier 0" sub-fix deletes a load-bearing tier).

**Dedup completeness:** essentially complete. ~227 raw findings → 126 adjudicated; the three named failure points (ChatGPT Audit Addendum, Grok §4/§5, Gemini memory) are all covered. One true orphan (**Claude D19**), one cited-but-unaddressed (**Claude D20**), three thin spots (**Grok §3.3 / §5.7 / §5.9**), one citation typo (**B-24 is Grok §4.9, not §4.10**).

---

## 1. Disposition changes at a glance

The card's default is "accept all except where marked." This is the exception list — every row where I recommend a change to the disposition or the fix. Rows not listed here are confirmed sound.

| Row | Card disposition | Recommended change | Why (one line) |
|---|---|---|---|
| A-01 | ACCEPT | ACCEPT W/ MODS | Keep both `assurance_basis` + `authority_basis`; name `FindingKind`; add migration; add governance to the view. |
| A-02 | ACCEPT | ACCEPT → **elevate CRITICAL** | Breaks Pattern C read path; reuse bundle's `EvaluatedTarget`/`EvaluationBasis`; reconcile with existing `target_*` fields. |
| A-04 | ACCEPT | ACCEPT W/ MODS | Default policy is self-contradictory (`judge_can_override:false` + an override allowlist). |
| A-05 | ACCEPT W/ MODS | (reinforced) | Compute `blocking_authority_satisfied` from `authority_basis`, not `assurance_basis`. |
| A-07 | ACCEPT | ACCEPT W/ MODS | `IndeterminateCause` is Addenda-A-owned (R203) → import, don't redefine; `EvaluationLimitationKind` already exists (§5.4.2) → reuse; collapse the two near-duplicate enums (architect decision). |
| A-11 | ACCEPT | **DECLINED** | Enum exists (§6.16.1); proposed value `cross_calibration` is wrong (`calibration`). |
| A-12 | ACCEPT (authored) | ACCEPT W/ MODS | Uses §5.13 `EvaluationVerdict` (a per-lane struct) where it means the 4-value outcome enum; `defer`/`request_changes` shouldn't force a verdict. |
| A-16 | ACCEPT (CRITICAL) | (keep) + fix | Whitelist the sanctioned `DirectFixStep` path; note advisory context is still *injected* (taint applies). |
| A-23 | ACCEPT W/ MODS | re-anchor | Fields are **Source Workspace §4.2/§4**, not FD §3/§5; rename the payload field. |
| A-26 | ACCEPT | (refine) | Pin `FindingMatchKey` to a stable artifact id (reconcile with D-18); reuse §6.2 `FailureKind`. |
| B-02 | ACCEPT | (refine) | Idempotency key collides with B-27's regenerate loop; add `attempt_seq`/`prior_output_hash`. |
| B-03 | ACCEPT ⚠verify | re-scope | Artifact path already has `ArtifactMutationPrecondition`+§11.20; real gap is the SW write API (tie to D-16). |
| B-08 | ACCEPT | (rename) | `ExecutionFailureKind` collides in name with §6.2 `FailureKind` and §11.17 `WorkspaceWriteFailureKind`. |
| B-15 | ACCEPT ⚠verify | **DECLINED / OP-A-only** | DOC12 registers `plan_review` (`OBL-DOC12-FORUM-01`); fix targets wrong registry. |
| B-16 | ACCEPT-AS-FIX | (modify) | Retain final `plan_id lexicographic` tiebreak; resolve risk-direction contradiction; drop `created_at`. |
| B-24 | ACCEPT (CRITICAL) | (re-frame) | Refinement of existing §6.7.1/§6.7.3, not a void; unify with D16/B-05/B-27; add `needs_verification` route. |
| B-25 | ACCEPT (CRITICAL) | **DECLINED** | `depends_on_step_ids` exists (§7.5); §6.11.1 cycle detection exists; proposed base deletes real fields. |
| C-03 | ACCEPT-AS-FIX | (complete) | Also remove `predicted_pre_hash` from the LLM contract; patch §11.20 RULE + prose. |
| D-01 | ACCEPT | (complete) | Map covers 11/15 `source_kind`s; add the 4 missing. |
| D-04 | ACCEPT | (modify) | **Keep tier 0** (`lookup_receipt`, load-bearing); reconcile the actual contradiction instead. |
| D-13 | ACCEPT | **elevate** | Cross-run guidance is an injection-into-prompts path; route through governance + the contested check. |
| D-16 | ACCEPT ⚠verify | (confirmed) | Real gap; already tracked as `OBL-ADDB-SW-V12-WORKSPACE-API-01`; home for B-03's precondition. |
| D-24 | ACCEPT | (confirmed) | Real privilege gap; anchor is **Task Forum §5.3/§5.4**. |

**New rows to add** (cross-cutting, see §6): a single `GovernanceEnvelope` mixin; a `RevisorTerminationLedger`; an exhaustive TypeOwnerRegistry sweep; a phantom-field lint.

---

## 2. The nine ⚠verify rows — verification results

The card flagged nine current-state claims as unconfirmed. Verified against the text:

| Row | Claim | Result |
|---|---|---|
| **A-02** | `evaluated_target`/`evaluation_basis` live on the bundle, not the envelope | **CONFIRMED.** Both fields are on `EvaluationFeedbackBundle` (FD §2, `evaluated_target: EvaluatedTarget`, `evaluation_basis: EvaluationBasis`). The envelope (COMMON §3.1) has `target_artifact_ref`/`target_artifact_version_ref`/`target_scope_ref`/`evaluation_snapshot_ref`/`criterion_lineage` instead. V3.3.1 §5.18 has the Pattern C Judge read the two missing names off the envelope. |
| **A-05** | FD has `authority_basis: EvaluationAuthorityBasis[]`; §3.4 rule 2 makes it the blocker test | **CONFIRMED.** FD §3.3 carries `authority_basis: EvaluationAuthorityBasis[]` (9 values); §3.4 rule 2: a `severity:"blocking"` finding MUST have ≥1 of `{deterministic_check, source_reference, tool_verification, user_instruction, saved_criteria}`. |
| **A-11** | `LearningMode` referenced, never enumerated | **FALSE.** Defined at §6.16.1 as `production \| signal_generation \| calibration`, with behaviors at §6.16.2. Card's proposed `cross_calibration` is wrong. → **DECLINE.** |
| **A-23** | `ApplicabilityScope.authority_level` vs `domain_payload.authority_level` conflict in FD | **WRONG ANCHOR.** Both fields are in **Source Workspace §4.2 / §4**, not FD. `ApplicabilityScope.authority_level: "binding"\|"persuasive"\|"advisory"\|"unknown"`; `domain_payload.authority_level` is a separate domain enum. (A *third* `authority_level` exists in Core — directive strength.) |
| **B-03** | No write precondition on Source Workspace direct fixes | **PARTIAL.** The artifact `direct_fix` path is already protected: §7.5 `preconditions[]` (incl. `live_artifact_hash_matches_snapshot`), §11.20 live-edit hash check, ln-4007 `ArtifactMutationPrecondition`. The genuine gap is the **Source Workspace record** write path (no concurrency machinery in SW V1.0.1). Gemini's "none exists" is wrong for the artifact path. |
| **B-15** | `RoomKind.plan_review` never registered | **WRONG OWNER.** Registered by **DOC12** (Forum V1.0.1: "DOC12 owns canonical room registrations… `RoomKind.plan_review` per V3.3 §14.9"; `OBL-DOC12-FORUM-01`). |
| **B-16** | §11.9 tie-breaker rule 4 = wall-clock `created_at` | **CONFIRMED.** §11.9.4 rules 1-5 end `4. RevisionPlan.created_at ascending; 5. plan_id lexicographic`. |
| **C-03** | §7.2.1 emits `predicted_post_hash` as an LLM output | **CONFIRMED.** §7.2.1 `rolling_hash_chain` carries `predicted_pre_hash` + `predicted_post_hash`; §11.20 RULE expects Step N+1 to validate against the predicted hash. |
| **D-16** | Workspace API ops referenced but undefined | **CONFIRMED.** V3.3.1 §12 has only "basic" ops; SW records the full surface as the open obligation `OBL-ADDB-SW-V12-WORKSPACE-API-01`. |

---

## 3. Per-row findings (detailed, with schema/anchor fixes)

Each entry is the authoritative consolidated finding for that row (first-pass + deeper-dive combined).

### A-01 — Two incompatible `EvaluationFinding` schemas — CONFIRMED; unify, but the fix has bugs

Verified incompatibility:
- **V3.3.1 §5.7**: `finding_text`, `severity(4)`, `state: FindingState`, **`basis: AssuranceBasis`** (singular), `target_artifact_ref`, `target_version_ref`, `taint_class`, `confidence: "low"|"medium"|"high"`, `schema_version: 1`.
- **FD §3.3**: `finding_kind(12)`, **`authority_basis: EvaluationAuthorityBasis[]`**, `lifecycle_state: EvaluationFindingLifecycleState`, `target_criterion_id?`, `affected_claim_refs?`, `confidence: number`, `based_on_board_digest_ref?`, `schema_version: "1.0"`.

The unify (single canonical finding + thin view) is the right call. Three fix bugs:

**(a) [CARD BUG] The basis collapse is lossy.** A-05 deletes `authority_basis` and computes `blocking_authority_satisfied` from `assurance_basis + severity`. But FD §3.4 rule 2's blocking-eligible set `{deterministic_check, source_reference, tool_verification, user_instruction, saved_criteria}` barely overlaps `AssuranceBasis` (`{deterministic_check, structured_validation, source_verified_external, claim_grounded_internal, trace_verified, coverage_mapping, comparative_judge, historical_baseline, statistical_threshold, llm_expert_judgment, specialist_panel_judgment, policy_backed}`). **`user_instruction` and `saved_criteria` have no `AssuranceBasis` member**, so a finding that blocks because the user said so cannot express its basis and the boolean wrongly reads false. Keep both arrays (A-01's own rationale concedes they are "not redundant").

**(b) [CARD BUG] The view strips governance.** `FeedbackFindingView` (the shape FD/forum/UI consume) carries no `taint_class`/`data_class`/`matter_id`/`privileged`. That re-opens the D-01/D-24 laundering paths.

**(c) [CARD BUG] No migration / `FindingKind` unnamed.** `schema_version 1 → "2.0"` changes shape (singular→array basis, string→numeric confidence, new required `finding_kind`), and `FindingKind` isn't a named type. V3.3.1 §5.7 findings carry no `finding_kind` at all.

Consolidated fix:
```ts
// Common Contracts §4.2A
type FindingKind = "criterion_failed"|"missing_requirement"|"unsupported_assertion"|"source_mismatch"
  |"format_violation"|"style_violation"|"incomplete_coverage"|"research_gap"
  |"subjective_quality_issue"|"tool_verified_failure"|"process_observation"|"custom";   // = FD §3.3 set

interface EvaluationFinding {
  finding_id: string; result_id: string;
  finding_kind: FindingKind; finding_text: string; explanation: string;
  severity: "low"|"medium"|"high"|"blocking";
  state: FindingState;                                  // unified 12-value set (see below)
  assurance_basis: AssuranceBasis[];                   // why-trustworthy (V3.3.1)
  authority_basis: EvaluationAuthorityBasis[];         // KEEP — what authorizes a hard block (FD §3.4 r2)
  confidence_score: number;                            // 0..1 (replaces low|med|high)
  confidence_basis: ConfidenceBasis[]; confidence_explanation: string;
  target_artifact_ref?: StorageRef; target_version_ref?: StorageRef;
  target_scope_ref?: ArtifactScopeRef; target_criterion_id?: string; affected_claim_refs?: string[];
  evidence_refs: StorageRef[]; verification_record_refs: StorageRef[]; supporting_material_snapshot_refs: StorageRef[];
  based_on_artifact_version_ref?: StorageRef;
  based_on_artifact_version_absent_reason?: "non_artifact_target"|"human_review_no_artifact"|"process_observation";
  based_on_source_workspace_snapshot_ref?: StorageRef; based_on_board_digest_ref?: StorageRef;
  // governance (GovernanceEnvelope mixin — see §6):
  taint_class: TaintClass; data_class: "public"|"internal"|"privileged"|"local_only";
  matter_id?: string; privileged: boolean; policy_decision_refs: PolicyEvaluationRef[];
  evaluation_target_state: "current_artifact"|"candidate_artifact"|"sandboxed_candidate";
  candidate_artifact_version_ref?: CandidateArtifactVersionRef; promotion_policy_ref?: StorageRef;
  match_key: FindingMatchKey; superseded_by_finding_id?: string;
  expires_at?: ISO8601; created_at: ISO8601; schema_version: "2.0"; migration_version: number;
}

interface FeedbackFindingView {
  finding_id: string; source_evaluation_finding_ref: string;
  display_summary: string; display_explanation: string;
  finding_kind: FindingKind; severity: "low"|"medium"|"high"|"blocking";
  lifecycle_state: FindingState; blocking_authority_satisfied: boolean;
  routed_action_refs: StorageRef[];
  // REQUIRED governance passthrough (copied, never recomputed):
  taint_class: TaintClass; data_class: "public"|"internal"|"privileged"|"local_only";
  matter_id?: string; privileged: boolean;
  schema_version: "1.1";
}

// blocking_authority_satisfied (faithful to FD §3.4 rule 2):
const BLOCKING_BASES: EvaluationAuthorityBasis[] =
  ["deterministic_check","source_reference","tool_verification","user_instruction","saved_criteria"];
//   = (severity !== "blocking") || authority_basis.some(b => BLOCKING_BASES.includes(b))

// validation.blocking_finding_without_authority (error): severity==="blocking" && !blocking_authority_satisfied
// validation.view_drops_governance_fields (error): view governance ≠ source governance
// validation.finding_v1_unmigrated (error): persisted v1 read without migration_version

// Migration v1 → v2.0:
//   basis (singular) → assurance_basis: [basis]
//   confidence "low"|"medium"|"high" → confidence_score 0.3|0.6|0.9
//   finding_kind ← classify from finding_text, default "custom"
//   authority_basis ← []   (legacy v1 had none)
```
Unified `FindingState` must be the full 12 V3.3.1 values (`proposed, active, contested, resolved, superseded_by_revision, superseded_by_source_change, tool_verified, human_verified, user_approved, rejected_by_user, dismissed, unrecoverable`); FD's 7-value `EvaluationFindingLifecycleState` is the subset that maps onto it.

### A-02 — Pattern C reads fields not on the envelope — CONFIRMED; elevate to CRITICAL

The source review rates this CRITICAL; the card lists it plain ACCEPT. It breaks the headline Pattern C read path, so **elevate**. Fix nuances: (1) reuse the bundle's existing `EvaluatedTarget`/`EvaluationBasis` types rather than minting new `EvaluatedTargetRef`/`EvaluationBasisRef`; (2) the envelope already encodes "what was evaluated" via `target_artifact_ref`+`target_scope_ref` and "basis" via `evaluation_snapshot_ref`+`criterion_lineage` — define the two fields as **typed projections over those existing fields** (or fix V3.3.1 §5.18 to read the fields that exist), to avoid a third overlapping representation.

### A-04 — Pattern C route-resolution policy — ACCEPT W/ MODS

[CARD BUG] The shipped default contradicts itself: `judge_can_override_evaluator: false` makes `override_allowed_only_for_finding_states` dead config. Collapse to one representation:
```ts
// drop the boolean; the allowlist IS the policy:
judge_override_allowed_for_finding_states: FindingState[];   // [] = never overrides
// a Judge numeric pass cannot clear an Evaluator blocking finding unless that finding's state ∈ this set.
```

### A-06 — State enum count & mapping skew — CONFIRMED

`OutcomeEvaluationState` has 15 members; COMMON §3.1 calls it "14-value"; §3.2's verdict mapping omits `evaluating`; `max_iterations_reached` is referenced (§5.7-area transition table) but absent from the enum. The fix (split runtime vs disposition states, add `max_iterations_reached`, one normative `OUTCOME_STATE_MATRIX`) is sound. See §3-A07/§6 for pruning the broader enum thicket.

### A-07 — Indeterminate/limitation taxonomy — ACCEPT W/ MODS (owner + redundancy)

[CARD BUG] Two types the card proposes to "add" already exist or are owned elsewhere:
- **`EvaluationLimitationKind`** is defined in V3.3.1 §5.4.2 (the P2 trust-vs-limitation split). A-07 must **reuse §5.4.2**, not fork a parallel 7-value enum (diff the card's list against §5.4.2 and reconcile).
- **`IndeterminateCause`** is referenced in COMMON §3.1 as `// V4 R203 taxonomy` — i.e., **owned by Addenda A (R203)**. Defining an 11-value version inside Common Contracts is an owner-boundary violation (the same dual-definition disease A-01 is killing). **Import** it from the Addenda A owner.

Deeper: `IndeterminateCause` (A-side) and `EvaluationLimitationKind` (B-side §5.4.2) are ~80% the same axis ("why no verdict") with different labels/cardinality (e.g., `missing_source`≈`source_unavailable`, `stale_source`≈`stale_evidence`, `policy_block`≈`policy_blocked`, `human_judgment_required`≈`human_judgment_needed`). The card's `LIMITATION_STATE_MAPPING` institutionalizes the redundancy. **Architect decision:** collapse them into one canonical "no-verdict-reason" enum owned once and imported by both addenda, with `IndeterminateCause` retired or aliased. Keep only `SubstantiveVerdictStatus` + the mapping as genuinely new (and prefer making `SubstantiveVerdictStatus` a derived column of `OUTCOME_STATE_MATRIX` rather than a free-standing enum).

### A-11 — `LearningMode` — DECLINE

Defined at §6.16.1: `production | signal_generation | calibration` (behaviors at §6.16.2). The card's `cross_calibration` is wrong; applying the fix verbatim would redeclare the enum and break §6.16.2 + the `cross_model_applicability` references. Residual: if §15 references `LearningMode` without pointing to §6.16.1, add the cross-reference. The E-07 behavior deferral stands.

### A-12 — `HumanOutcomeFeedbackEvent` (card-authored) — ACCEPT W/ MODS

[CARD BUG] `overridden_verdict?: EvaluationVerdict` / `resulting_verdict: EvaluationVerdict` references the §5.13 `EvaluationVerdict` **per-lane struct** (`{verdict_id, lane_id, …, result: "lane_passed"|…}`), but a human override is an outcome-level verdict. The intended enum is the 4-value one currently inline-and-unnamed on the envelope.
```ts
// Common Contracts §3 — NAME the inline envelope enum:
type OutcomeVerdict = "passed"|"failed"|"indeterminate"|"not_applicable";
// A-12 uses OutcomeVerdict (NOT §5.13 EvaluationVerdict):
//   overridden_verdict?: OutcomeVerdict; resulting_verdict?: OutcomeVerdict;
// decision ∈ {request_changes, defer} ⇒ resulting_verdict forbidden (routing actions, not verdicts).
// validation.human_feedback_verdict_misuse
```

### A-16 — Direct repair bypasses `revision_in` — CONFIRMED CRITICAL; fix has an interaction bug

FD §7.2 "Channel 2 — Direct repair wiring" literally routes `repair_instruction_out → DraftRevision.instruction_in`, `format_repair_out → FormatChecker.data_in`, `feedback_bundle_out → RevisionModule.context_in`, bypassing the §11.x `ArtifactMutationPrecondition` + `revision_in` capability chain. The fix is right, but:

[CARD BUG] V3.3.1 has a **sanctioned** artifact-mutating path that is *not* `revision_in` — the `DirectFixStep` (§7.5) with `target_port:"none_direct_fix"`, class-gated by §10, guarded by `ArtifactMutationPrecondition`. A-16's "only `revision_in` or `revision_compatible`" rule would forbid it. Whitelist it:
```ts
// validation.repair_routed_to_non_revision_port (error) UNLESS the write is:
//   (a) port == "revision_in", OR
//   (b) PortRevisionEligibility.revision_compatible === true WITH module_revision_capability_ref, OR
//   (c) a DirectFixStep (target_port == "none_direct_fix") whose direct_fix_class ∈ direct_fix_allowed_classes
//       AND carrying a satisfied ArtifactMutationPrecondition (§7.5/§11.20)
// All other instruction_in/data_in/context_in wiring = ADVISORY CONTEXT ONLY (no mutation).
```
Note (connects to D-01): "advisory context" is still **rendered into prompts** by DOC15/CIL. A-16 stops mutation, not injection — tainted advisory context must still pass the D-01 sanitization/taint rule before it reaches a prompt.

### A-17 / A-18 / A-19 / A-20 / A-21 — confirmed sound (with one note)

- **A-17** (Revisor is the planner, not a `revision_in` target) — CONFIRMED (FD ln 431 vs V3.3.1 §9). Sound.
- **A-18** (feedback-bundle emission contradicts itself) — sound; the emission matrix + absence-reason is the right shape.
- **A-19** (`proposed` has no negative exit) — CONFIRMED: §5.7.1 has only `proposed → active`; add `proposed → dismissed` + auto-dismiss at termination. Sound.
- **A-20** (`unanchored_llm_judgment` ack has no field) — sound.
- **A-21** (optional fields required by invariants) — sound, but the validation can't fire deterministically without a `finding_kind → targets_artifact` map; specify which `FindingKind` values target an artifact so `validation.artifact_targeted_finding_missing_version_ref` is decidable.

### A-23 — re-anchor

Fields are **Source Workspace §4.2** (`ApplicabilityScope.authority_level`) + **§4** (`domain_payload.authority_level`), not FD §3/§5. They're different vocabularies (legal weight vs domain rule strength), so a "conflict warning on differing values" is semantically odd; prefer **renaming** the payload field (`domain_payload.domain_authority_level`) over asserting precedence between incomparable scales. (A third `authority_level` in Core is directive strength — note in the TypeOwnerRegistry pass.)

### A-26 — `FindingMatchKey` — refine (two interactions)

[CARD BUG/interaction] (1) `failure_kind: FailureKind` should explicitly reuse the existing §6.2 `FailureKind` (see B-08 naming note). (2) Keying on `target_scope_ref: ArtifactScopeRef` can be version-sensitive, defeating D-18's stable-id fix on the very path that consumes the match key. Pin it:
```ts
interface FindingMatchKey {
  failure_kind: FailureKind;                 // reuse §6.2 FailureKind
  stable_artifact_id?: string;               // stable identity, not a versioned ArtifactScopeRef
  target_section_path?: string;              // version-independent section/anchor
  finding_summary_hash: string; normalized_finding_text_hash: string;
  criterion_id?: string; evidence_signature_hash?: string;
  schema_version: "1.0";
}
```

### A-27 — confirmed sound

`EvaluationSnapshot.source_workspace_head_hashes: Record<ArtifactRef,string>` is genuinely wrong-typed (the snapshotted values are workspace heads/records/sets, not artifact refs). The `SourceWorkspaceSnapshotHashSet` replacement is correct and is the concrete type B-03's precondition compares against.

### B-01 / B-02 / B-04 / B-05 / B-06 / B-07 / B-08 — runtime cluster

- **B-01** (unified `RevisionExecutionLifecycle` FSM) — sound and high-value.
- **B-02** (canonical idempotency key) — sound **but** [CARD BUG/interaction] collides with B-27: `attempt_class:"regenerate"` alone doesn't distinguish successive regenerations, so the second is deduplicated and B-27's loop can't progress. Add discriminators:
```ts
interface StepIdempotencyKey {
  run_id: string; plan_id: string; step_id: string; step_kind: StepKind;
  target_ref_hash: string; input_payload_hash: string;
  attempt_class: "first"|"retry"|"regenerate";
  attempt_seq: number;                 // monotonic per (step_id, attempt_class); REQUIRED for regenerate
  prior_output_hash?: string;          // the B-27 hash being escaped; folds the two fixes together
}
```
- **B-04** (rolling hash unsafe under parallel steps) — sound; correctly distinct from C-03.
- **B-05** (cascade convergence + duplicated rule) — sound; see §6 for unifying it with the other loop guards.
- **B-06** (dependency cycles + `pending_dependency` deadlock) — sound.
- **B-07** (`ParallelBatchFinalizationReceipt`) — sound.
- **B-08** (failure taxonomy) — sound **but** [CARD BUG] `ExecutionFailureKind` collides in name with §6.2 `FailureKind` (finding classification) and §11.17 `WorkspaceWriteFailureKind`. Rename to `StepExecutionFailureKind` and register all three (distinct scopes) in the TypeOwnerRegistry.

### B-09 / B-10 / B-11 / B-12 / B-13 / B-14 — confirmed sound

`B-09` candidate-vs-head split + `SideEffectIntentCandidate`; `B-10` cancel + Hard-Call blocking scope; `B-11` skip protocol; `B-12` policy-freshness fields; `B-13` `ResearchNeedLease`; `B-14` forum deadlock breaker — all sound. (B-14 cites Claude D20, whose actual substance — task-scoped forum — it does not address; see §4.)

### B-15 — DECLINE / OP-A-only

`plan_review` is registered by DOC12 (`OBL-DOC12-FORUM-01`); the Forum sub-addendum correctly defers via `room_kind?: string`. The card's "add to the Forum `RoomKind` registry" is wrong-owner. Keep only the existing DOC12 obligation; verify DOC12 registers it.

### B-16 — modify (incomplete + contradictory)

§11.9.4 currently: `1 required_for_overall_pass · 2 is_high_stakes · 3 priority asc · 4 created_at asc · 5 plan_id lexicographic`. Gemini's verbatim patch [CARD BUG] (a) drops rule 5, removing the only guaranteed total order → full ties go nondeterministic again, and (b) "`plan_risk_score descending` (safer first)" is self-contradictory. Corrected:
```
RULE concurrency_tie_breaker (CORRECTED):
  1. OutcomeDependencySpec.required_for_overall_pass = true > false
  2. EvaluationOutcomeDefinition.is_high_stakes = true > false
  3. EvaluationOutcomeDefinition.priority ascending
  4. RevisionCostEstimate.total_tokens ascending     (smaller/faster releases the lock sooner)
  5. plan_id lexicographic                            ← RETAIN (deterministic total order)
// Drop wall-clock created_at (the real Gemini defect). Drop plan_risk_score from the tiebreak entirely:
//   rules 1-2 already encode stakes, and ordering ties by risk starves small safe fixes.
```

### B-17 — sound (with a partial-coverage note)

The `instruction_in` discriminator / required typed ports fix is sound. Note it covers only the port-typing half of Grok §3.3; the broader "one document owns the end-to-end feedback→prompt data-flow + responsibility matrix" recommendation is not a distinct row (see §4).

### B-18 – B-23 — confirmed sound

`HardRevisionCall.options` min-length + default pair (B-18); `hard_call_resolved` producer (B-19); success-condition-5 quiescence gate (B-20); emit-after-persist (B-21); Pattern C invocation budget (B-22); routing exclusivity/idempotency (B-23) — all sound. B-20's quiescence gate should read the same termination accounting as §6 below.

### B-24 — Revisor sufficiency — re-frame (refinement, not a void)

[CARD BUG/framing] §6.7 already has: §6.7.1 (insufficient → emit `needs_verification|needs_information|needs_human_judgment|unable_to_evaluate`), §6.7.2 (seven success conditions), §6.7.3 (loop breaker `repeated_insufficiency_count`, default N=3 from `RevisorConfig.consecutive_insufficient_limit`), plus D16's `still_failing_same_reason` counter. The genuine gap is the **predicate** for "this attempt was insufficient." Your four triggers are that predicate — anchor them at §6.7.1/§6.7.3 and unify with D16/B-05/B-27 (see §6). Refined:
```ts
interface SufficiencyDetectionResult {
  outcome_id: string; no_sufficient_procedure: boolean;
  triggered_by: Array<
    | "no_capability_covers_outcome"
    | "max_attempts_without_score_improvement"     // ΔCalibratedScore < ε over window
    | "all_candidate_procedures_exhausted"
    | "evidence_insufficient_to_proceed">;
  attempts_made: number; best_score_seen?: CalibratedScore;
  recommended_route: "needs_human_judgment"|"unable_to_evaluate"|"needs_information"|"needs_verification";  // +needs_verification
  schema_version: "1.0";
}
// Feeds §6.7.3 repeated_insufficiency_count (it is the predicate that increments it), does NOT replace it.
// Per-attempt: emit the §6.7.1 state. Hard Call only AFTER the §6.7.3 threshold (per §6.8).
// validation.sufficiency_protocol_without_predicate (error): §6.7.3 increments without a SufficiencyDetectionResult.
```

### B-25 — DECLINE (misread + destructive)

`RevisionPlanStepBase` (§7.5) already has `depends_on_step_ids: string[]`; §6.11.1 does topological sort **with cycle detection**; §6.11.3 states steps form a DAG. The premise (no dependency field / DAG inexpressible) is false. The card's proposed 6-field base would also delete the real base's `step_order, affected_artifact_refs, affected_outcome_ids, source_repair_depth, idempotency_key, preconditions[], expected_output, on_failure, human_gate_recommended, goal_impact_assessment, expected_pre_hash, produced_post_hash`. Residual: confirm §11.3's [P1] lint and B-04's sequencing walk `depends_on_step_ids` (a one-line verification, not a CRITICAL gap). **B-26's `revalidation_trigger → revalidation_policy` rename is the one legitimate change here — express it as a field rename on the existing base, not a base replacement.**

### B-26 / B-27 — sound (with the B-02 interaction)

B-26 (single `revalidation_policy` field) sound — apply as a rename on the existing `RevisionPlanStepBase` (replaces `revalidation_trigger`). B-27 (regenerate identical-output guard) sound — fold its `previous_attempt_hashes` into the B-02 key (above) so it actually advances.

### C-01 / C-02 / C-04 / C-05 / C-06 / C-07 / C-08 / C-09 / C-10 — math cluster

All sound. C-01 (`FormulaRegistry` + `CalibratedScore`) is the structural keystone and correctly subsumes ~15 "no formula" findings. Note C-04's `advice_regression_rate` schema is also where Grok §5.7 ("metrics named but no schema records them") partly lands — state whether the full metric-set recording schema ships now or defers to E-06.

### C-03 — complete the edges

Sound (ACCEPT-AS-FIX). [Completeness] §7.2.1 carries **both** `predicted_pre_hash` and `predicted_post_hash`; remove both from the LLM output contract (the LLM can pass through a known snapshot hash but should not be contracted to *emit* a SHA). Also patch the §11.20 RULE `rolling_hash_chain_valid` (and the "Step N+1 validates against predicted hash" prose) + the `validation.rolling_hash_chain_broken/mismatch` codes to compare the dispatcher-computed post-hash. The §7.5 base's `expected_pre_hash?/produced_post_hash?` are the runtime-populated counterparts and stay.

### D-01 — complete the map

Sound (compliance blocker). [CARD BUG/completeness] The default `source_kind → taint_class` map covers 11 of the 15 `source_kind` members. Add the missing four (`TaintClass` values verified to exist):
```ts
//   financial_filing | expert_report | technical_doc  → external_authority_trusted
//   custom                                            → unclassified (require taint_class_override before use)
// Else validation.source_kind_taint_unmapped fires for these four.
```
The transitive-taint rule, `SanitizationNode`, and `TaintAggregationPolicy(max_taint)` are correct and high-value.

### D-02 / D-03 / D-05 / D-06 / D-07 / D-08 / D-09 / D-10 / D-11 / D-12 / D-13 — confirmed sound (notes)

All sound. Two elevations/notes:
- **D-09** (passive board auto-publishes everything) — for privileged matters this is adjacent to D-24; pair it under the privilege-firewall heading.
- **D-13** (cross-run RunGuidance) — **elevate.** It's an injection-into-future-prompts path (the never-checked `contested` state + the cross-run vector). Its fix should route through the governance/taint check (D-01) and the contested check, not just durable persistence.

### D-04 — keep tier 0 (modify)

[CARD BUG] "Remove `0` from the tier domain" deletes a load-bearing tier. Verified: tier 0 = `lookup_receipt` ("receipt records only"); it is a member of `SourceDocumentationMode`; `SourceRecord.tier: 0|1|2|3`; with examples ("Check today's stock price → tier 0"). The real "contradiction" is a prose/table spot that omits tier 0 or lists 1-3 while the schema says 0-3.
```
KEEP SourceRecord.tier ∈ {0,1,2,3}. tier 0 = lookup_receipt (receipt-only/ephemeral).
Reconcile the documentation-mode↔tier table and any "tiers 1-3" prose to include tier 0.
Align SourceTierTransition.from_tier/to_tier to the literal union 0|1|2|3 (not bare `number`).
```
The rest of D-04 (persist transitions, align verification states, gate demotion by access tier) is sound.

### D-14 / D-15 / D-17 / D-18 / D-19 / D-20 / D-21 / D-22 / D-23 — confirmed sound

`D-14` injection-slot/command-registry/compact-cards (correctly moves the DOC24-owned capability out of Core); `D-15` sub-agent plurality/fallback/5-points; `D-17` anchor/hash hygiene; `D-18` stable-key repeated-failure (reconcile with A-26 above); `D-19` per-module cost field; `D-20` `requires_background_progress` split; `D-21`…(card `D-21` = overload split) sound; `D-22` compat/anchor hygiene; `D-23` dispatch-expectation receipts — all sound.

### D-16 — confirmed gap

Define the workspace API (`create_workspace, read_record, append_record, update_record, acquire_record_lock`, each `→ command_ref + idempotency_key` per D-14), reference the existing `OBL-ADDB-SW-V12-WORKSPACE-API-01`, and make it the home for B-03's `WorkspaceWritePrecondition`:
```ts
interface WorkspaceWritePrecondition {
  target_record_ref: StorageRef; expected_snapshot_hash: string;   // SourceWorkspaceSnapshotHashSet member (A-27)
  on_mismatch: "abort_and_reevaluate"|"queue_behind_lock"|"fail"; lock_mode: "optimistic_snapshot_hash"|"pessimistic_write_lock";
}
// validation.workspace_record_write_without_precondition (error). Artifact path keeps ArtifactMutationPrecondition.
```

### D-24 — confirmed (privilege firewall)

Forum §5.3 carries `matter_id?` but §5.4 visibility resolution ignores it. The fix is correct and important. Anchor is **Task Forum §5.3/§5.4**.
```
A post with matter_id == X is visible ONLY to readers under matter_id == X, regardless of `visibility`;
`visibility` scopes WITHIN the matter. privileged:true is always matter-scoped at every access tier.
validation.forum_post_cross_matter_leak (error).
```

### §E (held) / §F (declined) — concur

The Phase-B deferral set and the four declines are appropriately scoped. One note: E-13's forward-compat learning-scope fields (`principal_id`, `learning_scope`, `share_eligibility`, `scope_inference_basis`) are correctly addable-now/behavior-deferred — and they should reuse the same `GovernanceEnvelope` mixin (§6) so networked-learning scope and matter/privilege travel together.

### §G — Professional Reliance Layer (the deliberate feature) — works, with gaps

The artifacts are coherent and implementable and integrate cleanly. Underspecified/buggy points:
- **G-06 `TaskReliancePacket`** has **no `reliance_status` derivation rule**. Specify: `not_safe_to_rely` if any unresolved limitation ∈ `{policy_blocked, unable_to_ground_claim}` or any open blocking finding; `human_review_required` if any pending Hard Call; `rely_with_limitations` if `unresolved_limitations` non-empty but non-fatal; else `safe_to_rely_within_scope`. Add `validation.reliance_status_underived`.
- **G-03 `EvidencePackage.claim_support_map`** depends on D-06 evidence anchors, which depend on the **Addenda-A-owned** claim extractor. Declare the degraded mode (extractor absent → `claim_support_map` all `not_checked`); ties to A-22.
- **G-01 `EvaluationContractReview`** re-expresses criteria as `criteria_summary: string[]` — make these projections of the typed `EvaluationOutcomeDefinition.criteria` (carry `criterion_refs`), not parallel prose, or the pre-flight check can disagree with what is actually evaluated.
- **G-02 `RevisionReviewPacket`** must key `finding_to_change_map` on canonical `EvaluationFinding.finding_id` and reference `RevisionPlanStep.step_id`s; `semantic_diff_ref` needs a declared diff artifact kind.
- All read-only DOC20 surfaces (G-12/13/15/20) need the standard surface contract (loading/empty/degraded/error/command/telemetry/read-model/safe-label/Inspector), even though they assert "no new truth."

---

## 4. Coverage matrix (dedup completeness vs the source review)

**Count reconciliation.** Raw findings ≈ **227** (Claude 63: A1-A6, B1-B12, C1-C15, D1-D24, S1-S6 · ChatGPT ~110: 89 findings + 8 IDEA + 2 CONFIRMED + 15 Audit Addendum + 7 self-learning-2 · Gemini 19: F-01..03, D-01..05, 5 memory, BUG-01..05, TaskConfirmationSignal · Grok 35: §3=6, §4=10, §5=14, 5 ideas) ≈ the card's "~228." Adjudicated: 88 fix + 13 held + 4 declined + 21 surfaces = **126**, plus 5 folded notes. Arithmetic holds.

**Failure-point verdicts (the three named likeliest-miss areas):**
- **ChatGPT Audit Addendum (15) — fully covered.** Net-new rows A-26, A-27, B-26; the other 12 reinforce B-02/B-04/B-07/C-07/B-11/A-10/D-06/D-10/D-12/D-13/D-15/D-21.
- **Grok §4/§5 (24) — all substantively covered.** Three thin (§3.3, §5.7, §5.9); one citation typo (B-24 is §4.9, not §4.10).
- **Gemini memory (5) — fully covered, all deferred** (E-01..E-05); the five BUGs are live (C-02/C-03/C-04/C-05/B-16).

**Exceptions to fix:**

| # | Finding | Status | Action |
|---|---|---|---|
| 1 | **Claude D19** — "Task Agent appears in two forum-shaped surfaces" | **ORPHAN** | Add a row or fold explicitly (Forum/Run-Board consolidation; D-10 models participants but not the two-surface duplication). |
| 2 | **Claude D20** — "Forum is run-scoped only; no task-scoped forum" | **THIN** — cited under B-14 (deadlock), substance not addressed | Adopt a task-scoped forum or explicitly decline. |
| 3 | **Grok §3.3** — one doc owns the end-to-end feedback→prompt data-flow + responsibility matrix | **THIN** — B-17 fixes only the port discriminator | Add the responsibility-matrix obligation to B-17 or A-15. |
| 4 | **Grok §5.7** — sub-agent advice metrics "named but no schema records them" | **THIN** — partly via C-04 | State whether the metric-set recording schema ships now vs defers to E-06. |
| 5 | **Grok §5.9** — `BoardDigest.open_research_needs` references `ResearchNeed` without importing the SW schema | **THIN** — attaches to A-09 + D-11 | Add the cross-ref to the TypeOwnerRegistry entry (`ResearchNeed` → SW §6). |
| 6 | **ChatGPT item 21** — "sufficiency failure maps limitation enum values **into the state field**" | **MERGE?** — folded into A-06/A-07 | Ensure A-07's mapping forbids limitation values occupying the state field; confirm not double-fixing §5.4.2.2. |
| 7 | **ChatGPT item 37** — "declared-dependency-only revalidation is too brittle" (scope, not depth) | **THIN** — folded into B-05 | B-05 fixes convergence; confirm B-05/B-26 cover revalidation *scope* or add a note. |
| 8 | **B-24** cited as "Grok §4.10" | **Citation typo** | It's Grok **§4.9**; §4.10 is the library-promotion finding → D-20's source. |
| 9 | **B-03** cites "ChatGPT CG-SW9" | **Attribution nuance** | No ChatGPT SW finding is about concurrent-write safety; B-03 is Gemini F-01 + D-05. |
| 10 | **ChatGPT items 28-29** — delivery/consumption receipts (per-item status) | **Covered via Appendix F under A-08**, not own rows | Verify Appendix F specifies *per-item* consumption status (item 29's ask). |

**No wrongful splits.** **No wrongful merges that lose a fix.** The two heaviest merges are legitimate: **E-10** absorbs all 12 ChatGPT `[SELF-LEARNING]` items into one Phase-B bucket; **C-01** absorbs ~15 "no formula" findings into the FormulaRegistry.

**Full crosswalk** (status: ✓ covered · M merged · S split · DEF deferred-§E · DEC declined-§F · POS confirmed-positive · NOTE folded-note · ORPH orphan · THIN partial; ⚠ = covered but the row has a defect flagged in §3):

*Claude (63):*
`A1→G-08✓ A2→G-09✓ A3→G-10✓ A4→G-17✓ A5→G-11✓ A6→E-08 DEF`
`B1→A-01+A-05 S B2→A-06✓ B3→A-03✓ B4→A-08✓ B5→A-09 M B6→A-09 M B7→B-05 M B8→B-05 M B9→B-04✓ B10→D-15 M B11→B-17✓ B12→D-09✓`
`C1→A-04✓ C2→A-19✓ C3→B-18✓ C4→B-06✓ C5→A-11⚠ C6→A-20✓ C7→D-17 M C8→D-01 M C9→D-11✓ C10→B-19✓ C11→D-23✓ C12→D-24✓ C13→D-04⚠ C14→A-24✓ C15→D-14 M`
`D1→D-15 M D2→B-20✓ D3→D-10/B-14 M D4→E-07 DEF D5→A-15/D-22 M D6→D-05 M D7→B-21✓ D8→A-25✓ D9→POS(@A-16) D10→POS D11→G-19✓ D12→C-09 M D13→C-01 M D14→D-17 M D15→B-13✓ D16→A-12⚠ D17→B-22✓ D18→D-08 M D19→ORPH D20→B-14 THIN D21→E-07 DEF D22→A-15/D-22/E-06 M D23→A-23⚠ D24→B-23✓`
`S1→G-12✓ S2→G-13✓ S3→G-14✓ S4→G-15✓ S5→G-16✓ S6→E-09 DEF`

*ChatGPT main (99):* IDEAs→`G-06,G-01,G-02,G-07,G-04,G-03,G-05,G-21` ✓ · CONFIRMED×2→POS
Seam(11-33)→`A-02⚠,A-03,A-04⚠,A-01⚠,A-05⚠,A-18,A-17,A-16⚠,D-05,A-06,A-06/A-07(M?),A-07⚠,A-07⚠,A-07⚠,A-08,A-08,A-21,A-08·AppxF,A-08/D-23,A-14,A-13,A-10,A-22`
Runtime(34-49)→`B-02⚠,B-04,B-04,B-05(THIN#37),B-05/B-06,B-07,B-07,B-12,B-08⚠,B-08⚠,B-08⚠,B-08⚠,B-09,B-09,B-10,B-10`
Math(50-60)→`C-01,C-01,C-10,C-08,C-09,C-09,C-07,C-06,C-06,C-07,C-01`
SW(61-71)→`D-03,D-04⚠,D-04⚠,D-05,D-05,D-04⚠,D-02,D-06,B-13,D-06,D-06`
Forum(72-81)→`D-07,D-07,D-09,D-07,D-08,D-08,D-10,D-10,D-10,D-10`
Core(82-88)→`D-14,D-14,D-14,A-09/A-15,D-14,D-14/A-15,A-15`
Sub-agent(89-91)→`D-15,D-15,E-06 DEF` · Taint(92-93)→`D-01,D-12` · Learning(94)→`E-13 DEF` · SL(95-99)→`E-10 DEF ×5`
*Audit Addendum (15):* `AA1→B-26 AA2→A-27 AA3→A-26⚠ AA4→A-10 AA5→B-11 AA6→D-13 AA7→D-10 AA8→D-12 AA9→B-02⚠ AA10→B-04 AA11→B-07 AA12→C-07 AA13→D-15 AA14→D-21 AA15→D-06` ✓
*Self-learning-2 (7):* all→`E-07/E-10/E-06` DEF

*Gemini (19):* `F-01→B-03⚠ F-02→B-14 F-03→D-01` · `D-01→D-13 D-02→F-04 DEC D-03→B-06 D-04→B-27 D-05→B-03/B-13` · Memory `Hydration→E-01 Precedence→E-02 Amnesia(GM-V1)→E-03 State/Structure→E-04 Denominator(GM-V2)→E-05` DEF · `TaskConfirmationSignal→F-02 DEC` · `BUG-01→C-02 BUG-02→C-03 BUG-03→C-04 BUG-04→B-16⚠ BUG-05→C-05` ✓

*Grok (35):* §3→`3.1→NOTE@A-16/G-08 3.2→E-11 DEF 3.3→B-17 THIN 3.4→B-05 3.5→E-08 DEF 3.6→G-20/A-03` · §4→`4.1→B-01 4.2→D-16 4.3→D-08 4.4→NOTE@A-15 4.5→B-02⚠ 4.6→NOTE@D-23 4.7→D-07 4.8→A-14 4.9→B-24(mislabeled §4.10) 4.10→D-20` · §5→`5.1→B-25(DECLINE) 5.2→NOTE@A-05 5.3→D-01 5.4→D-07 5.5→D-17 5.6→B-01 5.7→C-04 THIN 5.8→D-13 5.9→A-09/D-11 THIN 5.10→D-19 5.11→D-14 5.12→D-18 5.13→B-02 5.14→B-15(DECLINE)` · Ideas→`N1→E-11 N2→F-01/G-17 N3→G-18 N4→E-12 N5→G-20` ✓

---

## 5. Cut-or-keep

**Drop / downgrade (effort or risk without payoff as written):**
- **A-11 → DECLINE** (enum exists; proposed value wrong — net-negative if applied).
- **B-25 → DECLINE** the schema add (field exists; proposed base is destructive); keep only the B-26 rename.
- **B-15 → DECLINE** the registry add (wrong owner); keep only the existing DOC12 OP-A obligation.
- **A-07 redundancy** — collapse `IndeterminateCause`/`EvaluationLimitationKind` into one enum; fold `SubstantiveVerdictStatus` into the state matrix (prune two free-standing enums + a hand-maintained crosswalk).

**Keep (do not cut):** the entire §G Professional Reliance Layer — it's the deliberate 2027/2028 differentiator; the notes in §3 are "make it work," not "remove."

**Add (to make the system solid):** the `validation.blocking_finding_without_authority` error (from A-01); the `reliance_status` derivation rule (G-06); and the four cross-cutting items in §6.

---

## 6. New ideas

**Structural (make the fix package more robust):**

1. **One `GovernanceEnvelope` mixin, applied everywhere.** Governance is currently re-declared ad hoc (`EvaluationArtifactEnvelope` for envelopes, `RunBoardGovernanceEnvelope` for posts, inline on the finding, *missing* on the view). Define one mixin — `{ taint_class, data_class, matter_id?, privileged, policy_decision_refs, sanitization_required }` — required on every finding, view, packet, post, signal, and research record. Closes the A-01 view hole systematically, makes D-01/D-24 uniform, and satisfies the flatten plan's "no duplicate governance model." Add `validation.governed_object_without_envelope`.

2. **`FindingMatchKey` as the universal loop-identity spine + one `RevisorTerminationLedger`.** §5.5.4 ProgressSignal, D-18 repeated-failure, B-24 sufficiency, B-27 regenerate, and the D16 `still_failing_same_reason` breaker are all keyed on "same failure + same finding." Make them all consume the single `FindingMatchKey` and increment **one** ledger (cascade depth from B-05, attempts from B-24, same-reason count from D16, regenerate-hash set from B-27, quiescence from B-20). One accounting object means the loop guards cannot disagree about whether to stop — the actual safety guarantee.

3. **Taint-on-projection invariant + phantom-field lint.** Any projection/view/export of a governed object MUST carry the source's governance class or be marked `non_exportable` (`validation.view_drops_governance_fields`). Pair with `validation.field_reference_not_in_schema` (parse every "reads/populates/MUST carry `X`" against the named type's fields). Together these would have caught the A-01 view hole, A-02, A-12, A-26, B-25, and B-08 mechanically.

4. **Run the TypeOwnerRegistry (A-09) as an *exhaustive* sweep, not four pointers.** The three `*FailureKind` enums (#B-08), the two `*Verdict` types (#A-12), the `IndeterminateCause` owner + `EvaluationLimitationKind` duplicate (#A-07), and the `FindingKind` naming gap (#A-01) are all the same disease and fall out of a complete "every named type defined exactly once, every reference resolves, every cross-addenda type has a declared owner" pass. Highest-leverage discipline upgrade; maps straight onto the flatten plan's supersession matrix.

**Forward-looking product (built on pieces already in the card):**

5. **Reliance-decay monitoring** — the litigation-grade payoff of `TaskReliancePacket` (G-06) + `EvidencePackage` (G-03) + the §5.16 source snapshots. When a source changes (case overruled, statute amended, filing superseded), re-evaluate prior reliance packets and flag work-product whose `reliance_status` has **degraded** ("a brief you relied on in March now cites an overruled case"). This is the outward-facing form of staleness propagation and connects DOC23 source-change detection to the DAMS staleness work. Nothing on the market does this for legal work.

6. **A "delegation envelope"** composing `EvaluationContractReview` (G-01) + `AutonomousModePolicy` (Grok §3.1) + `BudgetNarrative` (G-05) + `AttentionLedger` (G-07): a scoped, revocable authorization — "run autonomously up to $X, within these criteria, escalating on these triggers" — that makes overnight/batched autonomous runs safe for high-stakes work. Turns "the Revisor has scary autonomy" (Grok §3.1) into "autonomy the user explicitly scoped."

---

## 7. Answers to the three specific questions

**(1) A-01 unification — does it work?** Yes — single canonical finding + thin projection is the right call, and the two schemas are genuinely incompatible (verified V3.3.1 §5.7 vs FD §3.3). But it **breaks a consumer as written**: collapsing `authority_basis` into `assurance_basis` loses the `user_instruction`/`saved_criteria` blocking bases, so FD §3.4 rule 2 can't be computed for those blockers. **Keep both arrays** (schema in §3-A01) and compute `blocking_authority_satisfied` from `authority_basis`. Also fix the view governance strip and add the v1→v2.0 migration. With those, unify — separate schemas under one name is the worse outcome.

**(2) §G Professional Reliance Layer — does it work / where buggy?** Coherent and implementable; integrates cleanly (all rows consume the canonical finding, the limitation taxonomy, the Pattern C chain, the shared cost types). The work to make it solid: (a) a `reliance_status` derivation rule for G-06; (b) declared degraded modes for the A-dependent pieces (G-03's claim_support_map relies on the Addenda-A claim extractor); (c) typed (not prose) criteria projections in G-01; (d) typed diff/anchor refs in G-02; (e) the standard surface contract on every read-only DOC20 view. Keep the whole layer.

**(3) B-24 sufficiency detection — sound?** The trigger set is sound and sufficient (capability / convergence / exhaustion / inputs). Two corrections: (a) it is **not** filling a void — §6.7.1/§6.7.2/§6.7.3 already define emit-states, seven success conditions, and a `repeated_insufficiency_count` loop breaker (N=3) plus D16's same-reason counter; B-24 is the *insufficiency predicate* that feeds `repeated_insufficiency_count`, anchored at §6.7.1/§6.7.3, not a new protocol; (b) route to a Hard Call **only after** the §6.7.3 threshold — per-attempt, emit the §6.7.1 state, and add `needs_verification` to the route enum. Unify it with D16/B-05/B-27 into one termination ledger (§6, idea 2). Schema in §3-B24.

---

## 8. Open items / recommended next steps

1. **R0.4 amendment package** applying the accepted rows + the corrections in §1/§3 to the operative specs. Build-blockers first: A-01 (both bases + view governance + migration), A-02 (elevate + reuse types), then the dispositions that flip (A-11, B-15, B-25 → decline; B-03, B-24, D-04 → re-scope).
2. **The three cross-cutting structural items** (§6 ideas 1-4) as their own short proposal — they're the highest-leverage and they de-risk the rest of the package.
3. **Coverage gaps to close** (§4): adjudicate Claude D19 (orphan) and D20 (task-scoped forum); decide Grok §3.3/§5.7/§5.9; fix the B-24 citation label.
4. **Not yet certified:** a full row-by-row dedup certification beyond the spot-checks and the section-by-section enumeration done here. The structure is verified and the three failure points are covered; a line-level certification of all 126 against all 227 raw assertions is available if you want it.

---

## Appendix — status legend

`ACCEPT` adopt as-is · `ACCEPT W/ MODS` adopt with the stated change · `DECLINE` do not apply (covered/wrong) · `⚠verify` resolved in §2. Crosswalk codes: ✓ covered · M merged · S split · DEF deferred · DEC declined · POS confirmed-positive · NOTE folded-note · ORPH orphan · THIN partial · ⚠ covered-but-row-has-a-flagged-defect. `[CARD BUG]` defect in the proposed fix · `[SPEC BUG]` confirmed defect in the operative spec.

*Verified against live operative specs in `wbrody/Elnor-Specs@main`. This document supersedes the three separate review passes for active use.*