OP_A_V3_6_TO_V3_7_PATCH_V1.md
OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/OP_A_V3_6_TO_V3_7_PATCH_V1.md
# DOC OP-A V3.6 → V3.7 Patch Document
**Patch source:** DOC73 V1.5.1 FINAL (`DOC73_V1_5_1_FINAL.md`, 11,657 lines, 33 sections, 126 INVs)
**Patch target:** DOC OP-A V3.6 → V3.7
**Patch date:** 2026-04-29
**Author:** Claude (per architect Will's instruction)
**Purpose:** Consolidate every cross-doc obligation introduced or modified by DOC73 V1.5.1 into OP-A's master coordination ledger.
---
## How to apply this patch
This document is a **delta against OP-A V3.6**. Each section below specifies edits to a specific OP-A V3.6 location:
- **REPLACE [X] WITH [Y]** — substitute existing content
- **APPEND TO §X** — add at end of named section
- **NEW ROW IN §X** — insert as new OBL row in the target section
- **NEW SECTION §X** — add a brand-new section
After all edits are applied, increment the version header from V3.6 to V3.7 and add the V3.7 maintenance log entry per the bottom of this patch document.
**Shape of changes:**
| Action | Count |
|---|---|
| Existing rows to update (status / calibration anchor) | 8 |
| New rows to add | ~62 |
| New §6.x sections added | 0 (V1.5.1 doesn't introduce new target docs beyond V3.6's set) |
| §6.21 DOC73 expansion | 11 new bundle rows (OBL-D73-NEW-04 through OBL-D73-NEW-11 plus refresh of NEW-01/02/03 and rebadging of NEW-PBE-CLUSTER-01 etc.) |
| §9 Open Meta-Architecture entries | 1 new (V1.5.1 audit complete) |
| §10 Maintenance log | 1 new entry (V3.7) |
---
## EDIT 1 — Update version header and front matter
### REPLACE the V3.6 front matter block (lines 1-57, ending with `---` before `**V3.5 changes from V3.4:**`) WITH:
```markdown
# DOC OP-A — Cross-Doc Obligation Tracker V3.7
**DOC ID:** DOC OP-A (operations spec, A series — cross-doc obligation tracker)
**Version:** V3.7 (DOC73 V1.5.1 FINAL fold-in — ~62 new rows across 12 target specs; §6.21 DOC73 §6.21 expanded from 3 V3.1-era rows to 14 rows; OBL-D73-NEW-01 through OBL-D73-NEW-11 bundles)
**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
**Date V3.7 produced:** 2026-04-29
**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.7 changes from V3.6:**
V3.7 folds in DOC73 V1.5.1 FINAL (paste-ready 11,657-line spec; 33 top-level sections; 126 named invariants). DOC73 V1.5.1 introduces the largest single-version expansion of cross-doc obligations to date — ~62 new rows distributed across DOC72, DOC24, DOC25, EC Core, DOC1, DOC18, BDSM, PropA, DOC15, DOC7, DOC20, DOC23, DOC8.
**Major V3.7 changes:**
- §6.21 DOC73: Existing OBL-D73-NEW-01, -02, -03 rows updated to `[REQ] [EXISTS]` against V1.5.1 (calibration anchor advanced from V1.4.1 → V1.5.1). 11 new bundle rows added (OBL-D73-NEW-04 through OBL-D73-NEW-11, plus OBL-D73-NEW-04D mathematical reference) covering the V1.5.1 normative additions per V1.5.1 §24.5.14 obligation summary.
- §6.20 DOC72: 1 new row OBL-D72-NEW-PBE-CLUSTER-01 (cluster API/result schema as superset of PBEClusterDetectionResultMinimum or DOC73-side adapter); 1 new row OBL-D72-NEW-NOVELTY-01 (contextual novelty asymptote per V1.5 cluster mechanics).
- §6.18 DOC24: 4 new rows for V1.5-driven extensions (lane-based packet budgeting, total_budget_tokens consumer surface, conditional probe sequencing, inspect_knowledge_summary tool registration).
- §6.19 DOC25: 6 new rows for V1.5.1 §17 IngestionResult contract (multi-hash discipline, V1.5 quality_class enum, V1.5 OPTIONAL prompt_injection_risk_flags field, hard-fail reason code cooperation, capacity lease integration, state machine compatibility).
- §6.22 EC Core: 4 new rows: OBL-EC-NEW-SESSION-CONTEXT-01 (ephemeral session_context store), OBL-EC-NEW-BLOB-01 (content-addressable blob store for versioned artifacts), OBL-EC-NEW-MIGR-01 (conditional GIE/KIE label remapping during migration), OBL-EC-NEW-PBE-RECEIPT-01 (PrimaryPBEOrchestrator with PBEOperationReceiptLite wrapping). Note: OBL-EC-AGT-06 (OCM), OBL-EC-AGT-07 (memory_agent), OBL-EC-AGT-08 (document_intelligence_agent) already exist in V3.5/V3.6; V1.5.1 §24.5.4 references the existing rows, no duplication needed.
- §6.5 DOC7: 9 new rows for V1.5 corpus page tab structure (Triage, Runs, Settings → Verifier Calibration, Settings → Migration, Suggested Corpora, Cost section, PBE-lite banner, 9-tab structure, PBEUICommandMatrixRow registration), plus OBL-D7-NEW-LIBRARY-NAMING-01 (library naming UI rendering rule).
- §6.15 DOC20: 4 new rows for V1.5 (scope indicator with firewalled annotation, PBE-lite mode banner, cost band display per cost acceptance tiers, library naming rendering rule).
- §6.14 DOC18: 2 new rows for V1.5 (vector lane tombstone filter per INV-8.X.6, vector tombstone GC per INV-8.X.7); plus OBL-D18-NEW-02 (FTS5 tokenizer for legal citations per V6 audit item).
- §6.23 BDSM: 5 new rows for V1.5 (privacy-partitioned utility ledgers, AVAPO C1-C5 signal dimensions, cluster_thrash_rate signal NEW V1.5, critique-utility signal, cross-firewall identity attempts signal).
- §6.25 PropA: 6 new rows for V1.5 (LearningVisibilityScope filtering, SchemaMigrationPlan emission for schema-changing iterations, verifier prompt iteration via VerifierCalibrationLedger, AVAPO regression fixture exclusion rules, post-retrieval critique prompt surface, additive synthesis regeneration prompt surface).
- §6.12 DOC15 / OCM: 2 new rows for V1.5 (specialist envelope assembly compatible with SpecialistPartialOutput typed union, prompt-composition governance for specialist envelope per V1.5 §15.7.2 stop-gap).
- §6.5 DOC7 (continued above), §6.17 DOC23: 2 new rows for V1.5 (gathering-agent task kind, task-output-to-corpus auto-ingest source class).
- §6.6 DOC8: 1 new row for V1.5 (pattern family for verifier calibration state transitions per §6.7C).
- §6.1 DOC1: 1 new row for V1.5 (reaffirm DOC1 §4.12 disclaimer of CU input authority aggregation scope).
- §9 Open Meta-Architecture Questions: 1 new entry (DOC24↔DOC73 V1.5.1 audit complete; DOC73 V1.5.1 stabilized with 126 invariants; absorption of GIE/KIE complete per V3.6 baseline).
- §10 Maintenance Log: V3.7 entry appended.
**Provenance tracking:** Every V3.7-added row carries `Calibrated against: DOC73 V1.5.1 (2026-04-29)` in its `Calibrated against:` field, and references DOC73 V1.5.1 §24.5.{N} subsection in its `Source:` field. This makes V3.7 additions cleanly distinguishable from prior layers via grep.
No existing rows from V3.1-V3.6 are deleted; the three V3.1-era DOC73 rows (OBL-D73-NEW-01, -02, -03) are status-updated to `[REQ] [EXISTS]` reflecting V1.5.1 implementation, with calibration anchor advanced.
---
```
(The patch then continues with the V3.6, V3.5, V3.4, V3.3, V3.2, V3.1 changelog blocks unchanged — preserve everything from current OP-A V3.6 line ~58 onward through `---` and `**V3.5 changes from V3.4:**` block until the start of `## 1. How to use this document`.)
---
## EDIT 2 — §6.1 DOC1 update (1 new row)
### APPEND TO §6.1 DOC1 — Memory Resilience (after the last existing OBL-D1-* row, before the closing `---`):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D1-NEW-V15-01:** Reaffirm DOC1 §4.12 disclaimer of CU input authority aggregation scope | DOC1 governance applies to CU promotion/revision lifecycle as memory directives, NOT to CU input authority aggregation. CU authority aggregation lives in DOC73 §3.2A, not DOC1. DOC1 §4.12 non-goals language explicitly retained. | `[REQ] [EXISTS — verify in next DOC1 revision]` |
- **Source:** DOC73 V1.5.1 §24.5.5; DOC73 V1.5.1 §23.6 (DOC1 reframing per V1.4 R5.3 A9)
- **Why:** Without explicit DOC1 disclaimer, any DOC1 governance update could accidentally re-claim CU authority aggregation scope, causing collision with DOC73 §3.2A authority aggregation algorithm.
- **Acceptance:** DOC1 §4.12 non-goals language retained verbatim or strengthened; DOC1 next revision verifies that no §4.x section transitively governs CU input authority resolution.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC1 R1
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **Notes:** Standing-orders preservation in PBE-lite mode (per DOC73 V1.5.1 §12.6.2) is unchanged DOC1 governance — explicitly preserved by V1.5.1.
```
---
## EDIT 3 — §6.5 DOC7 update (10 new rows)
### APPEND TO §6.5 DOC7 — Context Buckets & Files (after the last existing OBL-D7-* row, before the closing `---`):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D7-NEW-V15-01:** Corpus page 9-tab structure | DOC7 corpus page renders exactly 9 tabs in this order: (1) Profiles, (2) Extraction Instructions, (3) Triage / Conflicts, (4) Runs / Jobs, (5) Settings, (6) Members, (7) Activity, (8) Permissions, (9) Cost. Adding/removing/consolidating tabs is non-conformant per V1.5.1 INV-13.6. Profiles tab is **distinct** from Extraction Instructions tab. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13.6 + INV-13.6
- **Why:** Anti-summarization invariant (per CL-G-46 zone 11) — without explicit tab enumeration, coding agents would consolidate tabs (e.g., merge Profiles into Extraction Instructions), losing the architectural distinction between thin-plus structural metadata (Profiles) and substantive priorities (Extraction Instructions).
- **Acceptance:** DOC7 R8+ specifies the 9-tab structure with INV-13.6 enforcement; CI build-time check enumerates the rendered tabs.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC7 R7
- **Depends on:** —
- **Blocks:** OBL-D7-NEW-V15-02 through -09 (each tab's content)
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-02:** Triage / Conflicts tab implementation | DOC7 corpus page Triage tab surfaces ClaimFamilyBundles by lane (urgent / issue bundle queue / silent ledger), AccessPath issues per V1.5.1 §10.2A INV-10.2A.1, capability gaps per §14.5.1, and sealed-mode access denials per §11.X.2A. Per-bundle affordances: Accept as Contradiction / Dismiss as Noise / Refine Target / Resolve in Favor of Side X / Track Both Sides. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13.7 + §14.4.3 + §10.2A
- **Why:** Triage surface is the load-bearing UI for counterfactual finding bundles, access path rot, and capability gap remediation. Without it, surfaced issues have no actionable home.
- **Acceptance:** DOC7 R8+ Triage tab implements three lanes + three additional triage categories; per-bundle affordances enumerated.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC7 R7
- **Depends on:** OBL-D7-NEW-V15-01 (9-tab structure)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-03:** Runs / Jobs tab implementation | DOC7 corpus page Runs tab surfaces extraction run history, halted/degraded extractions per V1.5.1 §10.4A INV-10.4A.1/.2, cost per run, rollback affordance per §14.7.Z. Each run shows: run_id, corpus, extraction_spec_version, status, cost_consumed_usd, cost_estimated_usd, memories_produced, depth_degraded_to. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13.8 + §10.4A
- **Why:** Without Runs tab, halted/degraded extractions have no surfacing path; user cannot resume halted jobs or rollback bad runs.
- **Acceptance:** DOC7 R8+ Runs tab with active/recent/halted sections; rollback affordance triggers §14.7.Z preflight; resume affordance overrides EC scheduler.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC7 R7
- **Depends on:** OBL-D7-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-04:** Settings → Verifier Calibration sub-tab | DOC7 corpus page Settings tab includes a Verifier Calibration sub-tab displaying §6.7C VerifierCalibrationLedger state per (verifier_prompt_version, profile, corpus). Surfaces 5-state calibration_status enum (uncalibrated / calibrating / calibrated / drifting / failed). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6.7C + INV-6.7C.1/.2
- **Why:** Verifier calibration is gating mechanism for auto-promotion (INV-6.7C.1). Without UI surface, calibration state is invisible and verifier drift goes undetected.
- **Acceptance:** DOC7 R8+ Settings → Verifier Calibration with table view; calibration_status filterable.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-05:** Settings → Migration sub-tab | DOC7 corpus page Settings tab includes a Migration sub-tab surfacing §27.6 review queue for `needs_review`-flagged carve_out_class defaults from V1.4 → V1.5 migration. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13.6 + §27.6 + INV-27.5
- **Why:** V1.5.1 migration assigns `needs_review=true` to ambiguous carve_out_class cases (~5% of historical CUs). Without Migration tab, these flagged CUs have no review surface.
- **Acceptance:** DOC7 R8+ Settings → Migration with review queue + accept/edit/reject affordances per CU.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-06:** Suggested Corpora UI per stability protocol | DOC7 surfaces clustered corpus suggestions only when clusters are stable per §4.1A.3 (stability protocol with hysteresis); thrashing clusters do NOT surface as suggestions. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §4.1A.3 + INV-4.1A.3.1/.2
- **Why:** Without stability protocol, cluster thrash creates churning suggestion list that confuses users. Stability gate prevents this.
- **Acceptance:** DOC7 R8+ Suggested Corpora list filtered by `stability_status="stable"`; thrashing clusters surface ONLY in admin diagnostics view.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D72-NEW-PBE-CLUSTER-01 (cluster API)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-07:** Cost section displaying CostBudgetLedger | DOC7 corpus page Cost tab displays §5A.8 CostBudgetLedger with bucket breakdowns: extraction / verification / adaptation / self_improvement / retrieval / consolidation. Daily / weekly / monthly rollups. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §5A.8 + §13.6 tab 9
- **Why:** Cost observability per §6B.6 acceptance tiers requires visible bucket-level breakdowns. Cost band ($0-5/day target, $20+/day investigate) makes tiers measurable.
- **Acceptance:** DOC7 R8+ Cost tab with 6-bucket breakdown + 3 rollup periods.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-08:** PBE-lite banner format | DOC7 surfaces PBE-lite mode banner per V1.5.1 §12.6.Z when PBE is in degraded mode. Banner lists which 5 load-bearing contracts are unavailable (per INV-12.6.Z.1-.4). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §12.6.Z + INV-12.6.Z.1-.4
- **Why:** PBE-lite mode degrades silently without banner; users would not know why extraction is paused or why review queue is empty.
- **Acceptance:** DOC7 R8+ banner above corpus page header when PBE-lite active; lists unavailable contracts; persists until mode auto-recovers.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-PBE-RECEIPT-01 (PBE-lite mode signal source)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-V15-09:** PBEUICommandMatrixRow registration | Every state-changing UI control in DOC7 mutating DOC73 state MUST register a PBEUICommandMatrixRow per V1.5.1 §13.X + INV-13.X.1. Build-time check enumerates DOC7 button handlers and verifies each has a matrix row. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13.X + INV-13.X.1
- **Why:** Without registration discipline, coding agents would create UI affordances that bypass PBEOperationReceiptLite wrapping (per §0B INV-0B.1).
- **Acceptance:** DOC7 R8+ ships PBEUICommandMatrixRow registry; CI lint enforces every state-changing button has matrix row.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-PBE-RECEIPT-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D7-NEW-LIBRARY-NAMING-01:** Library naming UI rendering rule | DOC7 (and DOC20) renders the technical term "corpus" as user-facing "library" per V1.5.1 §0D terminology table. Schema field names retain `corpus_id`, `corpus_membership_id`. UI strings render "library." Lint rule scope: system-authored static strings only (excludes user-quoted text, log values containing user input, document contents per V6 Patch D-13). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §0D + V6 Patch D-13
- **Why:** Terminology consistency — coding agents reading the spec consume "corpus" as the technical term; UI users see "library." Without rendering rule, UI would expose the technical term and confuse users; or schema would be renamed to `library_id` and break cross-spec contracts.
- **Acceptance:** DOC7 R8+ ships UI rendering function `render_user_facing(text)` that substitutes "corpus" → "library" in system-authored static strings; CI lint enforces no UI rendering bypass.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 4 — §6.6 DOC8 update (1 new row)
### APPEND TO §6.6 DOC8 — Self-Learning (after the last existing row):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D8-NEW-V15-01:** Pattern family for verifier calibration state transitions | DOC8 adds pattern family for verifier_prompt_version × calibration_status transitions per V1.5.1 §6.7C. Pattern types: calibration_drift_onset (calibrated → drifting), calibration_recovery (drifting → calibrated), calibration_failure (drifting → failed), recalibration_request (failed → calibrating). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6.7C + §24.5.13
- **Why:** Without pattern family, verifier calibration drift signals have no taxonomy; BDSM signal aggregation has no schema for these transitions.
- **Acceptance:** DOC8 v1.12+ pattern catalog includes verifier_calibration_* family with 4+ pattern types; PropA prompt-iteration consumes patterns.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC8 v1.11.4
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 5 — §6.12 DOC15 update (2 new rows)
### APPEND TO §6.12 DOC15 — Cognitive Infrastructure Layer (after OBL-D15-NEW-02):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D15-NEW-V15-01:** Specialist envelope assembly with SpecialistPartialOutput typed union | DOC15 specialist envelope assembly compatible with V1.5.1 §15.7.7 typed `SpecialistPartialOutput` discriminated union. Failure paths return typed partial outputs (memory_synthesis_partial / document_intelligence_partial / ...), not free-form failure messages. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §15.7.7 + §24.5.9
- **Why:** Without typed partial outputs, specialist failure handling cannot route to typed reattempt paths. Free-form failure messages also leak chain-of-thought.
- **Acceptance:** DOC15 R7.1+ specialist envelope contract requires `SpecialistPartialOutput` discriminated union return type; failure paths typed.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC15 R7.1
- **Depends on:** OBL-EC-AGT-07 (memory_agent registry entry — already exists in V3.5/V3.6); OBL-EC-AGT-08 (document_intelligence_agent — already exists in V3.5/V3.6)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D15-NEW-V15-02:** DOC15 prompt-composition governance for specialist envelope (V1.5 stop-gap) | Until full DOC15 prompt governance lands, DOC15 owns specialist envelope assembly composition rules per V1.5.1 §15.7.2: which prompt fragments compose into the specialist call, in what order, with what isolation between specialist invocations. | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §15.7.2 + §24.5.9
- **Why:** Specialist invocation envelope is currently composed ad hoc; without governance, prompt fragments leak across invocations or fail to compose deterministically.
- **Acceptance:** DOC15 R7.1+ owns envelope_composition() function with deterministic ordering + isolation rules. V1.5.1 marks this as stop-gap until DOC15 prompt governance fully lands.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC15 R7.1
- **Depends on:** —
- **Blocks:** Future DOC15 full prompt governance
- **Created:** 2026-04-29 (V3.7)
- **Notes:** Stop-gap nature of this obligation — DOC15 may absorb this into broader prompt governance in a future revision; OP-A row updates accordingly.
```
---
## EDIT 6 — §6.14 DOC18 update (3 new rows)
### APPEND TO §6.14 DOC18 — LlamaIndex Retrieval Sidecar (after OBL-D18-03):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D18-NEW-V15-01:** Vector lane tombstone filter | DOC18 retrieval against `vec_nodes` MUST filter by node status (active / under_revision / contested) per V1.5.1 §8.X.6 INV-8.X.6. Implementation that returns embeddings for retracted/superseded/collapsed nodes is non-conformant. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §8.X.6 + INV-8.X.6
- **Why:** Without tombstone filter, vector retrieval surfaces stale embeddings — produces drift, contradicts retraction discipline.
- **Acceptance:** DOC18 R-next adds status-aware filter to vector lane query path; CI test verifies retracted-node embeddings never returned.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC18 R-current
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D18-NEW-V15-02:** Vector tombstone GC | Nightly consolidation removes retracted/superseded/collapsed embeddings older than 7 days per V1.5.1 §8.X.7 INV-8.X.7. Implementation that retains embeddings beyond grace window is non-conformant. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §8.X.7 + INV-8.X.7
- **Why:** Without GC, vector store grows unbounded with stale embeddings.
- **Acceptance:** DOC18 R-next adds nightly tombstone GC job; runs as part of §17.X Phase 5 nightly orchestration.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D18-NEW-V15-01 (filter must exist before GC is safe)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D18-NEW-02:** FTS5 tokenizer for legal citations | DOC18 FTS5 tokenizer handles legal citation patterns (e.g., "550 U.S. 544", "§10b-5", "Fed. R. Civ. P. 12(b)(6)") as preserved tokens, not split tokens. Without preservation, citation searches return zero results because tokenizer fragments the citation. | `[REQ] [MISSING]` |
- **Source:** DOC73 V6 Adjudication Card item 23
- **Why:** Securities litigation corpora (and legal corpora generally) depend on citation searches. Default FTS5 tokenizer fragments "550 U.S. 544" into ["550", "u", "s", "544"] losing citation semantics.
- **Acceptance:** DOC18 R-next custom tokenizer recognizes citation patterns from a configurable regex list; CI test verifies legal citations searchable.
- **Calibrated against:** DOC73 V6 card (2026-04-28)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 7 — §6.15 DOC20 update (4 new rows)
### APPEND TO §6.15 DOC20 — Browser/Notes/Document Viewer (after the last existing row):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D20-NEW-V15-01:** Visible scope indicator with one-click override | DOC20 workspace shell renders scope indicator showing current chat/note scope; click expands to per-corpus override per V1.5.1 §11. Firewalled annotation when scope crosses firewall boundary per §11.6 + INV-11.6. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §11.6 + §24.5.11
- **Why:** Without visible scope, users don't know which corpora are reachable; firewall breaches go unsurfaced.
- **Acceptance:** DOC20 R-next workspace shell adds scope indicator with annotation; firewall boundary highlighted when applicable.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D20-NEW-V15-02:** PBE-lite mode banner display | DOC20 workspace shell displays PBE-lite mode banner per V1.5.1 §12.6.Z when PBE is degraded. Mirrors DOC7 corpus page banner per OBL-D7-NEW-V15-08. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §12.6.Z + §24.5.11
- **Why:** PBE-lite affects all surfaces; workspace-level banner ensures users see the degraded state regardless of which surface is active.
- **Acceptance:** DOC20 R-next adds workspace-shell banner; coordinated with DOC7 banner per OBL-D7-NEW-V15-08.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-PBE-RECEIPT-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D20-NEW-V15-03:** Cost band display per acceptance tiers | DOC20 displays current cost band per V1.5.1 §6B.6 cost acceptance tiers ($0-5/day green target, $5-20/day yellow watch, $20+/day red investigate). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6B.6 + §5A.8 CostBudgetLedger
- **Why:** Cost observability — without surfaced band, cost overruns go unnoticed until budget gates trip.
- **Acceptance:** DOC20 R-next workspace shell adds cost band indicator; sources from §5A.8 CostBudgetLedger.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-07 (CostBudgetLedger surface)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D20-NEW-V15-04:** Library naming UI rendering rule (workspace-level) | DOC20 renders technical "corpus" as user-facing "library" per V1.5.1 §0D. Same rendering rule as OBL-D7-NEW-LIBRARY-NAMING-01 but applied at workspace shell level for navigation, breadcrumbs, search, scope indicator, banner. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §0D + §24.5.11
- **Why:** Workspace shell is highest-visibility surface for terminology; library naming consistency across DOC7 + DOC20 is the user-facing experience.
- **Acceptance:** DOC20 R-next consumes shared `render_user_facing()` rendering function from DOC7 (or replicates with same rules); CI lint applies.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-LIBRARY-NAMING-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 8 — §6.17 DOC23 update (2 new rows; §6.17 currently has no OBL rows)
### REPLACE the body of §6.17 DOC23 — Task System with:
```markdown
### §6.17 DOC23 — Task System
(No prior rows. V3.7 adds first DOC23 obligations driven by DOC73 V1.5.1.)
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D23-NEW-V15-01:** Gathering-agent task kind | DOC23 task system supports a `gathering_agent` task kind that runs extraction gathering work per V1.5.1 §14.7. Task carries (corpus_ref, source_class, gathering_plan, capability_requirements). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §14.7 + §24.5.12
- **Why:** Autonomous gathering (web fetch + named-API pull + file system scan) needs durable task representation; without it, gathering runs are ephemeral and uncoordinated with task scheduling.
- **Acceptance:** DOC23 task system adds gathering_agent task kind; integrates with EC Core capacity lease (per §15.5.Z).
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC23 R3
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D23-NEW-V15-02:** Task-output-to-corpus auto-ingest source class | DOC23 task outputs writing to a specific corpus carry source_class `named_api_pull` per V1.5.1 §14.8.X auto-ingest source class. Task scheduler emits ingest events to PBE on task completion. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §14.8.X + §24.5.12
- **Why:** Without explicit source_class, auto-ingested task outputs are indistinguishable from user-uploaded content; trust framework cannot apply differentiated rules.
- **Acceptance:** DOC23 task scheduler emits typed ingest events with source_class; PBE consumes per §14.8.X trust framework.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D23-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 9 — §6.18 DOC24 update (4 new rows)
### APPEND TO §6.18 DOC24 — Unified Knowledge, Capability, and Onboarding (after the last existing OBL-D24-* row):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D24-NEW-V15-01:** Lane-based packet budgeting (5 lanes with priority order) | DOC24 R3+ implements lane-based packet budgeting with 5 lanes per V1.5.1 §6.5: hard_required → user_pinned → high_relevance → medium_relevance → low_relevance. Long-chunk assembly: chunk > 40% of budget triggers reordering. | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §6.5 + §24.5.2
- **Why:** Without explicit lane-based budgeting, hard_required content can be silently trimmed when long chunks consume budget; prevents §3.2A authority preservation in extraction-mode KDA packets.
- **Acceptance:** DOC24 R3+ §19 packet governance specifies 5 lanes; long-chunk threshold 40%; verified in §6.5 conformance test.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC24 R3
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D24-NEW-V15-02:** total_budget_tokens consumer surface | DOC24 R3+ exposes `total_budget_tokens` as consumer surface for §6.5.0 readers per V1.5.1 §23.4 INV-23.4 (DOC73 reads from DOC24 packet governance, no DOC73-side budget machinery). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6.5.0 + §23.4 INV-23.4
- **Why:** Without exposed budget surface, DOC73 extraction would build its own budget tracker (duplication; drift risk). Exposing DOC24's total_budget_tokens makes DOC24 authoritative.
- **Acceptance:** DOC24 R3+ §19 publishes `total_budget_tokens` via packet governance read API; DOC73 §6.5.0 consumer reads it.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D24-NEW-V15-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D24-NEW-V15-03:** Conditional probe sequencing for onboarding | DOC24 R3+ supports conditional probes after Q9 per V1.5.1 §13A.4 (Q9.1 counterfactual scope, Q9.2 auth requirements, Q9.3 signal conflict). Probes triggered by specific compilation outcomes from intent-to-guidance pipeline. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §13A.4 + §24.5.2
- **Why:** Without conditional probes, ToolRequirementPlan compilation surfaces ambiguity that user has no path to resolve in onboarding flow.
- **Acceptance:** DOC24 R3+ onboarding flow extends with conditional probe machinery; trigger conditions per V1.5.1 §13A.4.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D24-NEW-V15-04:** inspect_knowledge_summary tool registration | DOC24 R3+ registers `inspect_knowledge_summary` capability tool per V1.5.1 §24.5.2 (formerly GIE Appendix A obligation). Tool returns structured summary of corpus knowledge state for user inspection. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §24.5.2 (was V1.1 GIE Appendix A obligation)
- **Why:** User-facing knowledge inspection requires a tool surface; without registration, no path for users to inspect what corpus has accumulated.
- **Acceptance:** DOC24 R3+ capability registry includes `inspect_knowledge_summary` with input/output contract; consumer is DOC7 corpus page (OBL-D7-NEW-V15-* family).
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 10 — §6.19 DOC25 update (6 new rows)
### APPEND TO §6.19 DOC25 — Document Intelligence & Universal Ingestion (after OBL-D25-02):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D25-NEW-V15-01:** §17 IngestionResult contract (multi-hash discipline) | DOC25 V2.0 §17 publishes `DOC25_IngestionResult` schema with multi-hash discipline per V1.5.1 §17 + §23.5 INV-23.5: `raw_file_hash`, `normalized_binary_hash`, `normalized_text_hash`, `page_hashes`, `chunk_hashes`, `source_instance_id`. | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §23.5 + §24.5.3 + INV-23.5
- **Why:** Without multi-hash discipline, dedup, version detection, and tombstone GC have no canonical content fingerprints.
- **Acceptance:** DOC25 V2.0 §17 has all 6 hash fields; DOC73 adapter consumes per §5A.7.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC25 V2.0
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D25-NEW-V15-02:** IngestionQualityReport with V1.5 quality_class enum | DOC25 V2.0 emits `IngestionQualityReport` per V1.5.1 §15.4.1 with V1.5 quality_class enum: `pristine` / `acceptable` / `degraded_acceptable` / `unusable`. | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §15.4.1 + §24.5.3
- **Why:** Without enum, quality classification is free-form; downstream extraction has no taxonomy for routing degraded documents.
- **Acceptance:** DOC25 V2.0 emits IngestionQualityReport with 4-value quality_class enum; DOC73 routing rules per §15.4 consume.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D25-NEW-V15-03:** V1.5 OPTIONAL prompt_injection_risk_flags field | DOC25 V2.0 may add OPTIONAL `security_report.prompt_injection_risk_flags` field per V1.5.1 §5A.7.A two-layer prompt-injection model. If absent, DOC73 adapter defaults `doc25_prompt_injection_risk_flags=[]` ONLY when DOC25 contract version lacks the field; otherwise fail per §5A.7.B mapping table. | `[OPTIONAL]` |
- **Source:** DOC73 V1.5.1 §5A.7.A + §24.5.3
- **Why:** Two-layer prompt-injection model has DOC25 source-level layer + DOC73 profile-specific layer. DOC25 layer is OPTIONAL — if DOC25 doesn't surface prompt injection risk, DOC73's §15.X scanner runs alone.
- **Acceptance:** OPTIONAL — if DOC25 V2.x adds the field, V1.5.1 adapter consumes; if not, V1.5.1 §5A.7.B mapping table applies the documented default.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D25-NEW-V15-04:** Hard-fail reason code cooperation | DOC25 V2.0 cooperates with DOC73's hard-fail reason code taxonomy per V1.5.1 §15.5.Y. DOC25 emits codes from a shared enum (e.g., `conversion_timeout`, `ocr_failed`, `unsupported_format`); DOC73 §15.5.Y owns the canonical enum. | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §15.5.Y + §24.5.3
- **Why:** Without cooperation, DOC25 emits free-form failure reasons; DOC73 cannot route systematic failure patterns to BDSM signal.
- **Acceptance:** DOC25 V2.0+ adopts shared reason code enum; emitted codes drawn from V1.5.1 §15.5.Y canonical list.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D25-NEW-V15-05:** Tool capacity lease integration | DOC25 V2.0 cooperates with EC Core capacity lease lifecycle per V1.5.1 §15.5.Z + INV-15.6 mechanism #3. Tools held via lease; lease times out if tool stops responding. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §15.5.Z + §15.6 + §24.5.3
- **Why:** Without lease lifecycle, dead-tool jobs wait forever; queued jobs never resume after tool recovers.
- **Acceptance:** DOC25 V2.0+ wraps tool dispatches in capacity lease; tool death moves job to `retryable_tool_failure` per V1.5.1 §15.6.3.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-CAPACITY-LEASE-01 (EC capacity lease infrastructure — see §6.22 EC Core)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D25-NEW-V15-06:** Strict ingestion state machine compatibility | DOC25 V2.0 ingestion state machine compatible with DOC73's 4-split machines per V1.5.1 §15.5.X (SourceInstanceState / ConversionArtifactState / CorpusMembershipExtractionState / MemoryWriteState). | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §15.5.X + INV-15.5 + §24.5.3
- **Why:** V1.4 single-machine framing is replaced by V1.5 four-machine split; DOC25 must align so ingestion-side states correspond to V1.5.1 SourceInstanceState + ConversionArtifactState.
- **Acceptance:** DOC25 V2.0+ state machine maps to V1.5.1 SourceInstanceState (4 states) + ConversionArtifactState (4 states); DOC73 owns CorpusMembershipExtractionState and MemoryWriteState.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 11 — §6.20 DOC72 update (2 new rows)
### APPEND TO §6.20 DOC72 — Hyper Intelligence Overlay (after OBL-D72-NEW-05):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-D72-NEW-PBE-CLUSTER-01:** PBEClusterDetectionResult schema as superset of PBEClusterDetectionResultMinimum, OR DOC73-side adapter | DOC72 R5.73+ exposes cluster API result schema as a superset of V1.5.1 §4.1A.2A `PBEClusterDetectionResultMinimum`, OR DOC73 publishes adapter mapping table per §0E.2. Tracked in both paths. Plus normative hub_penalty form `weighted_degree_median_normalized` per V1.5.1 §28A.4 with EPSILON guards; plus `inertia_factor=1.2` per PBE_CLUSTER_DEFAULTS. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §4.1A.2A + §28A.4 + §24.5.1
- **Why:** Without contract, cluster API and DOC73 surfacing policy diverge silently; hub_penalty arithmetic ambiguity (V6 audit item) unresolved.
- **Acceptance:** DOC72 R6+ either exposes the full schema as superset (DOC73 consumes directly per §4.1A.2A) OR confirms DOC73 publishes adapter mapping table per §0E.2; hub_penalty form documented; inertia_factor 1.2 documented.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC72 R5.73
- **Depends on:** —
- **Blocks:** OBL-D7-NEW-V15-06 (Suggested Corpora UI)
- **Created:** 2026-04-29 (V3.7)
- **Notes:** Decision point — Will to confirm whether DOC72 R6+ exposes superset directly or DOC73 ships adapter. Adapter is faster path; superset is cleaner long-term.
| **OBL-D72-NEW-NOVELTY-01:** Contextual novelty asymptote | DOC72 R5.73+ §42A novelty signal asymptotes (saturation curve) when cluster reaches a stability plateau, preventing runaway novelty boost as the same content re-surfaces in a stable cluster. Per V1.5.1 §6.7B routing + cluster stability protocol. | `[REQ] [MISSING]` |
- **Source:** DOC73 V6 Adjudication Card item 23; DOC73 V1.5.1 §4.1A.3 cluster stability protocol
- **Why:** Without asymptote, novelty score grows unbounded inside stable clusters as same-content variants re-arrive; routing verdicts skewed toward novelty when content is genuinely repetitive.
- **Acceptance:** DOC72 R6+ §42A novelty signal: when cluster stability_status="stable" and content within cluster's existing topology, novelty score saturates at threshold τ (default 0.4); CI test verifies asymptote.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC72 R5.73
- **Depends on:** OBL-D72-NEW-PBE-CLUSTER-01 (cluster stability state availability)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D72-NEW-V15-01:** §42A subscribable contradiction-write notifications | DOC72 R5.73+ §42A emits subscribable contradiction-write notifications on entity contradiction detection, consumed by V1.5.1 living-memory re-examination engine per §23.1A primitive contract (formerly GIE Appendix A obligation, now §42A). | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §23.1A + §24.5.1
- **Why:** Living memory re-examination is event-driven from contradiction-write events; without notifications, re-examination is polling-based with high latency.
- **Acceptance:** DOC72 R5.73+ §42A publishes contradiction event stream; subscribers register via standard pub-sub.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); DOC72 R5.73
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D72-NEW-V15-02:** §34A implication detection primitive | DOC72 R5.73+ §34A exposes implication-detection primitive: `(node_ref, change_kind) → [affected_node_refs]` per V1.5.1 §23.1A (formerly KIE R2 obligation, now §34A). | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §23.1A + §24.5.1
- **Why:** PBE bidirectional adaptation §5.3 needs implication detection to scope frontier of affected nodes; without primitive, scope is over-expansive (cascade to whole graph).
- **Acceptance:** DOC72 R5.73+ §34A publishes implication-detection primitive with input/output contract.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D72-NEW-V15-03:** §34A outcome chain traversal primitive | DOC72 R5.73+ §34A exposes outcome chain traversal primitive: `(outcome_chain_node) → [dependent_nodes]` per V1.5.1 §23.1A (formerly KIE R2 obligation, now §34A). | `[REQ] [PARTIAL]` |
- **Source:** DOC73 V1.5.1 §23.1A + §24.5.1
- **Why:** Outcome chain traversal supports cascade preview (per §3.2A.5 retraction cascade) and adaptation scope determination.
- **Acceptance:** DOC72 R5.73+ §34A publishes outcome chain traversal with input/output contract.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-D72-NEW-V15-04:** DomainSignalProfile pluggability — preserve securities_litigation profile | DOC72 R5.73+ §34A retains securities_litigation DomainSignalProfile per V1.5.1 §24.5.1 (KIE-absorbed contract). | `[REQ] [EXISTS — verify R5.73]` |
- **Source:** DOC73 V1.5.1 §24.5.1; user memories confirm securities_litigation profile is operative
- **Why:** Securities litigation is the architect's primary corpus type; DomainSignalProfile shape MUST remain pluggable post-KIE-absorption.
- **Acceptance:** Verify DOC72 R5.73 §34A has DomainSignalProfile pluggable; verify securities_litigation profile is operative.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **Notes:** Likely already EXISTS in DOC72 R5.73 (KIE absorption included it); verification step only.
```
---
## EDIT 12 — §6.21 DOC73 — UPDATE existing 3 rows + ADD 11 new bundle rows
### REPLACE the entire body of §6.21 DOC73 — Positronic Brain Enhancement (V1.4.1+) with:
```markdown
### §6.21 DOC73 — Positronic Brain Enhancement (V1.5.1+)
**Calibration update (V3.7):** DOC73 V1.5.1 FINAL is the operative spec as of 2026-04-29. The three V3.1-era OBL-D73-NEW-* rows below are status-updated to `[REQ] [EXISTS]` reflecting V1.5.1 implementation. Calibration anchor advanced from V1.4.1 → V1.5.1.
**EXISTING ROWS (V3.1, status updated in V3.7):**
| **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] [EXISTS — V1.5.1 §3.2A.1B]` |
- **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.1 §3.2A.1B implements `authority_of_snapshot(node)` with discriminated union covering CU / AuthorityAnchor / VersionedClaim / static_fact branches; AuthorityAnchor branch returns anchor_confidence_floor without falling through to Beta.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29) [advanced from V1.4.1]
- **Depends on:** OBL-D72-NEW-02 (AuthorityAnchor trait)
- **Blocks:** —
- **Created:** 2026-04-26
- **V3.7 update:** Status changed from `[REQ] [MISSING]` to `[REQ] [EXISTS — V1.5.1 §3.2A.1B]`. Implementation verified in V1.5.1 §3.2A.1B `authority_of_snapshot()` discriminated union.
| **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] [EXISTS — V1.5.1 §3.3 + §3.2A.1B]` |
- **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.1 §3.3 carve-out classification (carve_out_class enum: static_fact / authority_fixed / evolving) + §3.2A.1B AuthorityAnchor anchor floor preservation; lowest-watermark explicitly excludes anchored claims; carve_out_class=`authority_fixed` claims are not subject to drag-down.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29) [advanced from V1.4.1]
- **Depends on:** OBL-D72-NEW-02; OBL-D73-NEW-01
- **Blocks:** —
- **Created:** 2026-04-26
- **V3.7 update:** Status changed from `[REQ] [MISSING]` to `[REQ] [EXISTS — V1.5.1 §3.3 + §3.2A.1B]`. Implementation verified in V1.5.1 §3.3 carve_out_class enum + §3.2A.1B authority resolution.
| **OBL-D73-NEW-03:** Structured memory operations align with living memory | DOC73 living-memory operations explicitly reference structured operations from DOC24 R3 §13.5 (create / merge / narrow_scope / split / supersede / mark_contested / field_lock / field_adapt) | `[REQ] [PARTIAL — V1.5.1 §15.5 advances; full DOC24 R3 §13.5 cross-ref pending]` |
- **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.1 §15.5.X 4-split state machines + §14.7.X.A 4-outcome mutation protocol (TOUCH_ONLY / IN_PLACE_VERSION_APPEND / SUPERSEDE_WITH_NEW_NODE / RETRACT_WITH_AUDIT) implements the operation set substantively. Outstanding: explicit cross-reference table to DOC24 R3 §13.5 verbs in DOC73 V1.5.1+ to make alignment explicit.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29) [advanced from V1.4.1]
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-26
- **V3.7 update:** Status remains `[REQ] [PARTIAL]` — V1.5.1 implements the operations substantively (per §15.5.X + §14.7.X.A), but explicit cross-reference table to DOC24 R3 §13.5 verb names is still pending. Recommend addressing in DOC73 V1.5.2 or DOC24 R4 alignment pass.
---
**NEW BUNDLE ROWS (V3.7, from DOC73 V1.5.1 §24.5.14 obligation summary — 11 bundles):**
V1.5.1 introduces 11 OBL-D73-NEW-* obligation bundles. Each bundle covers multiple DOC73 V1.5.1 sections and represents a coordinated landing area. Bundle rows below.
| **OBL-D73-NEW-04:** Cross-cutting preamble + receipt schema bundle | V1.5.1 §0A Implementation Discipline Preamble + §0B PBEOperationReceiptLite schema + §0C Current Dependency Calibration Table + §0D Terminology + §0E Cross-Spec Field Path Discipline. Establishes spec-wide implementation discipline, receipt envelope schema for V1.6 transaction kernel prep, dependency calibration baseline, terminology table (corpus/library), and adapter discipline rules. | `[REQ] [EXISTS — V1.5.1 §0A-§0E]` |
- **Source:** DOC73 V1.5.1 §0A + §0B + §0C + §0D + §0E + §24.5.14 bundle ID OBL-D73-NEW-01
- **Why:** Without preamble + receipt schema, coding agents lack spec-wide discipline framework; receipt wrapping is non-uniform; terminology drifts.
- **Acceptance:** V1.5.1 ships all five sections (§0A-§0E); INV-0B.1 + INV-0B.2 enforced; lint rule for terminology rendering; adapter discipline mapping tables required at every adapter boundary.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** All other DOC73 V1.5.1 sections (preamble is foundational)
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §0A, §0B, §0C, §0D, §0E
| **OBL-D73-NEW-05:** Authority + carve-outs bundle | V1.5.1 §3.2A CU authority aggregation algorithm (authority_of_snapshot discriminated union, version-aware recursion, scope-dependent narrowing, frontier-cap with requeue, RecomputeCoordinator with frontier_root_continuation, UserAuthorityOverride with applies_to_version_ref) + §2 P5/P9 principles + §3.3 carve-out classification (carve_out_class: static_fact / authority_fixed / evolving) + §3.3D logical episodic/semantic tier separation + §3.3F authored persistence + §3.3G Beta skeptical prior + §3.3.X audit log integrity hash chain. | `[REQ] [EXISTS — V1.5.1 §3.2A + §3.3 family]` |
- **Source:** DOC73 V1.5.1 §3.2A + §3.3 + §24.5.14 bundle ID OBL-D73-NEW-02
- **Why:** Authority aggregation + carve-out classification are paired-risk concentration per V1.5.1 §24.3 sequencing; without unified bundle, implementation order is unclear.
- **Acceptance:** V1.5.1 §3.2A.1A through §3.2A.1I full algorithm; §3.3 carve-out enum + §3.3D tier assignment + §3.3F-G-X invariants. INV-3.2A.* family + INV-3.3F.1/.2/.3 + INV-3.3G.1 + INV-3.6 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D72-NEW-02 (AuthorityAnchor trait); OBL-D72-NEW-01 (AuthoritySourceClass schema)
- **Blocks:** OBL-D73-NEW-08 (extraction pipeline depends on authority resolution)
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §3.2A.1, §2 P5/P9, §15.6.1, §3.3, §3.3G
| **OBL-D73-NEW-06:** Privacy + retrieval bundle | V1.5.1 §11 privacy/visibility/governance with `make_visibility_decision()` constructor + 4-dimension firewall completeness (retrieval / cross-corpus identity / learning signal / metadata) + sealed-mode hard-deny + §8 retrieval algebra with RRF over candidate union + multiplicative scope boost + tombstone filter on vector lane + auth-aware retrieval score with review_required flag merged in. | `[REQ] [EXISTS — V1.5.1 §11 + §8]` |
- **Source:** DOC73 V1.5.1 §11.X + §8.X + §24.5.14 bundle ID OBL-D73-NEW-03
- **Why:** Privacy completeness is 4-dimensional simultaneous commitment; without unified bundle, dimensions enforced incompletely. Retrieval needs RRF + scope boost + tombstone filter as cohesive surface.
- **Acceptance:** V1.5.1 §11.X.1A `make_visibility_decision()` constructor + §11.X.2-§11.X.5 firewall dimensions; §8.X.4 RRF + §8.X.5 scope boost + §8.X.6/.7 tombstone filter. INV-11.X.1.1 + INV-11.X.2A.1 + INV-11.6 + INV-8.X.5/.6/.7 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §8.X, §11.X
| **OBL-D73-NEW-07:** Self-improvement bundle | V1.5.1 §6D self-improvement engine with §6D.4A pattern classifier mandatory feature inputs (verifier_verdict, carve_out_class) + §6D.10 LearningVisibilityScope partitioning + §6D.11 AVAPO test-fixture scope rules (sealed=NOT generated; firewalled=same_firewall_only) + §6D.12 ReviewAttributionDecision + §6D.13 SchemaMigrationPlan emission requirement. | `[REQ] [EXISTS — V1.5.1 §6D family]` |
- **Source:** DOC73 V1.5.1 §6D.4A + §6D.10 + §6D.11 + §6D.12 + §6D.13 + §24.5.14 bundle ID OBL-D73-NEW-04
- **Why:** Self-improvement engine requires verifier-feature gating + privacy partitioning + attribution + schema migration discipline as cohesive bundle. Privacy laundering through self-improvement is highest-priority privacy boundary in V1.5.
- **Acceptance:** V1.5.1 §6D.4A through §6D.13 implemented; INV-6D.10.1/.2 + INV-6D.11.1 + INV-6D.13.1/.2 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D73-NEW-06 (privacy infrastructure required for partitioning)
- **Blocks:** OBL-PROPA-NEW-V15-* (PropA consumes self-improvement signals)
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §6D.4A, §6D.10, §6D.11, §6D.12, §6D.13
| **OBL-D73-NEW-04D:** Mathematical reference appendix | V1.5.1 §28A Mathematical Reference Appendix providing executable math for §3.3G Beta distribution mechanics, §28A.2 RRF formula (k=60), §28A.4 hub_penalty formula (weighted_degree_median_normalized with EPSILON guards), §28A.7 stability and hysteresis patterns. | `[REQ] [EXISTS — V1.5.1 §28A]` |
- **Source:** DOC73 V1.5.1 §28A + §24.5.14 bundle ID OBL-D73-NEW-04D
- **Why:** Without normative math, formulas are paraphrased into prose and coding agents drift on critical numerics (RRF k value, hub_penalty form, EPSILON values).
- **Acceptance:** V1.5.1 §28A all 7 subsections; cross-referenced from §3.3G, §8.X.4, §4.1A.2, §17.2.C, §15.6.2A, §4.1A.3.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §28A
- **Notes:** Bundle ID matches V1.5.1 §24.5.14 nomenclature (OBL-D73-NEW-04D; appendix-suffix to NEW-04 self-improvement bundle).
| **OBL-D73-NEW-08:** Operational layer bundle | V1.5.1 §15 operational layer with §15.5.X 4-split state machines + §15.5.Y reason codes + §15.5.Z capacity lease lifecycle + §15.6.X versioned artifact reference-counting GC + §15.6.Y FailureOfFailureReceipt + §15.6.2A memory pressure measurement + §14.7.X-Z re-extraction directive flow with rollback preflight + §15.7.7-9 specialist sub-agent pattern with sole-writer + read-only invariants. | `[REQ] [EXISTS — V1.5.1 §15 + §14.7]` |
- **Source:** DOC73 V1.5.1 §15.5/§15.6/§14.7/§15.7 + §24.5.14 bundle ID OBL-D73-NEW-06
- **Why:** Operational layer is the load-bearing ingest+extract+commit machinery; without unified bundle, state machines + capacity discipline + specialist boundaries land piecemeal.
- **Acceptance:** V1.5.1 §15.5.X-Z + §15.6.X-Y + §15.6.2A + §14.7.X-Z + §15.7.7-9 all implemented. INV-15.3.X + INV-15.5 + INV-15.6 + INV-15.6.2A.1 + INV-15.6.X + INV-15.6.X.1 + INV-15.7.3A.1 + INV-15.7.8 + INV-15.7.8.1 + INV-15.7.9 + INV-14.7.* family enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-PBE-RECEIPT-01; OBL-EC-NEW-SESSION-CONTEXT-01; OBL-EC-NEW-BLOB-01; OBL-EC-NEW-CAPACITY-LEASE-01
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §15.5.X, §15.5.Y, §15.5.Z, §15.6.X, §15.6.Y, §14.7.X-Z, §15.7.7-9
| **OBL-D73-NEW-09:** PBE-lite + recovery bundle | V1.5.1 §12.6 PBE-lite degraded fallback mode with state machine (§12.6.X) + deferred replay queue (§12.6.Y) + banner format (§12.6.Z). Health checks for 5 load-bearing contracts + auto-recovery on contract restore. | `[REQ] [EXISTS — V1.5.1 §12.6]` |
- **Source:** DOC73 V1.5.1 §12.6 + §24.5.14 bundle ID OBL-D73-NEW-07
- **Why:** PBE-lite is the resilience mechanism; without unified state machine + replay + banner, partial implementation produces silent failure modes.
- **Acceptance:** V1.5.1 §12.6.X-Z all implemented; INV-12.6.X.1/.2 + INV-12.6.Y.1/.2/.3 + INV-12.6.Z.1/.2/.3/.4 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-EC-NEW-PBE-RECEIPT-01
- **Blocks:** OBL-D7-NEW-V15-08 (PBE-lite banner UI); OBL-D20-NEW-V15-02 (workspace banner)
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §12.6.X, §12.6.Y, §12.6.Z
| **OBL-D73-NEW-10:** Extraction + DOC25 adapter bundle | V1.5.1 §5A four-layer LLM intelligence architecture with per-layer contracts (§5A.5-§5A.9) + §5A.7 IngestionToExtractionContext adapter with build_chunk_inputs helper + §5A.7.A two-layer prompt-injection model + §5A.7.B mapping table + §5A.7.C validation function + §5A.8 CostBudgetLedger + §15.X AdversarialIngestionGuard + §14.7.X-Z re-extraction + §6.5.0 budget consumer + §10.4A depth degradation + §14.7.3A/B EstimatorConfidence gating + §6D.13 SchemaMigrationPlan. | `[REQ] [EXISTS — V1.5.1 §5A + §15.X + §14.7]` |
- **Source:** DOC73 V1.5.1 §5A + §15.X + §14.7 + §6.5.0 + §10.4A + §6D.13 + §24.5.14 bundle ID OBL-D73-NEW-08
- **Why:** Extraction pipeline is the primary value-producing path; cohesive bundle ensures adapter contracts + cost discipline + adversarial guard + depth degradation policy land together.
- **Acceptance:** V1.5.1 §5A through §5A.9 + §15.X + §14.7.X-Z + §6.5.0 + §10.4A + §14.7.3A/B all implemented; INV-5A.1 + INV-5A.5.1/.2 + INV-5A.6.1 + INV-5A.7.B.1 + INV-5A.7.C.1 + INV-5A.8.1/.2 + INV-15.X.1/.2 + INV-10.2A.1/.2 + INV-10.4A.1/.2 + INV-14.7.* enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D25-NEW-V15-01 through -06; OBL-D73-NEW-05; OBL-D73-NEW-07
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §5A.5-§5A.9, §15.X, §14.7.X, §6.5.0, §10.4A, §14.7.3A/B, §6D.13
| **OBL-D73-NEW-11:** Retrieval + ranking + verifier bundle | V1.5.1 §8 retrieval and activation with §8.X retrieval algebra + §8.X.5 multiplicative scope boost + §8.X.6 vector lane tombstone filter + §8.X.7 vector tombstone GC + §6.7C VerifierCalibrationLedger with 5-state calibration_status enum. | `[REQ] [EXISTS — V1.5.1 §8 + §6.7C]` |
- **Source:** DOC73 V1.5.1 §8.X + §6.7C + §24.5.14 bundle ID OBL-D73-NEW-09
- **Why:** Retrieval algebra + verifier calibration are paired — verifier signals gate auto-promotion in retrieval ranking; without unified bundle, ranking and verification land out of sync.
- **Acceptance:** V1.5.1 §8.X.4/.5/.6/.7 + §6.7C all implemented; INV-8.X.5/.6/.7 + INV-6.7C.1/.2 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D18-NEW-V15-01 (vector lane tombstone filter producer-side)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §8.X, §8.X.5, §8.X.6/7, §6.7C
| **OBL-D73-NEW-12:** UI / onboarding / corpus UX bundle | V1.5.1 §6A.1/§6A.3 extraction quality mechanisms surfacing + §13A onboarding flow (Q1-Q10 base + conditional probes Q9.1-9.3 + Q2.5 privileged-categories + Q3.5 volume + OnboardingSignalState) + §13 UI surfaces (DOC7 9-tab structure + DOC20 surface) + §0D library naming + §6B.7 success metrics surfacing + §10.2A AccessPath verification UX. | `[REQ] [EXISTS — V1.5.1 §13 + §13A + §10.2A]` |
- **Source:** DOC73 V1.5.1 §13 + §13A + §0D + §10.2A + §24.5.14 bundle ID OBL-D73-NEW-10
- **Why:** UI/UX bundle is user-facing surface for everything else; without coordinated landing, individual UX elements land but feel inconsistent.
- **Acceptance:** V1.5.1 §13.X UI surfaces + §13A.1-§13A.9 onboarding + §10.2A AccessPath UX all implemented; INV-13.6 + INV-13.X.1 + INV-13A.7.1 enforced.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-01 through -09; OBL-D7-NEW-LIBRARY-NAMING-01; OBL-D20-NEW-V15-01 through -04; OBL-D24-NEW-V15-03 (conditional probes)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §6A.1, §6A.3, §13A.X, §13.X, §0D, §6B.7, §10.2A
- **Notes:** Bundle ID is OBL-D73-NEW-12 in OP-A V3.7 numbering, but corresponds to V1.5.1 §24.5.14 bundle "OBL-D73-NEW-10" (V1.5.1 internal numbering). DOC73 V1.5.1 internal bundle 10 maps to OP-A row 12 because OP-A preserves NEW-01/02/03 numbering from V3.1.
| **OBL-D73-NEW-13:** GIE/KIE absorption (post-OP-A V3.6) bundle | V1.5.1 §23.1A reframe: GIE V2.2 absorbed into DOC72 R5.73 §42A; KIE R2 absorbed into DOC72 R5.73 §34A per OP-A V3.6 baseline. DOC73 V1.5.1 cross-references the absorbed sections (no longer references GIE/KIE as standalone). | `[REQ] [EXISTS — V1.5.1 §23.1A]` |
- **Source:** DOC73 V1.5.1 §23.1A + §24.5.14 bundle ID OBL-D73-NEW-11
- **Why:** Without explicit reframe, V1.5.1 might still reference GIE/KIE as standalone; OP-A V3.6 calibration requires references go to §42A / §34A (DOC72-absorbed).
- **Acceptance:** V1.5.1 §23.1A explicitly notes GIE/KIE absorption; all V1.5.1 cross-references use DOC72 §42A / §34A naming.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); OP-A V3.6 baseline (2026-04-27)
- **Depends on:** OBL-EC-NEW-MIGR-01 (conditional GIE/KIE label remapping if implementation data exists with stale labels)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
- **V1.5.1 sections:** §23.1A
- **Notes:** Bundle ID is OBL-D73-NEW-13 in OP-A V3.7; corresponds to V1.5.1 §24.5.14 bundle "OBL-D73-NEW-11."
```
---
## EDIT 13 — §6.22 EC Core update (4 new rows)
### APPEND TO §6.22 EC Core / DocIndex (after the last existing OBL-EC-* row, before the closing `---`):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-EC-NEW-PBE-RECEIPT-01:** PrimaryPBEOrchestrator with PBEOperationReceiptLite wrapping | EC Core PrimaryPBEOrchestrator (or equivalent EC writer worker) accepts `WriteIntent` events with `section_ref` identifying DOC73 spec section, `operation_kind` from V1.5.1 §0B `PBEOperationReceiptLite` enum, idempotency keys, and PBEOperationReceiptLite wrapping per V1.5.1 INV-0B.1. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §0B + §15.7.8 + §24.5.4 + INV-0B.1
- **Why:** Sole-writer invariant (INV-15.7.8) requires PrimaryPBEOrchestrator to accept WriteIntent events from specialists; receipt wrapping (INV-0B.1) requires every persistent operation to carry PBEOperationReceiptLite envelope. V1.6 transaction kernel prep depends on this.
- **Acceptance:** EC Core Addendum A V3.5+ adds PrimaryPBEOrchestrator section; WriteIntent schema published; PBEOperationReceiptLite envelope wrapping enforced; idempotency key handling specified.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); EC Core Addendum A V3.4
- **Depends on:** —
- **Blocks:** OBL-D73-NEW-08 (operational layer bundle); OBL-D73-NEW-09 (PBE-lite); OBL-D7-NEW-V15-09 (PBEUICommandMatrixRow); OBL-D7-NEW-V15-08 (PBE-lite banner); OBL-D20-NEW-V15-02 (workspace banner)
- **Created:** 2026-04-29 (V3.7)
| **OBL-EC-NEW-SESSION-CONTEXT-01:** Ephemeral session_context store | EC Core publishes ephemeral session_context store for specialist intermediate synthesis per V1.5.1 §15.7.9. Store is per-session, TTL-bound (default = session lifetime + 1 hour); MemoryAgent + DocumentIntelligenceAgent write intermediate work here, never the durable graph. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §15.7.9 + §24.5.4 + INV-15.7.9
- **Why:** Specialist read-only invariant (INV-15.7.9) requires ephemeral synthesis target distinct from durable graph; without session_context store, specialists would either (a) write durable (breaks INV-15.7.9), (b) lose intermediate work (breaks composition).
- **Acceptance:** EC Core Addendum A V3.5+ specifies session_context store schema, TTL discipline, key namespace; specialists write intermediate via store API.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** OBL-EC-AGT-07 (memory_agent — already exists in V3.5/V3.6) detailed implementation; OBL-EC-AGT-08 (document_intelligence_agent — already exists) detailed implementation
- **Created:** 2026-04-29 (V3.7)
| **OBL-EC-NEW-BLOB-01:** Content-addressable blob store for versioned artifacts | EC Core publishes content-addressable blob store for versioned artifacts per V1.5.1 §15.4.3A (ExtractionSpec versions retention) + §15.6.X (versioned ingestion artifact reference-counting GC). Schema: artifact_id, content_hash, reference_count, references_from[]. GC after grace window (7 days default). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §15.4.3A + §15.6.X + §24.5.4 + INV-15.4.3A.1/.2 + INV-15.6.X.1
- **Why:** Reference-counting GC requires durable blob store with refcount discipline; without it, versioned artifacts grow unbounded or are deleted while live references exist.
- **Acceptance:** EC Core Addendum A V3.5+ specifies blob store schema; reference-counting CI lint enforces no-physical-deletion-while-live-references; nightly GC job removes after grace window.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** OBL-D73-NEW-08 (operational layer bundle requires blob store for versioned artifacts)
- **Created:** 2026-04-29 (V3.7)
| **OBL-EC-NEW-MIGR-01:** Conditional GIE/KIE label remapping during migration | If existing runtime receipts, graph rows, or audit artifacts contain owner labels `GIE` or `KIE`, EC Core remaps labels to DOC72 R5.73 subarchitecture refs (§42A for former GIE; §34A for former KIE) during V1.4→V1.5 migration per V1.5.1 §27.8. **Conditional:** No obligation if no implemented data exists with stale labels. | `[REQ] [CONDITIONAL]` |
- **Source:** DOC73 V1.5.1 §27.8 + §24.5.4
- **Why:** OP-A V3.6 absorbed GIE V2.2 → DOC72 §42A and KIE R2 → DOC72 §34A; if implementation data exists with stale GIE/KIE labels, remapping is required for consistency.
- **Acceptance:** Conditional. If audit reveals labels exist, EC Core migration job remaps; if not, obligation is moot. V1.5.1 §27.8 specifies the conditional scope.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** OBL-D73-NEW-13 (GIE/KIE absorption reframe relies on label consistency)
- **Created:** 2026-04-29 (V3.7)
- **Notes:** **CONDITIONAL OBLIGATION.** Architect to determine whether implementation data with stale labels exists; if not, obligation is moot. If yes, scope of remap depends on data volume.
| **OBL-EC-NEW-CAPACITY-LEASE-01:** Capacity lease lifecycle infrastructure | EC Core publishes capacity lease lifecycle infrastructure per V1.5.1 §15.5.Z. Schema: CapacityLease with `LEASE_RENEWAL_HEARTBEAT` state. Lease times out if tool stops responding; lease invalidation on tool death moves jobs to `retryable_tool_failure` state. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §15.5.Z + §15.6.3 + §24.5.4
- **Why:** Tool capacity lease (per INV-15.6 mechanism #3) is one of the 6 independently-enforced resource control mechanisms; without lease lifecycle, dead-tool jobs hang.
- **Acceptance:** EC Core Addendum A V3.5+ specifies CapacityLease schema, heartbeat protocol, timeout discipline, recovery semantics.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** OBL-D25-NEW-V15-05 (DOC25 capacity lease integration); OBL-D73-NEW-08 (operational layer)
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 14 — §6.23 BDSM update (5 new rows)
### APPEND TO §6.23 BDSM — Behavioral Dynamics & Salience Matrix (after OBL-BDSM-NEW-05):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-BDSM-NEW-V15-01:** Privacy-partitioned utility ledgers | BDSM V7+ partitions utility ledgers by `LearningVisibilityScope` per V1.5.1 §6D.10 + §23.8 INV-23.8. Ledgers MUST partition by scope: sealed-source signals silently discarded with audit-only `learning_signal_dropped` receipt per INV-6D.10.2 + V1.5 `none_v1_5` semantic; firewalled-source signals aggregate ONLY into `same_firewall_only`-scoped ledgers. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6D.10 + §23.8 + INV-23.8 + §24.5.7
- **Why:** Privacy laundering through self-improvement is highest-priority privacy boundary in V1.5; without ledger partitioning, sealed/firewalled corpora signals leak into global learning.
- **Acceptance:** BDSM V7+ utility ledger schema includes `LearningVisibilityScope` partition key; aggregation queries filter by scope; sealed-source signals never aggregate; CI test verifies sealed-source isolation.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); BDSM V6.4
- **Depends on:** —
- **Blocks:** OBL-PROPA-NEW-V15-* (PropA consumes BDSM signals; partitioning must hold throughout pipeline)
- **Created:** 2026-04-29 (V3.7)
| **OBL-BDSM-NEW-V15-02:** AVAPO C1-C5 signal dimensions | BDSM V7+ tracks AVAPO C1-C5 signal dimensions per V1.5.1 §6D.8: schema-aware fixture diff (C1), exposure-normalized rejection (C2), synthetic gold provenance (C3), counterfactual integration (C4), tier classification (C5). Each signal dimension independently invariant per INV-6D.8. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6D.8 + INV-6D.8 + §24.5.7
- **Why:** AVAPO 5 sub-mechanisms are independently invariant; BDSM signal aggregation must track all 5 distinctly.
- **Acceptance:** BDSM V7+ adds 5 signal dimensions for C1-C5; aggregation does not collapse across sub-mechanisms.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-BDSM-NEW-V15-03:** cluster_thrash_rate signal (NEW V1.5) | BDSM V7+ adds `cluster_thrash_rate` signal for V1.5.1 §4.1A.2 PropA iteration of `inertia_factor` and `resolution`. When clusters thrash (frequent reconfigurations), signal feeds PropA to iterate cluster-detection parameters. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §4.1A.2 + §24.5.7
- **Why:** Cluster thrash without iteration produces unstable Suggested Corpora; PropA needs signal to iterate cluster_detection parameters.
- **Acceptance:** BDSM V7+ adds cluster_thrash_rate signal; emitted on every cluster reconfiguration; consumed by PropA per OBL-PROPA-NEW-V15-* family.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D72-NEW-PBE-CLUSTER-01 (cluster API)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-BDSM-NEW-V15-04:** Critique-utility signal (V1.5) | BDSM V7+ adds critique-utility signal per V1.5.1 §5A.4-conditional. When post-retrieval critique runs, signal tracks whether critique caught a quality issue (true positive) vs. flagged false issue (false positive) vs. missed issue (false negative). Iterates §5A.4 critique prompt via PropA. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §5A.4 + §24.5.7
- **Why:** Without critique-utility signal, post-retrieval critique runs blind — no learning signal to iterate prompt.
- **Acceptance:** BDSM V7+ adds critique-utility signal; tracks 3-class verdict; PropA consumes per OBL-PROPA-NEW-V15-* family.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-BDSM-NEW-V15-05:** Cross-firewall identity attempts signal | BDSM V7+ adds cross-firewall identity attempts signal per V1.5.1 §11.6 firewall completeness. When entity bridging is attempted across firewall boundaries, signal records the attempt (regardless of whether bridge succeeds via explicit user action or is blocked). | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §11.6 + §24.5.7
- **Why:** Firewall completeness invariant (INV-11.6) requires monitoring for boundary-crossing attempts; without signal, breaches go untracked.
- **Acceptance:** BDSM V7+ adds cross-firewall-identity-attempts signal; emitted at every cross-firewall identity bridge attempt (success or block).
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 15 — §6.25 PropA update (6 new rows)
### APPEND TO §6.25 MultiDoc PropA — Property/Authorization Architecture (after OBL-PROPA-NEW-02):
```markdown
**NEW ROWS (V3.7, from DOC73 V1.5.1 fold-in):**
| **OBL-PROPA-NEW-V15-01:** LearningVisibilityScope filtering | PropA R7+ prompt-iteration consumer MUST filter incoming signals by `LearningVisibilityScope` per V1.5.1 §6D.10 + §23.9 INV-23.9. Sealed-source signals silently discarded; firewalled-source signals scoped to same-firewall iteration only. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6D.10 + §23.9 + INV-23.9 + §24.5.8
- **Why:** Privacy partitioning must hold through entire learning pipeline (BDSM → PropA); PropA cannot iterate prompts using signals from sealed corpora.
- **Acceptance:** PropA R7+ consumer filters by scope; CI test verifies sealed-source signals never iterate prompts; firewalled-source signals iterate only same-firewall prompts.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29); PropA R6.3
- **Depends on:** OBL-BDSM-NEW-V15-01 (BDSM ledger partitioning is upstream)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-PROPA-NEW-V15-02:** SchemaMigrationPlan emission for schema-changing iterations | PropA R7+ schema-changing prompt iterations MUST emit `SchemaMigrationPlan` per V1.5.1 §6D.13 + §27.9 INV-27.9. Iterations without plan route to `manual_review_only` deployment per §6D.8 Tier 3. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6D.13 + §27.9 + INV-27.9 + §24.5.8
- **Why:** Schema-changing iterations break downstream consumers without migration plan; manual review safeguards production.
- **Acceptance:** PropA R7+ adds SchemaMigrationPlan emission for schema-changing iterations; deployment gate routes plan-less iterations to manual_review_only.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-PROPA-NEW-V15-03:** Verifier prompt iteration via VerifierCalibrationLedger | PropA R7+ iterates verifier prompts via V1.5.1 §6.7C VerifierCalibrationLedger. Signals from verifiers with `calibration_status ∈ {uncalibrated, drifting, failed}` are EXCLUDED per V1.5.1 INV-19.5. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6.7C + INV-19.5 + §24.5.8
- **Why:** Uncalibrated verifiers cannot drive prompt iteration (per INV-19.5); without ledger gating, drifting verifiers corrupt prompt-iteration signal.
- **Acceptance:** PropA R7+ consumes VerifierCalibrationLedger; filters signals by calibration_status; CI test verifies excluded-status signals never iterate.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-D7-NEW-V15-04 (Verifier Calibration UI surface)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-PROPA-NEW-V15-04:** AVAPO regression fixture exclusion rules | PropA R7+ AVAPO regression fixtures: sealed-source AVAPO fixtures NOT generated in V1.5; firewalled-source fixtures scoped to same-firewall per V1.5.1 §6D.11 + INV-6D.11.1. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6D.11 + INV-6D.11.1 + §24.5.8
- **Why:** Privacy-tainted regression fixtures contaminate gold suite; sealed-source fixtures NEVER generated; firewalled-source fixtures stay in same firewall.
- **Acceptance:** PropA R7+ AVAPO fixture generation skips sealed-source; firewalled-source fixtures tagged with scope; CI test verifies isolation.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-PROPA-NEW-V15-01 (visibility scope filtering required upstream)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-PROPA-NEW-V15-05:** Post-retrieval critique prompt surface | PropA R7+ adds post-retrieval critique prompt surface per V1.5.1 §5A.4-conditional. Critique runs after retrieval to flag quality issues. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §5A.4 + §24.5.8
- **Why:** Without critique prompt, retrieval results have no quality gate downstream of ranking.
- **Acceptance:** PropA R7+ registers post-retrieval critique prompt; signals from BDSM critique-utility (per OBL-BDSM-NEW-V15-04) iterate.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** OBL-BDSM-NEW-V15-04 (critique-utility signal)
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
| **OBL-PROPA-NEW-V15-06:** Counterfactual ambiguity classification + additive synthesis prompts | PropA R7+ adds counterfactual ambiguity classification prompt surface per V1.5.1 §6.7A 5-verdict + ambiguity_flag enums; plus additive synthesis regeneration prompt surface per §6.9.3. | `[REQ] [MISSING]` |
- **Source:** DOC73 V1.5.1 §6.7A + §6.9.3 + §24.5.8
- **Why:** Counterfactual classification is layer-2 verifier routing; without prompt, classification is ad hoc. Additive synthesis is alternative to total regeneration; without prompt, only total regeneration available.
- **Acceptance:** PropA R7+ registers both prompt surfaces; iteration signals from BDSM consume per OBL-BDSM-NEW-V15-* family.
- **Calibrated against:** DOC73 V1.5.1 (2026-04-29)
- **Depends on:** —
- **Blocks:** —
- **Created:** 2026-04-29 (V3.7)
```
---
## EDIT 16 — §9 Open Meta-Architecture Questions update (1 new entry)
### APPEND TO §9 Open Meta-Architecture Questions table (as the last new row):
```markdown
| **RESOLVED (V3.7):** DOC24↔DOC73 V1.5.1 audit complete | This V3.7 fold-in | DOC73 V1.5.1 stabilized as paste-ready spec (11,657 lines, 33 sections, 126 INVs). V6 Adjudication Card audit complete. Two-step audit (1: V1.5 → V1.5.1 audit ledger; 2: V1.5.1 final review pass) executed and clean. ~62 cross-doc obligations folded into OP-A V3.7 across 12 target specs. Earlier §9 question on DOC24↔DOC73 full seam audit ("when?") is RESOLVED — the audit happened across V1.5 (primary spec build) + V1.5.1 (audit-driven hardening). Outstanding: DOC72 R6+ absorption of DOC73 V1.5.1 obligations (see OBL-D72-NEW-PBE-CLUSTER-01, OBL-D72-NEW-NOVELTY-01, OBL-D72-NEW-V15-01 through -04); EC Core Addendum A V3.5 absorption of OBL-EC-NEW-PBE-RECEIPT-01 + OBL-EC-NEW-SESSION-CONTEXT-01 + OBL-EC-NEW-BLOB-01 + OBL-EC-NEW-MIGR-01 + OBL-EC-NEW-CAPACITY-LEASE-01. |
```
---
## EDIT 17 — §10 Maintenance Log update (1 new entry)
### APPEND TO §10 Maintenance Log table (as the last new row at top of table per chronological order):
```markdown
| 2026-04-29 | **V3.7 DOC73 V1.5.1 FINAL fold-in.** DOC73 V1.5.1 FINAL is operative (11,657 lines, 33 sections, 126 INVs; paste-ready). V3.7 folds in ~62 new cross-doc obligation rows across 12 target specs: §6.1 DOC1 (1), §6.5 DOC7 (10 incl OBL-D7-NEW-LIBRARY-NAMING-01), §6.6 DOC8 (1), §6.12 DOC15 (2), §6.14 DOC18 (3 incl OBL-D18-NEW-02 FTS5 tokenizer), §6.15 DOC20 (4), §6.17 DOC23 (2 — first DOC23 obligations), §6.18 DOC24 (4), §6.19 DOC25 (6), §6.20 DOC72 (6 incl OBL-D72-NEW-PBE-CLUSTER-01 + OBL-D72-NEW-NOVELTY-01), §6.22 EC Core (5 incl OBL-EC-NEW-PBE-RECEIPT-01 + OBL-EC-NEW-SESSION-CONTEXT-01 + OBL-EC-NEW-BLOB-01 + OBL-EC-NEW-MIGR-01 + OBL-EC-NEW-CAPACITY-LEASE-01), §6.23 BDSM (5 incl cluster_thrash_rate signal), §6.25 PropA (6). §6.21 DOC73: existing 3 V3.1-era rows (OBL-D73-NEW-01, -02, -03) status-updated to `[REQ] [EXISTS]` against V1.5.1; 11 new bundle rows (OBL-D73-NEW-04 through OBL-D73-NEW-13 plus appendix-suffix OBL-D73-NEW-04D mathematical reference) added per V1.5.1 §24.5.14 obligation summary. §9 Open Meta-Architecture: 1 new entry (DOC24↔DOC73 V1.5.1 audit complete). Note: OBL-EC-AGT-06 (OCM), OBL-EC-AGT-07 (memory_agent), OBL-EC-AGT-08 (document_intelligence_agent) already exist in V3.5/V3.6 — V1.5.1 §24.5.4 references the existing rows, no duplication. Provenance discipline: every V3.7-added row carries `Calibrated against: DOC73 V1.5.1 (2026-04-29)` for grep-based provenance tracking. | Claude Opus 4.7 |
```
---
## EDIT 18 — §11 End of tracker update
### REPLACE the V3.6 self-test items in §11 with:
```markdown
**Self-test for usability (V3.7):**
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 ~153 across all target docs (V3.6's ~91 + V3.7's ~62). Reviewer time budget for absorbing into companion-doc revisions should account for this volume — not all 153 will be absorbed in one revision per companion; expect multiple passes.
13. ✅ V3.7 adds DOC73 V1.5.1 cross-doc fold-in (11 bundle rows in §6.21 DOC73; ~51 additional rows distributed across 11 other target specs). Provenance: every V3.7-added row carries `Calibrated against: DOC73 V1.5.1 (2026-04-29)`.
**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:**
- DOC72 R6+ → V1.5.1 obligations absorption: OBL-D72-NEW-PBE-CLUSTER-01, OBL-D72-NEW-NOVELTY-01, OBL-D72-NEW-V15-01 through -04 land in DOC72 R6+
- EC Core Addendum A V3.5 → V1.5.1 obligations absorption: OBL-EC-NEW-PBE-RECEIPT-01 + OBL-EC-NEW-SESSION-CONTEXT-01 + OBL-EC-NEW-BLOB-01 + OBL-EC-NEW-MIGR-01 + OBL-EC-NEW-CAPACITY-LEASE-01
- DOC25 V2.1+ → V1.5.1 obligations absorption: OBL-D25-NEW-V15-01 through -06 (multi-hash, quality_class enum, OPTIONAL prompt-injection field, hard-fail enum cooperation, capacity lease, state machine compatibility)
- DOC7 R8+ → V1.5.1 corpus page UI: 9-tab structure, Triage / Runs / Settings sub-tabs, library naming UI rendering rule
- DOC73 V1.5.1 → next red team round: when reviewers produce findings against V1.5.1, those become V1.5.2 audit card; obligations surfaced ride V3.8+ increment
- Session 2 (V4): fold in DOC3 Companion R9.2 + DOC14 Cross-Doc R2 + CD-A 4.1.26 (already deferred from V3.x maintenance log)
- Session 3+ (V5+): ongoing fold-ins from §3 "not yet folded in" as new sources confirmed in scope
```
---
## End of patch document
**Summary statistics:**
- **Edits applied:** 18 numbered edits
- **New OBL rows added:** ~62 distributed across §6.1 / §6.5 / §6.6 / §6.12 / §6.14 / §6.15 / §6.17 / §6.18 / §6.19 / §6.20 / §6.21 / §6.22 / §6.23 / §6.25
- **§6.21 DOC73 expanded:** 3 V3.1-era rows status-updated + 11 new bundle rows (OBL-D73-NEW-04 through OBL-D73-NEW-13 plus OBL-D73-NEW-04D math appendix)
- **§9 entries added:** 1 (DOC24↔DOC73 V1.5.1 audit complete)
- **§10 entries added:** 1 (V3.7 maintenance log)
- **§11 self-test items updated:** 13 items (item 12 revised; item 13 added)
- **Front matter version:** V3.6 → V3.7
**Provenance:** Every V3.7-added row carries `Calibrated against: DOC73 V1.5.1 (2026-04-29)` in its calibration anchor field; can be grep'd to enumerate V3.7 additions.
**Verification after merge:** Run grep `Calibrated against: DOC73 V1.5.1 (2026-04-29)` over merged OP-A V3.7 — should return ~62 matches (one per V3.7-added row).