Elnor Repo Reader

DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3.md

OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3.md

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

Open text page · Open raw txt · Open path URL

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

**DOC ID:** DOC OP-A (operations spec, A series — cross-doc obligation tracker)
**Version:** V3 (Session 1 expansion — DOC15 R3.1 folded in field-level)
**Date created (V1):** 2026-04-26
**Date V2 produced:** 2026-04-26
**Date V3 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 changes from V2:**

V3 is the Session 1 fold-in per the ELNOR Cross-Doc Obligation Consolidation Carryover Prompt V2. DOC15 R3.1 has been fully expanded from V2's feature-area-grouped rows into field-level OBL rows.

- Added 56 new OBL rows across 10 target docs (DOC1, DOC4, DOC6, DOC7, DOC10, DOC11, DOC12, DOC14, DOC18, EC Core), plus 1 row to DOC15 self-reference
- Existing V2 DOC15-derived rows preserved (their feature-area framing remains the primary obligation; field-level rows added beside them where granular tracking is useful)
- DOC15 R3.1 §3 (DOC6) obligations now have explicit OBL rows; §6.4 DOC6 placeholder upgraded
- DOC15 R3.1 §7A and §10 (R2.1 graph/topology additions) now extracted: DOC18 retrieval receipts, DOC1 relationship index traversal
- DOC15 R3.1 Part 2 (R3) additions extracted: EC Core operation compiler routes, context-change events, contract-health snapshot; DOC10 RetrievalReceiptSchema and CIL UI transport; DOC11 packet inspector and overlay truth; DOC12 room-close bundle and prompt-plan query; DOC14 prompt-artifact observations
- DOC15 R3.1 Part 3 (R3.1 Authority Salience capture points 47-52) extracted: durable authority field set (display_label, persistence_class, injection_preference, last_user_reconfirmed_at, review_after_at), authority-specific telemetry, lane-aware render plan, application trace, maintenance proposal commands, Authority Audit surface
- §3 Source Registry: DOC15 R3.1 contract moved to "fully folded in" with row-by-row attribution; §3 "not yet folded in" updated
- §5 Source-doc currency snapshot: refreshed to reflect DOC72 R5.73, DOC73 V1.4.1 operative, DOC25 V2.0
- §10 Maintenance log: V3 entry appended
- DOC15 R3.1 source file annotated as archived; remains in original location for historical reference (default OP-A archive: in-place annotation; physical move TBD by architect)

**Staleness flag carried forward on every DOC15-derived row:** "DOC15 R3.1 (March 12, 2026 — 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)." Many obligations may now be satisfied by current architecture; status `[REQ] [PARTIAL]` defaulted with "Verify against current architecture" note.

**Next sessions:**
- Session 2 (planned for V4): DOC3 R9.2 Companion + DOC14 R2 Cross-Doc Companion + CD-A 4.1.26 staging doc
- Session 3+ (V5+): ongoing fold-ins from §3 "not yet folded in" as new sources are confirmed in scope

**Replaces / supersedes:**
- DOC OP-A V2 (this file is the new authoritative version)
- `DOC15_Cross_Document_Integration_Contract_R3_1_Consolidated_Current_Draft.md` (content fully folded; source archived)
- `CD_MASTER_INTEGRATION_INDEX_R1.md` (pointer model superseded; preserved per V2)

---

## 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) |
| **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."

---

### §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.

---

### §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

---

### §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

---

### §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.)

---

### §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.)

---

### §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.)

---

### §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

---

## 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) |

---

## 11. End of tracker

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

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 new V3 rows) Created date + Last verified 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 in V3).
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]`.

**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 session:** Session 2 — fold in DOC3 Companion R9.2 + DOC14 Cross-Doc R2 + CD-A 4.1.26 → produces OP-A V4.