Stage_5_Skeletal_DOC80_Review_Response.md
Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5_Skeletal_DOC80_Review_Response.md
# 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.