Elnor Repo Reader

# DOC OP-A — Cross-Doc Obligation Tracker V3.2

**DOC ID:** DOC OP-A (operations spec, A series — cross-doc obligation tracker)
**Version:** V3.2 (incremental update — DOC24 R3 audit-discovered cross-doc obligations added)
**Date created (V1):** 2026-04-26
**Date V2 produced:** 2026-04-26
**Date V3 produced:** 2026-04-26
**Date V3.1 produced:** 2026-04-26
**Date V3.2 produced:** 2026-04-26
**Status:** Active operations file (not a proposal; not a spec; this IS the tracker)
**Owner:** Will (architect); maintained by reviewing LLMs during sessions
**Folder:** `Current Specs/Operations Docs/`

**V3.2 changes from V3.1:**

V3.2 incorporates cross-doc obligations discovered during the DOC24 R3 audit pass. The audit found that 26% of accepted adjudication card items had not landed in the initial R3 draft; the corrective pass added 29 cards' content. Of those audit-added landings, three carried cross-doc obligations not previously captured in V3.1.

- Added 3 new OBL rows from audit-discovered impacts:
  - OBL-D21-NEW-02 (DOC21/22): bulk action affordances on review surfaces
  - OBL-D15-NEW-02 (DOC15): adaptive packet budgeting coordination
  - OBL-D72-NEW-05 (DOC72): WorkContextConstellation read-model publication
- §3 Source Registry updated: DOC24 R3 (final) added as folded-in source
- §10 Maintenance log: V3.2 entry appended

**Why this V3.2 increment.** Per V3.1's stated convention — "incremental V3.x for fold-ins; V4 reserved for Session 2" — the audit-discovered obligations are a fold-in event triggered by the audit being a distinct work unit from the original R3 drafting. V4 still rolls when Session 2 fold-in (DOC3 R9.2 + DOC14 R2 + CD-A 4.1.26) happens.

**Calibration anchor for V3.2 rows:** DOC24 R3 final (post-audit, 6,903 lines) and DOC24 R2.5 Adjudication Card V3 (audit cross-reference for ADJ-RT-079, ADJ-RT-099, ADJ-RT-105).

**Replaces / supersedes:**
- DOC OP-A V3.1 (this file is the new authoritative version)

---

## 1. How to use this document

**The single rule:** attach this tracker to every red team review and every spec drafting session. The reviewer (you, an LLM, or both) opens the section for the target doc being worked on, reads pending obligations, and either:

1. **Absorbs** an obligation into the spec revision (move row to "Absorbed" with date and revision number).
2. **Defers** an obligation explicitly with reason (move row to "Deferred" with reason).
3. **Adds** new obligations surfaced during the session (append to "Active" with source citation).
4. **Updates** an existing row's status (e.g., `[MISSING]` → `[PARTIAL]` after partial integration).

When the session closes, the reviewer's last step is to update this tracker. If the tracker doesn't get updated, the system loses memory of what was done.

**For new findings:** every cross-doc finding from a red team review or proposal becomes one or more rows here. The originating document (review file, proposal file, etc.) is cited as the source. Future revisions sweep this tracker to find their work.

**For session-start prep:** to know what's pending for the doc you're about to work on, read only the relevant `### DOC<N>` subsection under §6 "By Target Document — Active." That's your worklist.

---

## 2. Status Key

Inherited from DOC15 R3.1 contract format (it works; don't reinvent):

- `[REQ]` — Required. Target doc is broken or misleading without this.
- `[ENH]` — Enhancement. Target doc works but loses quality/trust/efficiency without it.
- `[FUT]` — Future. Needed for later phases, domain-pack work, or post-launch.
- `[EXISTS]` — Already defined in the target doc (current revision).
- `[PARTIAL]` — Partially defined; ownership or contract extension still needed.
- `[MISSING]` — Not defined in target doc.

A row's status uses one or two markers: e.g., `[REQ] [MISSING]` (required and not yet defined), `[ENH] [PARTIAL]` (enhancement, partially defined), `[REQ] [EXISTS]` (required and already in the spec — verification only).

---

## 3. Source Document Registry

Every document that has fed obligations into this tracker. Each source's content is now represented in §6 below; the source itself is preserved for historical reference and for citing detail.

### Folded-in sources

| Source Document | File Reference | Last Updated | Status | Folded In |
|---|---|---|---|---|
| DOC24 R2.5 §22 Cross-Doc Amendment Matrix | `DOC24_UNIFIED_KNOWLEDGE_CAPABILITY_ONBOARDING_ARCHITECTURE_R2_5.md` | April 2026 | Active spec revision | Yes (V1) — full §22 content extracted |
| V2 DOC24 Red Team Review | `DOC24_R2_5_RED_TEAM_REVIEW_CLAUDE_OPUS_4_7_V2.md` | 2026-04-26 | Active | Yes (V1) — cross-doc findings extracted (ISS-01b, ISS-03, ISS-11, ISS-12, ISS-17, ISS-22, ISS-23, ISS-26, ISS-28) |
| **DOC24 R2.5 Red Team Adjudication Card V3** | `DOC24_R2_5_RED_TEAM_ADJUDICATION_CARD_V3.md` | 2026-04-26 | Active | **Yes (V3.1)** — cross-doc obligations from accepted/accept_mod cards extracted to §6 target-doc sections. Card supersedes individual reviewer files for R3 planning. |
| **DOC24 R3 Landing Plan V1** | `DOC24_R3_LANDING_PLAN_V1.md` | 2026-04-26 | Active | **Yes (V3.1)** — §4 cross-doc obligations rollup folded in row-by-row; landing plan retained as separate artifact for R3 drafting work. |
| **DOC24 R3 (final, post-audit)** | `DOC24_UNIFIED_KNOWLEDGE_CAPABILITY_ONBOARDING_ARCHITECTURE_R3.md` | 2026-04-26 | Active | **Yes (V3.2)** — audit-discovered cross-doc obligations from ADJ-RT-079/099/105 added; companion-doc-only cards (008/036/092/101) re-confirmed. R3 itself is the operative spec, not a source for further obligations to track here unless future amendments surface. |
| **DOC15 Cross-Doc Integration Contract R3.1** | `DOC15_Cross_Document_Integration_Contract_R3_1_Consolidated_Current_Draft.md` | March 12, 2026 (Part 2 R3 revision); Part 3 authority salience additions undated; R3.1 consolidation undated | **STALE — predates DOC72 R5.73, DOC73 V1.4.1, DOC25 V2.0, DOC24 R2.5, BDSM V6.4, KDA R2, Persistent Onboarding Curiosity, GIE V2.2 absorbed, KIE R2 absorbed.** Source archived (in-place annotation). | **Yes (V3) — full row-by-row extraction of §§1-13 (Parts 1-3), all 52 capture points + §R3.1.A-F authority salience field/event/route/UI additions** |
| CD Master Integration Index R1 | `CD_MASTER_INTEGRATION_INDEX_R1.md` | 2026-04-01 | Superseded by this tracker | Yes (V1) — registry content folded into §3 |

### Scope rule for folding sources into this tracker

Only standalone documents whose primary purpose is tracking cross-doc obligations are foldable into OP-A. **Out of scope:**

- **Spec-internal cross-doc content** (e.g., DOC24 §22 amendment matrix, DOC3 §22). These migrate to OP-A when the owning spec next revises, as part of normal revision work.
- **Currently-outdated implementation guides.** Their successors fold in when those exist.
- **Documents whose existence or currency is unverified.** Listed in §9 Open Meta-Architecture Questions for investigation, not in this registry.
- **Documents being superseded by major revisions in progress** (e.g., DOC10-related trackers when DOC10 itself is being significantly revised). Wait for the post-revision tracker.

A document only enters this registry once the architect has confirmed (a) it exists in the folder structure, (b) its content reflects current architecture or its staleness is explicitly known and acceptable, and (c) it is not pending replacement by a forthcoming revision.

### Source documents NOT yet folded in (verified active sources awaiting fold-in session)

| Source Document | File Reference | Status | Plan |
|---|---|---|---|
| DOC3 Companion Doc Delta Plan R9.2 Canonical | `DOC3_Companion_Doc_Delta_Plan_R9_2_Canonical.md` | Confirmed exists; user has shared file | **Session 2 — planned for OP-A V4** |
| DOC14 Cross-Document Delta Companion R2 | `DOC14_CROSS_DOCUMENT_DELTA_COMPANION_R2.md` | Confirmed exists; user has shared file | **Session 2 — planned for OP-A V4** |
| CD-A 4.1.26 DOC3/DOC24 Cycle staging doc | `Addenda Proposals & In Progress/CD Cross Docs/CD-A_4-1-26_DOC3_DOC24_CYCLE.md` | Confirmed exists; user has shared file | **Session 2 — planned for OP-A V4** |
| Memory Intake and At-Use Disciplines Proposal V1 | `Addenda Proposals & In Progress/MEMORY_INTAKE_AND_AT_USE_DISCIPLINES_PROPOSAL_V1.md` | **Held off pending red team** — proposal in first draft; obligations not yet pinned to integrated specs | Add after proposal red team confirms approach and target sections are stable |
| Persistent Onboarding Curiosity amendment | `Addenda Proposals & In Progress/DOC24 Addenda/DOC24_AMENDMENT_PERSISTENT_ONBOARDING_CURIOSITY.md` | Drafted; references in V2 DOC24 review | Add as standalone source if/when adopted into a target spec |

---

## 4. Calibration / shelf-life note

Obligations in this tracker are calibrated against specific spec versions at the dates noted in §5. When a target spec revises:

1. **All rows targeting that doc** are reviewed against the new revision.
2. Rows whose obligations are now satisfied → moved to Absorbed.
3. Rows whose obligations changed shape due to revision → updated with new status/description.
4. Rows whose obligations are now obsolete due to architectural change → moved to Deferred with reason.

When a SOURCE document supersedes (e.g., DOC73 V1.5 supersedes V1.4.1 and changes a primitive that obligations referenced): rows derived from the older source are flagged for re-validation. The "Calibrated against" field on each row identifies its anchoring source versions.

---

## 5. Quick reference — Source-doc currency snapshot

For at-a-glance assessment of how stale this tracker's content might be:

| Spec / Source | Current Version | As Of | Sources In This Tracker That Reference It |
|---|---|---|---|
| DOC72 | **R5.73** | 2026-04-26 | V2 DOC24 review (current); DOC24 §22 (current); DOC15 R3.1 (predates DOC72 entirely) |
| DOC73 | **V1.4.1 (operative per architect)** | 2026-04-26 | V2 DOC24 review (current); DOC15 R3.1 (predates DOC73 entirely) |
| DOC24 | R2.5 | April 2026 | V2 DOC24 review (current); DOC15 R3.1 (predates DOC24 R2.5) |
| DOC25 | **V2.0** | 2026-04-26 | V2 DOC24 review (referenced); DOC15 R3.1 (predates DOC25 entirely) |
| DOC15 | R7.1 | 2026-03-13 | DOC15 R3.1 contract is the cross-doc companion, not the spec itself |
| DOC1 | Rebuild R1 | 2026-03-10 | All sources reference DOC1; storage model partially stale per master registry §10.3 |
| DOC72 GIE V2.2 | ABSORBED into DOC72 R5.73 §42A | 2026-04-26 | Per post-absorption versioning rule (Invariant #24), V2.2 is archived |
| DOC72 KIE R2 | ABSORBED into DOC72 §34A | 2026-04-26 | Archived |
| BDSM | V6.4 | 2026-04-07 | DOC24 §22 (current); referenced in DOC8 obligations |
| KDA | R2 | 2026-04-02 | DOC24 §22 (current); DOC15 schema obligations align |

**Implication:** DOC15 R3.1's content predates major architecture additions. Some obligations it raises may now be satisfied (e.g., DOC72 may now define seams DOC15 needed) or now obsolete (e.g., topics absorbed into DOC72/DOC73 since). DOC15 R3.1 obligations included in §6 below are extracted faithfully but are flagged with a staleness note in their Calibrated-against field. During each owner-doc revision, reviewers should verify whether DOC15-derived rows are still pending against current target spec state.

---

## 6. By Target Document — Active Obligations

Sections appear in DOC-number order. A target doc with no current obligations has the section header but `(no current obligations recorded)`.

---

### §6.1 DOC1 — Memory Resilience

**EXISTING ROWS (V1, preserved):**

| Obligation | Field/Change | Status |
|---|---|---|
| **OBL-D1-01:** Durable authority schema adoption | `authority_scope`, `creation_path` metadata, broader-correction approval gating | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 §10 / Priority Matrix #36, #37, #38, #39
- **Why:** Without durable authority scope and creation-path metadata, broader-than-session corrections silently apply globally; freeform task instructions wrongly become standing orders.
- **Acceptance:** DOC1 schema includes `authority_scope`; correction-broadening requires explicit approval; transient instructions pass through without auto-promotion.
- **Calibrated against:** DOC15 R3.1 (March 12, 2026 — predates DOC72/DOC73/DOC25/most addenda)
- **Note:** May overlap with V3 carryover §3.4 DOC1 Authority/Heuristic distinction — verify current status against DOC1 R1.

| **OBL-D1-02:** Maturity bypass eligibility check | Verify current §10.4 against ISS-01b cascade implications | `[REQ] [PARTIAL]` |

- **Source:** V2 DOC24 Red Team Review §ISS-01b
- **Calibrated against:** DOC72 R5.73; DOC73 V1.4.1

| **OBL-D1-03:** Memory governance audit surface | Inspector exposes provenance, scope, last-updated | `[REQ] [EXISTS]` |

- **Source:** V3 carryover §3.4 (existing requirement); DOC15 R3.1 §10.5
- **Status note:** Likely already in DOC1 R1; verify during next DOC1 revision.

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D1-04:** Durable authority record full schema (R3 expansion) | Field-level: `authority_id`, `scope` (9-value enum), `applies_to` (typed object), `creation_path` (4-value enum), `persistence_class` (3-value enum), `expires_at?`, `review_after_at?`, `revoked_at?`, `memory_firewall` (object) | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §1.1 (Part 2 R3) — Table "Durable authority schema adoption"
- **Why:** Companion to OBL-D1-01 at field-level granularity. Contract specifies exact schema fields needed for hot-path read model and audit/inspector routes.
- **Acceptance:** DOC1 schema validates all listed fields per the R3 contract. `scope` enum includes operation/session/thread/panel/room/task/workspace/matter/global. `creation_path` distinguishes explicit_user_save / approved_proposal / approved_review_outcome / manual_import.
- **Calibrated against:** DOC15 R3.1 (March 12, 2026 — predates DOC72 R5.73 and DOC73 V1.4.1)
- **Depends on:** —
- **Blocks:** OBL-EC-07 (hot-path lane render plan), OBL-EC-08 (telemetry events)
- **Created:** 2026-04-26
- **Last verified:** 2026-04-26
- **Notes:** Some fields may now overlap with DOC72 entity-graph node attributes; verify against DOC72 R5.73 §2.2 sparsity table and `memory_directive` node kind.

| **OBL-D1-05:** Authority mutation read model | Current-view/state support powering rescope/revoke/expiry/foundational render controls | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §1.1 (Part 2 R3) — last two rows of the schema table
- **Why:** UI for rescope/revoke/expiry/foundational controls needs a current-view read model exposing applied/skipped state per authority record.
- **Acceptance:** DOC1 exposes a current-view endpoint returning per-record mutation state and history.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D1-04
- **Blocks:** OBL-D10-12 (Authority Audit surface UI), OBL-EC-12 (mutation command ingestion)
- **Created:** 2026-04-26

| **OBL-D1-06:** Transient instruction split (three-class distinction) | DOC1 must distinguish: durable authority / transient one-dispatch constraints / candidate corrections awaiting approval | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §1.2 (Part 2 R3); §10.3 (Part 1)
- **Why:** Without explicit class distinction, freeform task wording silently flows into durable authority. CU authority resolution (DOC73 §3.2A) presumes this distinction exists upstream.
- **Acceptance:** DOC1 schema has type field distinguishing durable/transient/candidate; each class has different lifecycle and write-gate handling.
- **Calibrated against:** DOC15 R3.1 (stale); cross-check against DOC1 R1 §4.12 (CU authority disclaim) and DOC73 §3.2A
- **Depends on:** —
- **Blocks:** OBL-EC-10 (transient pass-through), OBL-D6-06 (durable-correction vs use-only-here controls)
- **Created:** 2026-04-26

| **OBL-D1-07:** Authority pipeline candidate-origin transparency | Pipeline exposes whether candidate came from explicit save vs inferred candidate | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §10.3 (Part 1) — second row
- **Why:** Advisor/inspector honesty — user can see whether a memory's origin was a deliberate save or an inferred suggestion.
- **Acceptance:** Authority records carry `origin_type: explicit_save | inferred` field exposed in inspector and audit surfaces.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D1-08:** Authority rescope/revoke/expiry read model | Scope edit, revoke, and expiry metadata exposed in read models so user can repair overly broad rules without file surgery | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §10.4 (Part 1)
- **Why:** UI repair path for over-broad authority. Without exposed rescope/revoke/expiry fields, user must edit JSON directly.
- **Acceptance:** Read model exposes mutation history; UI command paths exist for rescope/revoke/set_expiry.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D1-05
- **Created:** 2026-04-26

| **OBL-D1-09:** MemorySearchService ownership note | Future ownership note keeping semantic retrieval extractable from DOC1 / MemoryService | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §10.5 (Part 1)
- **Why:** Architectural placeholder for future split between DOC1 and a dedicated MemoryService.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D1-10:** Search mode / health visibility in debug surfaces | Search mode indicator, provider health, score breakdown | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §10.6 (Part 1)
- **Why:** Future search transparency — user can see which retrieval mode is active.
- **Calibrated against:** DOC15 R3.1 (stale); cross-check against current DOC72 R5.73 routing cascade §14.4 (Tier 1-3 disambiguation) — may already be partially covered.
- **Created:** 2026-04-26

| **OBL-D1-11:** Memory relationship index traversal seam (#42) | Bounded relationship-index traversal by source ID, relation type, scope filters, and strength, exposed through stable read/query seam | `[ENH] [PARTIAL]` |

- **Source:** DOC15 R3.1 §10.7 (Part 2 R2.1) / Priority Matrix #42
- **Why:** Lets DOC15 use one-hop relation-aware memory expansion without becoming the owner of the graph substrate.
- **Acceptance:** DOC1 (or DocIndex) exposes typed read API: `traverseRelations(source_id, relation_type, scope_filter, max_strength_drop, max_hops=1) → RelationNode[]`.
- **Calibrated against:** DOC15 R3.1 (stale); verify against DOC72 R5.73 §4.6 (edge types) which may already provide most of this.
- **Created:** 2026-04-26

| **OBL-D1-12:** Relation semantics for contradiction/supersession (#42 cont.) | Relation read models expose at least `contradicts`, `supersedes`, `derived_from`, `corrects`, `reinforces`, plus strength and provenance | `[ENH] [PARTIAL]` |

- **Source:** DOC15 R3.1 §10.8 (Part 2 R2.1)
- **Why:** Keeps advisors/suggestion cards honest about why older memory was suppressed/deprioritized.
- **Acceptance:** Edge type registry includes 5 listed relations; each has strength field (0-1) and provenance reference.
- **Calibrated against:** DOC15 R3.1 (stale); DOC72 R5.73 §4.6 typed edges may cover most — verify.
- **Created:** 2026-04-26

| **OBL-D1-13:** Authority salience field set (#47) | Durable authority record adds `display_label?`, `persistence_class` (standard/protected/foundational), `injection_preference` (auto/inline_full/inline_compact/ref_preferred), `last_user_reconfirmed_at?`, `review_after_at?` | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.A (Part 3) / Capture point #47
- **Why:** Without these fields, hot-path authority injection has no salience signal, no render preference, and no reaffirmation track for older rules.
- **Acceptance:** DOC1 schema includes 5 listed fields; EC Core current-view exposes them; CIL hot-path read model reads them.
- **Calibrated against:** DOC15 R3.1 Part 3 (undated; assumed March-April 2026)
- **Depends on:** OBL-D1-04
- **Blocks:** OBL-EC-07 (lane-aware render plan), OBL-EC-08 (telemetry), OBL-D10-12 (Authority Audit surface)
- **Created:** 2026-04-26
- **Notes:** This is the field-set addition for the V3 carryover's "authority salience" pass. Per Part 3 §R3.1.A: "DOC1 owns the schema truth; EC Core owns the current-view exposure."

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D1-NEW-01:** `memory.save` defaults `context_specific` not global | Default scope changed; require explicit "always/globally/remember this" or durable-proposal approval for global scope | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-051; Landing Plan V1 §4 OBL-D1-NEW-01
- **Why:** Default-global memory.save conflicts with DOC1's "strong but hard to create accidentally" authority posture and DOC24 §12.4C default-to-transient rule. One-off instructions silently become global memory.
- **Acceptance:** DOC1 schema validation rejects `memory.save` commands with `scope: global` unless authorization marker present. Default scope is `context_specific` or `session_candidate`.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC24 R3 Bundle F (Onboarding/Memory/Digest)
- **Created:** 2026-04-26

| **OBL-D1-NEW-02:** Consume DigestItemDisposition for `factually_wrong` corrections only | Digest dispositions other than `factually_wrong` do not flow to DOC1 confidence corrections | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-026; Landing Plan V1 §4 OBL-D1-NEW-02
- **Why:** Digest UI offers multiple disposition values (dismiss, not_relevant_here, factually_wrong, archive_candidate, archive_node, edit_and_save). Only `factually_wrong` should propose confidence corrections; the others are not factual-reliability signals.
- **Acceptance:** DOC1 correction-proposal handler filters by disposition; non-`factually_wrong` dispositions either no-op or route to non-DOC1 surfaces.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming)
- **Depends on:** DOC24 R3 §36 disposition split (ADJ-RT-026)
- **Blocks:** —
- **Created:** 2026-04-26

---

### §6.2 DOC3 — App Skills

(no current obligations recorded directly in this tracker; DOC3 R11.3 adjudication card and DOC3 Companion Delta Plan R9.2 contain the canonical DOC3-targeting obligations and **will be folded in during Session 2 — OP-A V4**.)

Cross-references for DOC3 work:
- DOC3 §22 (internal amendment matrix — read during R11.3 revision)
- V2 DOC24 review ISS-09 (ConversationHistoryService) — partially affects DOC3 if demonstration mode capture interacts with conversation history

DOC15 R3.1 obligations targeting DOC3 will be added in Session 2 fold-in (DOC15 R3.1 §11 mentions DOC3 in Part 2 R3 §11 retrieval lane naming context).

---

### §6.3 DOC4 — OpenClaw Bridge / Agent Registry

**EXISTING ROWS (V1, preserved):**

| **OBL-D4-01:** CIL Advisor agent definition | Agent registry entry for `cil_advisor` and similar advisor agents | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §9.1, §9.2
- **Why:** CIL needs registered advisor agents; DOC10 advisor dispatch (§7) requires DOC4 agent definitions.
- **Calibrated against:** DOC15 R3.1 (stale)

| **OBL-D4-02:** Agent document dependency fields | `requires_documents`, `recommended_documents` on agent registrations | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §9.3
- **Calibrated against:** DOC15 R3.1 (stale)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D4-03:** Review Advisor and Spec Advisor definitions | `review_advisor` (review/red-team explanatory support), `spec_advisor` (spec/debug advisory support) | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §9.2 (split out from OBL-D4-01)
- **Why:** Distinguishes from `cil_advisor`. Each advisor has different document dependencies and dispatch routing.
- **Acceptance:** DOC4 registry includes both as starter roles with their dependency lists.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D4-04:** Advisor Dispatcher agent (R3) | `advisor_dispatcher` agent definition | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §12 (Part 2 R3) — DOC4 must define cil_advisor + advisor_dispatcher + review_advisor
- **Why:** R3 contract adds advisor_dispatcher as the routing-layer agent that resolves payload_kind → specific advisor.
- **Acceptance:** DOC4 includes `advisor_dispatcher` with its own dependency declarations.
- **Calibrated against:** DOC15 R3.1 Part 2 R3 (March 12, 2026)
- **Created:** 2026-04-26

---

### §6.4 DOC6 — Panels, Forums, Self-Improvement

**Status check (carried from V2):** DOC6 numbering may be obsolete or absorbed. V3 carryover §1 doesn't list DOC6 prominently. **Per master spec list R2.7 row 13:** DOC6 v1.11.8.1 IS active operative — registry confirms. Verify against current DOC6 contents during next maintenance pass.

**NEW ROWS (V3, from DOC15 R3.1 §3 expansion):**

| **OBL-D6-01:** Panel Close ReviewOutcome | Panel close dialog writes `ReviewOutcomeSchema` | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.1 / Priority Matrix #3
- **Why:** Panel-first learning loop. Without ReviewOutcome at panel close, DOC15 has no whole-review attribution from panel surfaces.
- **Acceptance:** Panel close handler emits a ReviewOutcomeSchema record covering goal_type, close_reason, user_goal_met, findings_starred, findings_by_novelty.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D14-02 (ReviewOutcomeSchema definition)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D6-02:** Configuration dissatisfaction detection | Detect rerun-after-config-change dissatisfaction | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §3.2 / Priority Matrix #12
- **Why:** Direct negative signal for configuration tuning. User reruns soon after config change → signal that the change made things worse.
- **Acceptance:** DOC6 emits a `panel.config_dissatisfaction_detected` event when rerun follows config change within threshold window.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D6-03:** Panel feedback events to CIL bridge | Apply/edit/dismiss suggestion-card events carry original `dispatch_id` | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.3
- **Why:** Element-level recommendation learning needs attribution back to producing dispatch.
- **Acceptance:** Suggestion-card events include `original_dispatch_id` and `action_kind` (apply/edit/dismiss).
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D6-04:** Panel turn prompt lineage (multi-turn) | Panel turn prompt lineage export | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §3.4
- **Why:** Future prompt effectiveness for multi-turn panel workflows.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D6-05:** "Ask Elnor" integration in panel setup | Panel setup invokes `POST /api/cil/operation`; panel UI supports `Why?` via generic advisor dispatch | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.5 / Priority Matrix #7
- **Why:** First useful CIL UX path. Without Ask Elnor wiring at panel setup, panels can't invoke CIL recommendations.
- **Acceptance:** Panel setup calls operation compiler; Why? button dispatches via DOC10 advisor transport.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-EC-04 (operation compiler entry point), OBL-D10-01 (advisor dispatch endpoint)
- **Created:** 2026-04-26

| **OBL-D6-06:** Durable-correction vs use-only-here controls | Default "use only here" / task-or-session-scoped handling for freeform behavior instructions; explicit `save_as_correction` / `save_as_rule` action separated from ordinary chat input | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.6
- **Why:** Prevents accidental durable correction writes from stream-of-thought wording. Durable authority requires affirmative user action.
- **Acceptance:** Panel UI has explicit save-as-correction button distinct from chat send. Default behavior for freeform instructions is transient (per OBL-D1-06).
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D1-06 (transient instruction split), OBL-EC-10 (transient pass-through)
- **Created:** 2026-04-26
- **Notes:** Critical for Will's "no phantom memories / no auto-promotion of weak signals" failure modes.

| **OBL-D6-07:** Ask/Why telemetry on panel surfaces | Panel `Ask Elnor`, `Why?`, and authority-origin clicks emit `ui.control_invoked` with `dispatch_id` + `source_surface`; panel context/memory inspection emits `memory.origin_viewed` | `[ENH] [PARTIAL]` |

- **Source:** DOC15 R3.1 §3.7 / Priority Matrix #40
- **Why:** Makes over-sensitive learning inspectable; user can audit what actually applied.
- **Acceptance:** Both events registered in DOC10 telemetry catalog and emitted from panel UI.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D10-09 (CIL telemetry events catalog)
- **Created:** 2026-04-26

| **OBL-D6-08:** Authority maintenance proposal commands (R3 expansion) | Approval-gated user proposals for rescope, revoke, set expiry, set review date, set persistence class, set injection preference, mark foundational, prefer compact render | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.E (Part 3) / Capture point #51
- **Why:** Per Part 3 owner split: "DOC6 owns approval-gated user proposal / ship-lane handling where approval is required." Authority maintenance changes flow through DOC6's approval pipeline.
- **Acceptance:** DOC6 ship lane accepts authority maintenance proposals; emits approved actions to EC Core for durable write.
- **Calibrated against:** DOC15 R3.1 Part 3 (undated)
- **Depends on:** OBL-D1-05 (authority mutation read model), OBL-EC-12 (mutation command ingestion)
- **Blocks:** OBL-D10-12 (Authority Audit surface row-level actions)
- **Created:** 2026-04-26

---

### §6.5 DOC7 — Context Buckets & Files

**EXISTING ROWS (V1, preserved):**

| **OBL-D7-01:** MaterializationPreview API | Preview before injection of bucket-materialized content | `[ENH] [MISSING]` |
| **OBL-D7-02:** Hierarchical bucket levels | Bucket nesting / parent-child structure | `[ENH] [MISSING]` |
| **OBL-D7-03:** Bucket access telemetry to DOC8 | Track bucket access patterns for learning | `[ENH] [PARTIAL]` |
| **OBL-D7-04:** DocIndex-aware budget allocation | Bucket budget consults DocIndex for relative document weighting | `[ENH] [PARTIAL]` |
| **OBL-D7-05:** Document priority hints consumption | Consume hints from DocIndex / DOC10 | `[ENH] [PARTIAL]` |
| **OBL-D7-06:** Unified Context Budget Governance integration | Coordinate with DOC24 unified budget; overlap detection | `[REQ] [PARTIAL]` |

(Full V1 detail preserved per V2; not re-rendered for brevity. Sources: DOC15 R3.1 §6.1-6.5 / Priority Matrix #15-16; DOC24 R2.5 §22 / §27A.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D7-07:** Graph-aware document priority and support-pack hints (#45) | `document_priority_hints` carry topology-backed reason codes (`same_issue`, `same_matter`, `supersedes_target`, `support_pack_member`, `active_review_target_neighbor`); optional support-pack grouping hints | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §6.6 (Part 2 R2.1) / Priority Matrix #45
- **Why:** Lets learned document suggestions stay bounded while still being actionable. Topology-backed reason codes give DOC7 enough context to make smart materialization decisions.
- **Acceptance:** DOC7 hint schema includes 5 listed reason codes plus support-pack grouping field. DOC7 materialization considers reason codes when budgeting.
- **Calibrated against:** DOC15 R3.1 (stale); cross-check against DOC7 R7 §4.4 budget governance and DOC72 R5.73 §4.6 edge types.
- **Depends on:** OBL-EC-13 (topology read model availability)
- **Created:** 2026-04-26

| **OBL-D7-08:** Contradiction/supersession-aware materialization (R3 expansion) | DOC7 implements contradiction/supersession-aware materialization | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §9 (Part 2 R3) — third bullet
- **Why:** When materializing buckets, DOC7 should down-weight or skip content that's contradicted/superseded by other sources in the bucket.
- **Acceptance:** DOC7 materialization queries topology read model for `contradicts`/`supersedes` edges; emits warnings or trims contradicted content.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-EC-14 (contradiction/supersession edge exposure)
- **Created:** 2026-04-26

| **OBL-D7-09:** Active-review-target and support-pack member protection (R3 expansion) | DOC7 preserves active-review-target and support-pack member content from compression/trim | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §9 (Part 2 R3) — fourth bullet
- **Why:** Active review target should never be summarized away during budget pressure; user is actively examining it.
- **Acceptance:** DOC7 budget manager has pin/protection lane for active-review-target and support-pack members.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D7-10:** Degraded explanation when topology unavailable (R3 expansion) | DOC7 surfaces degraded explanation when topology is unavailable and only ordinary relevance is used | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §9 (Part 2 R3) — fifth bullet
- **Why:** Honesty about degraded mode. User should see "topology unavailable; using ordinary relevance only" rather than silently getting worse results.
- **Acceptance:** DOC7 emits `degraded_reason` field with codes when topology lane is unavailable.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

---

### §6.6 DOC8 — Self-Learning

(Existing OBL-D8-01 through OBL-D8-07 preserved from V2 — these cover §4.1-4.4 and DOC24 R2.5 §22 obligations. No new DOC15 R3.1 obligations targeting DOC8 beyond what V1 captured. R3 §7 — prompt-artifact lifecycle — adds one new row below.)

| **OBL-D8-08:** Prompt-artifact lifecycle acceptance (R3 expansion) | DOC8 adds prompt-artifact lifecycle (`assignment`, replay trial, canary, promotion/retirement); shared prompt-artifact family alignment with DOC14 / DOC15 / DOC17; evaluation artifact exports that can feed recommendation evidence; explicit cost firewall (cost/budget events do not become learning signals) | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §7 (Part 2 R3)
- **Why:** Prompt-artifact recommendation system needs DOC8 as the lifecycle owner. Without it, prompt artifacts have no replay/canary/promotion path.
- **Acceptance:** DOC8 schema includes prompt_artifact lifecycle states; emits PromptArtifactLifecycleEvent; cost firewall enforced (cost events excluded from quality signal pipeline).
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D14-08 (DOC14 prompt-artifact observation emissions)
- **Created:** 2026-04-26
- **Notes:** Cross-references BDSM V6.4 (DOC8 is BDSM computational engine per OBL-D8-07). Verify integration points.

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D8-NEW-01:** Filter utility feedback by MatrixExposureClass | Only `eligible_and_injected` (and optionally `eligible_reference_only`) cards produce direct utility signals; suppressed cards excluded from learning | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-124; Landing Plan V1 §4 OBL-D8-NEW-01
- **Why:** Without exposure-class filtering, Matrix learns from cards that were never seen (budget-suppressed, policy-blocked, source-excluded) and treats their non-use as user rejection. Pollutes utility ledger.
- **Acceptance:** DOC8 nightly batch reads MatrixExposureClass from manifest and excludes non-eligible classes from beta updates.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming); BDSM V6.4
- **Depends on:** UnifiedInjectionManifest schema (DOC24 R3 §38.2); OBL-BDSM-NEW-03
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D8-NEW-02:** Reflection loop scans TransientInstructionObservation ledger | §11.3 reflection process queries transient observation log for 3+ recurrences; promotes eligible observations to durable candidates | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-028; Landing Plan V1 §4 OBL-D8-NEW-02
- **Why:** §12.4C says repeated transients become durable candidates but no consumer of the observation ledger exists. DOC8 reflection loop is the natural consumer.
- **Acceptance:** DOC8 reflection process reads observation log filtered by `eligible_for_candidate_counting: true`; produces promotion candidates when threshold met.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming)
- **Depends on:** TransientInstructionObservation schema (DOC24 R3 §12.4C ADJ-RT-028)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D8-NEW-03:** Propose discovered tool alternatives into review queue | DOC8 surfaces detected tool alternatives (from execution traces) into a user-review queue rather than auto-creating `alternative_to` edges | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-048; Landing Plan V1 §4 OBL-D8-NEW-03
- **Why:** Auto-created alternative_to edges accumulate false alternatives. DOC8 should propose; user (or scheduled review) confirms.
- **Acceptance:** DOC8 emits `alternative_to_proposal` events; review queue UI exists for confirmation; only confirmed alternatives create graph edges.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC8 review-queue UI (DOC21/22 surface)
- **Created:** 2026-04-26

---

### §6.7 DOC10 — Unified Engagement Orchestration

**EXISTING ROWS (V1, preserved):**

OBL-D10-01 through OBL-D10-07 cover §7.1-7.6 and DOC24 R2.5 §22 routing cascade ownership. (Full detail in V2.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D10-08:** Retrieval receipt surfacing on CIL surfaces (#41 / R2.1) | CIL-facing explanation surfaces render retrieval receipt fields (`search_lane`, `provider_kind`, `corpus_id`, `route_reason`, `freshness_state`, `degraded_reason`) | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §7.7 (Part 2 R2.1, second row); §7.8 / Priority Matrix #41
- **Why:** Lets CIL explain whether a recommendation came from exact/live lookup vs semantic corpus vs canonical memory vs native runtime — not just "search."
- **Acceptance:** DOC10 transport carries RetrievalReceipt fields end-to-end; CIL UI components render them.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D18-01 (DOC18 receipt emission)
- **Created:** 2026-04-26

| **OBL-D10-09:** RetrievalReceiptSchema definition (R3 expansion) | Shared `RetrievalReceiptSchema` with at least: `provider` (enum: m365_graph_search, qmd_local_semantic, llamaindex_index, openclaw_native, ec_memory_search, keyword_fallback), `route_reason_codes`, `corpus_ids`, `degraded_reason_code?`, `topology_used` | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.2 (Part 2 R3) — full TypeScript schema
- **Why:** Shared schema for all retrieval providers. Without it, each provider invents its own receipt format.
- **Acceptance:** DOC10 publishes RetrievalReceiptSchema; DOC18, DOC3, DOC1 all emit conforming receipts.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** —
- **Blocks:** OBL-D18-01, OBL-D18-02
- **Created:** 2026-04-26

| **OBL-D10-10:** CIL UI transport types (R3 expansion) | DOC10 owns typed transport for: Ask/Advise/Why; suggestion-card apply/edit/dismiss; support-pack preview/apply/dismiss; prompt-artifact preview/dismiss/apply; memory-origin visibility / retrieval receipt display | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 §3.3 (Part 2 R3)
- **Why:** All CIL UI flows need typed transport contracts; otherwise they drift.
- **Acceptance:** DOC10 publishes 5 transport schemas. CIL UI consumes typed envelopes.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D10-11:** CIL telemetry event catalog (R3 expansion) | Register at minimum: cil.ask_clicked, cil.why_clicked, cil.advise_clicked, cil.suggestion_applied, cil.suggestion_edited, cil.suggestion_dismissed, cil.support_pack_previewed, cil.support_pack_applied, cil.prompt_artifact_previewed, cil.memory_origin_viewed | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §3.4 (Part 2 R3)
- **Why:** 10 named CIL events form the minimum telemetry surface. Missing any of them blinds the learning loop.
- **Acceptance:** DOC10 telemetry catalog includes all 10 event names with typed payloads.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** —
- **Blocks:** OBL-D6-07 (panel-side emission)
- **Created:** 2026-04-26

| **OBL-D10-12:** Authority Audit surface UI transport (#52 / R3 expansion) | DOC10 transport supports dedicated Authority Audit surface with loading/empty/populated/degraded/blocked/error states, sortable/filterable rows, row-level actions, `Why?` drilldown, snapshot endpoint, current-view row endpoint | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.F (Part 3) / Capture point #52
- **Why:** Authority audit is the user-facing inspection surface for hot-path injection decisions. Without it, authority salience and lane decisions are invisible.
- **Acceptance:** DOC10 transport includes AuthorityAuditRowSchema (per Part 3 §R3.1.F TypeScript), snapshot endpoint, current-view row endpoint, action affordances.
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-D1-13 (authority salience field set), OBL-EC-08 (telemetry event schema), OBL-EC-11 (application trace)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D10-13:** Authority-specific telemetry transport (#48 / R3 expansion) | DOC10 transports AuthorityHotPathTelemetryEvent (event_type enum: selected/inline_full/inline_compact/ref_only/trimmed_due_to_budget/skipped_cooled/origin_viewed/rescope/revoke/set_persistence_class/set_review_after) | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.B (Part 3) / Capture point #48
- **Why:** Authority-specific telemetry beyond generic memory selection. Required for audit and salience tuning.
- **Acceptance:** DOC10 publishes AuthorityHotPathTelemetryEventSchema with 11-value event_type enum (per Part 3 schema).
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-D1-13
- **Created:** 2026-04-26

---

### §6.8 DOC11 — OpenClaw Gateway

**EXISTING ROWS (V1, preserved):**

OBL-D11-01 through OBL-D11-07 cover §5.1-5.5 plus DOC24 R2.5 §22 receipt subsystem and R15 amendment. (Full detail in V2.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D11-08:** Semantic search boundary clarification | DOC11 clarifies OpenClaw-native semantic memory search and EC-owned ELNOR memory retrieval are separate systems; DOC11 does not assume Gateway RPC seam for EC/QMD semantic search | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §5.6 (Part 1 + Part 2 R2.1)
- **Why:** Prevents ownership confusion. OpenClaw's native search and ELNOR's EC-owned memory search are distinct lanes per DOC18 boundary rule.
- **Acceptance:** DOC11 contains a clarifying note in retrieval/search section explicitly excluding Gateway RPC for EC/QMD semantic search.
- **Calibrated against:** DOC15 R3.1 (stale); cross-check against DOC11 R14 + R15 amendment proposal which may have addressed this.
- **Created:** 2026-04-26

| **OBL-D11-09:** Context card / context plan acceptance (R3 expansion) | DOC11 accepts and renders the CIL-produced context card or context plan | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §4.1 (Part 2 R3)
- **Why:** Companion to OBL-D11-01 at the runtime level. DOC11 must accept the upstream-prepared plan.
- **Acceptance:** DOC11 packet builder accepts ContextCardSchema or ContextPlanSchema as input.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D11-01 (bootstrap accepts ContextPlan)
- **Created:** 2026-04-26

| **OBL-D11-10:** Prompt truth and packet inspector (R3 expansion) | DOC11 exposes runtime truth for: active overlay IDs, active prompt recipe IDs, dropped/trimmed overlay reasons, active review target inclusion, candidate apply-gate truth | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §4.2 (Part 2 R3)
- **Why:** Inspector and advisor need to see what's actually in the packet vs what was dropped, with reasons.
- **Acceptance:** DOC11 runtime truth includes 5 listed fields; exposed via packet inspector route.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D11-11:** Runtime packet inspector explanation (R3 expansion) | Inspector exposes enough truth to explain: what was actually injected, what was dropped, whether prompt-artifact application is blocked by runtime truth | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §4.3 (Part 2 R3)
- **Why:** Companion to OBL-D11-10. Inspector must answer "why was X not applied" with concrete runtime evidence.
- **Acceptance:** Inspector returns per-overlay/per-card disposition: applied/trimmed/dropped/blocked with reason code.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D11-12:** Lane-aware authority render plan acceptance (#49 / R3 expansion) | DOC11 packet truth accepts: `authority_selection_summary`, `authority_render_plan`, per-record `lane`, `render_form`, `hot_path_salience`, `salience_breakdown` | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.C (Part 3) / Capture point #49
- **Why:** Per Part 3 owner split: "DOC11 owns runtime packet/context-card truth where packet-level explanation is required."
- **Acceptance:** DOC11 packet inspector exposes authority_render_plan field per dispatch with all listed sub-fields.
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-EC-07 (lane-aware render plan upstream)
- **Created:** 2026-04-26

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D11-NEW-01:** Handoff revalidation on policy_generation_id | DOC11 must revalidate policy_generation_id is current at packet handoff; abort and reassemble if stale | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-004; Landing Plan V1 §4 OBL-D11-NEW-01
- **Why:** Privacy/policy mutations during in-flight packet assembly can cause revoked-source content to reach the model. The race window closes only if DOC11 checks the policy generation snapshot immediately before dispatch.
- **Acceptance:** DOC11 handoff handler reads packet manifest's policy_generation_id, queries EC PolicyDecisionEngine for current generation, aborts dispatch if mismatch and triggers reassembly.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming)
- **Depends on:** UnifiedInjectionManifest schema (DOC24 R3 §38.2); EC PolicyDecisionEngine generation tracking (OBL-EC-NEW-02)
- **Blocks:** DOC24 R3 Bundle A (§38 race-safety)
- **Created:** 2026-04-26

| **OBL-D11-NEW-02:** Consume PacketPreDispatchLintResult; refuse dispatch on lint failure | DOC11 reads lint result attached to packet; refuses dispatch and surfaces blocking failures if lint failed | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-121; Landing Plan V1 §4 OBL-D11-NEW-02
- **Why:** The pre-dispatch linter (DOC24 R3 §38.11) catches the failure classes red teams identified. Without DOC11 honoring the lint result, the linter is decorative.
- **Acceptance:** DOC11 dispatch path checks `lint_result.passed`; if false, dispatch is blocked with user-visible explanation listing blocking_failures.
- **Calibrated against:** DOC24 R3 (forthcoming)
- **Depends on:** PacketPreDispatchLintResult schema (DOC24 R3 §38.11)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D11-NEW-03:** Runtime truth reconciliation contract | DOC11 implements RuntimeTruthReconciliationSchema reconciliation when runtime outcome differs from receipt | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-024; Landing Plan V1 §4 OBL-D11-NEW-03
- **Why:** Action receipts can diverge from runtime truth (e.g., tool reports "sent email" but runtime shows no message sent). Without reconciliation, user sees false action-completion.
- **Acceptance:** DOC11 emits `action.receipt.reconciled_with_runtime_truth` events with full RuntimeTruthReconciliationSchema payload (compared_fields, mismatch_kind, reconciled_status); read-model updates correspond.
- **Calibrated against:** DOC24 R2.5; DOC24 R3 (forthcoming); EC Core
- **Depends on:** RuntimeTruthReconciliationSchema (DOC24 R3 §18.3A)
- **Blocks:** —
- **Created:** 2026-04-26

---

### §6.9 DOC12 — Inter-Agent Communication

**EXISTING ROWS (V1, preserved):**

OBL-D12-01 through OBL-D12-07 cover §2.1-2.6 and DOC24 R2.5 §22 graph projection. (Full detail in V2.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D12-08:** Active review target auto-pinning | Active review target pin state exported to CIL/DOC7 so CIL can request full-text retention | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §2.7 (Part 1)
- **Why:** Protects current review target from compression. CIL needs to know what's actively being reviewed.
- **Acceptance:** DOC12 emits `room.active_target_pinned` event; pin state queryable.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D12-09:** Room document context binding metadata | Room document binding metadata exported so CIL/advisors know what documents are in play | `[ENH] [PARTIAL]` |

- **Source:** DOC15 R3.1 §2.8 (Part 1)
- **Why:** Without document binding metadata, CIL can't reason about doc-relevance to the room.
- **Acceptance:** DOC12 room state exposes `bound_documents: DocumentRef[]`.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D12-10:** Moderator round-transition advisory hook | Explicit round-transition hook allowing "before next round, consider X" advisory | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §2.9 (Part 1)
- **Why:** Future round-transition advice path for moderator agents.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D12-11:** Room-close bundle (R3 expansion) | Room-close bundle contains: ReviewOutcome, findings-starred count, novelty signals, goal type, close reason, user-goal-met, prompt-lineage summary | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §5.1 (Part 2 R3)
- **Why:** Companion to OBL-D12-01 at field-level. Bundle is the structured payload at room close.
- **Acceptance:** RoomCloseBundleSchema published with 7 listed fields; emitted on every room close.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D12-01 (room close signal emission), OBL-D14-02 (ReviewOutcomeSchema)
- **Created:** 2026-04-26

| **OBL-D12-12:** Active review target stable exports (R3 expansion) | DOC12 exposes `review_target_kind`, active target refs, room document context as stable exports consumed by CIL | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §5.2 (Part 2 R3)
- **Why:** CIL needs stable handles to query what the room is currently reviewing.
- **Acceptance:** DOC12 read API exposes 3 fields per room.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D12-08
- **Created:** 2026-04-26

| **OBL-D12-13:** Prompt-plan query / overlay state export (R3 expansion) | DOC12 exposes real room-state truth for prompt-artifact recommendation alignment | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §5.3 (Part 2 R3)
- **Why:** Prompt-artifact recommendations need to know what's currently overlaid in the room.
- **Acceptance:** DOC12 read API returns `current_overlays: OverlayRef[]` and `current_prompt_plan: PromptPlanSchema` per room.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D12-14:** Partial close / replay-safe journal (R3 expansion) | DOC12 preserves partial-close state so CIL learning does not over-claim finality | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §5.4 (Part 2 R3)
- **Why:** A partial close (user navigates away mid-room) shouldn't be treated as a clean close by the learning loop.
- **Acceptance:** DOC12 distinguishes `clean_close` vs `partial_close` in close events; CIL filter excludes partial closes from goal-met learning.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

---

### §6.10 DOC13 — Cost Tracking & Enforcement

**EXISTING ROWS (V1, preserved):**

| **OBL-D13-01:** Cost firewall coordination | Cross-doc cost limit enforcement | `[REQ] [PARTIAL]` |
| **OBL-D13-02:** Cost data for DispatchCheckpoint | Cost reporting at dispatch | `[REQ] [PARTIAL]` |

(Full detail in V2.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D13-03:** Room/participant cost tagging (R3 expansion) | DOC13 adds room/participant cost tagging for review and prompt-artifact evaluation runs | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §13 (Part 2 R3) — first bullet
- **Why:** Without per-room/per-participant cost tagging, evaluation runs can't be cost-attributed.
- **Acceptance:** DOC13 cost records include `room_id?`, `participant_id?`, `evaluation_run_id?` fields.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D13-04:** Supervision-cost snapshots (R3 expansion) | DOC13 supports supervision-cost snapshots | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §13 (Part 2 R3) — second bullet
- **Why:** Supervision cost (reviewer agent overhead) needs to be tracked separately from primary work cost.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

| **OBL-D13-05:** Launch-time estimate support (R3 expansion) | DOC13 supports launch-time cost estimates for configurator surfaces | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §13 (Part 2 R3) — third bullet
- **Why:** Configurator surfaces (panel setup, room creation) need pre-launch cost estimates so user can decide before committing.
- **Acceptance:** DOC13 exposes `estimateCost(config: LaunchConfig) → CostEstimate` API.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

---

### §6.11 DOC14 — CANDOR

**EXISTING ROWS (V1, preserved):**

OBL-D14-01 through OBL-D14-06 cover §1.1-1.6. (Full detail in V2.)

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-D14-07:** Review advisor and document pinning notes | Review-advisor note in DOC14 (route review explanations to appropriate advisor); red-team document pinning rules (keep active review target full-text and visible) | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §1.7 (Part 1)
- **Why:** Review advisor flow needs DOC14 to declare its advisor; pinning rules protect target docs from compression.
- **Acceptance:** DOC14 includes section on review-advisor wiring and document pinning rules.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-26

| **OBL-D14-08:** Prompt-artifact observation emissions (R3 expansion) | DOC14 emits observation signals about: overlay effectiveness, prompt recipe effectiveness, candidate rewrite outcomes, replay/canary outcomes | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §6.2 (Part 2 R3)
- **Why:** Without prompt-artifact observation emissions from DOC14, the prompt-artifact learning loop has no quality signal.
- **Acceptance:** DOC14 publishes 4 typed observation events with attribution to producing dispatch.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** —
- **Blocks:** OBL-D8-08 (DOC8 prompt-artifact lifecycle consumes these)
- **Created:** 2026-04-26

| **OBL-D14-09:** Promote DOC14 companion D15 rows into owners (R3 expansion) | The following rows may not remain companion-only: D15-RT-001 Prompt artifact recommendation node, D15-RT-002 Recommendation retrieval path, D15-RT-003 Reverse-path fields, D15-RT-004 Finding novelty / review outcome ingestion, D15-RT-005 Context matcher expansion | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 §6.3 (Part 2 R3)
- **Why:** Companion-doc-only rows are at risk of being lost. Each should become an owner doc obligation.
- **Acceptance:** Each D15-RT row exists as a corresponding obligation in this OP-A tracker (under appropriate target doc) with explicit owner.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26
- **Notes:** This is a meta-obligation: it requires next OP-A maintenance pass to verify each D15-RT row has a corresponding row here.

---

### §6.12 DOC15 — Cognitive Infrastructure Layer

**EXISTING ROWS (V1, preserved):** OBL-D15-01 through OBL-D15-05.

DOC15 R3.1 contract is the cross-doc obligation document; OP-A V3 has now folded its content. After this V3, DOC15 R3.1 is archived per V2 carryover §9; new DOC15-internal obligations enter via DOC15 R7.1 spec revision.

| **OBL-D15-06:** Receipt receipt/lane truth boundary distinction (R3 expansion) | DOC15 explicitly relies on retrieval receipt/lane truth from DOC10/DOC18 while keeping topology/read-model truth separate | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 Part 2 R3 §V Acceptance D
- **Why:** Acceptance condition for R3 contract — semantic summary may never impersonate exact source text without receipt disclosure.
- **Acceptance:** DOC15 implementation enforces this rule in CIL UI rendering paths.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D15-NEW-01:** Coordinate with DroppabilityClass for hard_required preservation | DOC15 budget governance recognizes DOC24's `DroppabilityClass` enum and protects `hard_required` cards from utility-driven trimming | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-019; Landing Plan V1 §4 OBL-D15-NEW-02
- **Why:** DOC24 R3's overconstrained budget protocol fails closed when hard_required content can't fit. DOC15's budget allocations must respect this — the budget seam can't silently force-drop hard_required cards.
- **Acceptance:** DOC15 hot-path interactive profile and other budget allocations expose hard_required reservation semantics; non-droppable cards never trim under budget pressure (block instead).
- **Calibrated against:** DOC15 R3.1 (March 12, 2026 — predates DOC24 R3); DOC24 R3 (forthcoming)
- **Depends on:** DroppabilityClass schema (DOC24 R3 §27.0A)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D15-NEW-02:** Adaptive packet budgeting coordination *(V3.2 — added per audit; DOC24 R3 §19.1B)* | DOC15 budget governance accepts DOC24's `AdaptiveBudgetingPolicy` outputs as inputs to subsequent allocation rounds; honors min_lane_proportion_floor and max_lane_proportion_drift caps | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 §19.1B (audit-added per ADJ-RT-099); DOC24 R3 Adjudication Card V3 §ADJ-RT-099
- **Why:** R2.5's budget waterfall was static given inputs. R3 §19.1B adds adaptive feedback — when BDSM utility signals show consistently underutilized lanes, the next allocation adjusts proportions within bounded caps. Per ADJ-RT-099 reasoning, this MUST pair with §26.6 max_injection_boost to prevent runaway expansion. DOC15's budget governance is the upstream allocator and must honor the adjusted proportions on subsequent rounds.
- **Acceptance:** DOC15 budget service consumes `AdaptiveBudgetingPolicy.lane_proportion_drift` outputs; respects floor and drift caps; emits telemetry on adjustment.
- **Calibrated against:** DOC15 R3.1; DOC24 R3 (final)
- **Depends on:** AdaptiveBudgetingPolicy schema (DOC24 R3 §19.1B); max_injection_boost cap (DOC24 R3 §26.6 / ADJ-RT-022)
- **Blocks:** —
- **Created:** 2026-04-27 (V3.2 audit)

---

### §6.13 DOC16 — M365 Integration

(Existing OBL-D16-01, OBL-D16-02 preserved from V2. No new DOC15 R3.1 obligations targeting DOC16 directly; cross-references in §1.7 review-advisor noted but tracked under DOC14.)

---

### §6.14 DOC18 — LlamaIndex Retrieval Sidecar

**NEW ROWS (V3, from DOC15 R3.1 expansion — V2 had none):**

| **OBL-D18-01:** Retrieval receipt and corpus truth emission (#41 / R2.1) | Semantic-corpus results and sidecar-assisted recommendations export `provider_kind`, `search_lane`, `corpus_id`, `freshness_state`, `degraded_reason`, `route_reason` into route traces / read models | `[ENH] [MISSING]` |

- **Source:** DOC15 R3.1 §7A.1 (Part 2 R2.1) / Priority Matrix #41
- **Why:** Lets CIL explain semantic document suggestions truthfully instead of treating them as generic "search."
- **Acceptance:** DOC18 every result includes 6 listed fields; conforms to RetrievalReceiptSchema (OBL-D10-09).
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D10-09 (RetrievalReceiptSchema)
- **Blocks:** OBL-D10-08 (CIL surface rendering)
- **Created:** 2026-04-26

| **OBL-D18-02:** Boundary rule — sidecar does not become canonical | DOC18 keeps corpus-scoped retrieval provider truth but does NOT become canonical memory, matter identity, or permission truth | `[REQ] [EXISTS]` |

- **Source:** DOC15 R3.1 §7A.2 (Part 2 R2.1)
- **Why:** Prevents sidecar drift into a second hidden memory system. Architectural invariant.
- **Acceptance:** DOC18 contains explicit boundary statement; reviewers check during DOC18 revisions.
- **Calibrated against:** DOC15 R3.1 (stale); aligned with V3 carryover Invariant #15 (LlamaIndex is sidecar).
- **Created:** 2026-04-26
- **Notes:** Likely already enforced by current DOC18 R2 boundary statements. Verify.

| **OBL-D18-03:** DOC18 receipt and lane truth (R3 expansion) | DOC18 must guarantee provider receipt fields, corpus truth, degraded reason codes, route reason codes, explicit topology-not-owned boundary note | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 §10 (Part 2 R3)
- **Why:** R3 contract elevates these from R2.1 ENH to R3 REQ. Without them, the receipt-based explanation pipeline has gaps.
- **Acceptance:** DOC18 publishes guarantee statement and emits compliant receipts.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D18-01 (overlapping but more comprehensive)
- **Created:** 2026-04-26
- **Notes:** Consolidates with OBL-D18-01 — could be merged in next maintenance pass; preserved separately to maintain provenance from R2.1 vs R3.

---

### §6.15 DOC20 — Browser/Notes/Document Viewer

(Existing OBL-D20-01 through OBL-D20-03 preserved from V2 — these come from DOC24 R2.5 §22, not DOC15 R3.1. DOC15 R3.1 has no obligations directly targeting DOC20.)

---

### §6.16 DOC21 / DOC22 — Master UI Spec / Page Inventory

(Existing OBL-D21-01 through OBL-D21-03 preserved from V2 — these come from DOC24 R2.5 §22. DOC15 R3.1 has no direct UI-page obligations beyond what flows through DOC10 transport.)

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D21-NEW-01:** R3 inspector affordances — pages and routes | DOC21/22 register pages/routes for DOC24 R3 §38.10 inspector obligations: Why Cards, suppression reason inspector, suspended-context revival surface, demonstration interruption review, matter slot picker, disambiguation surface, tool bootstrap confirmation, source exclusion inspector, digest disposition picker, source policy revocation cascade preview | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-052, 102, 030, 029, 068, 016, 119, 003, 026, 005, 049 (10 cards converging on UI obligations); Landing Plan V1 §6 UI obligations rollup
- **Why:** DOC24 R3 specifies inspector/affordance behavior but page registration and route paths live in DOC21/22. Without this, R3's UI obligations are floating — spec says affordance exists, no page hosts it.
- **Acceptance:** DOC21/22 inventory adds 11 new pages or page-fragments (one per affordance row in Landing Plan V1 §6 table); each has registered route path, parent page, and component reference.
- **Calibrated against:** DOC24 R3 (forthcoming); DOC20 R3+ (where browser/notes integration pages live)
- **Depends on:** DOC24 R3 §38.10 obligations
- **Blocks:** R3 implementation (no UI surface = no observable behavior)
- **Created:** 2026-04-26

| **OBL-D21-NEW-02:** Bulk action affordances on review surfaces *(V3.2 — added per audit; DOC24 R3 §20.7A)* | DOC21/22 implement bulk-action UI patterns for review surfaces: multi-select with checkbox column, bulk operations (accept, reject with evidence prompt, defer, archive with destructive confirmation, rescope), filter-then-bulk, selection persistence across pagination | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 §20.7A bulk action affordances (audit-added per ADJ-RT-079); DOC24 R3 Adjudication Card V3 §ADJ-RT-079
- **Why:** Without bulk affordances, the calcification mitigation (per ADJ-RT-049) doesn't work — users can't realistically sweep 100+ low-confidence entities one at a time. The Authority Audit surface specifically (per Grok MED-04) needs bulk rescope, bulk demote, bulk re-anchor.
- **Acceptance:** DOC21/22 page inventory includes bulk-action UI patterns for: entity browser, suggestions inbox, digest review, authority audit, source policy review. Bulk operations follow `POST /api/{surface}/bulk-{action}` route convention with idempotency keys.
- **Calibrated against:** DOC24 R3 (final); DOC24 R3 §20.7A
- **Depends on:** OBL-EC-NEW-03 (route registry — bulk routes registered)
- **Blocks:** Calcification mitigation (DOC24 §20.6 / ADJ-RT-049)
- **Created:** 2026-04-27 (V3.2 audit)
- **Notes:** Distinct from OBL-D21-NEW-01 (inspector pages). OBL-D21-NEW-01 is page registration; OBL-D21-NEW-02 is interaction patterns within those pages.

---

### §6.17 DOC23 — Task System

(no current obligations recorded; DOC15 R3.1 contract has no direct DOC23 obligations.)

---

### §6.18 DOC24 — Unified Knowledge, Capability, and Onboarding (R2.5+)

(Existing OBL-D24-01 through OBL-D24-34 preserved from V2 — these come from V2 DOC24 review and DOC24 §22, not DOC15 R3.1. DOC15 R3.1 is a CIL companion contract; DOC24 is referenced indirectly via shared seams (e.g., advisor transport at DOC10) but has no direct DOC15 R3.1 obligations.)

---

### §6.19 DOC25 — Document Intelligence & Universal Ingestion

(Existing OBL-D25-01, OBL-D25-02 preserved from V2. DOC25 V2.0 supersedes V1.0; DOC25_IngestionResult contract finalized in DOC25 V2.0 §17. Update OBL-D25-01 status to `[REQ] [EXISTS]` when DOC73 V1.5 dereferences inlined schema.)

---

### §6.20 DOC72 — Hyper Intelligence Overlay (R5.73+)

(Existing OBL-D72-01 through OBL-D72-05 preserved from V2. DOC72 R5.73 has absorbed GIE V2.2 (29 patches NP01-NP29) into §42A; verify each OBL-D72 row against R5.73 — may now be `[REQ] [EXISTS]` for several. Rerun verification during next DOC72 revision pass.)

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D72-NEW-01:** AuthoritySourceClass schema on DomainSignalProfile | New schema enumerating authority source classes (binding_law, manufacturer_reference, clinical_guideline, language_specification, user_locked, etc.) per DomainSignalProfile | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-002 cross-doc cascade; Landing Plan V1 §4 OBL-D72-NEW-01
- **Why:** Without per-domain authority source classification, the DOC24 R3 confidence-floor fix cannot identify which claims are source-anchored vs internally derived. DOC73 §3.2A.1 cascade also requires this upstream.
- **Acceptance:** DOC72 R6+ adds AuthoritySourceClass enum, each DomainSignalProfile populates the relevant subset (legal: binding_law/persuasive_law/secondary_authority; medical: clinical_guideline/regulatory_directive/manufacturer_reference; etc.).
- **Calibrated against:** DOC72 R5.73; DOC24 R3 (forthcoming); DOC73 V1.4.1
- **Depends on:** —
- **Blocks:** OBL-D72-NEW-02 (AuthorityAnchor trait); OBL-D73-NEW-01 (authority_of branches)
- **Created:** 2026-04-26

| **OBL-D72-NEW-02:** AuthorityAnchor trait applicable to multiple node kinds | Trait that VersionedClaim, ConsolidatedUnderstanding, and other relevant node kinds can carry; pins authority that doesn't depend on local Beta confidence | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-002 cross-doc cascade; Landing Plan V1 §4 OBL-D72-NEW-02
- **Why:** The DOC24 R3 fix (authority anchor preserves primary_tag; confidence controls hedge_mode) requires DOC72 to expose the anchor as a queryable trait. Without it, DOC24 has no upstream source for `authority_anchor: true` claims.
- **Acceptance:** DOC72 R6+ defines AuthorityAnchor trait with fields {authority_source_class, anchor_evidence_ref, anchored_at, anchor_confidence_floor}; nodes can carry the trait; queries can filter by it.
- **Calibrated against:** DOC72 R5.73
- **Depends on:** OBL-D72-NEW-01
- **Blocks:** OBL-D73-NEW-01, OBL-D73-NEW-02
- **Created:** 2026-04-26

| **OBL-D72-NEW-03:** tool_capability sparsity tier in §2.2 with promotion rule | tool_capability node kind added to sparsity table with Tier C default; promotion rule expressed in terms of ToolCapabilityExperienceCounters (per ADJ-RT-009) | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-008, §ADJ-RT-009; Landing Plan V1 §4 OBL-D72-NEW-03
- **Why:** DOC72 R5.73 §2.2 sparsity table doesn't include tool_capability. With ~50-200 tool nodes at scale, lack of tier assignment causes uniform expensive lookups.
- **Acceptance:** §2.2 adds row for tool_capability with `default_tier: C` and `promotion_rule: user_visible_invocation_count >= N AND distinct_context_support >= M AND age_days >= 7`. Specific N/M values are starter config.
- **Calibrated against:** DOC72 R5.73
- **Depends on:** ToolCapabilityExperienceCounters schema (DOC24 R3 §14.6 ADJ-RT-009)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D72-NEW-04:** Five-value staleness enum confirmation | DOC72 staleness enum (`fresh | stale | verification_required | expired | invalidated`) confirmed canonical; DOC24 R3 aligns to it | `[REQ] [EXISTS — verify]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-031; Landing Plan V1 §4 OBL-D72-NEW-04
- **Why:** ChatGPT V2 review noted DOC24 R2.5 listed four-value enum stale to DOC72 R5.72's five-value enum. DOC72 R5.73 likely has the five-value form; DOC24 R3 adopts it.
- **Acceptance:** Verify §16.2 in DOC72 R5.73 has the five-value enum; if so, mark `[REQ] [EXISTS]` and the obligation is informational only. If R5.73 still has four values, this becomes a real DOC72 amendment requirement.
- **Calibrated against:** DOC72 R5.73
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D72-NEW-05:** WorkContextConstellation derived read-model *(V3.2 — added per audit; DOC24 R3 §13.4A.14)* | DOC72 publishes a `WorkContextConstellation` read-model derived from graph community detection (Louvain or similar). Strictly read-model — does NOT introduce a new node kind into the entity graph. | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 §13.4A.14 (audit-added per ADJ-RT-105); DOC24 R3 Adjudication Card V3 §ADJ-RT-105
- **Why:** DOC24 R3's step 4 workspace context can boost entities in high-strength constellations. The clustering must run as a Tier 3 background pass over the graph; results populate a separate projection. ChatGPT V2 critique correctly insists on read-model-only — automatic clustering must NOT become a second-truth that conflicts with user-stated relationships. DOC72 owns the graph; DOC72 owns the read-model produced from it.
- **Acceptance:** DOC72 R6+ defines `WorkContextConstellation` projection schema (constellation_id, entity_refs, detection_method, detected_at, cluster_strength, is_user_pinned). Tier 3 background job runs detection. Constellations consumable via DOC24 §13.4A workspace context boost and §35 cache warming. NO new node_kind added to DOC72 §2.x sparsity table.
- **Calibrated against:** DOC72 R5.73; DOC24 R3 (final)
- **Depends on:** —
- **Blocks:** DOC24 §13.4A.14 workspace boost integration; DOC24 §35.2 predictive warming via constellation patterns
- **Created:** 2026-04-27 (V3.2 audit)

---

### §6.21 DOC73 — Positronic Brain Enhancement (V1.4.1+)

(Existing OBL-D73-01, OBL-D73-02 preserved from V2. DOC73 V1.4.1 is operative per architect (master spec list R2.7 still labels CONCEPT DRAFT — registry update queued). Re-verify OBL-D73 rows against operative V1.4.1.)

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-D73-NEW-01:** §3.2A.1 authority_of() branches on AuthorityAnchor before VersionedClaim Beta path | Authority resolution function checks for AuthorityAnchor trait before falling through to Beta-derived authority via VersionedClaim | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-002 cross-doc cascade (ISS-01b); Landing Plan V1 §4 OBL-D73-NEW-01
- **Why:** Without this branch, AuthorityAnchor exists but doesn't influence ConsolidatedUnderstanding authority computation. The lowest-watermark rule continues to drag binding-authority claims down via local Beta confidence.
- **Acceptance:** DOC73 V1.5+ §3.2A.1 first checks node.authority_anchor; if present, returns `authority_anchor.anchor_confidence_floor` (or higher); only falls through to `beta_to_authority(node.confidence)` if no anchor.
- **Calibrated against:** DOC73 V1.4.1
- **Depends on:** OBL-D72-NEW-02 (AuthorityAnchor trait)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D73-NEW-02:** §3.3 carve-out cross-references AuthorityAnchor | Lowest-watermark rule explicitly carves out anchored claims (anchor floor protects against drag-down from co-occurring low-confidence claims) | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-002 cross-doc cascade; Landing Plan V1 §4 OBL-D73-NEW-02
- **Why:** Without the carve-out, ConsolidatedUnderstanding lowest-watermark over heterogeneous claims still pulls anchored authority down. The §3.2A.1 fix protects the function output but the §3.3 aggregation path is a parallel cascade.
- **Acceptance:** DOC73 V1.5+ §3.3 lowest-watermark explicitly excludes anchored claims from drag-down; documents the carve-out reasoning.
- **Calibrated against:** DOC73 V1.4.1
- **Depends on:** OBL-D72-NEW-02; OBL-D73-NEW-01
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-D73-NEW-03:** Structured memory operations align with living memory | DOC73 living-memory operations (§3.3 and surroundings) explicitly reference structured operations from DOC24 R3 §13.5 (create / merge / narrow_scope / split / supersede / mark_contested / field_lock / field_adapt) | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-092 (ChatGPT Idea 4); Landing Plan V1 §4 OBL-D73-NEW-03
- **Why:** DOC73 V1.4.1 already has living-memory semantics conceptually; structured operations from the adjudication card formalize the operation set. Aligns DOC24 memory.update verbs with DOC73's living-memory model.
- **Acceptance:** DOC73 V1.5+ §3.3+ enumerates the operation set; DOC24 R3 §13.5 references DOC73 as the operation owner.
- **Calibrated against:** DOC73 V1.4.1
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26
- **Notes:** May be partially satisfied by current DOC73 V1.4.1 living-memory architecture; verify which operations already exist before treating as fully `[MISSING]`.

---

### §6.22 EC Core / DocIndex

**EXISTING ROWS (V1, preserved):** OBL-EC-01 through OBL-EC-06.

**NEW ROWS (V3, from DOC15 R3.1 expansion):**

| **OBL-EC-07:** Lane-aware authority render plan (#49 / R3 expansion) | Context assembly accepts authority_selection_summary, authority_render_plan, per-record lane, render_form, hot_path_salience, salience_breakdown | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.C (Part 3) / Capture point #49
- **Why:** Per Part 3 owner split: "EC Core owns the assembly/planning checkpoint truth."
- **Acceptance:** EC Core context-assembly checkpoint persists authority_render_plan with all listed fields.
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-D1-13 (authority salience field set)
- **Blocks:** OBL-D11-12 (DOC11 packet truth consumption)
- **Created:** 2026-04-26

| **OBL-EC-08:** Authority-specific telemetry emission (#48 / R3 expansion) | EC Core emits AuthorityHotPathTelemetryEvent (11-value event_type enum: selected/inline_full/inline_compact/ref_only/trimmed_due_to_budget/skipped_cooled/origin_viewed/rescope/revoke/set_persistence_class/set_review_after) | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.B (Part 3) / Capture point #48
- **Why:** EC Core is the emission point; DOC10 is the transport.
- **Acceptance:** EC Core context-assembly path emits AuthorityHotPathTelemetryEvent on each per-authority decision.
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-D1-13
- **Blocks:** OBL-D10-13 (DOC10 transport)
- **Created:** 2026-04-26

| **OBL-EC-09:** Operation compiler routes (R3 expansion) | EC Core publishes: `POST /api/cil/operation` (compile OperationIntent → ResolvedOperation), `GET /api/cil/operation/:resolution_id` (retrieve compiled operation) | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §2.1 (Part 2 R3)
- **Why:** Companion to OBL-EC-04 (operation compiler entry point) at route level.
- **Acceptance:** EC Core HTTP handler publishes both routes.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-EC-04
- **Created:** 2026-04-26

| **OBL-EC-10:** Context assembly acceptance (R3 expansion) | EC Core context assembly accepts: ContextPlanSchema, transient-instruction pass-through, authority lane summaries, retrieval receipts, support-pack preview/apply decisions | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §2.2 (Part 2 R3); §11.3A (Part 1) / Priority Matrix #38
- **Why:** Companion to OBL-D1-06 (transient/durable split). EC Core is the consumer.
- **Acceptance:** Context assembly accepts 5 listed inputs; transient instructions stay out of durable authority unless separately saved.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-D1-06
- **Blocks:** —
- **Created:** 2026-04-26
- **Notes:** Critical for "no phantom memories / no auto-promotion" failure mode.

| **OBL-EC-11:** Authority application trace + skip reason taxonomy (#39, #50 / R3 expansion) | Dispatch/context-assembly read models export per authority record: authority_id, display_label, scope, persistence_class, lane, render_form, hot_path_salience, salience_breakdown, applied, skipped_reason; skipped_reason enum: scope_mismatch / budget_trim / cooled_to_ref_only / cooled_to_inspector_only / suppressed_by_stronger_scope / duplicate / revoked | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §11.4A (Part 1) / Priority Matrix #39; §R3.1.D (Part 3) / Capture point #50
- **Why:** Inspector/advisor must explain exactly why a rule did or did not apply, with concrete skipped_reason codes.
- **Acceptance:** Read model exposes 10 listed fields per authority record per dispatch; skipped_reason uses 7-value enum.
- **Calibrated against:** DOC15 R3.1 (stale); Part 3 (undated)
- **Depends on:** OBL-EC-07, OBL-D1-13
- **Blocks:** OBL-D10-12 (Authority Audit surface)
- **Created:** 2026-04-26

| **OBL-EC-12:** Authority maintenance command ingestion (#51 / R3 expansion) | EC Core ingests authority maintenance commands (rescope/revoke/set_expiry/set_review_date/set_persistence_class/set_injection_preference/mark_foundational/prefer_compact_render); writes durable after DOC6 approval | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §R3.1.E (Part 3) / Capture point #51
- **Why:** Per Part 3 owner split: "EC Core owns command ingestion and durable write execution after approval."
- **Acceptance:** EC Core command queue accepts 8 listed commands; routes through DOC6 approval lane before DOC1 durable write.
- **Calibrated against:** DOC15 R3.1 Part 3
- **Depends on:** OBL-D6-08 (DOC6 approval-gated proposals), OBL-D1-05 (mutation read model)
- **Created:** 2026-04-26

| **OBL-EC-13:** Topology read-model availability (#43 / R2.1) | Broader derived topology read-model over documents, claims, matters, workflow nodes, learned context exposed by stable IDs/aliases/bounded neighbor lookup | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §11.9 (Part 2 R2.1) / Priority Matrix #43
- **Why:** Enables future graph-aware CIL ranking, explanation, and document suggestions without making DOC15 the graph owner.
- **Acceptance:** EC Core / DocIndex exposes topology read API as a derived layer (rebuildable, not canonical) per V3 carryover Invariant #18.
- **Calibrated against:** DOC15 R3.1 (stale); cross-check against DOC72 R5.73 routing cascade — may overlap.
- **Depends on:** OBL-D72-04 (typed edges)
- **Blocks:** OBL-D7-07 (graph-aware document priority hints)
- **Created:** 2026-04-26

| **OBL-EC-14:** Contradiction/supersession edge exposure (#44 / R2.1) | Topology read models expose `contradicts`, `supersedes`, `supports`, `references`, `derived_from`, plus relation freshness/strength | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §11.10 (Part 2 R2.1) / Priority Matrix #44
- **Why:** Lets advisors/suggestion cards explain why material was down-ranked, hidden, or surfaced as replacement.
- **Acceptance:** Topology read API exposes 5 edge types with strength + freshness.
- **Calibrated against:** DOC15 R3.1 (stale); DOC72 R5.73 §4.6 may already cover.
- **Depends on:** OBL-EC-13
- **Blocks:** OBL-D7-08 (DOC7 contradiction-aware materialization)
- **Created:** 2026-04-26

| **OBL-EC-15:** Topology maintenance jobs and health export (#46 / R2.1) | Core/DocIndex build jobs maintain topology snapshots, freshness state, degraded/lagging health signals without mutating canonical truth | `[FUT] [MISSING]` |

- **Source:** DOC15 R3.1 §11.11 (Part 2 R2.1) / Priority Matrix #46
- **Why:** Keeps graph-backed explanation trustworthy during partial deployment.
- **Acceptance:** Build job catalog includes topology builders; health endpoint exposes freshness + degraded signals.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-EC-13
- **Created:** 2026-04-26

| **OBL-EC-16:** Context-change typed events (R3 expansion) | EC Core emits typed events for: model change, topology/read-model change, standing-order change, profile-definition change, runtime packet drift | `[REQ] [PARTIAL]` |

- **Source:** DOC15 R3.1 §2.3 (Part 2 R3); §11.5 (Part 1) / Priority Matrix #29, #30
- **Why:** Companion to OBL-EC-01 (standing-order event), OBL-EC-02 (profile-config event). R3 expands to 5 event types.
- **Acceptance:** EC Core emits 5 listed event types with consumers in CIL bridge.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Depends on:** OBL-EC-01, OBL-EC-02
- **Created:** 2026-04-26

| **OBL-EC-17:** Contract-health snapshot (R3 expansion) | EC Core exposes current-view read model that CIL Health can consume for companion-seam status | `[REQ] [MISSING]` |

- **Source:** DOC15 R3.1 §2.4 (Part 2 R3)
- **Why:** Health surface needs a snapshot of which companion seams are wired vs missing/degraded.
- **Acceptance:** EC Core publishes `/api/cil/contract-health` endpoint returning per-seam status.
- **Calibrated against:** DOC15 R3.1 Part 2 R3
- **Created:** 2026-04-26

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-EC-NEW-01:** RegisterRuntimeToolWithKnowledgeCommandSchema atomic command | EC command bus exposes single atomic command for tool registration that creates registry row + graph node + cache entry transactionally; rollback on partial failure | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-007; Landing Plan V1 §4 OBL-EC-NEW-01
- **Why:** §14.6 says EC "automatically" creates tool_capability node on registration but no transaction/saga is specified. Partial failures leave dangling nodes/cache entries; tool selection later returns null; learning never gets off the ground.
- **Acceptance:** EC Core defines RegisterRuntimeToolWithKnowledgeCommandSchema with atomic execution; ToolKnowledgeLinkState tracks reconciliation state (registry_only_pending_graph, graph_only_pending_registry, linked, failed_reconcile); compensating-transaction path on partial failure.
- **Calibrated against:** EC Core (current); DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC24 R3 Bundle D (Tool Capability)
- **Created:** 2026-04-26

| **OBL-EC-NEW-02:** PolicyDecisionEngine consumed at injection/cache/digest/dispatch boundaries | EC PolicyDecisionEngine is the single privacy/policy evaluator; DOC24 calls it at packet assembly, cache warming, digest generation, and DOC11 handoff | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-053, §ADJ-RT-003, §ADJ-RT-117; Landing Plan V1 §4 OBL-EC-NEW-02
- **Why:** Without single-evaluator pattern, DOC24 invents a parallel source-exclusion engine. PropA owns policy semantics; EC owns evaluation; DOC24 consumes decisions. Avoids second hidden privacy evaluator.
- **Acceptance:** PolicyDecisionEngine accepts ExposureContextSchema input (PropA-owned), returns PacketSourceEligibilityDecisionSchema; tracks policy_generation_id for race-safety; consumers (DOC24, DOC11) reference engine, not local evaluation.
- **Calibrated against:** EC Core (current); MultiDoc PropA R6.3; DOC24 R3 (forthcoming)
- **Depends on:** OBL-PROPA-NEW-01 (ExposureContextSchema)
- **Blocks:** DOC24 R3 Bundle A (Policy/Source); OBL-D11-NEW-01 (handoff revalidation)
- **Created:** 2026-04-26

| **OBL-EC-NEW-03:** Canonical route registry for §20.7 routes | EC Core owns the canonical route registry; DOC24 supplies route intents and read-model schemas; full per-route query schemas live in EC | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-063; Landing Plan V1 §4 OBL-EC-NEW-03
- **Why:** DOC24 §20.7 defers full per-route query schemas to "generated artifacts." Without an owner, coding agents will invent query parameters, pagination, error codes, and side effects. EC Core is the natural owner per its no-phantom-controls discipline.
- **Acceptance:** EC Core publishes route registry; DOC24 R3 §20.7 references registry; per-route query schemas exist in registry; CI gate validates DOC24 routes against registry.
- **Calibrated against:** EC Core (current); DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC24 R3 Bundle G (Routes/Events/Receipts)
- **Created:** 2026-04-26

| **OBL-EC-NEW-04:** Adversarial acceptance test harness in CI | EC Core CI runs the AdversarialAcceptanceTestSuite from DOC24 R3 §24; failure on any test indicates implementation drift from accepted adjudication | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-125; Landing Plan V1 §4 OBL-EC-NEW-04 and §5 acceptance test master list (74 tests)
- **Why:** Tests are what prevents adjudication card from becoming "another good document that implementation drifts away from." 74 tests cover the failure classes red teams identified across 4 reviewer rounds.
- **Acceptance:** EC Core CI pipeline includes AdversarialAcceptanceTestSuite stage; each test maps to specific ADJ-RT card; failure logs the card ID; tests cannot be skipped without explicit approval per documented R3 limitation.
- **Calibrated against:** DOC24 R3 (forthcoming); DOC24 R3 Landing Plan V1 §5
- **Depends on:** All ADJ-RT cards being implemented in DOC24 R3 (otherwise tests have nothing to verify)
- **Blocks:** R3 ship (cannot ship without tests passing)
- **Created:** 2026-04-26

---

### §6.23 BDSM — Behavioral Dynamics & Salience Matrix (V6.4+)

**NEW SECTION (V3.1).** BDSM did not have a §6 home in V3 — referenced by other obligations but no target-doc section. V3.1 creates this section; V3.2+ may add prior obligations from earlier reviews if needed.

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-BDSM-NEW-01:** Consume DeliveryDirective as canonical prompt-control vocabulary | BDSM does not create a second prompt-control language; DeliveryDirective `{primary_tag, hedge_mode, force_level, directive_source, reason_codes}` is the only vocabulary | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-001; Landing Plan V1 §4 OBL-BDSM-NEW-01
- **Why:** BDSM V6.4 already states this principle ("Matrix must not create a second prompt-control system"). The obligation is to ensure BDSM V6.5+ explicitly defines the canonical DeliveryDirective and lists the primary_tag enum (without DOC24-only flat tags like `low_confidence`, `external_view`, `community_consensus`, `synthesize`).
- **Acceptance:** BDSM V6.5+ §2/4.3/6.1-6.3 defines DeliveryDirective canonically; `low_confidence` becomes hedge_mode value, not primary_tag; DOC24 R3 references BDSM as schema owner.
- **Calibrated against:** BDSM V6.4; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC24 R3 Bundle B (DeliveryDirective + KDA Rendering Integration)
- **Created:** 2026-04-26

| **OBL-BDSM-NEW-02:** Consume UnifiedInjectionManifest with full field set | BDSM attribution reads UnifiedInjectionManifest including render_variant_id, template_version, exposure_class, suppression_kind | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-052, §ADJ-RT-116; Landing Plan V1 §4 OBL-BDSM-NEW-02
- **Why:** Without variant-level fields, BDSM attributes outcomes to underlying nodes when in fact the rendering variant caused the result. Variant-vs-content attribution becomes impossible.
- **Acceptance:** BDSM attribution code reads `manifest.render_variant_id`, `manifest.template_version`, `manifest.exposure_class`, `manifest.suppression_kind`; attributes outcome to the (node, variant, template) triple, not just node.
- **Calibrated against:** BDSM V6.4; DOC24 R3 (forthcoming)
- **Depends on:** UnifiedInjectionManifestSchema (DOC24 R3 §38.2); OBL-KDA-NEW-03 (variant tracking source)
- **Blocks:** OBL-BDSM-NEW-04 (exposure-evidence attribution)
- **Created:** 2026-04-26

| **OBL-BDSM-NEW-03:** Filter feedback by MatrixExposureClass | Only `eligible_and_injected` (and optionally `eligible_reference_only`) cards produce direct utility signals; suppressed cards excluded | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-124, §ADJ-RT-021; Landing Plan V1 §4 OBL-BDSM-NEW-03
- **Why:** Without exposure-class filtering, BDSM treats budget-suppressed/policy-blocked/source-excluded cards as "user ignored" — pollutes utility ledger with non-signals.
- **Acceptance:** BDSM utility-update code filters by `manifest.exposure_class`; only eligible+injected and (optionally) eligible+reference produce updates.
- **Calibrated against:** BDSM V6.4; DOC24 R3 (forthcoming)
- **Depends on:** OBL-BDSM-NEW-02; UnifiedInjectionManifest exposure_class field
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-BDSM-NEW-04:** Outcome attribution requires exposure evidence | When attributing positive outcome to a card, BDSM verifies the card was attended to (not just included in packet); ignored-but-correlated cards don't get credit | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-118; Landing Plan V1 §4 OBL-BDSM-NEW-04
- **Why:** Per Gemini's KDA-vs-BDSM scenario: LLM ignores card 50× but user gives 5/5 outcome. KDA wants to drop card; BDSM wants to boost it. Resolution: outcome attribution requires exposure evidence (attention data, not just inclusion).
- **Acceptance:** BDSM attribution code requires attention/exposure evidence (e.g., LLM activation patterns over the card's tokens, or downstream output traces) before crediting outcome to a card; evidence-less attribution does not boost utility.
- **Calibrated against:** BDSM V6.4; DOC24 R3 (forthcoming)
- **Depends on:** OBL-BDSM-NEW-02; OBL-BDSM-NEW-03; KDA neuroplasticity (which provides the variant-tuning path that operates within BDSM's outcome constraint)
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-BDSM-NEW-05:** force_level cannot override policy | BDSM may assign `force_level: hard` but PropA/EC policy decisions are final; force_level operates within policy constraints | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-117; Landing Plan V1 §4 OBL-BDSM-NEW-05
- **Why:** Without explicit precedence, an implementer could plausibly read "force_level: hard means must inject" and override a policy decision — exact safety violation that ADJ-RT-023 protects against on the [enforce] tag side.
- **Acceptance:** BDSM V6.5+ explicitly states the precedence rule; force_level assignment is a constraint within policy-eligible candidates only; never short-circuits policy.
- **Calibrated against:** BDSM V6.4; MultiDoc PropA R6.3; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26

---

### §6.24 KDA — DOC24 KDA / Knowledge Delivery Architecture (R2+)

**NEW SECTION (V3.1).** KDA did not have a §6 home in V3 — referenced by other obligations but no target-doc section. V3.1 creates this section.

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-KDA-NEW-01:** Adopt DOC24 RenderingTier (compact \| standard \| full) as canonical | KDA RenderingTier enum aligns with DOC24 R3 RenderingTier (DOC24 owns the tier name space; KDA renders) | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-035; Landing Plan V1 §4 OBL-KDA-NEW-01
- **Why:** KDA R2 has `compact | standard | full`; DOC24 R2.5 had `full | compact | auto`. Mismatch on `standard` (KDA-only) and `auto` (DOC24-only). DOC24 R3 adopts KDA's three values; `auto` becomes a render-request hint, not a tier value.
- **Acceptance:** KDA R3+ confirms `RenderingTier = "compact" | "standard" | "full"` is canonical; DOC24 R3 §19.2 references KDA as schema owner; `auto` is not in the tier enum.
- **Calibrated against:** KDA R2; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** DOC24 R3 Bundle B
- **Created:** 2026-04-26

| **OBL-KDA-NEW-02:** Standardize ClientKind on `elnor_native` | KDA examples use `local_elnor`; DOC24 ClientKind uses `elnor_native`; standardize on `elnor_native` with migration alias | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-036; Landing Plan V1 §4 OBL-KDA-NEW-02
- **Why:** Mismatch causes silent failures in normalization logic; coding agent picks one form arbitrarily and the consumer expects the other.
- **Acceptance:** KDA R3+ uses `elnor_native` throughout; alias `local_elnor → elnor_native` documented for migration.
- **Calibrated against:** KDA R2; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26

| **OBL-KDA-NEW-03:** Record render_variant_id and template_version in manifest | KDA writes its rendering variant identifiers into the unified injection manifest at render time | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-116; Landing Plan V1 §4 OBL-KDA-NEW-03
- **Why:** BDSM attribution-pollution prevention (OBL-BDSM-NEW-02) requires KDA to source the variant-level fields. KDA neuroplasticity changes specializations over time; without per-render variant ID in the manifest, BDSM can't distinguish content-quality from variant-quality.
- **Acceptance:** KDA renderer populates `manifest.render_variant_id`, `manifest.template_version`, `manifest.rendering_specialization_id` on every card render.
- **Calibrated against:** KDA R2; DOC24 R3 (forthcoming)
- **Depends on:** UnifiedInjectionManifestSchema (DOC24 R3 §38.2)
- **Blocks:** OBL-BDSM-NEW-02
- **Created:** 2026-04-26

| **OBL-KDA-NEW-04:** Operate within outcome-relevance constraints from BDSM | KDA neuroplasticity tunes rendering variants within outcome-relevance constraints set by BDSM attribution; cannot drop a card BDSM credits with positive outcome | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-118; Landing Plan V1 §4 OBL-KDA-NEW-04
- **Why:** Resolves the KDA-vs-BDSM arbitration gap. KDA's attention-based dropping of cards must respect BDSM's outcome-based requirement to keep them; KDA explores variant changes instead.
- **Acceptance:** KDA neuroplasticity reads BDSM utility signals; cards with positive BDSM attribution are not dropped even if KDA attention metrics suggest dropping; KDA tries variant changes (different position, compaction tier, content phrasing).
- **Calibrated against:** KDA R2; BDSM V6.4; DOC24 R3 (forthcoming)
- **Depends on:** OBL-BDSM-NEW-04
- **Blocks:** —
- **Created:** 2026-04-26

---

### §6.25 MultiDoc PropA — Property/Authorization Architecture (R6.3+)

**NEW SECTION (V3.1).** PropA did not have a §6 home in V3 — referenced by other obligations but no target-doc section. V3.1 creates this section.

**NEW ROWS (V3.1, from DOC24 R3 Adjudication Card V3):**

| **OBL-PROPA-NEW-01:** ExposureContextSchema owned by PropA, consumed by DOC24 and EC PolicyDecisionEngine | PropA defines exposure-context vocabulary (automatic_packet_injection, explicit_memory_attach, outbound_dispatch, cache_warming, digest_generation, etc.); DOC24 passes context to PolicyDecisionEngine; engine returns decision | `[REQ] [PARTIAL]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-053; Landing Plan V1 §4 OBL-PROPA-NEW-01
- **Why:** Without owned ExposureContextSchema, DOC24 either extends SourcePolicyRecord ad hoc (which ChatGPT V2 critique correctly flagged as the wrong layer) or invents its own evaluator. PropA is the policy-semantics owner; this schema belongs there.
- **Acceptance:** PropA R6.x+ defines ExposureContextSchema with at least the contexts above; DOC24 R3 §27.0B references PropA as schema owner; EC PolicyDecisionEngine accepts schema as input.
- **Calibrated against:** MultiDoc PropA R6.3; DOC24 R3 (forthcoming)
- **Depends on:** —
- **Blocks:** OBL-EC-NEW-02 (PolicyDecisionEngine consumes schema)
- **Created:** 2026-04-26

| **OBL-PROPA-NEW-02:** Policy semantics for hard-block precedence over BDSM force_level | PropA documents the precedence rule: a policy block is final regardless of BDSM force_level; force_level operates within policy-eligible candidates only | `[REQ] [MISSING]` |

- **Source:** DOC24 R3 Adjudication Card V3 §ADJ-RT-117; Landing Plan V1 §4 OBL-PROPA-NEW-02
- **Why:** Companion obligation to OBL-BDSM-NEW-05. The precedence must be stated on both sides — BDSM acknowledges it can be overridden; PropA explains why.
- **Acceptance:** PropA R6.x+ §2 (operative precedence) explicitly states force_level cannot override policy; documents reasoning.
- **Calibrated against:** MultiDoc PropA R6.3
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26

---

## 7. By Target Document — Absorbed Obligations

(Empty — no obligations have been moved to absorbed in V3. Items move here when integrated into target doc revisions, with date and revision number.)

Schema for absorbed entries (when populated):

```
**OBL-DXX-NN:** [original obligation title]
- Absorbed into: DOC<N> R<X>
- Absorbed at: YYYY-MM-DD
- Verification: [acceptance test result, CI gate confirmation, or "verified by [reviewer] on [date]"]
- Notes: [any drift from original obligation, scope changes, etc.]
```

---

## 8. By Target Document — Deferred Obligations

(Empty — no obligations have been moved to deferred in V3. Items move here when explicitly punted with reason.)

Schema for deferred entries (when populated):

```
**OBL-DXX-NN:** [original obligation title]
- Deferred at: YYYY-MM-DD
- Deferred by: [Will / reviewer name]
- Reason: [why deferred]
- Re-evaluate when: [trigger condition or date]
```

---

## 9. Open Meta-Architecture Questions

Items not yet obligation-grade but worth not losing track of.

| Question | Surfaced By | Notes |
|---|---|---|
| Should the cross-doc tracking system collapse to fewer surfaces? | This tracker's existence | Once DOC OP-A is proven in use for some sessions, evaluate whether per-doc companions are still adding value or whether everything should live in DOC OP-A. **DOC15 R3.1 archive (this V3) is the first test case.** |
| **Inventory of cross-doc tracking documents inherited from CD Master Integration Index R1 — verification needed** (carried from V2) | CD Master Integration Index R1 (archived) | R1 listed several tracking documents whose existence/currency is NOT verified: DOC72 Knowledge Store Integration Map R2 + Verification, DOC10 Orchestration Integration Ledger R10 (DOC10 awaiting major revision), DOC16 Deferred Additions R5.3 (still in folder), Running Brief Remediation v6 (outdated), ELNOR Knowledge Store Unification Plan R1, Cross-Document Integration Plan v4. Resolve disposition before any fold-in. |
| Memory Intake and At-Use Disciplines proposal — adopt? | V2 DOC24 review follow-up | Pending red team. If adopted, ~7 OBL rows enter against DOC72/DOC24/DOC1/DOC73. |
| DOC24↔DOC73 full seam audit — when? | V2 DOC24 review extension | Recommended: after DOC73 V1.5 stabilizes. ISS-01b is the canary; more seam findings likely. |
| DOC6 status (still active doc number?) — RESOLVED in V3 | DOC15 R3.1 §3 | DOC6 v1.11.8.1 confirmed active per master spec list R2.7 row 13. DOC6 obligations (OBL-D6-01 through OBL-D6-08) added in V3. |
| DOC74 reference in user note | Conversation 2026-04-26 | User mentioned DOC74; not in any current doc list. Possibly typo for DOC73, possibly a deprecated number. Verify. |
| DOC15 R3.1 contract maintenance — RESOLVED in V3 | This tracker's source registry | DOC15 R3.1 is fully folded into OP-A V3. Source archived (in-place annotation). Per V2 carryover Invariant #24 (post-absorption versioning rule), do not refresh DOC15 R3.1 as standalone going forward; subsequent CIL cross-doc work authors a NEW proposal against the operative DOC15 R7.1. |
| DOC1 R1 status | V3 carryover §10.3 | "Partially stale — Storage model JSONL → SQLite. Governance logic current." Schedule next review. |
| **NEW (V3):** DOC15-derived row triage against current architecture | This tracker (V3 expansion) | Many DOC15 R3.1 obligations may now be satisfied by DOC72 R5.73 / DOC73 V1.4.1 / DOC25 V2.0 / DOC24 R2.5 / BDSM V6.4 / KDA R2 / GIE V2.2 absorption / KIE R2 absorption. Schedule a triage pass that walks each `[REQ] [PARTIAL]` row and re-verifies against current spec. May reclassify many to `[REQ] [EXISTS]` (strikethrough) or `[ENH] [EXISTS]` (move to absorbed). |
| **NEW (V3):** OBL-D14-09 meta-obligation requires walking D15-RT-001 through D15-RT-005 | DOC15 R3.1 §6.3 (Part 2 R3) | Per OBL-D14-09, each D15-RT row should have a corresponding owner-doc obligation in this tracker. Walk during Session 2 (DOC14 R2 fold-in). |

---

## 10. Maintenance Log

| Date | Action | By |
|---|---|---|
| 2026-04-26 | **Created V1.** Folded in: V2 DOC24 review (full cross-doc findings); DOC24 R2.5 §22 amendment matrix; DOC15 R3.1 contract (feature-area-grouped extraction of §§1-11); CD Master Integration Index R1 (registry content). Deferred: Memory Intake and At-Use Disciplines proposal (pending red team); DOC3 R9.2 / DOC14 R2 / DOC72 maps / CD-A 4.1.26 / DOC10 ledger / DOC16 deferred / Running Brief / Knowledge Store Unification (not yet read). | Claude Opus 4.7 |
| 2026-04-26 | **V2 corrections pass.** Removed unverified source documents from §3 "not yet folded in" list. Moved to §9 Open Meta-Architecture Questions as inventory item requiring investigation. Tightened §3 scope rule. No fold-in work performed; no §6 obligation rows changed. | Claude Opus 4.7 |
| 2026-04-26 | **V3 Session 1 fold-in.** Expanded DOC15 R3.1 from V2's feature-area-grouped rows into field-level OBL rows. Added 56 new OBL rows across DOC1, DOC4, DOC6, DOC7, DOC10, DOC11, DOC12, DOC13, DOC14, DOC18, DOC15-self, EC Core. Coverage of DOC15 R3.1 Parts 1-3 complete (capture points 1-52, plus authority salience field/event/route/UI additions §R3.1.A-F). DOC15 R3.1 source archived (in-place annotation; physical move/rename TBD by architect). Updated §3 source registry, §5 currency snapshot, §9 open questions (DOC6 status resolved; DOC15 R3.1 maintenance resolved; added two NEW items: triage of DOC15 rows against current architecture, OBL-D14-09 meta-obligation walk). | Claude Sonnet 4.6 (Cowork) |
| 2026-04-26 | **V3.1 incremental update — DOC24 R3 cross-doc obligations.** Added 32 new OBL rows from `DOC24_R2_5_RED_TEAM_ADJUDICATION_CARD_V3.md` (125 cards) and `DOC24_R3_LANDING_PLAN_V1.md` §4. Coverage by target doc: DOC1 (2), DOC8 (3), DOC11 (3), DOC15 (1), DOC21/22 (1), DOC72 (4), DOC73 (3), EC Core (4), BDSM (5), KDA (4), MultiDoc PropA (2). Three new target-doc sections added: §6.23 BDSM, §6.24 KDA, §6.25 MultiDoc PropA. §3 source registry updated to include Adjudication Card V3 and Landing Plan V1. Versioning convention established: incremental V3.x for fold-ins like this; V4 reserved for Session 2 (DOC3/DOC14/CD-A consolidation). | Claude Opus 4.7 |
| 2026-04-27 | **V3.2 incremental update — DOC24 R3 audit-discovered cross-doc obligations.** DOC24 R3 audit revealed that the initial R3 draft had a 26% landing gap on accepted adjudication card items. The corrective audit pass added 29 cards' worth of content; of those, three carried cross-doc obligations not previously captured: ADJ-RT-079 (bulk action affordances on review surfaces), ADJ-RT-099 (adaptive packet budgeting coordination), ADJ-RT-105 (WorkContextConstellation derived read-model). Three new OBL rows added: OBL-D15-NEW-02 (DOC15 budget governance accepts adaptive policy outputs), OBL-D21-NEW-02 (DOC21/22 implements bulk-action UI patterns), OBL-D72-NEW-05 (DOC72 publishes WorkContextConstellation read-model from graph community detection). §3 source registry updated to include DOC24 R3 (final, post-audit) as folded-in source. R3 itself is now operative; future obligations on it would track post-implementation revisions, not this current spec wave. | Claude Opus 4.7 |

---

## 11. End of tracker

**Self-test for usability (V3.2):**

1. ✅ Reader can find what's pending for a target doc by reading exactly one section (§6.X for that doc).
2. ✅ Each obligation row has source citation, status, calibration anchor, and (for V3+ rows) Created date.
3. ✅ Status key is consistent with existing DOC15 R3.1 format.
4. ✅ Source documents are listed with last-updated dates so staleness is assessable.
5. ✅ Schema for Absorbed and Deferred sections is established (both empty).
6. ✅ Meta-architecture questions captured.
7. ✅ Coverage gap explicit: §3 lists "not yet folded in" sources with Session 2 plan.
8. ✅ DOC15 R3.1 staleness flag carried on every row derived from it.
9. ✅ Cross-references between rows captured via Depends on / Blocks fields.
10. ⚠ V3 expansion volume: 56 new rows. Triage pass needed against current architecture (DOC72 R5.73, etc.) — many `[MISSING]` may now be `[EXISTS]`.
11. ✅ V3.1 added 32 R3 obligations; V3.2 added 3 audit-discovered obligations. R3 is now the final operative spec.
12. ⚠ Total OBL rows now ~91 across all target docs. Reviewer time budget for absorbing into companion-doc revisions should account for this volume — not all 91 will be absorbed in one revision per companion; expect multiple passes.

**Maintenance discipline:** at the end of every red team review or spec revision session, the reviewer's last step is to update §6 (move absorbed items, update statuses, add new findings as new rows), §10 (log the action), and if applicable §3 (register newly-folded source documents).

**Next planned events:**
- DOC24 R3 → next red team round: when red team produces findings against R3, those become the R3.5 or R4 adjudication card; obligations surfaced from review ride a future V3.3+ increment
- Companion doc revision waves: as BDSM, KDA, DOC72, DOC73, PropA, EC Core revise to absorb their R3-imposed obligations, OP-A gets walk-through updates on those sections (status `[MISSING]` → `[EXISTS]` per absorption)
- Session 2 (V4): fold in DOC3 Companion R9.2 + DOC14 Cross-Doc R2 + CD-A 4.1.26
- Session 3+ (V5+): ongoing fold-ins from §3 "not yet folded in" as new sources confirmed in scope