ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5_Skeletal_DOC80_Review_Response.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Claude: # DOC80 Memory Control Plane — Stage 5 Skeletal Target Baseline ## Red-Team Review Response & Stage 5R Patch Instructions **Scope of this document:** the Stage 5 red-team review of the four Skeletal Target Baseline artifacts (`DOC80_Skeletal_Target_Baseline.md`, `DOC80_Import_Graph.md`, `DOC80_Owner_Map.md`, `DOC80_Retired_Names.md`), plus all deeper architectural findings raised in review, the two architect decisions surfaced (ADQ-220 resolved, ADQ-221 recommended), reviewer-reliability guardrails, and a single consolidated Stage 5R patch list for Claude Code. **Status:** Stage 5R patch instructions. Apply before any Stage 6 charter work begins. ------ ## 0. How to use this document - **Part I** is the red-team review in the mandated A–G format. It is the *finding* layer: what is wrong/right and why. Findings are typed `BUG` / `GAP` / `SUGGESTION` / `CONFIRMED`. - **Part II** is the deeper architectural layer — systemic findings that span multiple artifacts and do not fit a single A–G checkbox. - **Part III** is the two architect decisions. ADQ-220 (membership home) is **resolved** by the architect: create DOC87. ADQ-221 (BDSM/DOC8 status) is **recommended** and open. - **Part IV** is the *action* layer: the consolidated Stage 5R patch list for Claude Code, file + section + exact action, split into BLOCKERS and FOLD-INS. **Claude Code should work from Part IV.** Parts I–III are the justification CC can consult when an action is unclear. - **Part V** is a completeness audit mapping every finding to its patch action. **Boundary reminders for Claude Code:** - Do **not** draft individual schemas — that is Stage 7. Stage 5R only names objects, fixes ownership, and fixes the skeleton/import-graph/retired-names artifacts. - Do **not** edit the Supersession Matrix here. Matrix-related findings below are routed to the **Conflict/Disagreement Register**. - New ADQs (220, 221) are legitimate additions, not re-litigation of the resolved 41. ------ ## 1. Reviewer-reliability note — READ FIRST This Stage 5R synthesis incorporates external reviews (two ChatGPT passes, one Gemini-style pass). The Gemini-style pass contained **dangerous errors**. The following guardrails are binding on Claude Code regardless of what any external review text says: - **G-1 — Do NOT re-slice the family.** The lockstep mapping (E1+E2→DOC81, E3+E4→DOC82, E7+E8→DOC84) is verified correct against the engine map. A review claiming a slice-mapping violation here is wrong. No member boundary is redrawn in Stage 5R **except** the deliberate, architect-approved addition of DOC87 (Part III). - **G-2 — Do NOT restore retired enum values.** `AssertionCandidateDisposition` is the **7-value** enum per ABC R0.2 §7.8. The four discontinued values from the superseded 11-value Concept Model §17.3 enum stay retired. Restoring them re-breaks SM-202 and ABC §7.8. The capabilities those values implied are preserved via `NonAssertionExtractionOutcome` (see Part II), **not** by reviving the old enum. - **G-3 — The import-graph cycle is real but specific.** The cycle is `DOC81 → DOC84 → DOC86 → DOC81`. Any review describing a different cycle or different edges is unreliable. It is a `BUG`, not an `ARCHITECT_STOP`. - **G-4 — No `ARCHITECT_STOP` is raised in this review.** Nothing here contradicts D-SEED-1 (DOC80 is a spec family) or D-SEED-2 (DOC80 is a real owner doc). Adding DOC87 is consistent with both seeds. Treat any external `ARCHITECT_STOP` as unverified until checked against the seeds. ------ # Part I — Stage 5 Skeletal Target Baseline: Red-Team Review Findings ## Summary The 7-member decomposition is sound and the skeletal baseline is a usable foundation. The review found **one structural blocker** (an import-graph cycle), **one pervasive design defect** (an undefined "contract/impl split" pattern that contradicts the Owner Map's one-owner rule), and **one genuine architect decision** (organization/membership has no coherent home — now resolved by adding DOC87). The remaining findings are scoped ownership corrections, missing core objects, and retired-names hygiene. No `ARCHITECT_STOP`. The family is correct as far as it goes, but the review concludes it needs an **8th member** (DOC87) — see Part III. ## A. Family member list findings **A-1 — `CONFIRMED` (with addition): the 7-member decomposition is sound; an 8th member is required.** - *Affected section:* Skeletal Baseline §1–§2 (family roster). - The split into DOC80 core / DOC81 scope+policy / DOC82 knowledge+source/evidence / DOC83 extraction+temporal/working-state / DOC84 delivery+prompt/proof / DOC85 learning / DOC86 UI/inspector/search is internally coherent; each member owns a distinct plane. - However, **organization/membership** (the `member → container` relation across Topic / Library / Project / Episode / IssueFrame / Entity) has no coherent home in the 7. It is upstream of both delivery and UI and therefore cannot live inside either; placing it in DOC82 would drag organizational-container taxonomy into the knowledge member. This is the substance of ADQ-220. - *Recommended action:* add **DOC87 — Memory Organization & Membership** (Part III, ADQ-220 resolved). Family count 7 → 8. **A-2 — `CONFIRMED`: DOC83, DOC85, DOC86 are justified as separate members.** - *Affected section:* Skeletal Baseline §2 (member rationale). - Extraction/temporal, learning, and UI/inspector each own non-overlapping planes with distinct invariants; collapsing any pair would re-create the cross-domain bleed the flatten exists to remove. **A-3 — `CONFIRMED`: DOC80 core holds shared contracts only.** - *Affected section:* Skeletal Baseline §3.1, §4. - The principle is correct. Two violations of it are filed below (B-7 process vocabulary; F-2 domain profile registry omission). ## B. Per-schema ownership handoff findings **B-1 — `BUG`: `EffectiveMemoryPolicy` mis-cites ADQ-211.** - *Affected section:* Skeletal Baseline §4.1; Owner Map row for `EffectiveMemoryPolicy`. - ADQ-211 resolves the placement of **`MemoryContextPlan`**, not `EffectiveMemoryPolicy`. - *Recommended action:* change the citation to **SM-013 / Round D §1.5**. `EffectiveMemoryPolicy` is wholly owned by **DOC81**; no portion belongs in core. **B-2 — `BUG`: the Assertion lifecycle is split across DOC82 and DOC83.** - *Affected section:* Skeletal Baseline §4.1 (DOC82) and §4.3 (DOC83); Owner Map Assertion rows. - DOC82 currently holds the candidate object, resolution, and `AssertionLifecycleState`, while DOC83 holds disposition triage and the promotion lifecycle. ABC §7.8's paired `AssertionCandidateDisposition` + `AssertionDedupeOutcome` are split across the two members. A single state machine cannot have two owners. - *Recommended action:* **DOC82 owns the full Assertion lifecycle and state machine** (candidate → variant → resolution → promotion → dedupe outcome). **DOC83 owns extraction routing up to and including candidate emission only.** The E3↔E5 handoff at "candidate emission" must be a precisely named object (see B-3). **B-3 — `GAP`: the E3↔E5 charter handoff is unnamed.** - *Affected section:* Skeletal Baseline §4.3; Import Graph DOC83↔DOC82 edge. - The point where extraction stops and the Assertion lifecycle begins ("candidate emission") is described narratively but has no named object, so two charters will guess at the seam. - *Recommended action:* name the handoff object (e.g. `AssertionCandidateEmission`) with `schema_owner = DOC82`, produced-by DOC83. Add it to the OPA register as a cross-doc seam. **B-4 — `GAP`: `WorkSession` is unaccounted for.** - *Affected section:* Skeletal Baseline §4.3 (working-state). - `WorkSession` appears in source material but has no owner row and no retired-name entry. - *Recommended action:* assign `WorkSession` to **DOC83** (working-state) or formally retire it if `WorkEpisode` supersedes it. Decide explicitly; do not leave it unlisted. **B-5 — `GAP`: `VersionedClaim` has no Supersession Matrix row and no retired-name entry.** - *Affected section:* Retired Names table; Owner Map. - `VersionedClaim` is referenced but untracked. It is either a live object needing an owner or a retired name needing an entry. - *Recommended action:* resolve its status. If retired in favor of `Assertion` + `AssertionVariant`, add a retired-name row; if live, give it a `schema_owner`. Log the matrix gap in the **Conflict/Disagreement Register**. **B-6 — `BUG`: `DynamicHeaderLedger` ownership conflicts with ADQ-305.** - *Affected section:* Owner Map `DynamicHeaderLedger` row vs ADQ-305 resolution. - The skeletal Owner Map placement and ADQ-305 disagree on the owner. - *Recommended action:* reconcile to the ADQ-305 resolution; if ADQ-305 is itself ambiguous, log in the Conflict/Disagreement Register rather than silently picking an owner. **B-7 — `BUG`: process vocabulary has leaked into runtime core §4.** - *Affected section:* Skeletal Baseline §4 (DOC80 core object list). - `DispositionMove` and `LedgerInvalidationState` are **flattening-process** terms, not runtime objects. `SourceStatus`, `NormativeWeight`, `CapabilityStatus`, and `CapabilityTier` are in core by default without a proven runtime use. - *Recommended action:* move `DispositionMove` and `LedgerInvalidationState` out of runtime core. For the other four, require a proven runtime consumer or move them out. Add lint `core.process_vocabulary_in_runtime_object`. ## C. Import graph findings **C-1 — `BUG` (BLOCKER): the import graph contains a cycle.** - *Affected section:* Import Graph §1 (which falsely claims "no upward imports") and the DOC86→DOC81 edge. - The cycle is `DOC81 → DOC84 → DOC86 → DOC81`. The `DOC86 → DOC81` edge is the wrong-direction offender. - *Recommended action:* **delete `DOC86 → DOC81`. Add `DOC81 → DOC86`** to carry `PolicyStamp`, the `EffectiveMemoryPolicy` reference, `disclosure_class`, restamp eligibility, and safe-label constraints into the UI member. `DOC86 → EC` and `EC → DOC81` are external control flows, not member-to-member imports, and do not constitute a cycle. Re-prove the graph acyclic after the edit. Correct the false §1 claim. **C-2 — `GAP`: DOC15 import is attributed only to DOC86.** - *Affected section:* Import Graph §4.4. - DOC84 (delivery/prompt/proof) most likely also depends on DOC15; the single-importer claim is probably incomplete. - *Recommended action:* verify DOC84's DOC15 dependency and add the edge if real. **C-3 — `GAP`: the contract/impl split makes the import graph unprovable.** - *Affected section:* Import Graph §4.1. - Because ~10 schemas are labelled with a "contract" half and an "impl" half (see B-8 / Part II), the import edges they imply are undefined, so acyclicity cannot be fully proven. - *Recommended action:* resolved by eliminating the split (Part II / Patch B3). Re-derive the affected edges from single owners afterward. ## D. Owner boundaries findings **D-1 — `GAP`: DOC9 is not disclaimed.** - *Affected section:* Skeletal Baseline §3.2 (external-doc boundary list). - DOC9 (self-repair) is neither absorbed nor explicitly out-of-scope. - *Recommended action:* add a §3.2 line stating DOC80 does not own DOC9; name the seam if one exists. **D-2 — `BUG`: the DOC26 import is mis-cited.** - *Affected section:* Skeletal Baseline §3.2. - The DOC26 dependency cites AC-005 / ADQ-404, which are unrelated. - *Recommended action:* correct the citation to the actual basis for the DOC26 dependency, or remove the dependency if none exists. **D-3 — `CONFIRMED`: the remaining §3.2 external boundaries are correctly drawn.** - *Affected section:* Skeletal Baseline §3.2. ## E. Retired names findings **E-1 — `BUG`: the retired-names count is wrong.** - *Affected section:* Retired Names header ("22 entries") vs table (21 rows). - *Recommended action:* reconcile. Per E-2 the correct total is **22** once SM-040 is added. **E-2 — `GAP`: SM-040 (Library/Corpus intermixed) is missing from the retired-name table.** - *Affected section:* Retired Names table. - *Recommended action:* add the SM-040 retired-name row. This is the 22nd entry. **E-3 — `SUGGESTION`: tighten two retired-name semantics.** - *Affected section:* Retired Names rows for `Claim` and `CU`. - Bare `Claim` should not be aliased to `Assertion` without qualification; and what is retired for `CU` is *CU-as-reusable-truth-store*, not CU as a concept. State both precisely so the lints derived from this file do not over- or under-fire. **E-4 — `CONFIRMED`: the four discontinued `AssertionCandidateDisposition` values are correctly removed.** - *Affected section:* Retired Names enum row. - The arithmetic (11 → 7) is correct. See F-3 for the capability-rehoming follow-up. ## F. New canonical object families findings **F-1 — `CONFIRMED` (with `SUGGESTION`): the new extraction families are sound.** - *Affected section:* Skeletal Baseline §4.3 / new-family list. - `ExtractionOutputKind`, `ExtractionSidecarKind`, and `ExtractionRoutePolicyEnvelope` are legitimate new families. *Suggestion:* their traceability to source docs is thin — add a one-line provenance note per family so Stage 7 charters can verify them. **F-2 — `GAP`: the domain profile registry (ADQ-313) is missing from the DOC80 core section map.** - *Affected section:* Skeletal Baseline §4 (core object list). - ADQ-313 establishes a domain profile registry; it is a no-plane shared registry and belongs in core, but the core section map omits it. - *Recommended action:* add the domain profile registry to the DOC80 core object list. **F-3 — `GAP`: the capabilities behind the removed enum values are not re-homed.** - *Affected section:* Retired Names enum row; Skeletal Baseline §4.3. - The four discontinued disposition values implied real extraction capabilities (directive, procedure, CU-component, evaluation handling). Removing the values without re-homing the capability silently drops function. - *Recommended action:* introduce `NonAssertionExtractionOutcome` (owner **DOC83**) to carry the non-Assertion extraction paths. This is the correct way to preserve the capability — **not** restoring the retired enum values (see G-2). ## G. Round D / ABC absorption findings **G-1 — `CONFIRMED`: all Round D UI surfaces are present.** - *Affected section:* Skeletal Baseline §4.6 (DOC86) and Owner Map UI rows. - `UserContextSurfacePlan`, `VisibleContextActionSpec`, `InspectorVisibilityPlan`, `SearchAffordance`, `TopicActivationState`, `ProjectAutoLinkState` all appear. (Note: B-? — `TopicActivationState` re-homes to DOC87 per Part III; that is a placement change, not a missing-surface finding.) **G-2 — `CONFIRMED` (with `SUGGESTION`): ABC R0.2 absorption spot-checks pass.** - *Affected section:* Skeletal Baseline §4.1 (DOC82). - ABC-senior objects are correctly carried. *Suggestion:* add an explicit note to DOC82 §1 that **ABC R0.2 is senior to the Concept Model per DR-001**, so Stage 7 does not accidentally reintroduce superseded Concept Model definitions. ## Overall assessment The skeletal baseline is **approved to proceed to Stage 6 after the Stage 5R patch in Part IV is applied**. One blocker (the import cycle), one pervasive defect (the contract/impl split), and one architect decision (DOC87) gate Stage 6. Everything else is scoped correction. No `ARCHITECT_STOP`. ------ # Part II — Deeper architectural findings These are systemic findings raised in deeper review. They drive the highest-value patches. ## II-1 — `BUG`/`GAP`: the "contract/impl split" pattern is pervasive, undefined, and self-contradictory The skeleton labels ~10 schemas with a split "contract" owner and "impl" owner — `EffectiveMemoryPolicy`, `MemoryContextPlan`, `ContextProduct`, `RenderSafetyProof`, `AssertionRelationEdge`, `SearchAffordance`, `contamination_risk`, `RecentActivityRollup`, `CascadingSourceInvalidation`, `WorkEpisode`, and others. The pattern is never defined, and it **directly contradicts** the Owner Map's stated "one owner per schema" rule. **Resolved rule (this supersedes any earlier "define the split" framing):** - **Eliminate the split. Every schema has exactly one `schema_owner`.** - A compound owner is a **symptom**: it means two distinct schemas have been mislabeled as one. Resolve it by **splitting the row into two named schemas**, each with one owner — e.g. `RecentActivityRollup` (producer-side) vs `RecentActivityRollupConsumptionContract` (consumer-side). - Secondary relationships are expressed only through a closed verb set: **stores / executes / generates / consumes**. These are not ownership. - **Placement rule = domain membership.** `schema_owner` is the member that owns that schema's plane. DOC80 core holds a schema **only** when it has no plane — registries, the proof spine, shared vocabulary, `MemoryCoordinationTrace`. "Consumed by multiple members" is handled by **lateral imports**, never by hoisting into core. - Honor the already-resolved ADQs that placed specific objects in core (ADQ-203, ADQ-208, ADQ-211 — `ContextProduct`, `PromptShell`, `MemoryContextPlan`) — but record each as a **single-owner** core object, not a split. → Patch B3. ## II-2 — `GAP`: the proof spine has no enforcement teeth `MemoryFlowCertificate`, `ContextPacketProof`, and `RenderSafetyProof` are defined as objects but nothing **lints** their absence. A proof spine with no enforcement is decorative. *Recommended action:* add a `proof.*` lint family and a **failure-mode → proof-artifact → lint** mapping table to DOC80 core, so every proof obligation has a named lint that fires on its violation (e.g. durable write without `MemoryFlowCertificate`; render without `ContextPacketProof`; render without `RenderSafetyProof`; export/carryover/delegation without `MemoryFlowCertificate`; learning signal without `ContextPacketProof`). → Patch B8. ## II-3 — `GAP`: DOC85 is scoped against a phantom; DOC8 must be treated as capability-mining input DOC8 (self-learning) is a phantom — it is not a real, current spec. DOC85 is currently scoped as a thin "consume from DOC8" seam, which means it is built on nothing. *Recommended action:* **rescope DOC85** as the substantive memory-learning specification. It owns the learning architecture, learning targets, proof-gating of learning signals, the write-back path, friction promotion, and warrant-degradation producers. It **consumes BDSM** (which appears to be real) where BDSM is real, and treats legacy DOC8 as **capability-mining input only** — a source of requirements, not a dependency. → Patch B6. The precise degree of BDSM reliance is ADQ-221 (Part III). ## II-4 — `GAP`: the learning write-back path and the hot-path compute budget have no owner Two cross-cutting concerns are unowned: - The **learning write-back path** (how a learning outcome becomes a durable memory change) is under-specified. It must route through EC as the sole durable writer and be proof-gated. - There is **no end-to-end hot-path / compute budget owner**. ELNOR is local-first; compute contention is real. Some member must own the family-wide compute budget and the degraded behavior when it is exceeded. *Recommended action:* assign the write-back path explicitly (DOC85 owns the path, EC executes the write, proof-gated via DOC80 core). Name a compute-budget owner — DOC80 core owns the budget envelope; each member declares its hot-path cost. → Patch B9. ## II-5 — `GAP`: warrant-degradation triggers belong in core, not DOC85 Warrant-degradation triggers are consumed by multiple members. Placing the trigger registry in DOC85 makes learning the owner of something delivery and knowledge also depend on. *Recommended action:* the **warrant-degradation-trigger registry** is a no-plane shared registry → **DOC80 core**. DOC85 owns the *producers* of degradation signals; core owns the registry. → Patch B8. ## II-6 — `GAP`: async pipeline-halt semantics are unspecified `PolicyDisambiguationRequest` can interrupt the pipeline mid-flight. There is no specified park/resume behavior — what happens to in-flight context assembly when policy disambiguation is pending. *Recommended action:* add pipeline-suspension / park-resume semantics for `PolicyDisambiguationRequest`. Name the suspended-pipeline state. → Patch F-async. ## II-7 — `GAP`: `CascadingSourceInvalidation` has inconsistent (three-way) ownership `CascadingSourceInvalidation` is described with three different owners across artifacts. *Recommended action:* resolve to a single `schema_owner` using the II-1 rule. The cascade *envelope* (the invalidation event contract) is core; the *source-side payload* is DOC82; *execution of the write* is EC. Record each relationship with the correct verb. → Patch B3. ## II-8 — `GAP`: external dependencies are not pinned The DOC80 family is built on ~15 external docs that are themselves churning. With no pinning, a charter can be drafted against a stale external section without anyone noticing. *Recommended action:* add an `ExternalDependencyRecord` to DOC80 core with: `source_freeze_ref`, `repo_path`, `content_hash`, `header_version`, `dependency_status`, `drift_response`. Every external-doc dependency in §3.2 gets a record. → Patch B7. ## II-9 — `SUGGESTION`: git-native versioning discipline "main is always operative" is too strong for in-progress specs. Adopt git-native versioning: **stable filenames with no version suffixes**, a **per-document status header** (`draft` / `target-baseline` / `operative` / `superseded`), and git history as the version record. (Process artifacts such as *this review* may keep a version label; the spec family files should not.) → Patch B5. ## II-10 — `SUGGESTION`: four structural additions to the skeletal baseline These raise the baseline's verifiability and should be named in Stage 5R, drafted in charters: - **Memory object taxonomy table** in DOC80 core — columns: object name, `schema_owner`, storage, writer, durability class, proof obligation. One row per canonical object. This is the single index Stage 7 charters check against. - **End-to-end round-trip golden scenario** — one worked example traced from extraction through membership, policy, delivery, proof, and learning, naming every object it touches. It is the integration test for the family. - **Per-external-doc amendment-magnitude assessment** — for each external dependency, a one-line estimate of how much that doc must change. Surfaces hidden large dependencies early. - **Per-member obligations tables** — each member declares its `MemoryCoordinationTrace` obligations and its **degraded / blocked** states. Prevents "unwired seam" failures. → Patch F-struct. ------ # Part III — Architect decisions ## ADQ-220 — Organization/membership home — **RESOLVED: create DOC87** **Decision (architect-approved):** create an 8th family member, **DOC87 — Memory Organization & Membership**. **Rationale.** Membership — the durable `member → container` relation across Topic, Library, Project, Episode, IssueFrame, Entity — is: - **Upstream of two consumer planes.** DOC84 *consumes* memberships for delivery; DOC86 *renders* them. Anything upstream of two different consumers cannot live inside either — this is why membership in DOC84 is wrong, and equally why membership in DOC86 (UI owning the durable relation) is the same category error relocated. - **A cross-plane edge.** A membership edge connects a knowledge object to an *organizational container*. Placed in DOC82 it would force the canonical-knowledge member to define what a Topic / Library / Project *is* — the exact cross-domain bleed the flatten removes. (This is why membership edges are **not** the same kind of object as `EvidenceSupportEdge` / `AssertionRelationEdge`, which are knowledge-internal.) - **The owner of its own non-trivial invariants** — membership confers no truth authority, no policy override, no source support; a candidate membership is not a confirmed one; a removed/blocked edge must never reach injection. A plane with its own load-bearing invariants needs one owner that states and enforces them. **DOC87 scope — deliberately narrow.** DOC87 owns: `MemoryMembershipEdge`, `MembershipLifecycleState`, `MembershipSource`, `MembershipInvalidationPolicy`, the membership candidate/confirmed/removed/blocked/stale states, the membership invariants, `TopicLens` organization semantics, `TopicActivationState` (the Topic lifecycle), and the organizational containers that have **no other owner** (the Topic object itself; Library-as-organizational- container). The name is **memory-scoped on purpose** — it is "Memory Organization & Membership," not "Organization" — to fence out future scope creep. **DOC87 does NOT own:** truth (DOC82), source/corpus artifacts (DOC25/DOC73/DOC82), extraction (DOC83), `TopicCollectionDirective` (DOC83), policy/scope (DOC81), delivery/prompt products (DOC84), learning (DOC85), UI rendering (DOC86/DOC20), Project *mode* (DOC20), durable writes (EC), or graph storage (DOC72). **Five binding corrections to the membership proposal** (these refine the external-review DOC87 sketch and are mandatory): 1. **`TopicActivationState` → DOC87, not DOC86.** It is the Topic *lifecycle* (latent → suggested → auto_created_lens → confirmed → collection_enabled → paused → archived), not a UI surface. DOC86 *renders* it; DOC87 owns it. 2. **Own the edge universally; own containers only where homeless.** DOC87 owns the `MemoryMembershipEdge` for every container. It owns the *container object* only where the container has no other home — Topic, and Library-as-organizational-container. Containers owned elsewhere keep their owners: Episode / IssueFrame → DOC83, Entity → DOC72, Project-mode → DOC20. DOC87 owns only the membership *edge into* those. 3. **Second-graph guardrail.** DOC87 owns container-membership relations **only**. Knowledge-internal edges (`AssertionRelationEdge`, `EvidenceSupportEdge`) stay in DOC82. DOC72 stores membership edges as graph payload; EC writes them. Under the one-owner model: `MemoryMembershipEdge` → `schema_owner = DOC87`, `storage = DOC72`, `write = EC`, `consumers = DOC83 / DOC84 / DOC86`. Add lint `membership.edge_defines_non_membership_relation`. 4. **Decompose "Library."** Library-as-organizational-container → DOC87; `LibrarySourceBinding` / `CorpusIndex` / `SourceCollection` → DOC82 / DOC25; Library UI → DOC86 / DOC20. Do not assign "Library" wholesale to any one member. 5. **DOC87 is a new plan §12 slice.** Adding the member inserts a slice into the plan §12 structure (membership sits after extraction, before delivery) and adds a node to the import graph. Amend the §12 slice list and the import graph **deliberately**, and slot DOC87 into the **cycle-fixed** graph (after Patch B1), then re-prove acyclic. `TopicCollectionDirective` and `TopicCollectionDirectiveBudget` **stay in DOC83** and reference DOC87's Topic identity. This is a clean lateral import (DOC83 imports Topic identity from DOC87), not a split. → Patches B2, plus membership lints/fixtures in Patch B2. ## ADQ-221 — BDSM / DOC8 status — **RECOMMENDED, OPEN** **Recommendation:** add ADQ-221 to formally pin the status of BDSM and DOC8. DOC8 is a phantom (Part II-3); BDSM appears real but its boundary is unverified. ADQ-221 should resolve: (a) BDSM's `dependency_status` (real / partial / phantom), (b) which BDSM surfaces DOC85 may consume, (c) confirmation that legacy DOC8 is capability-mining input only. **Tier:** ADQ-221 does **not** block Stage 5R. The DOC85 rescope (Patch B6) can proceed without it. ADQ-221 is a **Stage 6 charter gate** for the DOC85/E9 charter — that charter should not be finalized until ADQ-221 is resolved. Add it to the Architect Decision Queue at charter-gate tier. ------ # Part IV — Stage 5R Patch Instructions for Claude Code **This is the action layer. Work from this part.** Each patch lists FILE(s), SECTION(s), and the exact ACTION. **BLOCKERS** must be complete before any Stage 6 charter begins. **FOLD-INS** must be *named* in the skeletal artifacts now and *drafted* in the relevant Stage 6 charter. ## Pre-instructions / guardrails - Apply guardrails **G-1 … G-4** from Part 1. Do not re-slice; do not restore retired enum values; the cycle is `DOC81→DOC84→DOC86→DOC81`; raise no `ARCHITECT_STOP`. - Do not draft schema *internals* (field lists, types) — Stage 5R only names objects and fixes ownership/structure. Schema bodies are Stage 7. - Do not edit the Supersession Matrix. Findings tagged "→ Conflict/Disagreement Register" below are logged there, not patched into the matrix. - After every structural edit (cycle fix, DOC87 insertion), **re-prove the import graph acyclic** before moving on. - Where a patch says "split a row into two named schemas," name both and give each one owner; do not invent field-level detail. ## BLOCKERS — complete before Stage 6 **B1 — Fix the import-graph cycle.** - *Files:* `DOC80_Import_Graph.md` (§1, the DOC86→DOC81 edge); cross-check `DOC80_Skeletal_Target_Baseline.md` §4.6. - *Action:* Delete the `DOC86 → DOC81` edge. Add `DOC81 → DOC86` carrying `PolicyStamp`, the `EffectiveMemoryPolicy` reference, `disclosure_class`, restamp eligibility, and safe-label constraints. Mark `DOC86 → EC` and `EC → DOC81` as external control flows (not member imports). Correct the false §1 statement that there are no upward imports. Re-prove acyclic. **B2 — Create DOC87 (resolves ADQ-220).** - *Files:* `DOC80_Skeletal_Target_Baseline.md` (§1–§4), `DOC80_Owner_Map.md`, `DOC80_Import_Graph.md`, `DOC80_Retired_Names.md`, `Architect_Decision_Queue.md`, the Flatten-and-Unify plan (§12 slice list). - *Action:* 1. Add **DOC87 — Memory Organization & Membership** to the family roster. Family count 7 → 8. Update every "7-member" reference across all four artifacts to "8-member." 2. DOC87 owns: `MemoryMembershipEdge`, `MembershipLifecycleState`, `MembershipSource`, `MembershipInvalidationPolicy`, membership candidate/confirmed/removed/blocked/stale states, the membership invariants, `TopicLens` organization semantics, `TopicActivationState`, the Topic object, and Library-as-organizational-container. 3. **Move `MemoryMembershipEdge` out of DOC84 into DOC87.** Owner Map row: `schema_owner = DOC87`, `storage = DOC72`, `write = EC`, `consumers = DOC83/DOC84/DOC86`. 4. **Move `TopicActivationState` from DOC86 to DOC87.** DOC86 keeps the *rendering* of it. 5. Keep `TopicCollectionDirective` + `TopicCollectionDirectiveBudget` in DOC83; note they reference DOC87's Topic identity (lateral import DOC83→DOC87). 6. Decompose "Library": container → DOC87; `LibrarySourceBinding`/`CorpusIndex`/ `SourceCollection` → DOC82/DOC25; Library UI → DOC86/DOC20. Fix all "Library" owner rows. 7. State: DOC84 *consumes* DOC87 membership for `ContextProduct` planning; it does not create/confirm/own membership. DOC86 *renders* membership and exposes command-closed controls (add/remove/pin/reject/confirm). 8. Add DOC87 to the import graph: imports DOC80 core + DOC82 (knowledge identities); receives membership candidates from DOC83; consumed by DOC84 and DOC86. Slot into the **B1-fixed** graph; re-prove acyclic. 9. Amend the plan §12 slice list to insert the organization/membership slice between extraction and delivery. 10. Add membership lints: `membership.edge_owned_by_delivery`, `membership.edge_used_as_truth_authority`, `membership.edge_bypasses_policy`, `membership.edge_confirmed_without_EC_write`, `membership.candidate_rendered_as_confirmed`, `membership.removed_or_blocked_edge_used_for_injection`, `membership.ui_control_without_command_closure`, `membership.library_membership_used_as_source_authority`, `membership.project_membership_used_as_scope_override`, `membership.edge_defines_non_membership_relation`. 11. Add membership fixtures (name them in the skeleton; bodies in the DOC87 charter): user-pinned Topic member renders and is Topic-Slice-eligible; rule-matched member stays candidate until approved/policy-cleared; Library membership gives source context but not truth authority; Project membership biases retrieval only when Project mode + policy permit; Project-off retrieval still works; removed edge appears nowhere; blocked edge is hidden/safe-labeled per disclosure policy; `TopicCollectionDirective` proposes candidates but does not confirm them. 12. Add OPA rows for the new DOC87 seams: DOC87↔DOC72 (storage), DOC87↔EC (write), DOC87↔DOC84 (consumption), DOC87↔DOC83 (candidate emission), DOC87↔DOC86 (render). 13. Add the ADQ-220 resolution record to `Architect_Decision_Queue.md` (resolved = create DOC87) — as a resolution record, not an open item. **B3 — Eliminate the contract/impl split; enforce one `schema_owner`.** - *Files:* `DOC80_Owner_Map.md` (all compound-owner rows), `DOC80_Skeletal_Target_Baseline.md` §4 and §4.1, `DOC80_Import_Graph.md` §4.1. - *Action:* For every schema currently shown with a split/compound owner — `EffectiveMemoryPolicy`, `MemoryContextPlan`, `ContextProduct`, `RenderSafetyProof`, `AssertionRelationEdge`, `SearchAffordance`, `contamination_risk`, `RecentActivityRollup`, `CascadingSourceInvalidation`, `WorkEpisode`, and any others present — resolve to **exactly one `schema_owner`**. Where two docs genuinely both have a stake, that is two schemas mislabeled as one: **split the row into two named schemas**, each with one owner (e.g. `RecentActivityRollup` vs `RecentActivityRollupConsumptionContract`). Express all secondary relationships only as `stores` / `executes` / `generates` / `consumes`. Apply the placement rule: `schema_owner` = the member owning that schema's plane; core only for no-plane objects; "consumed by multiple members" → lateral imports, never core-hoisting. Honor ADQ-203/208/211 placements but record each as single-owner. Add lint `owner_map.compound_schema_owner`. Re-derive affected import edges from the single owners. **B4 — Fix `EffectiveMemoryPolicy` citation and ownership.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4.1; `DOC80_Owner_Map.md`. - *Action:* Replace the ADQ-211 citation with **SM-013 / Round D §1.5**. Set `EffectiveMemoryPolicy` `schema_owner = DOC81`, wholly; no core portion. (This is a specific case of B3; do it explicitly because the wrong citation is load-bearing.) **B5 — Adopt git-native versioning discipline.** - *Files:* all four skeletal artifacts (headers). - *Action:* Remove version suffixes from spec-family filenames. Add a per-document status header field with one of `draft` / `target-baseline` / `operative` / `superseded`. State in the skeletal baseline that git history is the version record. (Process artifacts are exempt.) **B6 — Rescope DOC85 (DOC8 is a phantom).** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4.5 (DOC85); `DOC80_Owner_Map.md` DOC85 rows; `Architect_Decision_Queue.md` (add ADQ-221). - *Action:* Rescope DOC85 from a thin "consume from DOC8" seam into the substantive memory-learning specification: it owns learning architecture, learning targets, learning proof-gating, the write-back path, friction promotion, and warrant-degradation *producers*. State that DOC85 consumes BDSM where BDSM is real and treats legacy DOC8 as capability-mining input only (not a dependency). Add **ADQ-221** to the queue at charter-gate tier (gates the DOC85/E9 charter; does not gate Stage 5R). **B7 — Add external-dependency pinning.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §3.2 and §4 (core object list). - *Action:* Add `ExternalDependencyRecord` to the DOC80 core object list with fields `source_freeze_ref`, `repo_path`, `content_hash`, `header_version`, `dependency_status`, `drift_response`. Create one record stub per external dependency listed in §3.2. **B8 — Add proof-spine enforcement and the warrant-degradation registry to core.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4 (core); `DOC80_Owner_Map.md`. - *Action:* (a) Add a `proof.*` lint family and a **failure-mode → proof-artifact → lint** mapping table to DOC80 core, covering `MemoryFlowCertificate`, `ContextPacketProof`, and `RenderSafetyProof` obligations (durable write, render, export, carryover, delegation, learning-signal). (b) Add the **warrant-degradation-trigger registry** to the DOC80 core object list (no-plane shared registry); DOC85 owns the producers, core owns the registry. **B9 — Name the Assertion-lifecycle owner, the E3↔E5 handoff, and the compute-budget owner.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4.1 (DOC82), §4.3 (DOC83), §4 (core); `DOC80_Owner_Map.md`; `DOC80_Import_Graph.md`. - *Action:* (a) Assign the **full Assertion lifecycle/state machine to DOC82** (candidate → variant → resolution → promotion → dedupe outcome, including `AssertionLifecycleState` and the ABC §7.8 pair). DOC83 owns extraction routing **up to candidate emission only**. (b) Name the E3↔E5 handoff object (e.g. `AssertionCandidateEmission`, `schema_owner = DOC82`, produced-by DOC83); add it to the OPA register. (c) Add `NonAssertionExtractionOutcome` (`schema_owner = DOC83`) to carry directive/procedure/CU-component/evaluation extraction paths — this re-homes the capability behind the four removed enum values. (d) Name a family-wide **compute-budget envelope** in DOC80 core; each member declares its hot-path cost. **B10 — Remove process vocabulary from runtime core.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4. - *Action:* Move `DispositionMove` and `LedgerInvalidationState` out of the runtime core object list (they are flattening-process terms). For `SourceStatus`, `NormativeWeight`, `CapabilityStatus`, `CapabilityTier`: keep in core only with a named runtime consumer; otherwise move out. Add lint `core.process_vocabulary_in_runtime_object`. **B11 — Add the domain profile registry to core.** - *Files:* `DOC80_Skeletal_Target_Baseline.md` §4 (core object list). - *Action:* Add the domain profile registry (ADQ-313) to the DOC80 core section map as a no-plane shared registry. ## FOLD-INS — name now in the skeleton, draft in Stage 6 charters **F1 — Retired-names hygiene.** - *File:* `DOC80_Retired_Names.md`. - *Action:* Add the **SM-040** (Library/Corpus intermixed) retired-name row; correct the header count to **22**. Tighten two semantics: bare `Claim` is not an unqualified alias of `Assertion`; the retired item for `CU` is *CU-as-reusable-truth-store*, not CU as a concept. → Log the SM-040 matrix gap in the **Conflict/Disagreement Register**. **F2 — Disposition of `WorkSession` and `VersionedClaim`.** - *Files:* `DOC80_Owner_Map.md`, `DOC80_Retired_Names.md`. - *Action:* Decide each explicitly. `WorkSession` → assign to DOC83 (working-state) or retire in favor of `WorkEpisode`. `VersionedClaim` → give it a `schema_owner` or add a retired-name row. → Log the `VersionedClaim` matrix gap in the **Conflict/Disagreement Register**. **F3 — Reconcile `DynamicHeaderLedger` with ADQ-305.** - *File:* `DOC80_Owner_Map.md`. - *Action:* Set the owner to the ADQ-305 resolution. If ADQ-305 is itself ambiguous → log in the **Conflict/Disagreement Register**; do not pick silently. **F4 — DOC9 and DOC26 boundary fixes.** - *File:* `DOC80_Skeletal_Target_Baseline.md` §3.2. - *Action:* Add a line stating DOC80 does not own DOC9 (self-repair); name the seam if one exists. Correct the DOC26 import citation (the AC-005/ADQ-404 reference is wrong) or remove the dependency if unfounded. **F5 — DOC15 second importer.** - *File:* `DOC80_Import_Graph.md` §4.4. - *Action:* Verify whether DOC84 also imports DOC15; add the edge if real. **F6 — DOC82 precedence note.** - *File:* `DOC80_Skeletal_Target_Baseline.md` §4.1. - *Action:* Add an explicit note that ABC R0.2 is senior to the Concept Model per DR-001. **F7 — Extraction-family provenance.** - *File:* `DOC80_Skeletal_Target_Baseline.md` §4.3. - *Action:* Add a one-line provenance note for `ExtractionOutputKind`, `ExtractionSidecarKind`, `ExtractionRoutePolicyEnvelope`. **F-async — Pipeline park/resume semantics.** - *File:* `DOC80_Skeletal_Target_Baseline.md` (DOC84 / core). - *Action:* Name a pipeline-suspension state and park/resume semantics for `PolicyDisambiguationRequest` interrupting in-flight context assembly. **F-struct — Four structural additions (name now, draft in charters).** - *File:* `DOC80_Skeletal_Target_Baseline.md`. - *Action:* Name, in the skeleton, four new structures to be drafted in charters: (1) the **memory object taxonomy table** in DOC80 core (object / `schema_owner` / storage / writer / durability / proof obligation); (2) an **end-to-end round-trip golden scenario**; (3) a **per-external-doc amendment-magnitude assessment**; (4) **per-member obligations tables** for `MemoryCoordinationTrace` obligations and degraded/blocked states. ## Carry-forward verification (from Stage 4) - **SM-202 enum:** the Stage 5 Owner Map and Retired Names correctly reflect the 7-value ABC §7.8 enum. Verify the **Supersession Matrix SM-202 row itself** was corrected. If not → log in the **Conflict/Disagreement Register** (do not edit the matrix in Stage 5R). ------ # Part V — Completeness audit Every finding and decision raised in review, mapped to its patch. **Result: complete — every item is assigned.** | # | Finding / decision | Type | Patch | | ---------------- | ----------------------------------------- | ------------------- | ---------------- | | A-1 | 7 members sound; 8th required | CONFIRMED/+ | B2 | | A-2 | DOC83/85/86 justified | CONFIRMED | — | | A-3 | core = shared contracts only | CONFIRMED | B10, B11 | | B-1 | `EffectiveMemoryPolicy` mis-cites ADQ-211 | BUG | B4 | | B-2 | Assertion lifecycle split | BUG | B9 | | B-3 | E3↔E5 handoff unnamed | GAP | B9 | | B-4 | `WorkSession` unaccounted | GAP | F2 | | B-5 | `VersionedClaim` untracked | GAP | F2 | | B-6 | `DynamicHeaderLedger` vs ADQ-305 | BUG | F3 | | B-7 | process vocab in core | BUG | B10 | | C-1 | import-graph cycle | BUG (blocker) | B1 | | C-2 | DOC15 single-importer | GAP | F5 | | C-3 | split makes graph unprovable | GAP | B3 | | D-1 | DOC9 not disclaimed | GAP | F4 | | D-2 | DOC26 mis-cited | BUG | F4 | | D-3 | other §3.2 boundaries | CONFIRMED | — | | E-1 | retired-names count wrong | BUG | F1 | | E-2 | SM-040 missing | GAP | F1 | | E-3 | `Claim`/`CU` semantics | SUGGESTION | F1 | | E-4 | enum 11→7 correct | CONFIRMED | — | | F-1 | new extraction families | CONFIRMED/SUGG | F7 | | F-2 | domain profile registry missing | GAP | B11 | | F-3 | removed enum capability re-home | GAP | B9 | | G-1 | Round D surfaces present | CONFIRMED | — | | G-2 | ABC absorption + DR-001 note | CONFIRMED/SUGG | F6 | | II-1 | contract/impl split pervasive | BUG/GAP | B3 | | II-2 | proof spine has no lints | GAP | B8 | | II-3 | DOC85 scoped on phantom DOC8 | GAP | B6 | | II-4 | write-back path + compute budget unowned | GAP | B9 | | II-5 | warrant-degradation registry placement | GAP | B8 | | II-6 | async halt unspecified | GAP | F-async | | II-7 | `CascadingSourceInvalidation` 3-way owner | GAP | B3 | | II-8 | external deps not pinned | GAP | B7 | | II-9 | git-native versioning | SUGGESTION | B5 | | II-10 | 4 structural additions | SUGGESTION | F-struct | | ADQ-220 | membership home | RESOLVED → DOC87 | B2 | | ADQ-221 | BDSM/DOC8 status | OPEN (charter gate) | B6 | | Reviewer G-1…G-4 | Gemini-pass guardrails | guardrail | Pre-instructions | | Carry-fwd | SM-202 matrix row | verify | Carry-forward | **Audit notes:** - All 11 BLOCKERS and all FOLD-INS trace to at least one finding; no orphan patches. - All matrix-touching findings (SM-040, `VersionedClaim`, `DynamicHeaderLedger`, SM-202) are routed to the Conflict/Disagreement Register, not to matrix edits — consistent with the Stage 5 review boundary. - ADQ-220 is recorded as **resolved**; ADQ-221 as **open at charter-gate tier**. Neither is an `ARCHITECT_STOP`; neither contradicts D-SEED-1 or D-SEED-2. - Stage 6 gate: B1–B11 must be complete and the import graph re-proven acyclic (twice — after B1 and after B2) before any Stage 6 charter begins. ADQ-221 must be resolved before the DOC85/E9 charter is finalized. *End of Stage 5R Review Response & Patch Instructions.* # ChatGPT 1: # DOC80 Stage 5 Skeletal Target Baseline — Consolidated Red-Team Response and Stage 5R Patch Instructions ## 1. Bottom-line disposition **Keep the DOC80 family architecture, but patch Stage 5 before approving Stage 6 slice charters.** The skeletal architecture is directionally correct: DOC80 should be a real spec family, not a single document, and it should unify memory ownership without absorbing every adjacent owner doc. The current structure correctly separates core contracts, scope/policy, knowledge/source/evidence, extraction/temporal state, delivery/prompt/proof, learning, and UI/Inspector/Search. The Stage 5 prompt also correctly frames this as a skeletal architecture review rather than a full-spec review. But the current Stage 5 artifacts are not yet clean enough for slice drafting. The biggest problems are: ```text 1. Organization / membership deserves its own DOC87. 2. The Owner Map violates its own one-owner rule through compound ownership rows. 3. The import graph has a DOC86 → DOC81 direction bug. 4. DOC85 incorrectly treats DOC8 as a complete external learning owner. 5. Assertion lifecycle is split across DOC82 and DOC83. 6. Proof spine exists as schemas/prose but lacks enforcement lints. 7. Runtime DOC80 core contains flattening-process vocabulary. 8. Several missing or under-authorized object families need explicit disposition. 9. External dependencies are not pinned to specific source revisions. 10. The skeleton needs an end-to-end workflow proof before slice charters. ``` **No need to redo the whole architecture.** This should be a **Stage 5R skeletal architecture patch**, not another broad redesign. ------ # 2. Family structure: change from 7 members to 8 ## Decision I now recommend creating: ```text DOC87 — Organization and Membership Plane ``` This changes the DOC80 family from: ```text DOC80–DOC86 ``` to: ```text DOC80–DOC87 ``` The original 7-member skeleton was reasonable, but the membership/organization concerns are now large and central enough to justify a separate member. The Retired Names table already treats “Topic facts / Library facts / Project facts” as retired parallel truth stores, replaced by `MemoryMembershipEdge` plus canonical `Assertion` / `CU` / `EvidenceRecord`. That means membership is a core unification mechanism, not a minor delivery detail. ## Why DOC87 is better than DOC82 or DOC86 `MemoryMembershipEdge` is not truth, evidence, extraction, UI, policy, or delivery. It is the durable organization relationship that says: ```text This memory belongs to this Topic. This source belongs to this Library. This Assertion is linked to this Project. This IssueFrame belongs to this work episode. This item is a candidate member, pinned member, rule-matched member, removed member, blocked member, etc. ``` Putting it in DOC82 would over-expand canonical knowledge/source/evidence into all organization relations. Putting it in DOC86 would make membership too UI-shaped. Putting it in DOC84 would be a category error: delivery consumes membership; it should not define it. The current skeletal baseline puts `MemoryMembershipEdge` under DOC84’s runtime delivery/context-product section, which is the wrong home. ## Patch instruction: add DOC87 Patch `DOC80_Skeletal_Target_Baseline.md`, `DOC80_Owner_Map.md`, and `DOC80_Import_Graph.md`. Add: ```text DOC87 — Organization and Membership Plane ``` DOC87 owns: ```text MemoryMembershipEdge MembershipLifecycleState MembershipSource MembershipInvalidationPolicy MembershipCandidate ConfirmedMembership PinnedMembership SuggestedMembership RuleMatchedMembership RemovedMembership RejectedMembership BlockedMembership TopicLens organization semantics Library membership semantics Project memory-membership semantics Episode / IssueFrame / Entity membership semantics Organization read-model contracts Membership inspection semantics ``` DOC87 does **not** own: ```text Assertion / AssertionVariant / Evidence truth — DOC82 ConsolidatedUnderstanding semantics — DOC73, consumed by DOC82 SourceArtifact / ArtifactSegment / corpus ingestion — DOC25 / DOC73 Extraction execution — DOC83 / EC / DOC23 as applicable TopicCollectionDirective — DOC83 Policy or scope decisions — DOC81 / EC / PropA Delivery / prompt / proof — DOC84 / DOC24 / KDA / DOC11 Learning — DOC85 UI implementation — DOC86 / DOC20 Durable writes — EC Graph storage — DOC72 ``` Update member table: ```text DOC80 — Core / contracts / proof spine DOC81 — Scope and policy DOC82 — Canonical knowledge / source / evidence DOC83 — Extraction / temporal / working state DOC84 — Runtime delivery / prompt / proof / DAMS DOC85 — Learning architecture and proof-gated adaptation DOC86 — UI / Inspector / Search DOC87 — Organization / membership ``` DOC87 consumes from: ```text DOC82 canonical memory objects DOC83 extraction-created membership candidates DOC81 scope/policy eligibility DOC72 graph storage EC durable write execution ``` DOC84 consumes DOC87 membership for context-product planning and injection. DOC86 renders DOC87 membership and exposes command-closed controls. ------ # 3. ADQ-220 resolution If `ADQ-220` already exists, resolve it. If not, add it and resolve it. ```text ADQ-220 — Organization / Membership placement Decision: Create DOC87 — Organization and Membership Plane. Rationale: Organization/membership is not truth, source evidence, extraction, delivery, UI, policy, or learning. It is the durable relation layer that says what memory belongs to which Topic, Library, Project, Episode, IssueFrame, Entity, or organizational surface. Given likely future expansion of Projects, Topics, Libraries, saved views, shared/private organizational spaces, and access-sensitive memory networks, a separate DOC87 prevents membership from being mis-owned by DOC82, DOC84, or DOC86. Resolved placement: - MemoryMembershipEdge → DOC87 - TopicLens organization semantics → DOC87 - Library membership semantics → DOC87 - Project memory-membership semantics → DOC87 - TopicCollectionDirective / TopicCollectionDirectiveBudget → DOC83 - UI display and controls → DOC86 / DOC20 - ContextProduct planning consumes membership → DOC84 - Policy and scope remain DOC81 / EC / PropA ``` ------ # 4. Owner Map: fix one-owner rule and contract/implementation split ## Problem The Owner Map says `owns` means “defines the schema; one and only one owner per schema,” but the table contains compound owners such as: ```text DOC80 core + DOC84 DOC82 semantics + DOC72 storage DOC80 core + DOC85 DOC86 + PropA/EC DOC83 + DOC73 DOC82 + DOC83 ``` That contradicts the Owner Map’s own rule. The current table has rows like `MemoryContextPlan`, `RenderSafetyProof`, `PromptShellLearningContract`, `RecentActivityRollup`, `WorkEpisode`, `CascadingSourceInvalidation`, `SafeLabelPolicy`, and others with compound or cross-owner semantics. ## Patch instruction Patch `DOC80_Owner_Map.md`. Replace the single `owner` concept with ownership dimensions. Add this definition: ```text Ownership dimensions schema_owner: Defines the schema. Exactly one per schema. contract_owner: Defines a cross-member or external-facing contract when a neutral contract home is required. registry_owner: Owns a shared registry or canonical vocabulary. semantic_owner: Defines meaning, invariants, and use constraints. storage_owner: Stores runtime payload but does not define schema. generation_owner: Generates instances or derived read models. implementation_owner: Implements member-local algorithms or runtime behavior. execution_owner: Executes commands, writes, policy evaluation, rendering, or delivery. consumer_owner: Imports or consumes the schema by reference and must not redefine it. ``` Add rule: ```text Every schema row MUST have exactly one schema_owner. Compound owners are forbidden in schema_owner. If a concept legitimately spans docs, split it into separate named artifacts: - XContract - XRuntimeState - XProducerEvent - XConsumerView - XStoragePayload - XExecutionResult ``` Add lints: ```text owner_map.compound_schema_owner owner_map.schema_owner_missing owner_map.multiple_schema_owners owner_map.consumer_redefines_schema owner_map.implementation_restates_schema ``` ## Specific owner-map corrections Apply these directly: ```text AssertionRelationEdge schema_owner: DOC82 storage_owner: DOC72 execution_owner: EC EffectiveMemoryPolicy schema_owner: DOC81 execution_owner: EC inputs_from: PropA / EC / DOC81 policy contracts DOC80 core may own only shared vocabulary/registry if needed, not the schema. MemoryContextPlan schema_owner: DOC80 core, if retained as cross-family contract consumed by DOC24 implementation_owner: DOC84 consumer_owner: DOC24 ContextProduct registry registry_owner: DOC80 core delivery_integration_owner: DOC84 assembly_execution_owner: DOC24 rendering_owner: KDA RenderSafetyProof schema_owner: DOC80 core generation_owner: DOC84 / KDA / DOC11 as applicable consumer_owner: DOC85 PromptShellLearningContract schema_owner: DOC80 core learning_consumer_owner: DOC85 computation_owner: BDSM/DOC85 as patched below RecentActivityRollup schema_owner/generation_owner: DOC73 consumption_contract_owner: DOC83 or DOC80 core delivery_consumer: DOC84 invariant: orientation only, never evidence. WorkEpisode / EpisodeSegment schema_owner: DOC83 storage_owner: DOC72, if graph payload generation_owner: DOC73 only if external generation remains true execution_owner: EC SearchAffordance surface_schema_owner: DOC86 runtime_eligibility_contract_owner: DOC84 execution_owner: EC / DOC24 / DOC20 as applicable SafeLabelPolicy policy/schema owner: DOC81, if it governs disclosure safety UI rendering owner: DOC86 vocabulary registry owner: DOC81 or DOC80 core, but pick one execution_owner: EC / DOC20 CascadingSourceInvalidation support-edge validity owner: DOC82 invalidation event/lifecycle owner: DOC83 policy invalidation input owner: DOC81 execution_owner: EC ``` ------ # 5. Import Graph: fix DOC86 → DOC81 cycle ## Problem The Import Graph lists: ```text DOC86 → DOC81: UserContextSurfacePlan stamps → policy restamp panel ``` while also saying imports flow downward and there are no upward imports. That direction is wrong. UI should not import upward into policy. Policy state flows to UI. User actions route through EC. ## Patch instruction Patch `DOC80_Import_Graph.md`. Delete: ```text DOC86 → DOC81 ``` Add: ```text DOC81 → DOC86: EffectiveMemoryPolicy reference, PolicyStamp, PolicyStampInvalidation, disclosure_class, restamp_eligibility, SafeLabelPolicy constraints. DOC86 → EC: user inspect / restamp / disclose / membership-control command events. EC → DOC81: policy re-evaluation, restamp, or disambiguation execution under DOC81 contract. ``` Add proof statement: ```text There is no DOC86 → DOC81 schema import. DOC86 may send user command events to EC. EC may trigger DOC81 policy re-evaluation. This is command flow, not schema import. ``` Re-run acyclicity proof. Add lint: ```text import_graph.upward_import_to_policy ``` ------ # 6. DOC85 / DOC8: rescope learning so it is not phantom ## Problem The current skeleton treats DOC85 as a thin learning-integration member consuming DOC8/BDSM. It says DOC85 owns final-prompt-proof gating but DOC8 owns computation. That is unsafe because DOC8 is partly phantom / incomplete. Claude’s latest comment is correct: if DOC8 is not a complete operative learning engine, DOC85 cannot point at it as if it were real. The DOC80 rebuild is the opportunity to de-phantom memory learning. BDSM appears more concrete as a utility/matrix/proof-gated attribution substrate. DOC85 should consume BDSM where real, but should own the memory-learning architecture that DOC8 was supposed to provide. ## Patch instruction Patch `DOC80_Skeletal_Target_Baseline.md` and `DOC80_Owner_Map.md`. Rename/reframe DOC85: ```text DOC85 — Learning Architecture and Proof-Gated Adaptation ``` Replace current rationale: ```text DOC85 consumes DOC8/BDSM learning computation. ``` with: ```text DOC85 owns the DOC80-family memory-learning architecture. DOC85 owns: - learning target taxonomy; - final-prompt-proof-gated utility eligibility; - learning signal eligibility; - product/shell/placement/UI learning contracts; - false-suppression sampling; - incident/friction → pattern → assertion/procedure escalation; - learning-derived warrant-degradation trigger producers; - learned-adjustment governance; - write-back routes; - canary / rollback / cooldown / partitioning requirements for memory-learning changes. DOC85 consumes BDSM’s utility / matrix / attribution substrate where that substrate is real and pinned. Legacy DOC8 is treated as: - capability-mining source; - actual-capability source; - lineage input; - not a presumed complete owner of memory-learning computation. ``` Add DOC85 non-goals: ```text DOC85 does not own canonical truth. DOC85 does not own DOC72 confidence. DOC85 does not own policy permissions. DOC85 does not override source authority. DOC85 does not bypass EC, DOC1, DOC81, DOC82, DOC83, DOC84, DOC86, or KDA/DOC24/DOC11. ``` ## DOC8 staging This answers the user’s question about timing. ```text Stage 5R: Rescope DOC85 so it owns the memory-learning rebuild target and treats DOC8 as legacy/capability-mining unless proven operative. Stage 6 / E9 charter: Require DOC8/BDSM Actual Capability Reconciliation. Stage 7 / E9 drafting: Draft DOC85’s substantive learning architecture. Stage 9 / Stage 11: Validate learning with proof-gated fixtures and no-phantom learning lints. ``` So: **yes, the skeletal structure can proceed without fully rebuilding DOC8 first**, but only if Stage 5R stops treating DOC8 as a complete external owner. ## E9 charter requirement Add to Stage 6 E9 charter: ```text DOC8/BDSM Actual Capability Reconciliation Before drafting DOC85, the slice must inventory: 1. What DOC8 actually specifies today. 2. What BDSM actually specifies today. 3. What DOC72/DOC73/DOC24/DOC23/KDA/DOC20/EC assume DOC8 does. 4. Which assumptions are satisfied by existing DOC8. 5. Which assumptions are satisfied by BDSM. 6. Which assumptions are phantom and must be specified in DOC85. 7. Which learning outputs require DOC1, EC, policy, owner-doc write-back, canary, rollback, or user review. ``` ## DOC85 write-back section Add to DOC85 section map: ```text §3. Learned-adjustment governance and write-back §3.1 LearnedAdjustmentCandidate §3.2 Allowed adjustment targets: extraction_threshold topic_collection_budget prompt_shell_variant context_product_selection warning/suppression threshold warrant_degradation_trigger UI notice/surface timing false-suppression sampling rate §3.3 Forbidden direct adjustments: canonical truth policy permissions source authority DOC72 epistemic confidence final-prompt proof cross-scope visibility §3.4 Required gates: final-prompt proof policy_generation partition scope/visibility partition canary or review where required EC execution DOC1 Write Gate where durable memory behavior changes §3.5 Write-back route: DOC85 → EC → affected owner contract EC remains sole durable writer. ``` Add Owner Map seam: ```text DOC85 produces LearnedAdjustmentCandidate. EC executes approved durable adjustments. DOC81/DOC83/DOC84/DOC86 consume only approved compiled adjustment bundles. DOC85/DOC8/BDSM may not directly mutate policy, assertion truth, extraction ownership, source authority, prompt output, or UI controls. ``` ------ # 7. Assertion lifecycle: consolidate under DOC82 ## Problem The current skeletal baseline places `Assertion`, `AssertionVariant`, `AssertionCandidate`, `AssertionResolution`, and `AssertionLifecycleState` in DOC82, but leaves `AssertionCandidateDisposition`, six-step extraction triage, and promotion lifecycle in DOC83. The Owner Map currently lists `AssertionCandidateDisposition` as DOC83-owned. That splits one object’s lifecycle across two members. ## Final rule ```text The member that owns an object owns that object’s complete lifecycle and state machine. ``` Therefore: ```text DOC82 owns the Assertion object family and its lifecycle. DOC83 owns extraction routing up to candidate emission. ``` ## Patch instruction Move these from DOC83 to DOC82: ```text AssertionCandidateDisposition AssertionDedupeOutcome AssertionResolution AssertionLifecycleState Assertion promotion lifecycle AssertionMergeOperation AssertionSplitOperation AssertionUnmergeOperation AssertionReconciliation AssertionIdentitySignature EffectiveWarrant, if tied to Assertion use ``` DOC83 keeps: ```text ExtractionContextPlan ExtractionRouteContext, unless DOC82 keeps route provenance ExtractionResult ExtractionOutputKind ExtractionSidecarKind NonAssertionExtractionOutcome IssueFrameUpdate generation IncidentObservation / FrictionEvent routing ReviewQueueEntry generation TopicCollectionDirective TopicCollectionDirectiveBudget ``` Add normative rule: ```text DOC83 may emit an AssertionCandidate and recommended routing metadata. DOC82 owns canonical assertion resolution, disposition, dedupe, lifecycle, merge, split, unmerge, warrant, promotion, and degradation. DOC1 remains Write Gate. EC remains sole durable writer. ``` ------ # 8. Non-Assertion extraction path ## Problem We should not restore the retired 11-value `AssertionCandidateDisposition` enum. The Retired Names table correctly retires the old Concept Model 11-value enum, including `retain_as_cu_component`, `create_directive_candidate`, `create_procedure_candidate`, and `evaluation_only`. But the underlying capability concern is valid: extraction can produce directives, procedures, CU components, evaluation artifacts, entity updates, null results, issue-frame updates, etc. Those should not be forced through `AssertionCandidateDisposition`. ## Patch instruction Add under DOC83: ```text NonAssertionExtractionOutcome ``` Definition: ```ts type NonAssertionExtractionOutcome = | { kind: "directive_candidate"; target_owner: "DOC1" | "DOC72"; route: "memory_directive_path"; } | { kind: "procedure_candidate"; target_owner: "DOC3" | "DOC72"; route: "procedure_or_standing_procedure_path"; } | { kind: "cu_component_or_cu_request"; target_owner: "DOC73"; route: "consolidated_understanding_path"; } | { kind: "evaluation_only"; target_owner: "DOC23"; route: "evaluation_namespace"; } | { kind: "entity_update"; target_owner: "DOC72"; route: "graph_entity_path"; } | { kind: "null_result"; target_owner: "DOC83"; route: "null_result_memory_path"; } | { kind: "issue_frame_update"; target_owner: "DOC83"; route: "working_state_path"; }; ``` Add rule: ```text Not every extracted memory object is an AssertionCandidate. Truth-apt reusable propositions use AssertionCandidate → Assertion. Non-assertion outputs route to their owner path and must not reintroduce old assertion-disposition enum values. ``` ------ # 9. Proof spine: add enforcement lints ## Problem The skeletal baseline defines `MemoryFlowCertificate`, `ContextPacketProof`, and `RenderSafetyProof`. It also says MemoryFlowCertificate is mandatory for durable write / render / export / carryover / delegation / learning attribution. But schemas and prose are not enforcement. The latest Claude comments correctly warn that proof-spine controls become phantom controls without lints. ## Patch instruction Patch `DOC80_Skeletal_Target_Baseline.md` DOC80 core §11. Add: ```text Proof spine enforcement lints proof.durable_write_without_memory_flow_certificate proof.render_without_context_packet_proof proof.render_without_render_safety_proof proof.export_without_memory_flow_certificate proof.carryover_without_memory_flow_certificate proof.delegation_without_memory_flow_certificate proof.learning_signal_without_context_packet_proof proof.learning_signal_without_render_safety_proof proof.utility_credit_without_final_prompt_presence proof.memory_flow_certificate_missing_policy_generation proof.memory_flow_certificate_missing_scope_or_visibility_partition proof.context_packet_proof_missing_final_prompt_status proof.render_safety_proof_missing_template_or_lint_version ``` Add table: ```text Failure mode | Required proof artifact | Enforcement lint ``` Include at least: ```text durable memory write inline render reference-only render export carryover delegation subagent delivery learning attribution prompt-shell learning UI/Inspector disclosure search affordance execution ``` ------ # 10. DOC84 / DOC24 boundary: delivery-integration contract, not packet assembly ## Problem DOC84 currently says it owns runtime delivery, context products, prompt/proof, and DOC24 packet integration. That is directionally right, but the Owner Map contains phrases like `ContextProduct (assembly)` with DOC84 as owner and DOC24 executing assembly. This can blur DOC84 into DOC24’s packet assembly owner role. ## Patch instruction Use this wording everywhere: ```text DOC80 owns ContextProduct registry and shared delivery vocabulary. DOC84 owns DOC80-family delivery-integration contracts: MemoryContextPlan consumption, ContextProductDecision constraints, DAMS salience/attenuator seam, prompt-shell runtime selection, render/proof gates, delivery-policy constraints. DOC24 owns packet assembly mechanics and manifests. KDA owns deterministic rendering. DOC11/OpenClaw owns final runtime prompt truth. DOC85 learns only from proof-gated delivered content. ``` Replace: ```text DOC84 owns ContextProduct assembly ``` with: ```text DOC84 owns Memory Control Plane delivery-integration contract. DOC24 owns assembly. ``` Add lint: ```text doc84.redefines_doc24_packet_assembly ``` ------ # 11. ContextAssemblyTrace / MemoryCoordinationTrace ## Problem `ContextAssemblyTrace` appears in DOC84’s section map. DOC24 already has assembly traces/manifests. DOC80 already has `MemoryCoordinationTrace` as a cross-plane trace tying extraction, context, surface, manifests, proof, Inspector explanation, and learning. The skeletal baseline consumes ADQ-209 saying the three-plan model is retained and `MemoryCoordinationTrace` ties them. ## Patch instruction ```text Do not create a DOC84-owned ContextAssemblyTrace that shadows DOC24. ``` Either: ```text A. Rename DOC84 item to MemoryContextAssemblyTraceConsumptionContract; ``` or: ```text B. State that ContextAssemblyTrace is DOC24-owned if already defined, and DOC84 imports/consumes it. ``` Add rule: ```text MemoryCoordinationTrace is the DOC80-family cross-plane trace. DOC24 ContextAssemblyTrace / packet manifests remain DOC24-owned. DOC84 must not create a duplicate assembly-trace system. ``` ------ # 12. MemoryCoordinationTrace: restore and extend ## Problem Round D/ABC carried `MemoryCoordinationTrace` as central, but the Stage 5 skeleton risks leaving it as just a name. The latest comments emphasize that without it, Inspector “why included / why excluded / why not remembered” cannot connect extraction, context planning, policy, delivery, UI, and learning. ## Patch instruction Ensure DOC80 core owns: ```text MemoryCoordinationTrace ``` Add required trace links: ```text request_ref source_observation_refs ExtractionContextPlan refs ExtractionResult refs AssertionResolution refs MemoryMembershipEdge refs ScopeResolutionResult refs EffectiveMemoryPolicy refs MemoryContextPlan refs ContextProductDecision refs DOC24 manifest refs KDA patch refs FinalPromptInjectionManifest refs RenderSafetyProof refs ContextPacketProof refs UserContextSurfacePlan refs InspectorVisibilityPlan refs LearningSignal refs ``` Add pipeline suspension state for policy disambiguation: ```ts type MemoryCoordinationTraceState = | "active" | "suspended_for_policy_disambiguation" | "resumed_after_policy_disambiguation" | "failed_closed" | "completed"; ``` Add rule: ```text When PolicyDisambiguationRequest fires mid-pipeline: - trace state becomes suspended_for_policy_disambiguation; - partial assembly is cached; - compute is yielded; - no unsafe render occurs; - resume requires EC policy clearance; - unresolved timeout follows safe fallback. ``` ------ # 13. External dependency pinning ## Problem DOC80 imports from many owner docs that are themselves moving: DOC72, DOC73, DOC24, DOC25, DOC11, DOC1, DOC3, DOC15, DOC20, DOC23, EC, PropA, KDA, BDSM, DOC8, etc. The latest Claude comments correctly identify that Stage 5 treats these as stable when they are not. ## Patch instruction Add an `ExternalDependencyPin` table to `DOC80_Skeletal_Target_Baseline.md` and `DOC80_Owner_Map.md`. ```ts type ExternalDependencyPin = { external_doc: string; pinned_revision_or_commit: string; pinned_path: string; imported_objects_or_contracts: string[]; import_owner_member: "DOC80" | "DOC81" | "DOC82" | "DOC83" | "DOC84" | "DOC85" | "DOC86" | "DOC87"; volatility: "stable" | "moving" | "unknown"; drift_response: "re_audit" | "owner_map_patch" | "architect_stop"; }; ``` Required pins: ```text DOC72 DOC73 DOC25 DOC24 KDA BDSM DOC8 legacy EC Core PropA DOC20 DOC23 DOC1 DOC11 DOC3 DOC15 DOC9 parked/future DOC26 if still referenced ``` Add lint: ```text external_dependency.unpinned_import external_dependency.moving_dependency_without_drift_response ``` ------ # 14. Family version coherence ## Problem The DOC80 family will have multiple members. If each evolves independently with no compatibility rule, the family will recreate version sprawl. Claude’s latest suggestion is correct: the skeleton needs a family-version-coherence rule now. ## Patch instruction Patch `DOC80_Skeletal_Target_Baseline.md` §0 or §1. Add: ```text DOC80 Family Version Coherence DOC80-family members are single living documents in git. The repository commit history is the version record. A change spanning multiple DOC80-family members should be committed as one atomic commit or PR. Each member must declare: - family_generation_id; - required_core_generation; - compatible_member_generations where applicable; - changed_contracts; - migration / recharter implications. No member may advance a contract-breaking change without either: 1. a family-generation update; or 2. explicit compatibility statement proving other members remain valid. ``` Add lints: ```text family.member_contract_changed_without_generation_update family.member_requires_unknown_core_generation family.incompatible_member_generation ``` ------ # 15. Process vocabulary out of runtime core ## Problem `DispositionMove` and `LedgerInvalidationState` are flattening-process concepts. They should not live in runtime DOC80 core. Claude flagged this correctly. ## Patch instruction Patch `DOC80_Skeletal_Target_Baseline.md`, DOC80 §4. Remove from runtime core: ```text DispositionMove LedgerInvalidationState ``` Move to: ```text Flattening Plan / Execution Ledger only ``` For these: ```text SourceStatus NormativeWeight CapabilityStatus CapabilityTier ``` add: ```text runtime_relevance_review_required ``` Rule: ```text If a vocabulary is used only by the flattening process, source registry, source freeze, supersession matrix, capability inventory, or execution ledger, it must not be part of the DOC80 runtime product spec. ``` Add lint: ```text runtime_core.contains_flattening_process_vocabulary ``` ------ # 16. Hot-path and background compute budget ## Problem DOC84 has `HotPathCostBudget`, but memory read/delivery traverses DOC81 → DOC82 → DOC84 → DOC24/KDA/DOC11. Background extraction and learning can contend with hot-path delivery on a local-first machine. No member owns the end-to-end budget. Claude correctly flagged this. ## Patch instruction Add to DOC80 core: ```text FamilyWideComputeBudget ``` It owns: ```text hot_path_read_budget prompt_assembly_budget policy_meet_budget scope_resolution_budget retrieval_budget DAMS_attenuator_budget render_budget search_affordance_preflight_budget background_extraction_budget background_learning_budget contention_policy ``` Rule: ```text No DOC80-family member may add hot-path LLM calls unless explicitly allowed by FamilyWideComputeBudget. Background extraction, Topic future-watch, parse-quality work, and learning must yield to hot-path delivery under the budget policy. ``` Each slice charter must include: ```text compute_budget_slice hot_path_contribution background_budget_contribution contention_behavior ``` Add lints: ```text compute.hot_path_llm_call_without_budget compute.member_missing_budget_slice compute.background_task_no_yield_policy compute.search_affordance_preflight_unbounded ``` ------ # 17. CU / DOC73 reconciliation and SourceBoundSynthesisProjection ## Problem DOC73 owns `ConsolidatedUnderstanding`. DOC82 may consume it directly or wrap it via `SourceBoundSynthesisProjection` if DOC73 diverges. The skeleton has the right direction, but the wrapper could become a permanent shadow-CU system if not constrained. ADQ-219 already says DOC73 owns CU semantics and a divergence beyond wrapper absorption escalates. ## Patch instruction Add to E3/E4 charter: ```text DOC73 CU Reconciliation Decision The charter must decide one of: 1. DOC73 CU satisfies DOC80 source-bound synthesis contract. → no wrapper. 2. Temporary wrapper required. → SourceBoundSynthesisProjection allowed only with expiry gate, reconciliation obligation, and OP-A row. 3. Permanent wrapper required. → architect approval required; add lint proving wrapper is not a local CU redefinition. ``` Add lints: ```text cu.shadow_cu_without_architect_approval cu.wrapper_without_expiry_or_reconciliation_gate cu.used_as_reusable_truth ``` ------ # 18. VersionedClaim lineage ## Problem `VersionedClaim` is retained at DOC73 legacy and mapped to `AssertionVariant`, but the lineage table is not yet defined. This is load-bearing. ## Patch instruction Add to E3/E4 charter: ```text DOC73_VersionedClaim_to_AssertionVariant_Lineage_Table ``` It must include: ```text versioned_claim_ref source_cu_ref source_span_refs assertion_variant_ref lineage_kind preserved_fields lost_or_transformed_fields migration_status review_required ``` Add lints: ```text versioned_claim.unmapped_to_assertion_variant versioned_claim.lineage_table_missing ``` ------ # 19. CognitiveDiff / ResumeCard ## Problem `CognitiveDiff + Resume card` appears in the Owner Map and DOC84 section map, but this object family was not clearly authorized and risks becoming a vague phantom working-state layer. The current Owner Map lists it under DOC84 as “Resume support.” ## Recommendation Do **not** create a canonical `CognitiveDiff` object at Stage 5 unless Will later approves it. ## Patch instruction Patch DOC84: ```text Demote CognitiveDiff to derived ResumeProjection / ResumeCard. ResumeCard is: - a derived presentation over IssueFrame, RecentActivityRollup, MemoryCoordinationTrace, PriorDeliveryLedger, and relevant membership edges; - not truth-bearing; - not evidence; - not a durable memory object unless separately approved; - invalidated when its source refs invalidate. ``` If kept: ```text Create ADQ: Should CognitiveDiff become a canonical object family? Default: no, derived projection only. ``` Add lint: ```text cognitive_diff.canonical_without_authorization resume_card.used_as_evidence ``` ------ # 20. WorkSession disposition ## Problem The prompt specifically anchors WorkSession, WorkEpisode, and EpisodeSegment, but the Owner Map covers WorkEpisode/EpisodeSegment and does not clearly account for WorkSession. ## Patch instruction Add one explicit row: ```text WorkSession Disposition: retained as light temporal grouping under DOC83; OR absorbed into WorkEpisode; OR retained externally; OR retired/deferred with rationale. ``` My recommendation: ```text Retain WorkSession as a light temporal grouping under DOC83 if it already exists in current specs. It is not user-visible by default. It supports resume, recent-work reconstruction, multi-surface continuity, and episode grouping. ``` Add lint: ```text worksession.missing_disposition ``` ------ # 21. SemanticProjection and ProjectionInvalidationPolicy ## Problem `SemanticProjection` and `ProjectionInvalidationPolicy` appear in DOC84, but projections are cross-cutting and could duplicate DOC72/DOC73/DOC20/DOC24 read-models. ## Patch instruction Define narrowly: ```text SemanticProjection: A derived, non-canonical view over canonical memory objects. It never owns truth. It must carry source_refs, generation_id, invalidation_policy, projection_owner, and proof/read-model refs. ProjectionInvalidationPolicy: The invalidation rule for a projection when sources, policy, scope, membership, or canonical objects change. ``` Owner placement: ```text DOC80 core owns projection contract if cross-family. Specific projection owner depends on projection type: - DOC84 delivery projection - DOC86 UI projection - DOC82 knowledge projection - DOC87 organization projection ``` Add lints: ```text projection.used_as_canonical_truth projection.missing_source_refs projection.missing_invalidation_policy projection.owner_missing ``` ------ # 22. Retired Names cleanup ## Problems The Retired Names file says total retired entries = 22, while the visible table appears to have 21 rows. It also allows `Premise` as a memory-object alias in DOC72/DOC73 legacy citation contexts until cross-doc rename pass, which is too broad. It also lacks a clear row for “Corpus as user-facing parallel Library,” which was flagged in reviews. ## Patch instruction Patch `DOC80_Retired_Names.md`. 1. Recount entries and fix total. ```text If there are 21 rows, change total to 21. If 22 intended, add the missing row. ``` 1. Add row: ```text retired_name: Corpus (as user-facing parallel Library) superseded_by: Library (user-facing source collection) + internal Corpus / SourceCollection / CorpusIndex processing state allowed_historical_context: DOC73 / DOC25 / source-processing lineage only lint: corpus_user_facing_parallel_library ``` 1. Tighten `Premise` alias: ```text Premise as memory object is allowed only in explicit Legacy / Lineage / Supersession subsections. It is not allowed in active normative DOC80 text. It expires at completion of cross-doc rename pass. ``` 1. Add semantic retired-name lints: ```text retired.scalar_memory_policy_decision_used retired.cu_used_as_reusable_truth retired.topiclens_as_passive_saved_view_only retired.premise_memory_object_active_use retired.corpus_as_user_facing_parallel_library ``` Because some retained names are allowed in narrowed form, lints must be context-aware, not simple string matches. ------ # 23. DOC9 boundary ## Problem DOC9/self-repair is not clearly named in the skeletal baseline’s “does not own” list, even though the Stage 5 prompt specifically asks whether DOC80 avoids absorbing DOC9 self-repair. DOC9 is a future/parked self-repair/code-modification source. It may have useful repair-event memory seams but should not be absorbed into DOC80. ## Patch instruction Add to `DOC80_Skeletal_Target_Baseline.md` external-owner/non-goals section: ```text DOC9 / self-repair is parked/future. DOC80 may mine repair-event memory seams only if explicitly approved. DOC80 does not absorb: - self-repair pipeline mechanics; - patch proposal mechanics; - approval/application/verification/rollback mechanics; - code-autonomy policy; - coder/reviewer separation; - git snapshot/rollback mechanics. ``` Add lint: ```text doc9.self_repair_absorbed_without_approval ``` ------ # 24. DOC15 import and token/context budget seam ## Problem The import graph currently imports DOC15 only into DOC86, but DOC15’s CIL context assembly / token budgets / injection hierarchy likely also touch DOC84 delivery and possibly DOC80 core. DOC15 Addendum A cataloged 106 memory/context/self-learning systems and flagged competing context managers, single-writer violations, schema gaps, and budget gates. ## Patch instruction Add a source check: ```text Verify DOC15 import seams: - DOC84 ← DOC15 for injection hierarchy, token budgets, context assembly constraints, if still operative. - DOC85 ← DOC15 only if learning signals or CIL learning interfaces remain relevant. - DOC86 ← DOC15 only for UI/control surfaces, if applicable. ``` Add to ExternalDependencyPin table: ```text DOC15 Addendum A: status: support_non_normative / audit_lineage / capability-mining source use: identify current memory/context/self-learning systems and context manager conflicts not controlling over current DOC15 unless re-adopted ``` Add lint: ```text doc15.context_budget_import_missing ``` ------ # 25. DOC26 / UnifiedWorkspaceLibrary citation check ## Problem The import graph includes DOC86 importing from DOC26 with a citation to AC-005 / ADQ-404. Some reviews flagged that citation as possibly wrong. ## Patch instruction ```text Verify whether DOC26 is a real current owner doc and whether AC-005 / ADQ-404 actually authorize the DOC86 ← DOC26 import. If yes: correct the citation and pin the external dependency. If no: remove DOC26 import or mark it aspirational/parked. ``` Add lint: ```text import_graph.invalid_authorization_citation ``` ------ # 26. Warrant-degradation trigger registry ## Problem Warrant degradation triggers are currently in DOC85. That over-weights learning. A trigger registry is cross-cutting: triggers may come from source changes, policy changes, stale authority, learning signals, parse-quality issues, or source invalidation. ## Patch instruction ```text WarrantDegradationTriggerRegistry → DOC80 core EffectiveWarrant semantics → DOC82 Learning-derived trigger producers → DOC85 Source/parse trigger producers → DOC82/DOC83/DOC25/DOC73 Policy trigger producers → DOC81 Delivery/outcome trigger producers → DOC84/DOC85 ``` Add lints: ```text warrant.trigger_registry_owned_by_learning_only warrant.learning_escalates_beyond_epistemic_band warrant.policy_block_collapsed_into_warrant ``` ------ # 27. NullResultMemory invalidation ## Problem NullResultMemory has fields for source index/materialization/population generation, but source invalidation must explicitly invalidate dependent null results. Some reviews overstate the problem, but the dependency should be explicit. ## Patch instruction Add rule under DOC83 / CascadingSourceInvalidation: ```text When source_index_generation_id, materialization_snapshot_ref, access_set_hash, or scope_population_generation_id changes, any dependent NullResultMemory becomes verification_required or stale_possible until re-run. ``` Add lint: ```text null_result.used_after_source_or_access_generation_change ``` ------ # 28. SearchAffordance direction and ownership ## Rule ```text DOC86 owns visible SearchAffordance surface and user controls. DOC84 owns runtime eligibility when embedding SearchAffordance in context products. DOC87 owns organizational membership data that may feed search scope. DOC81/EC policy gates search execution. EC executes preflight/commands. DOC20 implements UI. ``` Patch Import Graph: ```text DOC87 → DOC84: membership/search scope data consumed for context-product planning. DOC84 → DOC86: runtime delivery state / eligible affordance state. DOC81 → DOC86: policy/disclosure state. DOC86 → EC: user command events. EC → DOC81/DOC84/DOC87: policy preflight, search execution, read-model refresh. ``` Add lints: ```text search_affordance.no_preflight search_affordance.cross_scope_auto_pull search_affordance.visible_without_command search_affordance.scope_filter_missing search_affordance.policy_generation_missing ``` ------ # 29. Round D UI surface checklist Add to DOC86 charter and baseline: ```text RoundD_UI_Surface_Checklist: - review queue card - policy restamp panel - blocked-item explanation - privacy banner - Project quarantine chip - cross-project search chip - task handoff scope-envelope confirmation - Topic Notice - Topic Slice availability - Library Notice - Library Source Slice availability - Search More affordance - why included / why excluded / why not remembered Inspector ``` Add lint: ```text doc86.round_d_ui_surface_missing ``` ------ # 30. Stage 5 workflow-proof stories Add a skeletal workflow-proof section before Stage 6 charters. These are not full fixtures yet, but they test whether the DOC80 family composes. Required workflow stories: ```text 1. Topic-driven extraction over a Library TopicCollectionDirective scans Library/corpus, produces AssertionCandidates, resolves to Assertion, creates DOC87 membership, injects Topic Slice. 2. No-project default-mode retrieval Ordinary chat uses prompt/entities/Topics/Libraries/recent work/graph without Project mode. 3. Ethical-wall blocked item Relevant item exists, scope/policy blocks it, UI/Inspector shows safe label or nothing. 4. CU to Assertion DOC73 CU supports/generates AssertionCandidate; DOC82 resolves Assertion; CU remains source-bound. 5. Qwen incident Transient statement becomes IncidentObservation/FrictionEvent, not durable Assertion; recurrence may promote to FrictionPattern/Procedure under DOC85/DOC83 gates. 6. Carryover to external model EffectiveMemoryPolicy + MemoryFlowCertificate + ContextPacketProof determine what can move. 7. RecentActivityRollup orientation Orientation-only product cannot support factual warrant. 8. SearchAffordance execution DOC86 surface + EC preflight + DOC84 eligibility + DOC87 scope/membership + DOC81 disclosure gate. 9. Membership edit User pins/removes a Topic member; EC writes DOC87 membership state; DOC84 delivery and DOC86 UI update accordingly. 10. Learning write-back DOC85 learns prompt-shell/product outcome only after final-prompt proof; any durable adjustment routes through EC and owner gates. ``` Add to family-wide acceptance: ```text At least one end-to-end round-trip scenario must be specified before charters: source → extraction → candidate → resolution → membership → policy → delivery → render → final prompt proof → learning → Inspector explanation. ``` Claude specifically suggested a required end-to-end scenario reconstructed through `MemoryCoordinationTrace`; I agree. ------ # 31. Handling unreliable external review findings Some prior red-team comments were useful; at least one review contained confident but false claims. Claude’s latest review identified a “Gemini-style” review as substantially unreliable and warned not to route it to Claude Code because it fabricated architecture-stop findings, incorrectly claimed slice-mapping violations, and recommended restoring retired enum values that ABC superseded. ## Patch instruction Add to Conflict / Disagreement Register: ```text External review reliability note: - Do not restore the retired 11-value AssertionCandidateDisposition enum. - Do not act on claims that DOC80 slice mapping violates E1/E2, E3/E4, or E7/E8 unless verified against DOC80_Skeletal_Target_Baseline.md. - Do not treat all formatted red-team output as reliable; every claimed file fact must be checked against the actual artifact. ``` Add process rule: ```text Any red-team finding labeled architect_stop must include exact file/path/section evidence before being added to the Architect Decision Queue. ``` ------ # 32. Specific Stage 5R patch list for Claude Code Give Claude Code the following high-priority patch list. ## Stage 5R blockers — must complete before Stage 6 charters ```text 1. Add DOC87 — Organization and Membership Plane. - Update family count from 7 to 8. - Move MemoryMembershipEdge out of DOC84 into DOC87. - Move TopicLens / Library / Project membership semantics into DOC87. - Keep TopicCollectionDirective in DOC83. - Keep UI controls in DOC86. - Keep delivery consumption in DOC84. 2. Fix Owner Map one-owner rule. - Add ownership dimensions. - Remove compound schema_owner rows. - Add owner-map lints. 3. Fix import graph cycle. - Delete DOC86 → DOC81 schema import. - Add DOC81 → DOC86 policy/disclosure flow. - Add DOC86 → EC command flow. - Add EC → DOC81 re-evaluation flow. - Re-prove acyclicity. 4. Rescope DOC85. - DOC85 owns memory-learning architecture. - DOC85 consumes BDSM where real. - Legacy DOC8 is lineage/capability-mining unless reconciled. - Add DOC8/BDSM Actual Capability Reconciliation requirement for E9. 5. Consolidate Assertion lifecycle under DOC82. - DOC83 emits candidates; DOC82 owns disposition/resolution/dedupe/lifecycle/merge/split/unmerge/warrant. 6. Add NonAssertionExtractionOutcome under DOC83. - Do not restore retired 11-value AssertionCandidateDisposition. 7. Add proof-spine enforcement lints. - MemoryFlowCertificate / ContextPacketProof / RenderSafetyProof must be enforced, not merely named. 8. Remove process vocab from runtime core. - DispositionMove and LedgerInvalidationState out of DOC80 runtime product spec. 9. Add external dependency pinning. - Pin DOC72/DOC73/DOC24/DOC25/DOC11/DOC1/DOC3/DOC15/DOC20/DOC23/KDA/PropA/EC/BDSM/DOC8 legacy/DOC9. 10. Add DOC9 parked/future boundary. 11. Tighten Retired Names. - Fix total count. - Add Corpus-as-user-facing-Library retired row. - Narrow Premise alias to lineage/supersession only. 12. Add WorkSession disposition. 13. Demote CognitiveDiff to derived ResumeCard projection unless Will later approves canonical CognitiveDiff. 14. Add SemanticProjection narrow definition and projection lints. 15. Add CU reconciliation gate and VersionedClaim lineage-table requirement. 16. Add family-version-coherence rule. 17. Add family-wide compute-budget contract. 18. Add workflow-proof stories and required end-to-end round-trip scenario. ``` ## Fold-ins to relevant charters, but name now in Stage 5R ```text 19. DOC86 Round D UI checklist. 20. SearchAffordance ownership and policy/preflight direction. 21. NullResultMemory invalidation through source/materialization/access generation. 22. Warrant-degradation-trigger registry split. 23. DOC15 import seam check for DOC84/DOC85/DOC86. 24. DOC26 citation verification. 25. DynamicHeaderLedger finalizer wording with DOC24/KDA. 26. PriorDeliveryLedger policy-generation restamp rule. 27. DAMS owner cleanup: no “DAMS V5” as owner column; DOC84 owns DAMS substrate section. 28. EffectiveMemoryPolicy per-action/per-destination schema_owner DOC81. 29. SafeLabelPolicy owner cleanup. 30. ContextAssemblyTrace / MemoryCoordinationTrace distinction. ``` ------ # 33. Recommended Stage 5R review prompt After Claude Code patches Stage 5R, send a short regression review prompt: ```text Review the Stage 5R patch to DOC80 Skeletal Target Baseline, Import Graph, Owner Map, Retired Names, and any updated ADQ / lint sections. Questions: 1. Does DOC87 cleanly solve organization/membership placement without becoming a second graph, policy system, or UI spec? 2. Does the Owner Map now have exactly one schema_owner per schema and clear non-schema owner dimensions? 3. Is the import graph acyclic, especially after removing DOC86 → DOC81? 4. Is DOC85 properly rescoped as the substantive memory-learning architecture instead of a DOC8 shell? 5. Does the DOC8/BDSM Actual Capability Reconciliation requirement land in E9? 6. Is Assertion lifecycle consolidated under DOC82 and extraction routing kept under DOC83? 7. Are proof-spine lints sufficient to make MemoryFlowCertificate / ContextPacketProof / RenderSafetyProof non-phantom? 8. Are retired names, DOC9 boundary, WorkSession, CognitiveDiff, CU reconciliation, VersionedClaim lineage, dependency pinning, family-version coherence, and compute budget handled? 9. Can Stage 6 slice charters proceed? ``` ------ # 34. Final audited disposition I agree with Claude’s latest comments on the big points: ```text - Contract/implementation split is load-bearing and must be formalized. - Proof spine needs enforcement lints. - Learning write-back is under-specified. - End-to-end hot-path budget needs a family-wide owner. - DOC85 needs a structural rationale, not a historical one. - Family-version coherence should be added now. - An end-to-end round-trip golden scenario should be required. - External dependencies should be pinned. ``` I modify Claude’s recommendation in two places: ```text 1. Membership/organization should become DOC87, not be forced into DOC82 or DOC86. 2. DOC85 should not merely strengthen its rationale; it should be rescoped as the substantive memory-learning architecture because DOC8 is partly phantom. ``` I reject or do not adopt the following: ```text - Do not restore the old 11-value AssertionCandidateDisposition enum. - Do not let DOC8 remain the assumed complete learning computation owner. - Do not let DOC84 own durable membership. - Do not let DOC86 import schemas upward into DOC81. - Do not let process-only flattening vocabulary live in runtime DOC80 core. - Do not create DOC87 as a broad second graph; keep it narrow to organization/membership. ``` ## Final status ```text Stage 5: not ready for Stage 6 charters as-is. Stage 5R patch required. Architecture remains sound. DOC80 family should become DOC80–DOC87. DOC85 learning rebuild must be addressed now at skeleton level. DOC8 full rebuild happens in E9, but Stage 5R must stop treating DOC8 as real/complete. ``` After Stage 5R passes, proceed to Stage 6 slice charters. # ChatGPT 2: # DOC80 Stage 5 Skeletal Target Baseline — Unified Red-Team Review and Stage 5R Patch Directive ## Executive disposition The Stage 5 skeletal DOC80 architecture is **directionally sound and worth preserving**, but it is **not yet clean enough to approve for Stage 6 slice charters**. The correct next move is a targeted **Stage 5R patch**, not a redesign from scratch. The seven-member DOC80 family is a strong backbone: DOC80 core/contracts; DOC81 scope/policy; DOC82 canonical knowledge + source/evidence; DOC83 extraction + temporal/working state; DOC84 delivery + prompt/proof; DOC85 learning; DOC86 UI/Inspector/Search. The structure correctly separates truth, source, route, policy, delivery, rendering, learning, and UI — the central goal of the flattening process. The Stage 5 prompt also correctly frames this as a skeletal architecture review governed by plan §18, not a full slice/spec review. However, the skeleton currently has several structural defects that should be fixed before charters: 1. Organization/membership has no clean owner. 2. The Owner Map violates its own one-owner-per-schema rule. 3. The Import Graph has a wrong-direction DOC86 → DOC81 edge. 4. DOC80 core contains flattening-process vocabulary that should not become runtime product vocabulary. 5. DOC85 is too dependent on DOC8/BDSM if DOC8 remains a phantom or incomplete owner. 6. Non-Assertion extraction pathways risk being lost after the 11→7 `AssertionCandidateDisposition` cleanup. 7. External owner dependencies need revision/content-hash pinning. 8. Retired-name lints need semantic tightening around bare `Claim` and source-bound `ConsolidatedUnderstanding`. There is **no D-SEED-level contradiction**. DOC80-as-family and DOC80-as-real-owner-doc remain viable. But Stage 5R is mandatory before Stage 6. ------ ## Scope of this review This unified review consolidates: - the required Stage 5 red-team prompt response; - the prior findings on the skeletal baseline, owner map, import graph, and retired-name table; - the deeper architectural review; - Claude’s response and its reliability triage of other reviews; - the final patch instructions that Claude Code should execute. Primary artifacts reviewed: - `DOC80_Skeletal_Target_Baseline.md`; - `DOC80_Import_Graph.md`; - `DOC80_Owner_Map.md`; - `DOC80_Retired_Names.md`; - the Stage 5 red-team prompt; - Claude’s response / synthesis. ------ # Part I — Findings by red-team prompt category ## A. Family member list findings ### [A1] [CONFIRMED] Seven members is defensible and should be preserved unless ADQ-220 changes organization/membership ownership. The current seven-member structure is coherent: ```text DOC80 — Core / Contracts DOC81 — Scope + Policy DOC82 — Canonical Knowledge + Source / Evidence DOC83 — Extraction Spine + Temporal / Working-State DOC84 — Runtime Delivery + Prompt / Proof DOC85 — Learning Integration DOC86 — UI / Inspector / Search ``` This is superior to a single mega-spec and better than a loose set of scattered addenda. It makes the memory system reviewable and owner-bounded. **Recommended action:** Keep the seven-member structure as the default. Do not redraw the family-member map during Stage 5R except as required by the organization/membership decision. ### [A1] [CONFIRMED] DOC83 is coherent as Extraction + Temporal / Working-State. DOC83 combines E5 and E6. That is acceptable because extraction feeds working-state structures: IssueFrames, IssueFrameUpdates, RecentActivityRollup consumption, IncidentObservation, FrictionEvent, FrictionPattern, and NullResultMemory. **Recommended action:** Keep E5/E6 together. ### [A1] [CONFIRMED] DOC85 should remain separate from DOC84. Learning must consume proof, not own delivery. DOC85 should not be merged into DOC84. Delivery/proof and learning are distinct owner boundaries. **Recommended action:** Keep DOC85 separate, but rescope it if DOC8 is incomplete or phantom. ### [A1] [CONFIRMED] DOC86 should remain separate from DOC84. UI/Inspector/Search is about user-visible controls, command closure, disclosure, and safe visibility. It should not be merged into runtime prompt assembly. **Recommended action:** Keep DOC86 separate from DOC84. ### [A2] [CONFIRMED] Lockstep pairs are correctly preserved. The skeleton maps: ```text E1/E2 → DOC81 E3/E4 → DOC82 E7/E8 → DOC84 ``` That is correct. Any review claiming the lockstep pairs are mis-mapped should be disregarded unless it cites different file content. The skeletal baseline explicitly maps these lockstep pairs correctly. **Recommended action:** Do not redraw these mappings. ### [A3] [GAP] DOC80 core is mostly right, but it contains flattening-process vocabulary that should not become runtime product vocabulary. DOC80 core should own shared runtime contracts and registries, such as: ```text ReasonCode registry ContextProductKind registry PromptShellRegistry MemoryCoordinationTrace ContextPacketProof RenderSafetyProof MemoryFlowCertificate cross-family namespace rules runtime policy/action/destination vocabularies ``` But the current skeleton places process/rebuild vocabularies in DOC80 core, including items like: ```text DispositionMove SourceStatus NormativeWeight CapabilityStatus CapabilityTier LedgerInvalidationState ``` Some or all of those belong to the flattening plan / execution ledger / migration appendix, not the runtime Memory Control Plane. **Recommended action:** Move `DispositionMove` and `LedgerInvalidationState` out of runtime DOC80 core. Review `SourceStatus`, `NormativeWeight`, `CapabilityStatus`, and `CapabilityTier` one by one. Keep only those that are genuinely runtime memory properties. Put process-only vocabulary in a migration/lineage appendix or leave it in the flattening artifacts. ------ ## B. Per-schema ownership handoff findings ### [B1] [BUG] Owner Map violates its own one-owner rule. `DOC80_Owner_Map.md` defines `owns` as “defines the schema; one and only one owner per schema,” with separate roles for consumes, stores, and executes. But several rows use compound owners or mix contract/implementation/producer/storage responsibilities in one row. Affected rows include at least: ```text EffectiveMemoryPolicy MemoryContextPlan ContextProduct RenderSafetyProof AssertionRelationEdge SearchAffordance contamination_risk RecentActivityRollup CascadingSourceInvalidation WorkEpisode SafeLabelPolicy PromptShellLearningContract False-suppression sampling TopicRiskClass ``` **Recommended action:** Split compound rows into single-owner rows using role-specific suffixes: ```text *Contract *RuntimeState *ProducerEvent *ConsumerView *StoragePayload *ExecutionResult ``` Examples: ```text EffectiveMemoryPolicyContract — DOC80 or DOC81 EffectivePolicyMeetModel — DOC81 EffectivePolicyEvaluationExecution — EC MemoryContextPlanContract — DOC80 MemoryContextPlanRuntimeAssembly — DOC84 / DOC24 seam SearchAffordanceSurfaceState — DOC86 SearchAffordancePreflightResult — EC / DOC81 / DOC84 SearchAffordanceExecutionMode — DOC86 surface contract RecentActivityRollupGeneration — DOC73 RecentActivityRollupConsumptionContract — DOC83 RecentActivityRollupDeliveryProduct — DOC84 RecentActivityRollupSurface — DOC86 ``` After Stage 5R, “one schema, one owner” should hold with zero exceptions. ### [B2] [CONFIRMED] Assertion → DOC82 is clean if the three-way split is explicit. The handoff is architecturally correct: ```text DOC82 owns Assertion-family schemas and identity semantics. DOC72 stores graph payload and retains graph topology. EC executes durable writes. ``` This does not break DOC72’s role as knowledge graph owner because DOC72 retains graph topology and storage semantics; DOC82 defines the memory-control Assertion contract. **Recommended action:** Keep the handoff, but add a `GraphMutationContract` to make the DOC82 → EC → DOC72 path explicit. ### [B2] [SUGGESTION] Add `GraphMutationContract`. The system needs a contract so DOC82’s schema semantics and DOC72’s graph storage cannot drift. **Recommended action:** ```text DOC80 core owns GraphMutationContract / GraphMutationEnvelope as a cross-family handoff contract. DOC82 compiles Assertion / Evidence / merge / split / unmerge changes into GraphMutationContract payloads. EC executes all durable writes. DOC72 stores graph payload. ``` Do **not** remove EC from graph mutation. EC remains the sole durable writer. ### [B2] [CONFIRMED WITH CAUTION] ConsolidatedUnderstanding stays DOC73-owned. ADQ-219’s conditional wrapper approach is correct: ```text DOC73 owns ConsolidatedUnderstanding semantics. DOC82 consumes CU directly if DOC73 semantics match source-bound synthesis. If they diverge, DOC82 uses SourceBoundSynthesisProjection / SourceBoundSynthesisRef. ``` The wrapper must not become a second CU truth abstraction. **Recommended action:** Keep the wrapper as conditional. E3/E4 must reconcile DOC73 CU semantics before final CU/source-evidence language. Divergence beyond clean projection should trigger architect review. ### [B2] [CONFIRMED] ContextProduct and MemoryContextPlan belong in DOC80 core as registry/contract, not implementation. The decision is correct: ```text DOC80 core owns ContextProductKind registry. DOC80 core owns MemoryContextPlanContract. DOC24 owns packet assembly mechanics. DOC84 owns runtime delivery/assembly integration. ``` **Recommended action:** Rename ambiguous rows to distinguish registry/contract from assembly/runtime. ### [B3] [GAP] Directives and Procedures are not protected enough. The old Concept Model’s 11-value `AssertionCandidateDisposition` included pathways for directive candidates and procedure candidates. The retired-name table correctly identifies those values as no longer part of the canonical AssertionCandidateDisposition enum, but the capabilities must survive elsewhere. **Recommended action:** Add a non-Assertion extraction pathway in DOC83: ```text NonAssertionExtractionOutcome DirectiveCandidate ProcedureCandidate CUComponentCandidate EvaluationOnlyExtractionOutput TaskOutputExtractionOutput ``` Principle: ```text Not every extracted memory object is an AssertionCandidate. ``` Routing: ```text DirectiveCandidate → DOC1 / directive memory / DOC72 as appropriate ProcedureCandidate → DOC3 / DOC72 procedural memory seam CUComponentCandidate → DOC73 CU source-bound synthesis path EvaluationOnlyExtractionOutput → DOC23 / evaluation namespace TaskOutputExtractionOutput → DOC23 task-output namespace ``` ### [B3] [GAP] Library / Corpus / SourceCollection / CorpusIndex are under-placed. ADQ-202 resolved that Library is user-visible, while Corpus / SourceCollection / CorpusIndex are internal ingestion/source-processing structures behind Libraries. The skeleton does not yet give them a clean landing. **Recommended action:** Add explicit placement: ```text DOC82: - SourceCollectionRef - CorpusIndexRef - LibrarySourceBinding - source/evidence contract for Library/corpus sources DOC83: - LibraryCorpusExtractionRoute - TopicCollectionDirective → Library/corpus binding - extraction outputs through AssertionCandidate or NonAssertionExtractionOutcome DOC84: - Library Notice - Library Source Slice - Library-backed SearchAffordance product DOC86 or DOC87: - Library surface - Library membership - Project-Library binding indicator ``` This prevents Library/corpus from becoming a hidden truth store. ### [B3] [GAP] `VersionedClaim` needs a concrete mapping obligation. The Owner Map says `VersionedClaim` maps by lineage to AssertionVariant. That is acceptable as a direction, but not enough for linting. **Recommended action:** E3/E4 must produce a `VersionedClaim → AssertionVariant` mapping table or fixture. ------ ## C. Import graph findings ### [C1] [BUG] Plan §18 “no local redefinition” proof is not yet satisfied because Owner Map rows still have joint owners. The Import Graph claims no local redefinition and no dual-running families, but the Owner Map’s compound-owner rows undermine this proof. **Recommended action:** Patch Owner Map first, then re-run the import-graph proof. ### [C1] [CONFIRMED] Required target-freeze files are path-resolvable. The Import Graph reports all seven target-package files as path-resolvable and no missing target-freeze files. **Recommended action:** No change, but re-check after Stage 5R. ### [C2] [BUG] DOC86 → DOC81 import direction is wrong. The Import Graph says there are no upward imports, but its lateral table includes `DOC86 → DOC81` for UI surface stamps / policy restamp panel. That is directionally wrong. Policy should feed UI. UI should command EC. EC should re-evaluate policy. **Recommended action:** Replace with: ```text DOC81 → DOC86: - PolicyStamp - EffectiveMemoryPolicy reference - disclosure_class - restamp_eligibility - safe_label_constraints DOC86 → EC: - restamp command - user confirmation - UI action command EC → DOC81 / PropA: - policy re-evaluation - new PolicyStamp ``` The DOC86 → EC and EC → DOC81 flows are external execution flows, not intra-family imports. ### [C2] [SUGGESTION] Add missing organization/directive/library import paths. Add explicit lateral paths for: ```text DOC82 → DOC83: - Directive / Procedure reference contracts - source-support requirements DOC83 → DOC84: - Directive Block candidate - Procedure Block candidate - Library Source Slice candidate Organization owner → DOC84: - MemoryMembershipEdge / TopicLens / Library membership consumed for delivery ``` The “organization owner” depends on ADQ-220. ------ ## D. Owner boundaries findings ### [D1] [CONFIRMED] Major external boundaries are mostly preserved. The skeleton correctly says DOC80 does not own: ```text DOC23 task graph execution DOC20 general UI implementation DOC11/OpenClaw final runtime truth DOC3 skill lifecycle DOC25 SourceArtifact / ArtifactSegment / parse quality DOC24 packet assembly mechanics KDA deterministic rendering DOC8/BDSM computation, if real EC durable writes PropA policy rule input DOC1 Write Gate DOC15 CIL ``` The owner-boundary framing is directionally right. ### [D2] [BUG] DOC26 appears without enough basis. The Owner Map lists DOC26 as an external owner for UnifiedWorkspaceLibrary / Project Mode Control Surface. If DOC26 is not in Source Freeze and OP-A, this is premature. **Recommended action:** Either: ```text Keep DOC26 only if: - SourceFreeze row exists; - OP-A row exists; - it is marked active or aspirational external owner. ``` or remove DOC26 from the Stage 5 skeleton and route Project/Library UI seams through DOC20/Q + DOC86 until DOC26 is formally introduced. ### [D2] [GAP] External dependency pinning is missing. DOC80 imports from many moving external docs: DOC72, DOC73, DOC25, DOC24, KDA, DOC11, DOC8/BDSM, EC, PropA, DOC20, DOC23, DOC1, DOC3, DOC15, and possibly DOC26. The Owner Map treats them as stable, but they are moving targets. **Recommended action:** Add `ExternalDependencyRecord` rows: ```ts type ExternalDependencyRecord = { owner_doc: string; imported_contracts: string[]; source_freeze_ref: string; repo_path: string; content_hash: string; header_version?: string; dependency_status: | "pinned_for_doc80_stage5" | "moving_external" | "unresolved"; amendment_required?: string; }; ``` Use Source Freeze record IDs and content hashes, not just prose version labels. ------ ## E. Retired names findings ### [E1] [GAP] Retired-name table is useful but should be explicitly reconciled to Supersession Matrix rows. The retired-name table has 22 entries and is a navigable index drawn from the Supersession Matrix. It should not be assumed exhaustive until linted. **Recommended action:** Add Stage 6/9 check: ```text Every Supersession Matrix row with disposition: - retire_as_superseded - split_into_multiple_targets - semantic_compression - merge_into_target - replace_* must either: 1. appear in DOC80_Retired_Names.md; or 2. have a documented "not a retired-name case" reason. ``` ### [E2] [BUG] Bare `Claim` alias treatment is too loose. The retired-name table treats bare/generic `Claim` as retired but allows namespaced contexts. That should be tightened. Namespaced claims are not aliases for bare `Claim`; they are retained namespaced types. **Recommended action:** ```text Claim (bare/generic): legacy_alias_allowed = no. LegalClaim / EvaluationClaim / ClaimExtractorOutput: retained namespaced types, not aliases for bare Claim. ``` ### [E2] [BUG] `ConsolidatedUnderstanding` retired-name row is too broad. The retired concept is not `ConsolidatedUnderstanding` itself. DOC73 still owns valid source-bound CU semantics. The retired concept is CU-as-reusable-truth. **Recommended action:** ```text Retired name/concept: ConsolidatedUnderstanding-as-reusable-truth Lint fires when: CU is used as canonical reusable fact, warrant, or source-independent truth without AssertionCandidate → Assertion path. Lint does not fire when: DOC73 source-bound CU semantics are referenced or consumed properly. ``` ### [E3] [BUG] 11→7 enum cleanup is correct, but removed capabilities must survive elsewhere. Do **not** restore old values to `AssertionCandidateDisposition`. ABC’s 7-value enum remains canonical. But preserve these capabilities outside the enum: ```text retain_as_cu_component create_directive_candidate create_procedure_candidate evaluation_only ``` **Recommended action:** Add `NonAssertionExtractionOutcome` path as described above. ------ ## F. New canonical object family findings ### [F1] [CONFIRMED] No unauthorized new family requires D-SEED-level architect_stop. The new/restored objects generally trace to ABC, Round D, Supersession Matrix, or resolved ADQ decisions: ```text MemoryCoordinationTrace EpisodePolicyEpoch PolicyDisambiguationRequest PolicyCappedDAMSInput DynamicHeaderLedger ReviewQueueBatch TopicCollectionDirectiveBudget ProjectAutoLinkState NullResultMemory IncidentObservation / FrictionEvent / FrictionPattern AssertionMergeOperation family AssertionDedupeOutcome ExtractionRouteContext ExtractionRoutePolicyEnvelope SourceParseQualitySidecar CascadingSourceInvalidation RenderSafetyProof MemoryFlowCertificate ContextPacketProof ``` **Recommended action:** No D-SEED architect_stop. ### [F2] [GAP] Organization/membership object family is missing or under-placed. This is the most important open architectural issue. Current problem: ```text MemoryMembershipEdge appears in delivery/DOC84. TopicLens appears near UI/DOC86. TopicCollectionDirective appears in extraction/DOC83. Library/corpus has no clean skeletal owner. ``` That recreates overlap rather than flattening it. **Recommended action:** Add ADQ-220 before Stage 6. Suggested ADQ: ```text ADQ-220 — Where does organization/membership live? Question: Where should the organization/membership plane live, including MemoryMembershipEdge, TopicLens, Library surface, Project memory-scope membership, LibrarySourceBinding, and user-visible organization semantics? Options: A. Expand DOC86 into "Organization + UI / Inspector / Search." B. Add DOC87 "Organization & Membership Plane." C. Split ownership: - MemoryMembershipEdge → DOC82; - TopicLens / Library / Project user-facing surfaces → DOC86; - TopicCollectionDirective → DOC83. Recommendation: Architect decision required before Stage 6. Option B is architecturally cleanest. Option A is acceptable if Will wants to preserve seven members. Option C is workable but risks scattering the organization plane. ``` Tier: ```text architect_stop or blocking batch_for_architect blocks: all Stage 6 charters ``` Practical effect: do not approve Stage 6 charters until answered. ### [F2] [GAP] Memory object taxonomy table is missing. The skeleton would be much safer with a family-wide taxonomy table. **Recommended action:** Add a table: ```text object_kind truth_apt? source_bound? durable? owner storage policy_gate delivery_products learning_allowed? ui_inspector_surface? ``` Example rows: ```text Assertion CU EvidenceRecord TopicLens Library MemoryMembershipEdge RecentActivityRollup IssueFrame Directive Procedure NullResultMemory ContextProduct SearchAffordance ``` This will prevent future category errors. ### [F2] [GAP] Add `GraphMutationContract`. Covered above under B2, but it is also a new support object that should be named before Stage 6. ### [F2] [GAP] Add family-wide compute-budget contract. Local-first execution on one machine requires compute-budget coordination across extraction, delivery, and learning. Do **not** overload `EpisodePolicyEpoch` for compute scheduling. It is a policy-generation/versioning boundary, not a compute orchestrator. **Recommended action:** Add to DOC80 core: ```text MemoryComputeBudgetContract HotPathBudget BackgroundMemoryWorkBudget BackpressurePolicy YieldResumePolicy ``` Execution stays with EC/runtime. ### [F2] [GAP] Add pipeline suspension semantics. `PolicyDisambiguationRequest` replaces scalar `ask_user`, but a mid-pipeline user question needs park/resume semantics. **Recommended action:** Add to `MemoryCoordinationTrace`: ```text status = suspended_for_policy_disambiguation partial_assembly_ref suspension_reason safe_question_ref resume_policy stale_input_recheck_required ``` Flow: ```text trace suspended partial assembly cached / invalidatable compute yielded safe question emitted resume only after clearance source/policy/scope freshness rechecked ``` ------ ## G. Round D / ABC absorption findings ### [G1] [CONFIRMED] Round D UI surfaces are mostly absorbed into DOC86. DOC86 includes: ```text review queue / batched architect-decision card policy restamp panel blocked-item explanation panel privacy / policy banner Project auto-link quarantine chip cross-project search expansion chip task handoff scope-envelope confirmation Topic Notice / Library Notice / Search More affordances ``` That is correct. **Recommended action:** Preserve DOC86 UI surface coverage. ### [G1] [GAP] E10 fixtures should be seeded explicitly before Stage 6. **Recommended action:** Stage 6 E10 charter must include command-closure fixtures for: ```text SearchAffordance policy restamp blocked notices safe labels Project quarantine review queue task handoff cross-project search Topic Notice / Library Notice / Search More ``` ### [G2] [CONFIRMED] ABC seniority over Concept Model is mostly respected for `AssertionCandidateDisposition`. The skeleton uses ABC’s 7-value enum and retired-name handling identifies the Concept Model’s removed 11-value values. **Recommended action:** Do not restore the 11-value enum. Preserve removed capabilities through non-Assertion extraction outcomes. ### [G2] [SUGGESTION] Add explicit Stage 6 checks for ABC core mechanisms. Stage 6 charters should cite the senior ABC rule for: ```text EvidenceSupportEdge warrant ladder Assertion merge/split/unmerge AssertionCandidateDisposition AssertionDedupeOutcome extraction triage degradation triggers ``` ------ # Part II — Response to Claude’s own synthesis / external-review triage Claude’s synthesis is mostly right and should shape the Stage 5R patch. ## 1. Do not route the unreliable external review to Claude Code as a patch list. Claude correctly identified that one external review was substantially unreliable. Its false claims included: ```text incorrect lockstep mapping bug fabricated DOC81↔DOC84 / DOC81↔DOC83 cycles incorrect proposal to restore retired enum values false claim that Round D UI surfaces were missing ``` The valid underlying concern — preserving directive/procedure/evaluation/CU-component extraction capability — should be captured via `NonAssertionExtractionOutcome`, not by restoring retired enum values. **Instruction to Claude Code:** Ignore any review that says to redraw E1/E2, E3/E4, E7/E8 lockstep mapping or restore the 11-value `AssertionCandidateDisposition`. ## 2. Organization/membership requires explicit architect decision. Claude sharpened this issue correctly. My prior suggestion to expand DOC86 is acceptable but may still be a category error if DOC86 remains “UI.” Organization is not UI; UI renders organization. **Final recommendation:** Add ADQ-220. Architect decides among DOC87, expanded DOC86, or split ownership. I lean toward **DOC87 Organization & Membership Plane** if Will is comfortable adding an eighth member. If Will wants to preserve seven members, expand DOC86 to **Organization + UI / Inspector / Search** and make clear DOC20/Q remains implementation owner. ## 3. DOC85 must be rescoped if DOC8 is phantom. If DOC8 is not a real, settled, operative learning spec, DOC85 cannot merely “consume DOC8.” That would make DOC85 a shell around a phantom owner. **Final recommendation:** Add ADQ-221 if BDSM/DOC8 status is not fully settled. Suggested ADQ: ```text ADQ-221 — What is the status of BDSM / DOC8 for DOC85? Options: A. BDSM/DOC8 is real enough; DOC85 consumes BDSM computation and owns orchestration/seams. B. BDSM is real but DOC8 is partial; DOC85 owns memory-learning architecture and consumes BDSM as substrate. C. DOC8/BDSM are insufficient; DOC85 owns full learning requirements and marks substrate implementation as future completion. Recommendation: B, unless Will confirms DOC8 is operative and complete. ``` Baseline patch: ```text DOC85 owns memory-learning architecture: - learning targets; - proof-gated utility; - learning event schema; - write-back path; - friction / false-suppression learning; - prompt-shell learning contract; - policy/source/warrant bounds; - learning-derived trigger producers. DOC85 consumes BDSM only to the extent BDSM is real and specified. ``` ## 4. Versioning discipline should be added, but “main is always operative” should be softened. Claude’s point about stable filenames is correct. Product specs should not proliferate `_V5`, `_R0.2`, `_FINAL` suffixes. But this wording is too strong: ```text main branch is always operative ``` During this rebuild, `main` may contain drafts, target baselines, review packs, runbooks, and non-operative artifacts. **Recommended wording:** ```text DOC80-family product specs use stable filenames without version suffixes. Git history is the revision record. Document header status controls whether each file is draft, target baseline, operative, superseded, or lineage. Changes spanning multiple DOC80-family members should land in one coherent commit/PR. Process artifacts, runbooks, review packs, and historical snapshots may remain versioned. ``` ## 5. External dependency pinning should use Source Freeze references. Claude is right that DOC80 depends on moving external specs. The fix should use `SourceFreezeRecord` / content hash references, not just prose version labels. **Recommended action:** Add `ExternalDependencyRecord` as above. ------ # Part III — Stage 5R Patch Instructions for Claude Code Use the following as the direct instruction block for Claude Code. ```text Run Stage 5R before Stage 6 charters. Do not proceed to Stage 6 until the Stage 5R blockers below are patched and the Stage 5 artifacts are resubmitted. Guardrails: 1. Do NOT redraw the verified lockstep mapping: - E1/E2 → DOC81 - E3/E4 → DOC82 - E7/E8 → DOC84 2. Do NOT restore the old 11-value AssertionCandidateDisposition enum. ABC’s 7-value enum remains canonical. 3. Preserve removed Concept Model capabilities through NonAssertionExtractionOutcome or equivalent, not by restoring retired enum values. 4. Do NOT re-litigate D-SEED-1 through D-SEED-4. 5. Do NOT silently reopen resolved ADQs. If a resolved ADQ appears wrong after Stage 5 analysis, create a Conflict / Disagreement Register entry and an architect decision. ``` ## Stage 5R Blockers ### 1. Fix import graph direction and cycle. File: ```text Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md ``` Patch: ```text Delete DOC86 → DOC81 from the intra-family lateral import table. Add: DOC81 → DOC86: - PolicyStamp - EffectiveMemoryPolicy reference - disclosure_class - restamp_eligibility - safe_label_constraints Represent: DOC86 → EC: - restamp command - user confirmation - UI action command EC → DOC81 / PropA: - policy re-evaluation - new PolicyStamp ``` Re-check the directed graph is acyclic. ### 2. Add ADQ-220 for organization/membership ownership. File: ```text Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md ``` Add: ```text ADQ-220 — Where does the organization/membership plane live? Question: Where should MemoryMembershipEdge, TopicLens, Library surface, Project memory-scope membership, LibrarySourceBinding, and user-visible organization semantics live? Options: A. Expand DOC86 to "Organization + UI / Inspector / Search." B. Add DOC87 "Organization & Membership Plane." C. Split: - MemoryMembershipEdge → DOC82; - TopicLens / Library / Project user-facing surfaces → DOC86; - TopicCollectionDirective → DOC83. Recommended answer: Architect decision required. Option B is architecturally cleanest. Option A is acceptable if preserving seven members is preferred. Option C is workable but risks scattering organization semantics. Tier: architect_stop or blocking batch_for_architect. Blocks: All Stage 6 charters. ``` Pending Will’s decision, move `MemoryMembershipEdge` out of DOC84’s delivery section or mark it as unresolved pending ADQ-220. ### 3. Fix Owner Map one-owner violations. File: ```text Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md ``` Patch all compound-owner rows. Use separate names and roles: ```text *Contract *RuntimeState *ProducerEvent *ConsumerView *StoragePayload *ExecutionResult ``` Rows requiring review include: ```text EffectiveMemoryPolicy MemoryContextPlan ContextProduct RenderSafetyProof AssertionRelationEdge SearchAffordance contamination_risk RecentActivityRollup CascadingSourceInvalidation WorkEpisode SafeLabelPolicy PromptShellLearningContract False-suppression sampling TopicRiskClass ``` After patch, every schema row must have exactly one `owns` owner. ### 4. Move flattening-process vocabulary out of runtime DOC80 core. File: ```text Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md ``` Patch DOC80 core §4. Remove from runtime core: ```text DispositionMove LedgerInvalidationState ``` Review and either remove or justify as runtime: ```text SourceStatus NormativeWeight CapabilityStatus CapabilityTier ``` If retained, explain runtime use. Otherwise move to: ```text Appendix: Flattening / Supersession / Migration Controls ``` or leave in flattening-plan artifacts only. ### 5. Add DOC80-family versioning discipline. File: ```text DOC80_Skeletal_Target_Baseline.md ``` Add: ```text DOC80-family product specs use stable filenames without version suffixes. Git history is the revision record. Document header status controls whether each file is draft, target baseline, operative, superseded, or lineage. Changes spanning multiple DOC80-family members should land in one coherent commit/PR. Process artifacts, runbooks, review packs, and historical snapshots may remain versioned. ``` Do not say “main is always operative” without the header-status qualification. ### 6. Rescope DOC85 if DOC8 is phantom or incomplete. Files: ```text DOC80_Skeletal_Target_Baseline.md DOC80_Owner_Map.md Architect_Decision_Queue.md ``` Add ADQ-221 if needed: ```text ADQ-221 — What is the status of BDSM / DOC8 for DOC85? Options: A. BDSM/DOC8 is real enough; DOC85 consumes BDSM computation and owns orchestration/seams. B. BDSM is real but DOC8 is partial; DOC85 owns memory-learning architecture and consumes BDSM as substrate. C. DOC8/BDSM are insufficient; DOC85 owns full learning requirements and marks substrate implementation as future completion. Recommended: B unless Will confirms DOC8 is operative and complete. ``` Patch DOC85 to own memory-learning architecture, not just consume a phantom DOC8: ```text DOC85 owns: - learning targets; - final-prompt-proof-gated utility; - learning event schema; - write-back path; - friction / false-suppression learning; - prompt-shell learning contract; - policy/source/warrant bounds; - learning-derived trigger producers. ``` ### 7. Add external dependency pinning. Files: ```text DOC80_Owner_Map.md DOC80_Skeletal_Target_Baseline.md ``` Add `ExternalDependencyRecord` table: ```ts type ExternalDependencyRecord = { owner_doc: string; imported_contracts: string[]; source_freeze_ref: string; repo_path: string; content_hash: string; header_version?: string; dependency_status: | "pinned_for_doc80_stage5" | "moving_external" | "unresolved"; amendment_required?: string; }; ``` Every external owner import must cite Source Freeze ref, path, content hash, and amendment requirement where applicable. ### 8. Add non-Assertion extraction path. Files: ```text DOC80_Skeletal_Target_Baseline.md DOC80_Owner_Map.md DOC80_Retired_Names.md ``` Add to DOC83: ```text NonAssertionExtractionOutcome DirectiveCandidate ProcedureCandidate CUComponentCandidate EvaluationOnlyExtractionOutput TaskOutputExtractionOutput ``` Add routing: ```text directive → DOC1 / directive memory / DOC72 as appropriate procedure → DOC3 / DOC72 procedural memory seam CU-component → DOC73 CU support path evaluation → DOC23 / evaluation namespace task output → DOC23 task-output namespace ``` State: ```text Not every extracted memory object is an AssertionCandidate. ``` ### 9. Add Library / Corpus / SourceCollection / CorpusIndex placement. Patch skeleton and owner map: ```text DOC82: - SourceCollectionRef - CorpusIndexRef - LibrarySourceBinding - source/evidence contract for Library/corpus sources DOC83: - LibraryCorpusExtractionRoute - TopicCollectionDirective → Library/corpus binding - extraction outputs through AssertionCandidate or NonAssertionExtractionOutcome DOC84: - Library Notice - Library Source Slice - Library-backed SearchAffordance product Organization owner pending ADQ-220: - Library surface - Library membership - Project-Library binding indicator ``` ### 10. Patch retired-name semantics. File: ```text DOC80_Retired_Names.md ``` Patch bare Claim: ```text Claim (bare/generic): legacy_alias_allowed = no. LegalClaim / EvaluationClaim / ClaimExtractorOutput: retained namespaced types, not aliases. ``` Patch CU: ```text Retired concept: ConsolidatedUnderstanding-as-reusable-truth. Allowed: DOC73 source-bound ConsolidatedUnderstanding contexts. Lint fires only when CU is used as reusable truth/warrant/canonical fact without AssertionCandidate → Assertion path. ``` ### 11. Clarify or remove DOC26. Files: ```text DOC80_Owner_Map.md DOC80_Skeletal_Target_Baseline.md DOC80_Import_Graph.md ``` Either cite Source Freeze + OP-A basis for DOC26, or remove DOC26 from Stage 5 skeleton and route Project/Library UI seams through DOC20/Q + DOC86 or DOC87 pending ADQ-220. ### 12. Move warrant degradation trigger registry out of DOC85. Patch: ```text DOC80 core: - WarrantDegradationTriggerKind registry / namespace DOC82: - EffectiveWarrant / warrant evaluation semantics DOC81: - policy_change trigger input DOC25: - parse_quality_audit trigger producer DOC73: - supporting_CU_stale trigger producer DOC84 / DOC24: - session_bound_expiry / delivery-proof trigger producer DOC85: - learning-derived trigger producer only EC: - executes degradation transitions ``` ### 13. Split CascadingSourceInvalidation ownership. Patch: ```text DOC82: - support-edge validity - AssertionVariant support semantics DOC83: - invalidation event / lifecycle DOC81: - policy invalidation input only EC: - executes transition DOC84: - invalidates affected context products / proofs ``` Do not let DOC81 own all cascading source invalidation. ### 14. Clarify DAMS V5 owner status. Patch: ```text DAMS V5 is not a separate active owner doc after DOC80 adoption unless explicitly declared as a submember. DOC84 owns the DAMS substrate section. "DAMS V5" may remain as a lineage/substrate section name. ``` Remove “DAMS V5” from Owner Map owner columns unless it is formally declared as a submember. ### 15. Add pipeline suspension semantics to MemoryCoordinationTrace. Patch DOC80 core / MemoryCoordinationTrace: ```text status = suspended_for_policy_disambiguation partial_assembly_ref suspension_reason safe_question_ref resume_policy stale_input_recheck_required ``` Flow: ```text trace suspended partial assembly cached / invalidatable compute yielded safe question emitted resume only after clearance freshness/policy/scope rechecked ``` ### 16. Add family-wide compute-budget contract. Patch DOC80 core: ```text MemoryComputeBudgetContract HotPathBudget BackgroundMemoryWorkBudget BackpressurePolicy YieldResumePolicy ``` Do not overload `EpisodePolicyEpoch` for compute scheduling. ### 17. Add memory object taxonomy table. Add to skeleton: ```text object_kind truth_apt? source_bound? durable? owner storage policy_gate delivery_products learning_allowed? ui_inspector_surface? ``` Include at least: ```text Assertion AssertionVariant EvidenceRecord ConsolidatedUnderstanding TopicLens Library MemoryMembershipEdge RecentActivityRollup IssueFrame Directive Procedure NullResultMemory ContextProduct SearchAffordance MemoryFlowCertificate ``` ### 18. Add per-member MemoryCoordinationTrace obligations. Each member must state what it emits/consumes: ```text DOC81: - policy_generation_id - scope_resolution_trace_ref - effective_policy_ref - disclosure decision refs DOC82: - source/evidence support refs - assertion_resolution_ref - warrant evaluation refs DOC83: - extraction_context_plan_ref - candidate disposition refs - issue/recent/null-result lifecycle refs DOC84: - memory_context_plan_ref - context_product_decision_ref - render_safety_proof_ref - context_packet_proof_ref DOC85: - learning_event_ref - utility attribution ref - proof-gated outcome ref DOC86 / DOC87: - visible action ref - inspector visibility ref - membership/surface ref - user command / degraded no-op receipt ref ``` ### 19. Add per-member degraded / blocked states. Each DOC81–DOC86/DOC87 member must have a degraded/blocked state section. Examples: ```text DOC81: policy_unknown_fail_closed scope_uncertain_fail_closed disclosure_not_disclosable DOC82: source_unmaterialized parse_quality_unknown evidence_support_lost warrant_degraded DOC83: extraction_deferred_policy candidate_review_required null_result_stale issueframe_update_policy_blocked DOC84: context_product_blocked reference_only_render render_safety_failed final_prompt_proof_missing DOC85: learning_blocked_no_final_prompt_proof learning_audit_only utility_attribution_insufficient DOC86: visible_action_disabled safe_label_only inspector_hidden_by_policy degraded_noop_receipt ``` ### 20. Add doc-number collision check. Before Stage 6 charters: ```text Check REPO_FILE_MANIFEST for existing DOC80–DOC86 / DOC87 assignments. If any number is already assigned outside this family, create architect decision. Otherwise reserve the numbers in the skeletal baseline. ``` ------ # Part IV — Stage 5R acceptance criteria Stage 5R passes only if: 1. Import graph is acyclic. 2. DOC86 → DOC81 edge is removed. 3. Owner Map has zero compound-owner schema rows. 4. Organization/membership owner is decided or explicitly blocking Stage 6. 5. DOC80 runtime core no longer contains process-only flattening vocabulary. 6. DOC85 no longer depends on phantom DOC8 as if it were settled. 7. External dependency table pins imported owner docs by Source Freeze ref and hash. 8. Non-Assertion extraction pathways are preserved outside `AssertionCandidateDisposition`. 9. Library/corpus/source-collection placement is explicit. 10. Retired-name semantics for bare Claim and CU-as-reusable-truth are patched. 11. DOC26 is justified or removed. 12. Warrant degradation, cascading source invalidation, and DAMS ownership are split correctly. 13. Memory object taxonomy table exists. 14. MemoryCoordinationTrace obligations are assigned per member. 15. Degraded/blocked states are seeded per member. 16. Stage 6 charter requirements are updated accordingly. ------ # Final overall assessment The DOC80 Stage 5 skeleton is **architecturally promising and fundamentally coherent**, but the Stage 5 gate has not fully done its job yet. The seven-member family should be preserved as the default; it correctly separates truth, source/evidence, extraction, scope/policy, delivery/proof, learning, and UI/control surfaces. There is no D-SEED contradiction and no need to restart the flattening architecture. But Stage 5R is necessary because the skeleton still has owner-boundary and category errors that would compound during slice drafting: - organization/membership is under-owned; - one-owner discipline is violated; - UI-to-policy import direction is wrong; - process vocabulary leaks into runtime core; - DOC85 may be a shell around phantom DOC8; - non-Assertion extraction capability could be lost; - external dependencies are not pinned; - retired-name lints need semantic refinement. After the Stage 5R patch above, the skeleton should be strong enough to approve Stage 6 slice charters. # # CODEX: # DOC80 Stage 5 Skeletal Target Baseline — Red-Team Review Findings ## Summary The 7-member DOC80 family split is defensible, but the baseline needs patching before Stage 6 charters begin. The main defects are an ABC §7.8 enum mismatch, ambiguous multi-owner rows, missing retired-name coverage for SM-040, and several missing canonical object slots. ## A. Family member list findings - [A1] [CONFIRMED] Seven members is defensible. DOC83, DOC85, and DOC86 each have enough independent owner-boundary weight to remain separate. - affected family member(s) / section(s): DOC83, DOC85, DOC86 - recommended action: keep the 7-member structure. - [A2] [CONFIRMED] The required lockstep pairs are respected: E1/E2 → DOC81, E3/E4 → DOC82, E7/E8 → DOC84. - affected family member(s) / section(s): DOC81, DOC82, DOC84 - recommended action: no family split change. - [A3] [SUGGESTION] DOC80 core is mostly scoped correctly, especially ReasonCode registry, ContextProduct registry, and PromptShellRegistry. But the core/implementation split should be stated more sharply for EffectiveMemoryPolicy, MemoryContextPlan, and RenderSafetyProof so DOC80 core owns contracts, not downstream execution. - affected family member(s) / section(s): DOC80 core; DOC81; DOC84 - recommended action: clarify “contract owner” vs “implementation/execution owner” in the section map and Owner Map. ## B. Per-schema ownership handoff findings - [B1] [BUG] The Owner Map violates its own “one owner per schema” rule in rows that list multiple owners under `owner kind = owns`. - schema(s) affected: `AssertionRelationEdge`, `EffectiveMemoryPolicy`, `MemoryContextPlan`, `RenderSafetyProof`, `PromptShellLearningContract`, `SearchAffordance`, `TopicRiskClass` - recommended handoff change: split each row into canonical schema/contract owner vs storage/implementation/executor/consumer. - [B2] [BUG] `OPA-001` still says DOC72 emits the Assertion schema and identity contracts, which contradicts the Stage 5 handoff of Assertion-family schema ownership to DOC82. - schema(s) affected: `Assertion`, `AssertionVariant`, `AssertionCandidate`, `AssertionResolution`, `AssertionIdentitySignature` - recommended handoff change: amend OP-A wording so DOC82 owns the schema contract, DOC72 stores graph payload, and EC executes durable writes. - [B2] [CONFIRMED] `ConsolidatedUnderstanding → DOC73 retained` is architecturally clean if ADQ-219 is enforced: direct consumption if DOC73 matches, wrapper only if reconciliation requires it, and architect escalation if the wrapper becomes a redefinition. - schema(s) affected: `ConsolidatedUnderstanding`, `SourceBoundSynthesisProjection` - recommended handoff change: keep the handoff, but make the E3/E4 reconciliation gate non-optional. - [B3] [GAP] `WorkSession` is used by ABC/Round D material but is not explicitly handed off or imported in the skeletal baseline. `WorkEpisode + EpisodeSegment` is covered; `WorkSession` is not. - schema(s) affected: `WorkSession` - recommended handoff change: add an explicit owner/import row for `WorkSession`, or state that it is retired/renamed into `WorkEpisode`. - [B3] [CONFIRMED] The DOC24 delivery/proof anchors called out in the prompt are present in DOC84. - schema(s) affected: `PriorDeliveryLedger`, `CarryoverCapsule`, `DynamicHeaderLedger`, `MemoryContextPlanDeterminismInputs` - recommended handoff change: no handoff change. ## C. Import graph findings - [C1] [BUG] The import-graph proof is weakened by the multi-owner rows in the Owner Map. They create ambiguity around “no local redefinition” and “every cross-doc import has an owner.” - plan §18 condition affected: §4.1 and §4.4 - recommended action: normalize Owner Map rows to one canonical schema owner plus consumers/stores/executors. - [C1] [SUGGESTION] Retired names appear in canonical section-map/owner-map prose, e.g. `ScopeMembrane` and `ask_user`, outside clearly labeled lineage/supersession sections. - plan §18 condition affected: §4.3 - recommended action: move those references into lineage notes or explicitly allow “supersession annotation fields” as a lint-safe historical context. - [C1] [CONFIRMED] The seven required target-package files are path-resolvable locally. - plan §18 condition affected: §4.5 - recommended action: no availability patch. - [C2] [BUG] The lateral import graph lists `DOC86 → DOC81`, but the stated reason says UI consumes policy-plane data. That arrow is backwards if it is a schema import, and it risks implying a cycle. - plan §18 condition affected: intra-family import graph / no-cycle proof - recommended action: change to `DOC81 → DOC86` for policy/scope data consumed by UI, or model UI restamp as an EC command handoff rather than an import. ## D. Owner boundaries findings - [D1] [CONFIRMED] The skeleton does not wholesale absorb DOC23 task graph mechanics, DOC20 non-memory UI implementation, DOC11 runtime truth, DOC3 skill lifecycle, DOC9 self-repair, or implementation planning. - [D2] [SUGGESTION] Boundary preservation is mostly sound, but the Owner Map needs stricter wording to avoid implicit absorption through “contract + impl” joint ownership rows. ## E. Retired names findings - [E1] [BUG] SM-040 is missing from the retired-name table. The matrix splits `Library / Corpus / SourceCollection / CorpusIndex (intermixed)`, but there is no retired-name/lint row for that old intermixed usage. - [E2] [SUGGESTION] `Premise` as memory object has an expiry in the alias table, but the allowed historical context column reads broad/indefinite. Make the expiry visible in the row itself. - [E3] [BUG] The `AssertionCandidateDisposition` retired-name row and skeletal references do not match ABC R0.2 §7.8. ABC’s actual 7 values are `durable_eligible`, `durable_eligible_confirmation_required`, `session_scoped`, `ephemeral_reroute`, `candidate_only_pending_issueframe`, `review_queue`, and `reject_not_memory`; the baseline instead carries a different 7-value list and treats only four old values as discontinued. ## F. New canonical object families findings - [F1] [CONFIRMED] I did not find an unauthorized new canonical family. The new families are generally backed by the Supersession Matrix, ADQ decisions, ABC R0.2, or Round D R0.2. - [F2] [GAP] Several ABC/Round D canonical objects are missing or under-specified in the skeletal owner/section maps. Affected examples: `TopicLens`, `MemoryMembershipEdge` owner row, `WarrantEvaluationResult`, `WarrantConsequenceRegistry`, `DomainProfileWarrantPolicy` / domain-profile registry, `IngestionCostBudget`, `PromotionGateRecord`, `ConsideredItemLedger`, `PromptShellExposure`, and `WorkSession`. ## G. Round D / ABC absorption findings - [G1] [CONFIRMED] Round D UI / Inspector / SearchAffordance surfaces are substantially carried into DOC86 §4 and related sections. - [G2] [BUG] ABC R0.2 is not faithfully absorbed for `AssertionCandidateDisposition`; the skeletal baseline appears to rely on a superseded or intermediate enum rather than ABC §7.8’s actual senior enum. - [G2] [GAP] ABC §21 normalization objects are not fully represented in the skeletal baseline, especially warrant consequence/domain-profile/budget/promotion/considered-item structures. ## Overall assessment No `ARCHITECT_STOP` finding surfaced against D-SEED-1 or D-SEED-2, but the skeletal DOC80 architecture should be patched before Stage 6. The family split is sound; the blocking work is cleanup of schema ownership precision, ABC enum alignment, retired-name coverage, and missing canonical object slots.