DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3_6.md
OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3_6.md
ELNOR REPO READER TEXT MIRROR
Original path: OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/DOC_OP_A_CROSS_DOC_OBLIGATION_TRACKER_V3_6.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z
---
# DOC OP-A — Cross-Doc Obligation Tracker V3.6
**DOC ID:** DOC OP-A (operations spec, A series — cross-doc obligation tracker)
**Version:** V3.6 (architecture clarification — agent-vs-capability registry split; capability-registered flag on agent rows)
**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
**Date V3.3 produced:** 2026-04-26
**Date V3.4 produced:** 2026-04-27
**Date V3.5 produced:** 2026-04-27
**Date V3.6 produced:** 2026-04-27
**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.6 changes from V3.5:**
V3.6 records an architectural clarification surfaced by Will: agents and capabilities are different things, and the relationship between the **Agent Identity Registry** (EC Core Addendum A V3.4+, per V3.5 decision) and the **Capability Registry** (DOC24, populated by Workstream K) needs to be explicit.
**Clarification:**
- Agent Identity Registry = "who's on staff" (every named agent, with execution profile + dependencies)
- Capability Registry = "what we can invoke" (capability types include `tool`, `mcp`, `api`, `app`, `procedure`, `skill`, `plugin`, **`agent`**)
- Each agent capability entry has `implemented_by_agent_id` cross-reference to the agent identity registry
- **Not every agent is capability-registered:** invokable agents get capability entries; infrastructure-only agents live in the agent identity registry only
**V3.6 updates:**
- OBL-EC-AGT-01 — registry schema clarification: include `lifecycle_state` and note explicit relationship to DOC24 capability registry
- OBL-EC-AGT-02 through OBL-EC-AGT-08 — added `capability_registered` annotation on each row (yes/no/mixed)
- §9 Open Meta-Architecture Questions: ARCHITECTURE CLARIFICATION RECORDED — agent-vs-capability registry split
- Workstream K (in ROADMAP, not OP-A) — updated to specify `agent` as a capability type with cross-reference pattern
No new OBL rows; no agent identities changed.
---
**V3.5 changes from V3.4:**
V3.5 records an architecture decision: **EC Core Addendum A V3.4+ becomes the System Agent Identity Registry** for ELNOR. Architect picked Option A (per V3.4 §9 disposition question on EC Core agent registry ownership).
The registry is a thin index — for each system agent it lists agent_id, one-line purpose, owning spec doc (where the agent's detailed contract lives), required execution profile (cross-references EC Core Addendum A §5), and declared document dependencies. Agent detailed contracts stay in their owning specs (DOC15 for cil_advisor + OCM; SUBAGENT V4 for MemoryAgent + DocumentIntelligenceAgent; DOC4 for OpenClaw-bridge-side advisor agents like review_advisor + spec_advisor; etc.).
V3.5 additions:
- §6.22 EC Core: 8 new OBL rows for System Agent Identity Registry
- OBL-EC-AGT-01: New §X "System Agent Identity Registry" section in EC Core Addendum A
- OBL-EC-AGT-02 through OBL-EC-AGT-08: One registry entry per system agent (cil_advisor, advisor_dispatcher, review_advisor, spec_advisor, OCM, MemoryAgent, DocumentIntelligenceAgent)
- §9 Open Meta-Architecture Questions: ARCHITECTURE DECISION RESOLVED — EC Core agent registry ownership (Option A picked)
- §10 Maintenance log: V3.5 entry appended
V3.5 does NOT change DOC4 ownership — DOC4 retains OpenClaw bridge content and per-agent implementation contracts where applicable (e.g., review_advisor implementation lives in DOC4; its registry entry is OBL-EC-AGT-04 in EC Core Addendum A).
The two RRB-derived disposition decisions remain pending:
- **OBL-D24-RRB-04** — Running Brief slot keep-or-deprecate. Independent of the registry decision.
- **OBL-D15-RRB-03** — OCM agent keep-or-absorb-or-deprecate. Independent of the registry decision (OCM gets a registry entry either way; if deprecated, the registry entry moves to deprecated state).
---
**V3.4 changes from V3.3:**
V3.4 is a correction pass. V3.3 OBL-D15-RRB-03 and the related §9 question + RRB archive header incorrectly suggested OCM could merge into DOC73 MemoryAgent. **OCM and MemoryAgent serve different purposes:** OCM is a context/orientation agent (RRB v6 §4: extract mode updates Running Brief from recent turns; query mode returns attributed cross-surface summaries); DOC73 MemoryAgent is a specialist sub-agent for bounded memory retrieval/processing from the durable knowledge graph (SUBAGENT V4 §1.8). Different domains.
V3.4 corrections:
- OBL-D15-RRB-03 disposition options corrected: "keep / merge into DOC15 CIL extract path / deprecate" (no DOC73 MemoryAgent reference)
- §9 Open Meta-Architecture Questions: same correction
- §10 Maintenance log: V3.4 entry appended
- (RRB archive header in Subsumed Specs also corrected separately)
No other changes from V3.3.
---
**V3.3 changes from V3.2:**
V3.3 fixes 10 audit-discovered gaps from V3 (DOC15 R3.1 fold-in self-audit) AND folds in Running Brief Remediation v6 (RRB) so RRB can be archived. RRB was an 843-line implementation guide self-calibrated against very old DOC10 R10 / DOC11 V3 / DOC12 R2; substantially superseded by current architecture (DOC24 R3, DOC72 R5.73, DOC15 R7.1, DOC8 v1.11.4, DOC13, DOC20-22) but contained unique content worth preserving.
**Audit gap fixes (10 rows):**
- DOC3 §11 (R3) — 4 obligations missed in V3 (lane naming, llamaindex_index provider, canonical vs sidecar separation, capability-family truth)
- DOC10 §7.3 — explicit `+ask/+advise` routing row (was rolled into OBL-D10-01)
- DOC12 §2.4 — `reopened_room_found_same` FUT signal
- DOC16 §14 (R3) — preservation sync rule
- DOC1 §1.3 (R3) — required routes/read seams as explicit row
- EC Core §11.1 — Nightly Scheduler Extension (CIL phases 4, 4.5, 5, 6, 7)
- EC Core #31 — DocIndex access events
- EC Core #34 — Agent dependency resolution (EC side)
- EC Core #35 — Proactive document surfacing (EC/DocIndex side)
- EC Core §11.4 — Standing Order Conflict Detection (EXISTS verification)
**RRB v6 fold-in (~22 rows):** Unique content extracted as obligations against current owner docs:
- DOC24: 5-slot injection ownership table; surface profiles + per-surface budgets; Running Brief as registered injection slot; no-unregistered-injection invariant (load-bearing); scope definitions (surface/run/agent/participant/global); render-at-injection-time discipline
- DOC15: SurfaceScope schema; Two-track extraction (OCM agent + deterministic heuristic fallback); OCM agent (extract + query modes, hidden system status) — disposition decision needed
- DOC11: Canonical reset notice for fresh surfaces; surface plumbing in hot path; bootstrap slot ownership distinct from conversation context block
- EC Core: Surface reset triggers + effects + reset_generation; handoff seed mechanism; environment awareness aggregator endpoint `/api/environment/entities`; ContextInjectionEvent schema
- DOC10: 7 new context-injection telemetry event names
- DOC8: 5 new RRB-derived friction fingerprints; nightly context quality summary metrics; corrections carry surface_kind/surface_id/participant_id
- DOC12: Parallel-agent isolation rule (room participants do not silently inherit one another's brief); SurfaceSummaryArtifact contract
- DOC2 (NEW SECTION §6.2A): Freshness Manager coordination rule (carries DOC2 retirement context per DOC72 Continuity Synthesis R1)
- DOC20/DOC21/DOC22: Compact context viewers in chat/room/panel/forum headers; OCM agent management page; Memory Browser editor preservation; header health indicator
RRB v6 archived to `Subsumed Specs/RUNNING_BRIEF_REMEDIATION_v6_ARCHIVED_2026-04-26.md` after this fold-in.
**Calibration anchor for V3.3 rows:** RRB v6 (March 3, 2026) — STALE; self-calibrated against DOC10 R10 / DOC11 V3 / DOC12 R2. Every RRB-derived row carries staleness flag. Triage against DOC24 R3 / DOC72 R5.73 / DOC15 R7.1 still pending — many `[REQ] [MISSING]` rows may now be `[REQ] [PARTIAL]` or `[REQ] [EXISTS]`.
**Replaces / supersedes:**
- DOC OP-A V3.2 (this file is the new authoritative version)
- `RUNNING_BRIEF_REMEDIATION_v6.md` (content folded; source archived)
---
## 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** | `Subsumed Specs/DOC15_Cross_Document_Integration_Contract_R3_1_Consolidated_Current_Draft_ARCHIVED_2026-04-26.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 to Subsumed Specs 2026-04-26. | **Yes (V3, audit gaps fixed in V3.3) — 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** |
| **Running Brief Remediation v6** | `Subsumed Specs/RUNNING_BRIEF_REMEDIATION_v6_ARCHIVED_2026-04-26.md` | March 3, 2026 | **STALE — self-calibrated against DOC10 R10 / DOC11 V3 / DOC12 R2 (all very old). Substantially superseded by DOC24 R3, DOC72 R5.73, DOC15 R7.1, DOC8 v1.11.4, DOC13, DOC20-22.** Source archived to Subsumed Specs 2026-04-26. | **Yes (V3.3)** — unique content extracted: 5-slot injection ownership table, surface profiles + budgets, no-unregistered-injection invariant, scope definitions, SurfaceScope schema, OCM agent contract, canonical reset notice, surface reset triggers/effects, handoff seed, environment aggregator endpoint, ContextInjectionEvent schema, 7 telemetry events, 5 friction fingerprints, parallel-agent isolation, SurfaceSummaryArtifact contract, freshness coordination rule (DOC2). |
| 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
| **OBL-D1-AUD-01:** Required routes / read seams for durable authority (audit gap from V3) | DOC1 publishes three explicit route surfaces: read authority by scope/applicability; apply authority mutation commands; expose authority application/skip telemetry/current views to EC/CIL | `[REQ] [PARTIAL]` |
- **Source:** DOC15 R3.1 §1.3 (Part 2 R3) — missed in V3 fold-in
- **Why:** Schema and mutation read model (OBL-D1-04, OBL-D1-05) and application-trace (OBL-EC-11) are necessary but not sufficient — DOC1 also needs to expose them as named routes. Without explicit route definitions, callers don't know which endpoint to call.
- **Acceptance:** DOC1 publishes route surface enumeration; EC Core and DOC10 reference DOC1 routes by name.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D1-04 (schema), OBL-D1-05 (mutation read model), OBL-EC-11 (application trace)
- **Created:** 2026-04-27 (V3.3 audit fix)
---
### §6.2 DOC3 — App Skills
DOC3 R11.3 adjudication card and DOC3 Companion Delta Plan R9.2 will be folded in during Session 2 (OP-A V4). The 4 rows below are V3.3 audit-gap fixes for DOC3 obligations from DOC15 R3.1 Part 2 R3 §11 that should have been extracted in V3 but were incorrectly deferred.
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
**NEW ROWS (V3.3 audit gap fixes from DOC15 R3.1 Part 2 R3 §11):**
| **OBL-D3-AUD-01:** Settle retrieval lane naming once | DOC3 establishes canonical retrieval lane vocabulary across the suite (e.g., `m365_graph_search`, `qmd_local_semantic`, `llamaindex_index`, `openclaw_native`, `ec_memory_search`, `keyword_fallback`) | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §11 (Part 2 R3) — first bullet — missed in V3 fold-in
- **Why:** Without canonical lane names, every retrieval-emitting doc invents its own vocabulary and CIL surface explanations drift.
- **Acceptance:** DOC3 publishes the lane enum in a referenced location; DOC18, DOC1, DOC11 all reference it.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** —
- **Blocks:** OBL-D10-09 (RetrievalReceiptSchema provider enum)
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-D3-AUD-02:** Reflect `llamaindex_index` as provider kind | DOC3 retrieval routing recognizes `llamaindex_index` as a distinct provider kind (not "general semantic search") | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §11 (Part 2 R3) — second bullet — missed in V3 fold-in
- **Why:** DOC18 LlamaIndex sidecar emits `llamaindex_index` as its provider value; DOC3 routing must recognize and preserve it through the retrieval pipeline.
- **Acceptance:** DOC3 routing schema includes `llamaindex_index` as named provider; results carry provider attribution end-to-end.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D3-AUD-01
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-D3-AUD-03:** Keep canonical memory search distinct from sidecar corpus retrieval | DOC3 retrieval routing maintains explicit boundary: canonical ELNOR memory search (EC-owned via DOC72 graph) ≠ sidecar corpus retrieval (DOC18 LlamaIndex). No silent merging at routing layer. | `[REQ] [PARTIAL]` |
- **Source:** DOC15 R3.1 §11 (Part 2 R3) — third bullet — missed in V3 fold-in
- **Why:** Sidecar drift into "second hidden memory system" is an architectural failure mode (V3 carryover Invariant #15). DOC3 routing layer is where that drift would happen.
- **Acceptance:** DOC3 routing schema clearly distinguishes canonical memory lane from sidecar corpus lane; results carry lane attribution; no automatic merging without retrieval receipt disclosure.
- **Calibrated against:** DOC15 R3.1 (stale); aligned with V3 carryover Invariant #15 (LlamaIndex is sidecar)
- **Depends on:** OBL-D3-AUD-01
- **Blocks:** OBL-D18-02 (DOC18 boundary rule)
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-D3-AUD-04:** Expose capability-family truth used by CIL suggestion reasoning | DOC3 publishes capability-family vocabulary that CIL uses to reason about which app skills are available for a given task; suggestion cards reference capability families by stable name | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §11 (Part 2 R3) — fourth bullet — missed in V3 fold-in
- **Why:** Without capability-family truth, CIL suggestions about which skill to invoke have no anchored vocabulary; recommendations drift between sessions.
- **Acceptance:** DOC3 publishes capability-family registry with stable names; CIL suggestion-card reasoning references them.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3 audit fix)
---
### §6.2A DOC2 — Freshness Manager (NEW SECTION in V3.3)
DOC2 (ELNOR Freshness Manager Addendum) had no §6 home in V3.x. RRB v6 §9 (Part H) targets DOC2 with a coordination rule. DOC72 Continuity Synthesis Architecture R1 proposes DOC2 retirement, so any DOC2 obligation should carry that context.
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D2-RRB-01:** Freshness-related context flows through registered layers only | Freshness Manager must not inject freshness-related context outside registered injection layers; freshness signals respect Running Brief surface budget; no surface-budget inflation by freshness data | `[REQ] [MISSING]` |
- **Source:** RRB v6 §9 (Part H — Freshness Manager coordination)
- **Why:** Without this rule, freshness signals leak into the prompt as ad-hoc injection bypassing the registered-layer discipline (per OBL-D24-RRB-01).
- **Acceptance:** DOC2 specifies freshness signals route through DOC24 KOI baseline or surface_summary_block, not direct prompt injection. Freshness telemetry conforms to ContextInjectionEvent schema (OBL-EC-RRB-04).
- **Calibrated against:** RRB v6 (STALE); cross-check against DOC72 Continuity Synthesis R1 which proposes DOC2 retirement.
- **Depends on:** OBL-D24-RRB-01 (no-unregistered-injection invariant)
- **Created:** 2026-04-27 (V3.3)
- **Notes:** **DOC2 retirement caveat:** DOC72 Continuity Synthesis Architecture R1 (in review) targets DOC2 retirement. If DOC2 retires, this obligation transfers to whichever spec absorbs freshness ownership — likely DOC72 §X. Verify during Continuity Synthesis integration.
---
### §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
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D8-RRB-01:** Friction fingerprints for context pipeline regressions (5 new) | DOC8 friction fingerprint catalog adds: repeated incorrect surface resets; room summary over-budget regressions; duplicate bootstrap + brief overlap; off-path context injection; repeated OCM query fallback during room/panel/forum work | `[ENH] [MISSING]` |
- **Source:** RRB v6 §7.3 (DOC8 friction trigger additions)
- **Why:** Without these fingerprints, surface-aware context regressions don't trigger DOC8 friction signals → no learning from repeated context failures.
- **Acceptance:** DOC8 friction fingerprint catalog includes 5 listed names with detection logic; DOC8 nightly batch updates each.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-D10-RRB-01 (telemetry events that drive these fingerprints)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D8-RRB-02:** Nightly context quality summary metrics | DOC8 nightly summary adds: surface_reset_count, surface_summary_generation_count, surface_summary_truncation_count, usage_sample_missing_rate | `[ENH] [MISSING]` |
- **Source:** RRB v6 §7.6 (Nightly context quality summary)
- **Why:** Quality metrics for context pipeline health. Without them, context-pipeline degradation is invisible.
- **Acceptance:** DOC8 nightly quality summary includes 4 listed metrics; surfaces in dashboard / friction reports.
- **Calibrated against:** RRB v6 (STALE)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D8-RRB-03:** Corrections from room/panel/forum carry surface fields | Corrections arising from room/panel/forum work carry `surface_kind`, `surface_id`, and `participant_id?`; remain candidates (do not become durable memory automatically) | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §10 (Part J — Self-learning event generation)
- **Why:** Without surface attribution, room-derived corrections silently propagate to global authority. Per OBL-D1-06 transient/durable split, room corrections should default to candidate.
- **Acceptance:** Correction emission schema includes surface fields; DOC8 routes room-derived corrections to candidate pipeline only.
- **Calibrated against:** RRB v6 (STALE); aligns with OBL-D1-06 transient instruction split.
- **Depends on:** OBL-D11-RRB-02 (surface plumbing in hot path), OBL-D1-06
- **Created:** 2026-04-27 (V3.3)
---
### §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
| **OBL-D10-AUD-01:** `+ask/+advise` routing for CIL surfaces (audit gap split) | Dispatcher chooses `cil_advisor` for `payload_kind = cil_query_context`; routing rule explicit and separate from generic advisor dispatch | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §7.3 (Part 1) — was rolled into OBL-D10-01 in V3; split out per audit
- **Why:** Specific routing rule for CIL surfaces deserves its own row; keeps explanatory traffic off the main worker per DOC15 design.
- **Acceptance:** DOC10 dispatcher implements payload_kind-based advisor selection; cil_query_context maps to cil_advisor.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D10-01 (generic advisor dispatch endpoint)
- **Created:** 2026-04-27 (V3.3 audit fix — split row)
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D10-RRB-01:** Context-injection telemetry event names (7 events) | DOC10 telemetry catalog registers RRB-derived context-injection event names: `context_surface_reset`, `surface_summary.generated`, `surface_summary.reused`, `surface_summary.truncated`, `context_injection_unregistered`, `context_room_bootstrap_overlap_detected`, `context_usage_sample_missing` | `[REQ] [MISSING]` |
- **Source:** RRB v6 §7.2 (New required events)
- **Why:** Without these named events, surface-aware telemetry has no consistent vocabulary. Each event maps to a specific failure mode RRB tracked.
- **Acceptance:** DOC10 telemetry catalog includes all 7 event names with typed payloads conforming to ContextInjectionEvent schema (OBL-EC-RRB-04).
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-EC-RRB-04 (ContextInjectionEvent schema)
- **Blocks:** OBL-D8-RRB-01 (DOC8 friction fingerprints reference these events)
- **Created:** 2026-04-27 (V3.3)
---
### §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.3, from RRB v6 fold-in):**
| **OBL-D11-RRB-01:** Canonical reset notice via bootstrap slot | When a fresh room/panel/forum/chat→room upgrade occurs, DOC11 transport delivers the canonical reset notice through the bootstrap slot (NOT the conversation_context_block). Reset notice text: "This is a new {surface_kind} context. Treat it as distinct from prior chats, rooms, panels, forums, and tasks unless the supplied handoff or imported summary explicitly links them. Do not assume unseen prior surface history applies here." | `[REQ] [MISSING]` |
- **Source:** RRB v6 §2.4 (Canonical reset notice for fresh surfaces)
- **Why:** Without the notice, models silently assume prior surface history applies on fresh surfaces. The notice is mandatory on fresh room/panel/forum and chat→room upgrade.
- **Acceptance:** DOC11 bootstrap slot delivery includes reset notice when surface is fresh; notice never appears in conversation_context_block; rule enforced in tests.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-EC-RRB-01 (reset detection), OBL-D24-RRB-02 (slot ownership)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D11-RRB-02:** Surface plumbing in hot path | DOC11 hot-path wrappers pass `surface_kind`, `surface_id` (and `participant_id?`, `room_id?`, `panel_run_id?`, `forum_thread_id?`, `task_id?` where applicable) through every dispatch | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §1.2 (SurfaceScope), §12.3 P0 (surface plumbing in hot paths)
- **Why:** Without surface plumbing, downstream consumers (DOC24 packet assembly, DOC8 friction, DOC10 telemetry) can't distinguish chat-vs-room-vs-panel context. Surface-aware behavior collapses.
- **Acceptance:** DOC11 dispatch envelope schema includes SurfaceScope object; hot path validates required fields; missing surface plumbing fails early.
- **Calibrated against:** RRB v6 (STALE); cross-check against DOC11 R14 + R15 amendment.
- **Depends on:** —
- **Blocks:** OBL-D24-RRB-03 (surface profiles depend on surface_kind), OBL-EC-RRB-01 (reset triggers depend on surface_id)
- **Created:** 2026-04-27 (V3.3)
**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
| **OBL-D12-AUD-01:** `reopened_room_found_same` future stale-room signal (audit gap) | Future stale-room diagnostic signal: emitted when a user reopens a previously-closed room and the state matches the prior close (no meaningful change in interim) | `[FUT] [MISSING]` |
- **Source:** DOC15 R3.1 §2.4 (Part 1) — Passive Room Signals — missed in V3 fold-in
- **Why:** Diagnostic for room-reopening behavior; future learning signal for "did anything actually change between close and reopen?"
- **Acceptance:** DOC12 emits `reopened_room_found_same` event when room state matches prior close fingerprint.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Created:** 2026-04-27 (V3.3 audit fix)
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D12-RRB-01:** Parallel-agent isolation in rooms | Room participants may each have their own brief scope, but shared room summary is external and compact. No participant may silently inherit another participant's full Running Brief. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §5.4 (Parallel-agent isolation)
- **Why:** Without isolation, multi-participant rooms cross-contaminate context. Each participant should see their own scope-bounded brief plus the shared room summary, not other participants' private briefs.
- **Acceptance:** DOC12 room state model isolates per-participant brief; shared room summary published as separate compact artifact (per OBL-D12-RRB-02).
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-D12-RRB-02 (SurfaceSummaryArtifact)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D12-RRB-02:** SurfaceSummaryArtifact contract for rooms/panels/forums | DOC12 publishes SurfaceSummaryArtifact schema (summary_id, surface_kind, surface_id, updated_at, version, generated_by, participant_id?, summary, unresolved_questions?, recent_agreements?, recent_disagreements?, cited_ref_ids?, route_trace_id?, gateway_session_key?, fingerprint). Max rendered size SURFACE_SUMMARY_MAX_TOKENS (default 220). Refresh on meaningful change only (not every message). Room summaries are not owned by Running Brief; they are consumed by it. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §2.5 (Surface summary artifact)
- **Why:** Without a defined artifact, CIL/Running Brief consumers can't reliably extract compact room/panel/forum summaries. The artifact is also the consumer contract for Layer 2 in surface profiles.
- **Acceptance:** DOC12 publishes SurfaceSummaryArtifactSchema; OCM agent or moderator agent generates artifact on meaningful drift; refresh respects token cap.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Blocks:** OBL-D12-RRB-01 (parallel-agent isolation depends on shared summary), OBL-D24-RRB-03 (surface profiles consume Layer 2)
- **Created:** 2026-04-27 (V3.3)
- **Notes:** Verify against DOC12 R7.1 — may already define summary export.
---
### §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.3, from RRB v6 fold-in):**
| **OBL-D15-RRB-01:** SurfaceScope schema | DOC15 publishes SurfaceScope object: `{ surface_kind: "chat" \| "room" \| "task" \| "panel" \| "forum"; surface_id: string; run_id: string; agent_id: string; participant_id?: string; room_id?: string; panel_run_id?: string; forum_thread_id?: string; task_id?: string; origin_surface_kind?: SurfaceKind; origin_surface_id?: string; }` | `[REQ] [MISSING]` |
- **Source:** RRB v6 §1.2 (Surface-aware scope model)
- **Why:** Without a single canonical SurfaceScope, every surface-aware path invents its own subset of fields. SurfaceScope is the foundation for OBL-D11-RRB-02 (surface plumbing), OBL-EC-RRB-01 (reset triggers), OBL-D24-RRB-03 (surface profiles).
- **Acceptance:** DOC15 publishes SurfaceScope as an interface (with all fields per the listed schema); referenced by DOC11, DOC24, EC Core, DOC8, DOC10.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Blocks:** OBL-D11-RRB-02, OBL-EC-RRB-01, OBL-D24-RRB-03, OBL-EC-RRB-04
- **Created:** 2026-04-27 (V3.3)
| **OBL-D15-RRB-02:** Two-track extraction discipline (OCM primary + deterministic fallback) | DOC15 specifies two-track context extraction: OCM agent (primary) using bounded sliding window + current brief state + compact surface metadata; deterministic heuristic (fallback) using latest turn + local state. Heuristic runs immediately on every turn. OCM runs async and overwrites heuristic output when valid structured output arrives. | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §1.4 (Two-track extraction)
- **Why:** Without a deterministic fallback, async OCM failure causes the brief to fall silent. The two-track discipline ensures hot-path resilience.
- **Acceptance:** DOC15 specifies both tracks with explicit hand-off rules; CI verifies that fallback runs on every turn even when OCM is unavailable.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3)
| **OBL-D15-RRB-03:** OCM agent specification (extract + query modes, hidden system status) | DOC15 specifies OCM as a system-level always-on hidden background agent with two bounded modes: extract mode (updates Running Brief from recent turns) and query mode (returns attributed cross-surface summaries, read-only, attributed results only, low-trust banner, cannot be sole basis for durable actions, bounded rate limits, lexical fallback when unavailable). OCM is NOT: a visible room participant, a moderator by default, a surface owner, a durable-state writer, an autonomous repair/orchestration agent. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §4.1, §4.2, §4.4 (OCM agent — what it is and is not)
- **Why:** OCM is one of the load-bearing concepts of the context layer — a context/orientation agent distinct from durable memory retrieval. Either DOC15 owns it explicitly as a named system agent, or it gets formally deprecated with a note pointing at successors within the context-extraction path (e.g., DOC15 CIL extract pipeline absorbing the function).
- **Acceptance:** DOC15 R7.1+ specifies OCM as a named system agent with extract + query modes; OR architect decides to deprecate, and a deprecation note replaces this row.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3); corrected 2026-04-27 (V3.4)
- **Notes:** **DISPOSITION-DECISION ROW.** Pairs with OBL-D24-RRB-04 (Running Brief slot disposition). If RRB concept survives, OCM survives with it. If RRB deprecated, OCM functions either (a) absorb into DOC15 CIL extract pipeline as an unnamed implementation path, or (b) get formally retired with the Running Brief itself. **Note:** OCM is a context/orientation agent (extract from recent turns + cross-surface summary query), NOT a memory-retrieval agent. DOC73 MemoryAgent is a different agent serving a different purpose (bounded retrieval from the durable knowledge graph) and is not a substitute for OCM. Architect to decide.
**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.)
**NEW ROWS (V3.3 audit gap fix):**
| **OBL-D16-AUD-01:** DOC16 preservation sync rule (audit gap) | Once an owner doc adopts a DOC16 deferred-additions seam, DOC16 must add a note that the preserved planning block is superseded by the owner doc and may not remain the only production-looking home for that seam | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §14 (Part 2 R3) — missed in V3 fold-in
- **Why:** DOC16 (deferred additions) is preservation layer. Without explicit supersession discipline, owner-doc adoption can leave DOC16 as a phantom alternate home for the same seam.
- **Acceptance:** DOC16 maintenance protocol includes "supersession sync" step; each adopted seam in an owner doc gets a corresponding DOC16 supersession note pointing at the new owner.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3 audit fix)
- **Notes:** Applies to DOC16_R5_4 / DOC16_Deferred_Additions_R5_3 carried anomalies — those are the present-tense embodiment of this rule failing.
---
### §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.)
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D20-RRB-01:** Memory Browser top card remains primary editor (audit-grounded) | DOC20 specifies that the Memory Browser top card is the primary edit/inspect surface for Conversation Context / Running Brief; show surface_kind, surface_id, last reset reason, reset_generation, surface summary attachment status, compact usage/cost status when available | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §1.5 ("Context is not memory, but Memory Browser remains the main editor"), §8.1 (Conversation Context Card)
- **Why:** Concrete UI ownership rule — single editor (Memory Browser), multiple read-only viewers (chat header, room sidebar, panel header, forum header).
- **Acceptance:** DOC20 R4.3+ identifies Memory Browser top card as the unique editor; v6-listed display fields appear in the card.
- **Calibrated against:** RRB v6 (STALE)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D20-RRB-02:** Compact context viewers in chat/room/panel/forum headers | DOC20 specifies compact read-only context indicator viewers in: ordinary chat header, room sidebar / participant drawer, panel header, forum header. Viewers only — do not replace Memory Browser editor. | `[ENH] [MISSING]` |
- **Source:** RRB v6 §8.2 (Compact surface viewers)
- **Why:** Surface-aware visibility — user can see at a glance what context is active per surface without opening the full editor.
- **Acceptance:** DOC20 R4.3+ adds 4 viewer specs (one per surface kind); each is read-only; each shows surface_kind, brief summary, reset state.
- **Calibrated against:** RRB v6 (STALE)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D20-RRB-03:** OCM agent management page | DOC20 specifies OCM agent management page where OCM is configurable but clearly labeled as a system agent and NOT a room participant | `[ENH] [MISSING]` |
- **Source:** RRB v6 §8.3 (OCM agent management page)
- **Why:** OCM disposition (per OBL-D15-RRB-03) determines whether this page exists at all. If OCM survives, page is required for inspectability.
- **Acceptance:** DOC20 includes OCM management page spec OR (if OCM deprecated) note pointing at successor agent management surface (DOC73 MemoryAgent management).
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-D15-RRB-03 (OCM disposition decision)
- **Created:** 2026-04-27 (V3.3)
| **OBL-D20-RRB-04:** Header health indicator includes context fields | DOC20 header health indicator displays current surface kind, summary block attachment status, usage/cost sample presence | `[ENH] [PARTIAL]` |
- **Source:** RRB v6 §8.4 (Header health indicator)
- **Why:** At-a-glance health visibility for context pipeline status.
- **Acceptance:** DOC20 header indicator schema includes 3 listed fields.
- **Calibrated against:** RRB v6 (STALE)
- **Created:** 2026-04-27 (V3.3)
---
### §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.)
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-D24-RRB-01:** No-unregistered-injection invariant (load-bearing) | Every injected block must come from a registered layer or slot. Off-path injection emits telemetry event `context_injection_unregistered` and friction event `context_pipeline_offpath_injection`. | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §3.6 (No-unregistered-injection invariant — "unchanged, stronger wording")
- **Why:** Without this invariant, ad-hoc injection paths can bypass budget governance and produce phantom prompt content. This is one of the central architectural constraints of the context layer.
- **Acceptance:** DOC24 R3 §27 (KOI baseline + contextual packet) explicitly states the invariant; runtime emits the named telemetry + friction events on violation; CI/eval test fails if any unregistered injection path reaches the model.
- **Calibrated against:** RRB v6 (March 3, 2026 — STALE; predates DOC24 R3); verify against current DOC24 R3 §27 and §38 — may already be `[REQ] [EXISTS]`.
- **Depends on:** —
- **Blocks:** OBL-D24-RRB-02 (slot ownership table consumes this)
- **Created:** 2026-04-27 (V3.3)
- **Notes:** Was flagged in V3 audit as load-bearing rule needing explicit owner. RRB §3.6 is the canonical statement. Promote to `[EXISTS]` once verified in DOC24 R3.
| **OBL-D24-RRB-02:** Five-slot injection ownership table | DOC24 documents 5 named injection slots with explicit owners and lean rules: `lean_ec_annotations` (DOC11, lean), `conversation_context_block` (Running Brief / DOC15, lean), `surface_summary_block` (DOC12/DOC6 producer; DOC24 consumer, lean), `room_bootstrap_block` (DOC12 + DOC11 transport, bounded but separate), `attached_context_refs` (DOC7, ref-first) | `[REQ] [MISSING]` |
- **Source:** RRB v6 §1.3 (Injection slots separation rule, table)
- **Why:** Without explicit slot ownership, injection content drifts between owners (e.g., room bootstrap leaks into conversation context block). The table is load-bearing.
- **Acceptance:** DOC24 R3 §27 / §38 publishes the 5-slot table verbatim with owner + lean rules. Renderer enforces that each slot's content comes only from its named owner.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-D24-RRB-01
- **Blocks:** OBL-D24-RRB-03, OBL-D11-RRB-01 (bootstrap slot ownership)
- **Created:** 2026-04-27 (V3.3)
- **Notes:** Critical anti-pattern stated by RRB §1.3: "the Running Brief MUST NOT absorb `room_bootstrap_block` or full surface transcript payloads."
| **OBL-D24-RRB-03:** Surface profiles and per-surface budgets | Per-surface layer profile mapping: `chat` = layers 1+4+5; `task` = 1+3+4+5; `room` = 1+2+4+5 (smallest profile); `panel` = 1+2+4 (small); `forum` = 1+2+4 (small). Per-surface conversation context token budgets: chat=250, task=180, room/panel/forum=140. SurfaceSummary budget=220. | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §3.2 (Surface profiles and budgets), §2.2 (Constants: BRIEF_MAX_TOKENS_CHAT/TASK/SHARED_SURFACE, SURFACE_SUMMARY_MAX_TOKENS)
- **Why:** Different surfaces need different layer mixes and budgets. Without explicit per-surface profile, packet assembly defaults to one-size-fits-all.
- **Acceptance:** DOC24 R3 packet assembly path consults SurfaceKind to select layer set and budget caps. Constants surfaced as configurable (per profile).
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-D24-RRB-02
- **Created:** 2026-04-27 (V3.3)
- **Notes:** Verify against DOC24 R3 — may already specify surface profiles.
| **OBL-D24-RRB-04:** Running Brief as registered injection slot (or explicit deprecation) | DOC24 either (a) defines the Running Brief as a first-class injection slot with surface-scoped ephemeral auto-updating orientation summary semantics, or (b) explicitly deprecates the concept with a migration note pointing at the current owner of orientation responsibilities. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §1.1 (The Running Brief's narrowed scope)
- **Why:** Running Brief was a load-bearing concept for surface-scoped orientation. Current architecture (DOC24 KOI baseline + contextual packet) may have absorbed this implicitly but doesn't appear to explicitly own "Running Brief" by name. Architect needs to decide: keep it as a concept under DOC24/DOC15, or formally deprecate.
- **Acceptance:** DOC24 R3 either includes Running Brief slot definition or §16 (Recent Major Changes) carries an explicit deprecation note.
- **Calibrated against:** RRB v6 (STALE); needs disposition decision by architect.
- **Created:** 2026-04-27 (V3.3)
- **Notes:** **DISPOSITION-DECISION ROW.** This is the central question raised by RRB fold-in. Without architect decision, OBL-D24-RRB-01 through 03 land unevenly. Resolve before next DOC24 revision.
| **OBL-D24-RRB-05:** Scope definitions table (surface/run/agent/participant/global) | DOC24 publishes scope definitions: `surface` (one concrete chat/room/task/panel/forum instance), `run` (execution/run instance within surface), `agent` (one visible/system agent identity), `participant` (visible participant binding within room/panel/forum), `global` (suite-wide durable scope). | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §5.6 (Scope definitions table)
- **Why:** Without canonical scope vocabulary, authority/memory/correction scope language drifts. DOC1 §10.1 schema uses 9-value `scope` enum (operation/session/thread/panel/room/task/workspace/matter/global) which overlaps but isn't identical to RRB's 5-value scope vocabulary.
- **Acceptance:** DOC24 R3 reconciles RRB scope definitions with DOC1 authority scope enum into one canonical model. Both reference the unified table.
- **Calibrated against:** RRB v6 (STALE); cross-check against DOC1 §10.1 9-value enum (OBL-D1-04).
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-27 (V3.3)
- **Notes:** This is a TERMINOLOGY RECONCILIATION row. RRB and DOC1 disagree on scope vocabulary; one canonical model needed.
| **OBL-D24-RRB-06:** Render-at-injection-time discipline | Context blocks render at injection time, not stored as pre-rendered prompt strings. Each render call uses current state, current budget, current surface profile. | `[REQ] [PARTIAL]` |
- **Source:** RRB v6 §2.3 (Keep v5 defect fixes — "render-at-injection-time"); RRB §3.1 (Renderer contract)
- **Why:** Pre-rendered prompts go stale; budget calculations drift from runtime truth. Render-at-injection-time keeps prompt content current and budgets enforced.
- **Acceptance:** DOC24 R3 specifies that all conversation_context_block and surface_summary_block content is rendered at injection time via a named renderer function (e.g., `renderConversationContextBlock`).
- **Calibrated against:** RRB v6 (STALE)
- **Created:** 2026-04-27 (V3.3)
---
### §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
**NEW ROWS (V3.3 audit gap fixes):**
| **OBL-EC-AUD-01:** Nightly Scheduler Extension — CIL phases (audit gap from V3) | Add CIL phases 4, 4.5, 5, 6, 7 to scheduler in nightly order; DOC8 rollup available before CIL phase 4.5; deterministic phase ordering | `[REQ] [PARTIAL]` |
- **Source:** DOC15 R3.1 §11.1 (Part 1) — missed in V3 fold-in
- **Why:** CIL nightly governance pipeline depends on scheduler running phases 4, 4.5, 5, 6, 7 in order with DOC8 rollup gate before 4.5. Without explicit scheduler entries, CIL phases run ad-hoc.
- **Acceptance:** EC Core scheduler config registers all 5 CIL phases with the gate; nightly run logs phase start/finish per phase.
- **Calibrated against:** DOC15 R3.1 (stale); verify against EC Core Addendum A V3.3 nightly schedule.
- **Depends on:** —
- **Blocks:** OBL-D8-08 (DOC8 prompt-artifact lifecycle relies on scheduler order)
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-EC-AUD-02:** DocIndex access events (audit gap — Priority Matrix #31) | Document access events from DocIndex emitted to CIL bridge for usage learning | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §11.6 #31 — missed in V3 fold-in (V3 covered #32 but not #31)
- **Why:** Without document access events, CIL has no signal for which documents are actually being used vs. ignored.
- **Acceptance:** DocIndex emits typed access event on each document load/materialize/touch; CIL bridge consumes.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-EC-AUD-03:** Agent dependency resolution at spawn (EC side, audit gap — Priority Matrix #34) | EC Core/DocIndex resolves agent document dependencies at spawn time, providing lightweight advisor context | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §11.7 #34 — V3 covered DOC10 side via OBL-D10-03, missed EC Core side
- **Why:** DOC10 advisor dispatch declares dependencies; EC Core/DocIndex must actually resolve them at spawn to make advisors document-aware without baking docs into agent definitions.
- **Acceptance:** EC Core agent spawn pipeline calls DocIndex resolver with declared dependency list; resolver returns DocumentRef[] usable in advisor context.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D10-03 (DOC10 declarations)
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-EC-AUD-04:** Proactive document surfacing path (EC/DocIndex side, audit gap — Priority Matrix #35) | EC Core/DocIndex routes document recommendations to load/materialize on suggestion-card apply | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §11.8 #35 — V3 covered DOC10 side via OBL-D10-05, missed EC/DocIndex side
- **Why:** DOC10 emits doc recommendations from suggestion cards; EC Core/DocIndex must actually load the recommended docs when user applies the card.
- **Acceptance:** EC Core registers `documents.load_recommended` command consumed by DocIndex; suggestion-card apply triggers it.
- **Calibrated against:** DOC15 R3.1 (stale)
- **Depends on:** OBL-D10-05
- **Created:** 2026-04-27 (V3.3 audit fix)
| **OBL-EC-AUD-05:** Standing Order Conflict Detection Export (audit gap — verification row) | Conflict count export in context assembly so CIL can emit conflict diagnostics | `[ENH] [EXISTS]` |
- **Source:** DOC15 R3.1 §11.4 (Part 1)
- **Why:** Source marked `[ENH] [EXISTS]` — already in target spec per DOC15 R3.1's claim. V3 skipped silently; better to record for verification.
- **Acceptance:** Verify EC Core context assembly exposes `standing_order_conflict_count` field; if missing, downgrade to `[PARTIAL]`.
- **Calibrated against:** DOC15 R3.1 (stale); requires verification against EC Core Addendum A V3.3.
- **Created:** 2026-04-27 (V3.3 audit fix — verification row)
**NEW ROWS (V3.3, from RRB v6 fold-in):**
| **OBL-EC-RRB-01:** Surface reset triggers + effects + reset_generation field | EC Core implements reset detection on: agent change, session gap > BRIEF_SESSION_RESET_GAP_MINUTES (default 60min), surface_kind change, surface_id change, chat→room upgrade, panel/forum opened as fresh surface, explicit user/system reset. Reset effects: write handoff snapshot if prior brief non-empty; clear ephemeral entries; increment `reset_generation`; store `_last_reset_reason`; emit `context_surface_reset` telemetry; if room/panel/forum, require bootstrap slot to carry canonical reset notice. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §5.1 (Surface reset triggers), §5.2 (Reset effects)
- **Why:** Without explicit reset semantics, brief carries stale state across surface transitions, causing context bleed between rooms/panels/tasks.
- **Acceptance:** EC Core surface lifecycle exposes reset detection per the 7 trigger conditions; reset effects execute atomically; telemetry emits on every reset.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Blocks:** OBL-D11-RRB-01 (canonical reset notice requires reset detection)
- **Created:** 2026-04-27 (V3.3)
| **OBL-EC-RRB-02:** Handoff seed mechanism on agent switch / surface transfer | Bounded short-lived handoff seed: separate from ordinary brief state; TTL = `BRIEF_HANDOFF_SEED_TURNS` (default 3 turns) and `BRIEF_HANDOFF_SEED_MINUTES` (default 10 min); imported handoff does NOT imply same-surface continuity; chat→room upgrade uses imported summary / handoff artifact, not implicit transcript carry-over. | `[REQ] [MISSING]` |
- **Source:** RRB v6 §5.3 (Handoff seed on agent switch or surface transfer)
- **Why:** Without bounded handoff, agent transitions either lose all context (cold start) or leak full context (over-coupling). Handoff seed gives a middle path with explicit TTL.
- **Acceptance:** EC Core publishes handoff seed schema + TTL constants; hot path consults seed during fresh-surface bootstrap; seed expires per TTL.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-EC-RRB-01
- **Created:** 2026-04-27 (V3.3)
| **OBL-EC-RRB-03:** Environment awareness aggregator endpoint | EC Core publishes `GET /api/environment/entities` as bounded compact aggregator returning Layer 1 environment snapshot (rooms, visible agents, hidden system agents, capability health/degraded state, model/provider control awareness from Gateway-facing catalog). | `[ENH] [PARTIAL]` |
- **Source:** RRB v6 §6.1-6.3 (Environment awareness, aggregator endpoint)
- **Why:** Without a single bounded aggregator, environment awareness gets pulled from N different APIs per turn — slow and inconsistent.
- **Acceptance:** EC Core HTTP handler publishes route; response schema bounded to Layer 1 lean profile.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** —
- **Created:** 2026-04-27 (V3.3)
| **OBL-EC-RRB-04:** ContextInjectionEvent telemetry schema | EC Core emits typed ContextInjectionEvent with fields: event_id, ts, agent_id, participant_id?, run_id, surface_kind, surface_id, room_id?, panel_run_id?, forum_thread_id?, operation_id?, route_trace_id?, gateway_session_key?, layer (number), slot (enum: conversation_context_block / surface_summary_block / other), label, action (enum: none/truncated/reused/session_reset/cleared/edited/omitted), reason?, tokens, fingerprint, cached?, usage (UsageSampleLite). | `[REQ] [MISSING]` |
- **Source:** RRB v6 §7.1 (Telemetry event schema)
- **Why:** Without a single typed schema for context-injection telemetry, every injection path invents its own format. Schema is the foundation for OBL-D10-RRB-01 (named events) and OBL-D8-RRB-01 (friction fingerprints).
- **Acceptance:** EC Core publishes ContextInjectionEventSchema (Zod or equivalent); all injection paths emit conforming events; telemetry log conforms.
- **Calibrated against:** RRB v6 (STALE)
- **Depends on:** OBL-EC-RRB-01
- **Blocks:** OBL-D10-RRB-01, OBL-D8-RRB-01
- **Created:** 2026-04-27 (V3.3)
**NEW ROWS (V3.5, System Agent Identity Registry per architecture decision 2026-04-27):**
| **OBL-EC-AGT-01:** System Agent Identity Registry section in EC Core Addendum A | EC Core Addendum A V3.4+ adds a new section "System Agent Identity Registry" providing a thin index of all named ELNOR system agents. Schema per entry: `agent_id` (stable string), `purpose` (one-line), `owning_spec_doc` (pointer to detailed contract), `required_execution_profile` (cross-reference to §5), `declared_document_dependencies` (array of doc refs), `lifecycle_state` (enum: active / deprecated / candidate). Registry is the canonical "who's on staff" list; detailed agent contracts live in their owning specs. | `[REQ] [MISSING]` |
- **Source:** Architecture decision 2026-04-27 — Option A picked over Option B (DOC4 keep-as-registry). Rationale: EC Core is the orchestrator and already needs to know the full agent list; pairing identity with profile assignment in the same doc is natural; keeps detailed contracts in specialist owners.
- **Why:** No single doc currently owns "the list of all ELNOR system agents." Identity is fragmented across DOC4, DOC15, SUBAGENT V4 notes. Registry section creates one canonical home.
- **Acceptance:** EC Core Addendum A V3.4+ has a new section between §5 (Execution profiles) and §6 (Token/cost governance) containing the registry table + per-entry detail rows. Schema published. Registry includes all 7 currently-named agents (entries OBL-EC-AGT-02 through OBL-EC-AGT-08 below).
- **Calibrated against:** EC Core Addendum A V3.3 (current; pre-decision); will land in V3.4.
- **Depends on:** —
- **Blocks:** OBL-EC-AGT-02 through OBL-EC-AGT-08
- **Created:** 2026-04-27 (V3.5)
- **Notes:** Registry is **a thin index, not a re-spec.** Each agent's detailed contract (extract input schema, query mode protocol, composition pattern, etc.) remains in its owning spec.
- **V3.6 clarification:** Agent Identity Registry is distinct from the **DOC24 Capability Registry** (populated by Workstream K). Agents that are user-invokable get entries in BOTH registries: agent identity registry for "who they are," capability registry for "they're invokable as a capability" (with type=`agent` and `implemented_by_agent_id` cross-reference). Infrastructure-only agents (e.g., advisor_dispatcher) appear ONLY in the agent identity registry. Per-agent `capability_registered` annotation added to OBL-EC-AGT-02 through OBL-EC-AGT-08.
| **OBL-EC-AGT-02:** Registry entry — `cil_advisor` | agent_id: `cil_advisor`. Purpose: Powers CIL `Why?` path; explains injection decisions and authority application. Owning spec: DOC15 R7.1 §9.1 (concept) + DOC4 (registry implementation). Required profile: any (no special trust constraints). Dependencies: DOC15, DOC72 entity graph snapshot. | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §9.1; cross-references OBL-D4-01.
- **Why:** cil_advisor is one of the load-bearing advisor agents for CIL surfaces. Registry entry standardizes its identity so DOC10 advisor dispatch, DOC4 bridge, and DOC15 implementation all reference the same agent_id.
- **Acceptance:** EC Core Addendum A registry table includes this row; DOC4 + DOC15 cross-reference back to the registry entry.
- **Calibrated against:** DOC15 R3.1 (stale); DOC4 v1.11.6.2.
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **Notes:** Cross-references existing OBL-D4-01 (cil_advisor agent definition). OBL-D4-01 stays — it covers DOC4-side bridge implementation. OBL-EC-AGT-02 adds the registry-side identity entry. **V3.6 capability-registered: YES** — cil_advisor is invoked via DOC10 advisor dispatch (`+ask`/`+advise`/`Why?`); will appear in DOC24 capability registry (Workstream K) with type=`agent`, `implemented_by_agent_id: "cil_advisor"`.
| **OBL-EC-AGT-03:** Registry entry — `advisor_dispatcher` | agent_id: `advisor_dispatcher`. Purpose: Routing layer that resolves payload_kind → specific advisor. Owning spec: DOC4 (bridge implementation) / DOC10 (transport routing). Required profile: any. Dependencies: DOC10 advisor dispatch transport, DOC4 agent registry. | `[REQ] [MISSING]` |
- **Source:** DOC15 R3.1 §12 (Part 2 R3); cross-references OBL-D4-04.
- **Why:** Registry entry for the advisor dispatcher itself. Without it, the dispatcher is an unnamed implementation detail.
- **Acceptance:** EC Core Addendum A registry table includes this row.
- **Calibrated against:** DOC15 R3.1 (stale).
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **V3.6 capability-registered: NO** — advisor_dispatcher is infrastructure-only (the dispatcher itself is not directly invoked as a capability; it routes invocations to specific advisors). Lives in Agent Identity Registry only.
| **OBL-EC-AGT-04:** Registry entry — `review_advisor` | agent_id: `review_advisor`. Purpose: Review/red-team explanatory support — explains finding judgments, ReviewOutcomes, prompt lineage decisions. Owning spec: DOC4 (registration + bridge); DOC14 (consumer for review surfaces). Required profile: any. Dependencies: DOC14, DOC72 review-target entity refs. | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §9.2 + §1.7 (review-advisor note); cross-references OBL-D4-03.
- **Why:** Registry entry. Pairs with DOC14 review-advisor wiring.
- **Acceptance:** EC Core Addendum A registry table includes this row; DOC4 retains implementation detail.
- **Calibrated against:** DOC15 R3.1 (stale).
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **V3.6 capability-registered: YES** — review_advisor is invoked via DOC14 review surfaces / DOC10 advisor dispatch; will appear in DOC24 capability registry with type=`agent`, `implemented_by_agent_id: "review_advisor"`.
| **OBL-EC-AGT-05:** Registry entry — `spec_advisor` | agent_id: `spec_advisor`. Purpose: Spec/debug advisory support — answers questions about spec content, points at relevant DOC sections. Owning spec: DOC4 (registration + bridge). Required profile: any. Dependencies: spec corpus index (where specs live). | `[ENH] [MISSING]` |
- **Source:** DOC15 R3.1 §9.2; cross-references OBL-D4-03.
- **Why:** Registry entry.
- **Acceptance:** EC Core Addendum A registry table includes this row.
- **Calibrated against:** DOC15 R3.1 (stale).
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **V3.6 capability-registered: YES** — spec_advisor is invoked via DOC10 advisor dispatch on spec/debug surfaces; will appear in DOC24 capability registry with type=`agent`.
| **OBL-EC-AGT-06:** Registry entry — `ocm` (Operations Context Manager) | agent_id: `ocm`. Purpose: Context/orientation agent. Extract mode pulls Running Brief updates from recent turns. Query mode returns attributed cross-surface summaries (read-only, low-trust banner, cannot be sole basis for durable actions). Hidden system agent; NOT a visible room participant. Owning spec: DOC15 R7.1+ (per OBL-D15-RRB-03). Required profile: any (no model-specific requirement). Dependencies: DOC15 Running Brief state, DOC12 surface state for query mode. Lifecycle state: **PENDING DISPOSITION DECISION** (per OBL-D15-RRB-03). | `[REQ] [MISSING]` |
- **Source:** RRB v6 §4 (OCM agent — what it is and is not); cross-references OBL-D15-RRB-03.
- **Why:** OCM has a registry entry regardless of disposition. If kept as named agent, registry entry is `active`. If absorbed into DOC15 CIL extract pipeline, registry entry moves to `deprecated`. If fully retired with Running Brief, registry entry is removed.
- **Acceptance:** EC Core Addendum A registry table includes this row with explicit `lifecycle_state: "candidate"` (pending disposition) until OBL-D15-RRB-03 resolves.
- **Calibrated against:** RRB v6 (STALE).
- **Depends on:** OBL-EC-AGT-01
- **Notes:** **Distinct from `memory_agent` (OBL-EC-AGT-07).** OCM is a context/orientation agent; memory_agent is a memory-retrieval agent. Different domains.
- **Created:** 2026-04-27 (V3.5)
- **V3.6 capability-registered: MIXED** — query mode is invokable as a capability (cross-surface summary requests); extract mode is background-only / not directly invoked. If OCM disposition (per OBL-D15-RRB-03) keeps OCM as named agent, capability registry will have ONE entry (type=`agent`, `implemented_by_agent_id: "ocm"`, capability scope: `query_mode_only`). If OCM is absorbed/deprecated, no capability entry.
| **OBL-EC-AGT-07:** Registry entry — `memory_agent` (DOC73 MemoryAgent) | agent_id: `memory_agent`. Purpose: Specialist sub-agent for bounded memory retrieval/processing from the durable knowledge graph (DOC72 entity graph + DOC1 memory directives). Hidden system agent; consumed by DOC73 PBE for compositional reasoning. Owning spec: SUBAGENT V4 §1.8 (specification) + DOC73 (consumer). Required profile: typically `local_qwen_reviewer` or equivalent local profile (memory operations should default to same-machine to avoid leaking durable knowledge). Dependencies: DOC72 entity graph, DOC1 memory directives, DOC73 PBE primitives. Lifecycle state: candidate (SUBAGENT V4 currently a notes file, not yet a formal spec). | `[REQ] [PARTIAL]` |
- **Source:** SUBAGENT V4 §1.8 (MemoryAgent specification); cross-references OBL-D73 territory.
- **Why:** MemoryAgent is named in SUBAGENT V4 notes and consumed by DOC73 V1.4.1, but has no registry entry. Per architecture decision, gets a registry entry in EC Core Addendum A.
- **Acceptance:** EC Core Addendum A registry table includes this row.
- **Calibrated against:** SUBAGENT V4 (2026-04-24); DOC73 V1.4.1.
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **Notes:** Will: this answers your direct question — MemoryAgent IS in the new EC Core Addendum A registry as OBL-EC-AGT-07. Its detailed contract stays in SUBAGENT V4 §1.8.
- **V3.6 capability-registered: YES** — memory_agent is invoked by DOC73 PBE compositional reasoning + potentially by other consumers wanting bounded memory retrieval; will appear in DOC24 capability registry with type=`agent`, `implemented_by_agent_id: "memory_agent"`.
| **OBL-EC-AGT-08:** Registry entry — `document_intelligence_agent` (DOC25 / DOC73 DocumentIntelligenceAgent) | agent_id: `document_intelligence_agent`. Purpose: Specialist sub-agent for document intelligence — coordinates ingestion across MarkItDown / Docling / NuExtract / GLiNER / Firecrawl / Tesseract / OCR per DOC25 routing; produces `DOC25_IngestionResult` consumer contract output. Owning spec: SUBAGENT V4 §1.9 (specification) + DOC25 V2.0 (ingestion contract owner) + DOC73 (consumer). Required profile: variable — text-only operations may use cloud profile; sensitive document content uses local-only profile per source policy. Dependencies: DOC25 V2.0 ingestion architecture, DOC73 PBE corpus extraction, DOC72 §20A surface intake. | `[REQ] [PARTIAL]` |
- **Source:** SUBAGENT V4 §1.9 (DocumentIntelligenceAgent specification); cross-references DOC25 V2.0 + DOC73.
- **Why:** DocumentIntelligenceAgent is named in SUBAGENT V4 notes and consumed by DOC73 + DOC25 but has no registry entry.
- **Acceptance:** EC Core Addendum A registry table includes this row.
- **Calibrated against:** SUBAGENT V4 (2026-04-24); DOC25 V2.0; DOC73 V1.4.1.
- **Depends on:** OBL-EC-AGT-01
- **Created:** 2026-04-27 (V3.5)
- **Notes:** Will: this answers your direct question — DocumentIntelligenceAgent IS in the new EC Core Addendum A registry as OBL-EC-AGT-08. Its detailed contract stays in SUBAGENT V4 §1.9.
- **V3.6 capability-registered: YES** — document_intelligence_agent is invoked by DOC25/DOC73 ingestion paths; will appear in DOC24 capability registry with type=`agent`, `implemented_by_agent_id: "document_intelligence_agent"`.
---
### §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). |
| **NEW (V3.3, corrected V3.4):** Running Brief slot disposition decision | OBL-D24-RRB-04, OBL-D15-RRB-03 | RRB v6 fold-in surfaced two pending disposition decisions: (a) does DOC24 keep "Running Brief" as a registered injection slot, or formally deprecate the concept? (b) does DOC15 keep OCM as a named system agent with extract+query modes, or absorb its functions into the DOC15 CIL extract pipeline as an unnamed implementation path? Both decisions affect ~10 OBL rows. **Note:** OCM is a context/orientation agent (RRB §4 extract + query modes); DOC73 MemoryAgent is a memory-retrieval agent (SUBAGENT V4 §1.8). Different domains — they do not substitute for one another. V3.3 erroneously suggested merging OCM into MemoryAgent; corrected in V3.4. Architect to decide before next DOC24/DOC15 revision. |
| **RESOLVED (V3.5):** EC Core agent registry ownership decision | OBL-EC-AGT-01 through OBL-EC-AGT-08 | Architect picked **Option A** on 2026-04-27: EC Core Addendum A V3.4+ becomes the System Agent Identity Registry (thin index of agent_id, purpose, owning spec, required profile, dependencies, lifecycle state). DOC4 retains OpenClaw bridge content + per-agent implementation contracts where applicable; agent identity registry moves to EC Core Addendum A. 8 new OBL rows added: OBL-EC-AGT-01 (registry section) + OBL-EC-AGT-02 through OBL-EC-AGT-08 (per-agent entries: cil_advisor, advisor_dispatcher, review_advisor, spec_advisor, OCM, MemoryAgent, DocumentIntelligenceAgent). |
| **CLARIFIED (V3.6):** Agent-vs-Capability registry split | OBL-EC-AGT-* + Workstream K | Architectural clarification: Agent Identity Registry (EC Core Addendum A) and Capability Registry (DOC24 R3+, populated by Workstream K) are different registries serving different purposes. Agent Identity Registry = "who's on staff." Capability Registry = "what we can invoke" (capability types: tool / mcp / api / app / procedure / skill / plugin / **agent**). Invokable agents get entries in BOTH registries (capability entry has type=`agent` and `implemented_by_agent_id` cross-reference); infrastructure-only agents (e.g., advisor_dispatcher, OCM extract mode) live in Agent Identity Registry only. Per-agent `capability_registered: yes/no/mixed` annotation added to OBL-EC-AGT-02 through OBL-EC-AGT-08 in V3.6. ROADMAP Workstream K updated to specify `agent` as a capability type. |
| **NEW (V3.3):** Scope vocabulary reconciliation | OBL-D24-RRB-05 | RRB §5.6 has 5-value scope (surface/run/agent/participant/global). DOC1 §10.1 has 9-value enum (operation/session/thread/panel/room/task/workspace/matter/global). One canonical scope model needed. Reconcile during DOC24 R3+ or DOC1 next revision. |
| **NEW (V3.3):** RRB-derived row triage against current architecture | This V3.3 fold-in | Same triage gap as V3 — many `[REQ] [MISSING]` RRB rows may already be `[REQ] [PARTIAL]` or `[REQ] [EXISTS]` against DOC24 R3 / DOC72 R5.73 / DOC15 R7.1 / DOC8 v1.11.4. Schedule a triage pass that walks each new V3.3 row against current spec state. |
| **NEW (V3.3):** DOC2 retirement coordination | OBL-D2-RRB-01 | DOC72 Continuity Synthesis Architecture R1 proposes DOC2 retirement. The single OBL-D2-RRB-01 row (freshness coordination) needs to transfer to whichever spec absorbs DOC2's responsibilities — likely DOC72 §X. Track during Continuity Synthesis integration. |
---
## 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 |
| 2026-04-27 | **V3.6 architectural clarification — Agent-vs-Capability registry split.** Will surfaced the question: are sub-agents (memory_agent, document_intelligence_agent) capabilities? Resolution: agents and capabilities are different things. Agent Identity Registry (EC Core Addendum A V3.4+ per V3.5) lists every named agent. Capability Registry (DOC24 R3+ via Workstream K) lists invokable capabilities. The two cross-reference: invokable agents appear in BOTH (capability entry has type=`agent` + `implemented_by_agent_id`); infrastructure-only agents appear ONLY in agent identity registry. Per-agent `capability_registered: yes/no/mixed` annotation added to OBL-EC-AGT-02 through OBL-EC-AGT-08. ROADMAP Workstream K updated to add `agent` as a capability type. No new OBL rows; clarification only. | Claude Sonnet 4.6 (Cowork) |
| 2026-04-27 | **V3.5 architecture decision recorded — EC Core Addendum A becomes System Agent Identity Registry.** Architect picked Option A (over Option B which would have kept agent registry in DOC4). EC Core Addendum A V3.4+ adds a new "System Agent Identity Registry" section between §5 (Execution profiles) and §6 (Token/cost governance). Registry is a thin index — agent_id, purpose, owning spec, required execution profile, declared document dependencies, lifecycle state. Detailed agent contracts stay in their owning specs. 8 new OBL rows: OBL-EC-AGT-01 (registry section infrastructure) + OBL-EC-AGT-02 through OBL-EC-AGT-08 (one entry per system agent: cil_advisor, advisor_dispatcher, review_advisor, spec_advisor, ocm, memory_agent, document_intelligence_agent). MemoryAgent and DocumentIntelligenceAgent (which Will asked about specifically) are now registered as OBL-EC-AGT-07 and OBL-EC-AGT-08; their detailed specs stay in SUBAGENT V4 §1.8 and §1.9. DOC4 is NOT changed — retains OpenClaw bridge content + per-agent implementation where applicable; agent identity registry moves to EC Core. §9 question on registry ownership marked RESOLVED. | Claude Sonnet 4.6 (Cowork) |
| 2026-04-27 | **V3.4 correction pass over V3.3.** Fixes OCM/MemoryAgent conflation error introduced in V3.3 OBL-D15-RRB-03, §9 disposition-decision question, and RRB archive header (handled separately). OCM (context/orientation agent — extract Running Brief updates from recent turns + bounded cross-surface query) and DOC73 MemoryAgent (bounded memory retrieval from durable knowledge graph) serve different purposes. V3.3 incorrectly listed "merge into DOC73 MemoryAgent" as an OCM disposition option; V3.4 corrects to "absorb into DOC15 CIL extract pipeline" or "deprecate with Running Brief." No content additions; pure correction. | Claude Sonnet 4.6 (Cowork) |
| 2026-04-27 | **V3.3 incremental update — V3 audit gap fixes + Running Brief Remediation v6 fold-in.** Two distinct work units folded in same increment. (A) **Audit gap fixes (10 rows)** — V3 self-audit identified 10 missed/under-extracted obligations from DOC15 R3.1: DOC3 §11 (R3) 4 obligations (lane naming, llamaindex_index provider, canonical vs sidecar separation, capability-family truth) — OBL-D3-AUD-01 through OBL-D3-AUD-04; DOC10 §7.3 explicit `+ask/+advise` routing — OBL-D10-AUD-01; DOC12 §2.4 `reopened_room_found_same` FUT signal — OBL-D12-AUD-01; DOC16 §14 (R3) preservation sync rule — OBL-D16-AUD-01; DOC1 §1.3 (R3) required routes/read seams — OBL-D1-AUD-01; EC Core §11.1 nightly scheduler extension — OBL-EC-AUD-01; EC Core #31 DocIndex access events — OBL-EC-AUD-02; EC Core #34 agent dependency resolution (EC side) — OBL-EC-AUD-03; EC Core #35 proactive document surfacing (EC/DocIndex side) — OBL-EC-AUD-04; EC Core §11.4 standing order conflict detection (EXISTS verification) — OBL-EC-AUD-05. (B) **RRB v6 fold-in (~22 rows)** — RRB v6 (March 3, 2026; 843 lines; self-calibrated against DOC10 R10 / DOC11 V3 / DOC12 R2) substantially superseded by current architecture but contained unique content extracted as obligations: DOC24 (no-unregistered-injection invariant load-bearing, 5-slot injection ownership table, surface profiles + budgets, Running Brief slot disposition decision, scope definitions terminology reconciliation, render-at-injection-time discipline) — OBL-D24-RRB-01 through OBL-D24-RRB-06; DOC15 (SurfaceScope schema, two-track extraction discipline, OCM agent disposition decision) — OBL-D15-RRB-01 through OBL-D15-RRB-03; DOC11 (canonical reset notice via bootstrap slot, surface plumbing in hot path) — OBL-D11-RRB-01, OBL-D11-RRB-02; EC Core (surface reset triggers + effects, handoff seed mechanism, environment aggregator endpoint, ContextInjectionEvent schema) — OBL-EC-RRB-01 through OBL-EC-RRB-04; DOC10 (7 context-injection telemetry event names) — OBL-D10-RRB-01; DOC8 (5 friction fingerprints, nightly quality summary metrics, surface-attributed corrections) — OBL-D8-RRB-01 through OBL-D8-RRB-03; DOC12 (parallel-agent isolation, SurfaceSummaryArtifact contract) — OBL-D12-RRB-01, OBL-D12-RRB-02; DOC2 NEW SECTION §6.2A (freshness coordination rule with retirement caveat) — OBL-D2-RRB-01; DOC20 (Memory Browser top card editor, compact context viewers, OCM management page, header health) — OBL-D20-RRB-01 through OBL-D20-RRB-04. RRB v6 archived to Subsumed Specs. Two **DISPOSITION-DECISION rows** flagged for architect: OBL-D24-RRB-04 (Running Brief slot keep-or-deprecate) and OBL-D15-RRB-03 (OCM agent keep-or-deprecate). | Claude Sonnet 4.6 (Cowork) |
---
## 11. End of tracker
**Self-test for usability (V3.6):**
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