DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md
Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md
# DOC80 Stage 5R — Red-Team Reviews and Synthesis
**Scope:** Memory Control Plane flatten — DOC80 family (DOC80–DOC87), Stage 5R Skeletal Target Baseline.
**Contents:** Red-team reviews from three reviewers (Claude, ChatGPT, Codex) across the Stage 5 (round 1) and Stage 5R (round 2) prompts, followed by the architect-adjudicated synthesis.
**Operative section for Claude Code:** §4 (Synthesis) — specifically §4.4 (must-fix list), §4.5 (fold-ins), §4.6 (DOC88/retention/erasure landing), §4.7 (the one ADQ), and §4.10 (instructions for Claude Code).
---
## 1. Claude — Red-Team Reviews
### 1.1 Round 1 — Stage 5 Skeletal Target Baseline
#### DOC80 Stage 5 Skeletal Target Baseline — Red-Team Review Findings
##### Summary
The skeletal architecture is structurally sound and consistent with D-SEED-1/D-SEED-2 — no `ARCHITECT_STOP`. But two real BUGs (an apparent DOC82↔DOC83 import cycle the Stage 5R cycle-fix missed, and a mis-cited ABC §7.7/§7.8 enum-and-triage pair carried into the retired-name table) should be patched before Stage 6 charters consume the baseline.
##### A. Family member list findings
- **A1 [CONFIRMED]** The DOC87 addition (8th member, ADQ-220) is well-reasoned: membership is genuinely upstream of both DOC84 (delivery consumes it) and DOC86 (UI renders it), and is a cross-plane edge that does not belong inside DOC82. DOC85 (substantive, rescoped per Patch B6) and DOC86 (UI/Inspector/Search) are each substantial enough to stand alone. 8 is defensible.
- affected family member(s): DOC85, DOC86, DOC87
- recommended action: none
- **A1 [SUGGESTION]** DOC83 is the **only** member that fuses two **non-lockstep** slices (E5 Extraction + E6 Temporal/Working-State). Every other member is either a declared lockstep pair (DOC81=E1/E2, DOC82=E3/E4, DOC84=E7/E8) or a single standalone slice (DOC85=E9, DOC86=E10, DOC87=new slice). The family's own logic gave E9 and E10 their own members; by that logic E5 and E6 — also non-lockstep — would each merit one (→ 9 members). The §1.1 rationale ("Not lockstep, but pipeline-adjacent") is thin for an asymmetry this visible.
- affected family member(s): DOC83, §1.1 split rationale
- recommended action: either strengthen §1.1 to justify why pipeline-adjacency fuses E5+E6 when E9/E10 were not fused with their neighbors, or explicitly record DOC83 as a candidate future split if the E5 or E6 charter grows large. Not a re-slice request — G-1 forbids that at Stage 5R — just a rationale gap.
- **A3 [CONFIRMED]** ReasonCode registry (ADQ-310), ContextProduct registry (ADQ-203), PromptShellRegistry (ADQ-208) are correctly in DOC80 core. No domain-specific schema has leaked into core: MemoryCoordinationTrace, the proof spine, the warrant-degradation-trigger registry (cross-plane per ADQ-312's multi-owner producer list), and the domain-profile registry (ADQ-313) are all genuinely plane-less.
- affected section(s): §1.1, §2 DOC80 section map
- recommended action: none
- **A2 [CONFIRMED]** All three plan §12 lockstep pairs map 1:1 to a member; no lockstep pair was split.
##### B. Per-schema ownership handoff findings
- **B1 [CONFIRMED]** Every load-bearing schema in §4 has an explicit single owner. The B3-anchor sweep passes: WorkSession (DOC83, DR-005), EpisodeSegment (DOC83), PriorDeliveryLedger / CarryoverCapsule / DynamicHeaderLedger / MemoryContextPlanDeterminismInputs (all DOC84), RecentActivityRollup (split generation/consumption). DOC24 claims ownership of none of them — confirmed against the Owner Map §5.
- **B2 [GAP]** §3.3 states "ABC R0.2 is senior" but never reconciles that with the DOC82/DOC73 re-homing. ABC §2.1's owner table assigns the **Assertion/AssertionVariant schema to DOC72** and **EvidenceRecord/EvidenceSupportEdge to the DOC73/DAMS seam**; the baseline re-homes both to DOC82. This is authorized (D-SEED-2 exists precisely to stop schemas being "scattered across DOC72/DOC24/DOC73"), but the baseline never says it is overriding ABC §2.1's owner-table *placement*. A Stage 7 charter author reading §3.3's blanket "ABC senior" could treat ABC §2.1 as governing.
- schema(s) affected: Assertion family, EvidenceRecord/EvidenceSupportEdge; §3.3
- recommended handoff change: add an explicit note — "D-SEED-2 supersedes ABC §2.1's pre-flattening owner-table *placement*; ABC's identity/relation/warrant *semantics* are preserved." Scope the §3.3 seniority claim to semantics, not placement.
- **B2 [SUGGESTION]** The Assertion 3-way split (DOC82 schema / DOC72 storage / EC writes) is clean *per the §1.2 one-owner rule*, but the DOC72 amendment is the load-bearing risk and is currently only "at Stage 6 charter authoring."
- schema(s) affected: Assertion family; OPA-001, OPA-006
- recommended handoff change: make the DOC72 defer-amendment a hard pre-condition gate on the E3 charter, not just a tracked OP-A row, so DOC82 schema / DOC72 storage / EC writer cannot drift apart during drafting.
- **B2 [SUGGESTION]** The conditional `SourceBoundSynthesisProjection` wrapper (ADQ-219) is acceptably bounded — reconciliation is pinned to the E3/E4 charter and escalates to `architect_stop` if the wrapper cannot absorb divergence — but it has **no sunset**. If it activates, nothing forces DOC73 to later converge.
- schema(s) affected: SourceBoundSynthesisProjection, ConsolidatedUnderstanding
- recommended handoff change: if the wrapper activates, attach a convergence obligation (a dedicated OP-A row) requiring DOC73 to converge to the source-bound-synthesis contract or the architect to bless permanent divergence — so the shim cannot silently ossify.
- **B2 [GAP]** `MemoryContextPlan` contract is placed in DOC80 core (ADQ-211), but §1.2's core-eligibility enumeration is "registries, the proof spine, shared vocabulary, MemoryCoordinationTrace." `MemoryContextPlan` is none of those — it is a cross-cutting *contract*. The ContextProduct *registry* fits "registries"; the MemoryContextPlan contract does not. A lint built literally from §1.2 could flag it as wrongly-in-core.
- schema(s) affected: MemoryContextPlan; §1.2
- recommended handoff change: extend §1.2's core-eligibility list to explicitly name "cross-cutting contract whose implementation is owned downstream" so it is consistent with ADQ-203/ADQ-211 and lint-safe.
- **B3 [CONFIRMED — with note]** No load-bearing schema is missing from the table. `VersionedClaim` is genuinely unresolved (DR-003, PENDING, no SM row) — correctly tracked, but it means the import-graph §5.1/§5.2 proof cannot fully close for that name until DR-003 resolves.
##### C. Import graph findings
- **C2 [BUG]** The §2 lateral-import table lists **both** `DOC82 → DOC83` and `DOC83 → DOC82` as rows, with inconsistent from/to semantics (row 1 puts the schema *owner* in "from"; row 2 puts the *producer* in "from"). As written it reads as a DOC82↔DOC83 bidirectional pair — and with `DOC83→DOC87` + `DOC87→DOC82` also present, a potential DOC82→DOC83→DOC87→DOC82 triangle. §5.6's acyclicity proof addresses only the B1 DOC81/84/86 fix and never proves the DOC82/83 pair acyclic; G-3 asserts "the cycle" (singular) was the only one. This is the same *class* of error as the B1 cycle (an import-direction mistake), missed by the round-1 review.
- plan §18 condition affected: §4 acyclicity / §5.6
- recommended action: normalize the from/to column to one convention. Reclassify the `AssertionCandidateEmission` *data handoff* as an intra-family **control flow** (the file already has an "external control flows, not member imports" carve-out — extend it to intra-family), not a schema import. The genuine schema dependency is one-directional — DOC83 imports DOC82's contracts (including the DOC82-owned `AssertionCandidateEmission` schema); DOC82 receives instances but imports nothing from DOC83. Once normalized, the pair collapses to a single downward DOC83→DOC82 edge and the graph is acyclic.
- **C1 [CONFIRMED — with note]** §5.1–§5.5 hold as asserted, except §5.1 (no local redefinition) and §5.2 (no dual-running families) cannot fully close while `VersionedClaim` is PENDING (DR-003) and while `ExtractionOutputKind` / `ExtractionSidecarKind` / `ExtractionRoutePolicyEnvelope` are real ABC §7 types carried with provenance notes (F7) but no SM rows. Acceptable as a tracked deferral per plan §8, but it should be named as an open item against §5.1/§5.2 rather than shown as fully ✓.
- plan §18 condition affected: §4.1, §4.2
- recommended action: footnote §5.1/§5.2 with the VersionedClaim + Extraction-trio matrix-row gap.
##### D. Owner boundaries findings
- **D1 [CONFIRMED]** The plan §1.2 non-absorption list is preserved. DOC9 (self-repair) is explicitly disclaimed (F4). DOC86 owns memory-UI *contracts* (UserContextSurfacePlan, VisibleContextActionSpec) while DOC20 implements panels — a clean memory-UI-seam vs general-UI split, consistent with §1.2.
- **D2 [SUGGESTION]** §3.2's disclaimers hold and nothing is implicitly absorbed. One watch-item: "Library" is decomposed 4 ways — DOC87 (container), DOC25 (LibrarySourceBinding/CorpusIndex/SourceCollection), DOC82 (SourceEnvelope seam), DOC86+DOC20 (UI). That decomposition is authorized (SM-040), but the actual Corpus hierarchy is deferred to ADQ-202 at the E4 charter. Recommend flagging the Library decomposition as gated on ADQ-202 so the four owners do not fragment before E4 resolves it.
##### E. Retired names findings
- **E1 [CONFIRMED]** All 15 SM rows with retire/split/semantic_compression/merge disposition (SM-001/002/070/080/102; SM-004/010/014/040/071; SM-012/020/202; SM-021/060) appear in the 22-entry retired-name table. The table also correctly covers name-changing `absorb_as_target_rule` rows (SM-003/005/006/081/105/106/108). No retire/split/compression/merge row is missing.
- **E2 [SUGGESTION]** `Premise (as memory object)` is **not** indefinite — §3 gates it on the cross-doc rename pass. But the §1 row's `allowed_historical_context` column ("DOC72/DOC73 legacy citation contexts") shows no expiry; the expiry lives only in §3. A lint author reading §1 alone would treat it as permanent.
- recommended action: cross-reference §3's expiry condition inside the §1 row (or add an `alias_expiry` column value).
- **E3 [BUG]** See G2. The four "discontinued" values and SM-202's stated "ABC §7.8 7-value enum" do not match the actual ABC R0.2 §7.8 `AssertionCandidateDisposition`. The retired-name table's enum row inherits the wrong values.
##### F. New canonical object families findings
- **F1 [CONFIRMED]** Every family in the prompt's F-list traces to an SM row or ADQ — `SourceBoundSynthesisProjection`/ADQ-219, `PolicyDisambiguationRequest`/SM-102, `PolicyCappedDAMSInput`/SM-107, `EpisodePolicyEpoch`/SM-101, `MemoryCoordinationTrace`/SM-100, `ReviewQueueBatch`/SM-210, `DynamicHeaderLedger`/SM-209, `TopicCollectionDirectiveBudget`/SM-211, `ProjectAutoLinkState`/SM-212, `NullResultMemory`/SM-205, friction trio/SM-206, `AssertionMergeOperation`/SM-204, `AssertionDedupeOutcome`/ABC §7.8, `SourceParseQualitySidecar`/SM-207, `CascadingSourceInvalidation`/SM-208, proof spine/SM-050+SM-051. No unauthorized NEW family → **no `ARCHITECT_STOP`**.
- **F1 [GAP]** `NonAssertionExtractionOutcome` and `AssertionCandidateEmission` are NEW Stage-5R objects (B9/F-3) with no SM row and — unlike SM-040, which got Conflict Register DR-002 when added the same way — no DR entry. `ExtractionOutputKind`/`ExtractionSidecarKind`/`ExtractionRoutePolicyEnvelope` are real ABC §7 types also lacking individual SM rows (provenance-noted via F7 only).
- recommended action: log Conflict Register DR entries for `NonAssertionExtractionOutcome` + `AssertionCandidateEmission` (matrix-row addition deferred, mirroring the SM-040/DR-002 pattern). Also worth clarifying: `NonAssertionExtractionOutcome` conceptually overlaps ABC §7.5's `ExtractionOutputKind` (which already enumerates `directive_candidate`/`procedure_candidate`/`consolidated_understanding`); the baseline should state whether it wraps, specializes, or is orthogonal to that enum.
- **F2 [GAP]** `WarrantEvaluationResult` (ABC §3.9, a distinct type alongside `WarrantEvaluationInput`) is not named in DOC82 §1.8, which lists `UseWarrant + WarrantEvaluationInput + EffectiveWarrant` but not the result type.
- recommended action: add `WarrantEvaluationResult` to DOC82 §1.8 so Stage 7 does not miss it.
##### G. Round D / ABC absorption findings
- **G1 [CONFIRMED]** All seven Round D §19.7 required UI surfaces (review queue/batch card, policy restamp panel, blocked-item explanation panel, privacy banner, Project auto-link quarantine chip, cross-project search expansion chip, task handoff scope-envelope confirmation) are present in DOC86 §4, plus Topic/Library/Search-More notices; the why-included/why-excluded/why-not-remembered Inspector lands in DOC86 §2 backed by MemoryCoordinationTrace. Nothing from Round D was dropped or mis-assigned.
- **G2 [BUG]** DOC83 §1.6 and `DOC80_Owner_Map.md` §4 both describe ABC §7.7 as a **"Six-step extraction triage."** ABC R0.2 §7.7 ("Normative classification decision tree") is a **Step 0 through Step 11 — 12-step — tree**. This mis-describes a frozen senior input and will mislead a Stage 7 charter author. (Possible benign reading: a 6-step *substantive* subset, Steps 2–7 — if so it must be named explicitly.)
- recommended action: correct to "the 12-step (Steps 0–11) ABC §7.7 decision tree," or name the intended subset.
- **G2 [BUG]** SM-202 and `DOC80_Retired_Names.md` anchor the `AssertionCandidateDisposition` supersession to value names that **do not appear in ABC R0.2 §7.8**. The actual ABC §7.8 enum is `{ durable_eligible, durable_eligible_confirmation_required, session_scoped, ephemeral_reroute, candidate_only_pending_issueframe, review_queue, reject_not_memory }`. SM-202's parenthetical "ABC §7.8 7-value enum: discard_not_memory / retain_ephemeral_observation / retain_session_note / record_friction_event / update_issue_frame / retain_as_evidence_only / create_or_merge_assertion" matches neither ABC §7.8 nor a recognizable subset — it reads as a paraphrase of the §7.7 decision-tree *outcomes*, conflating two distinct ABC constructs. Consequently the Owner Map's **DR-006 "verified at Stage 5R: matrix SM-202 row reflects ABC §7.8 7-value enum" is incorrect.** The skeletal G-2 guardrail correctly *says* "use the 7-value ABC §7.8 enum" but never enumerates it, so the wrong values propagate through the retired-name table unchallenged.
- recommended action: per the review boundary (no matrix edits here), route the matrix fix to the Conflict Register — **re-open DR-006** — and reconcile SM-202 to the actual ABC §7.8 enum. The retired-name table (a Stage 5 primary target) must be corrected directly: its E3 row currently lists discontinued values that cannot be verified against ABC §7.8. The architectural *intent* (7-value disposition + separate `AssertionDedupeOutcome`, non-assertion routing via `ExtractionOutputKind`) is consistent with ABC — this is a transcription error, not an architecture reversal, so not `ARCHITECT_STOP`.
##### Overall assessment
The skeletal DOC80 architecture is sound enough for Stage 6 charters to begin — the 8-member family, owner boundaries, the one-owner rule, and the import-graph *intent* are coherent and consistent with D-SEED-1/D-SEED-2, and there are **no `ARCHITECT_STOP` findings**. However, two BUGs should be patched in a Stage 5R-style pass *before* Stage 6 charters consume the artifacts, because charters will directly read these: (1) **C2** — the import graph's DOC82↔DOC83 from/to notation produces an apparent cycle that §5.6 never disproves; fix by normalizing notation and reclassifying the `AssertionCandidateEmission` handoff as an intra-family control flow; and (2) **E3/G2** — SM-202, `DOC80_Retired_Names.md`, and the DOC83/Owner-Map "six-step §7.7" description mis-cite ABC R0.2; reconcile to the actual ABC §7.8 enum and §7.7 step count and re-open DR-006. The remaining items (B2 §1.2/§3.3 reconciliation, VersionedClaim DR-003, SourceBoundSynthesisProjection sunset, NonAssertionExtractionOutcome/AssertionCandidateEmission DR entries, WarrantEvaluationResult, DOC83 split rationale) are GAPs/SUGGESTIONs that can be folded into the same patch or carried as charter-time obligations without re-slicing.
### 1.2 Round 2 — Stage 5R Skeletal Target Baseline
#### DOC80 Stage 5R Skeletal Target Baseline — Round-2 Red-Team Review Findings
##### Summary
The patched Stage 5R architecture is structurally close to ready and raises **no `ARCHITECT_STOP`** — the 8-member decomposition is sound, the lockstep mapping holds, and DOC87 was the right addition. But it is **not clean**: round 2 surfaces one systematic high-leverage defect plus two import-graph issues that must be fixed before Stage 6, because Stage 6 charters consume exactly the artifacts that carry the errors.
The highest-leverage finding: **the OP-A Candidate Disposition was *augmented* at Stage 5R but never *reconciled*.** Rows OPA-025–030 were added for DOC87, but the pre-existing rows OPA-001/004/005/011/012 still describe pre-flattening ownership (DOC72 "emits Assertion schema," DOC73 "emits EvidenceRecord/EvidenceSupportEdge," DAMS "emits classification," DOC8 as a runtime learning participant) — every one of those now contradicts a Stage 5R decision (B9, B6, ADQ-221). OP-A rows *are* the cross-doc amendment obligations Stage 6 hands to DOC72/DOC73/etc.; if they are stale, the amendments will be written against the wrong architecture. Secondarily: the B3 one-owner patch is only partially applied (four Owner Map rows still carry two docs in the `owns` cell), and the import graph has a phantom DOC82↔DOC83 cycle plus a genuine DOC83→DOC87 backward dependency that the slice ordering inverts. The biggest *missing* concern is an owner for memory **retention / erasure / legal-hold** — nothing in the 8 members owns deletion, and it sits in real tension with the append-only proof/audit model.
##### 3.A — What did this miss?
- **A-1 [GAP — architect-tier]** No family member owns memory **retention / erasure / right-to-be-forgotten / legal-hold** lifecycle. The architecture is rich in *creation* and *invalidation* (CascadingSourceInvalidation, supersession, `AssertionLifecycleState` incl. `retired`, NullResultMemory) but `retired` ≠ *erased*, and the whole durability model is append-only (JSONL audit log, `preserve_audit_history: true` on split/unmerge, "auto-archive = suppress, not delete"). There is no path for "purge everything derived from this source/client/privileged document."
- what's missing: an owner + named contract for hard erasure, retention windows, legal hold, and how erasure reconciles with the append-only audit/proof spine.
- why it matters: load-bearing for a litigation-support deployment (privilege purge, client-data deletion, retention policy); retrofitting erasure at Stage 7 means re-opening every slice because it is cross-plane (DOC82 Assertions, DOC87 memberships, DOC84 delivery history, DOC85 learning signals).
- recommended action: new ADQ — does the family need a 9th member (retention/erasure) or an explicit DOC81 cross-plane erasure-propagation contract? Decide before Stage 6.
- **A-1 [GAP]** Replay-based recovery is *implied* by the JSONL audit log but never named or owned. No member states "the audit log is replay-complete" or owns "rebuild canonical state from audit log."
- what's missing: a named recovery/replay contract and the invariant that every durable-state mutation is in the audit log.
- why it matters: corruption/disaster recovery is undefined; Stage 7 cannot fixture it.
- recommended action: name a recovery contract in DOC80 core (or the DOC81/EC seam); state the replay-completeness invariant.
- **A-5 [GAP]** The consistency / concurrency / ordering model is never stated. "EC is sole writer" gives write *serialization* but the architecture never states the *model that produces* (single-node, single-writer, SQLite-WAL) nor the ordering rule for **concurrent submissions** from multiple chat windows, scheduled runs, and background jobs all hitting EC at once.
- what's missing: an explicit consistency/ordering statement as a named assumption.
- why it matters: B-2 race conditions below are unanalyzable without it; Stage 7 drafters will each assume a different model.
- recommended action: state the single-node/single-writer consistency model and concurrent-submission ordering rule in DOC80 core §1 (scope/non-goals).
- **A-1 [GAP — light]** Aggregate memory-plane observability is unowned. MemoryCoordinationTrace is per-request; the Inspector is per-object. Nothing owns corpus-level health (extraction-funnel throughput, contested-Assertion rate, warrant distribution, review-queue depth trends).
- recommended action: name where memory-plane aggregate observability lives (DOC86 Inspector backend or DOC80 core).
- **A-4 [GAP]** Embedding-model migration is an unhandled edge case. `AssertionDedupeOutcome.dedupe_basis = semantic_equivalence` and `AssertionIdentitySignature` depend on embeddings; if the embedding model migrates, those results change, but no member names that dependency or an invalidation path.
- recommended action: name the embedding-model dependency and its invalidation effect (likely a DOC82↔DOC72 seam note + ExternalDependencyRecord).
- **A-2 [GAP]** Scenario "user revokes a Library after extracts were already injected into past sessions": CascadingSourceInvalidation handles the *warrant* side, and PriorDeliveryLedger / PolicyStampInvalidation handle past *deliveries* — but there is no named invalidation path from CascadingSourceInvalidation into an already-propagated **CarryoverCapsule** (DOC84). A revoked-source extract carried into a new chat is unaddressed.
- recommended action: name the CascadingSourceInvalidation → CarryoverCapsule invalidation seam.
##### 3.B — Where will this break?
- **B-1 [GAP]** The single most fragile dependency is the **DOC80-family ↔ EC seam**. EC is the sole durable writer, scope executor, membership writer, and learning executor — 4 of 8 members (DOC81/83/85/87) route durable effects through it — and EC is itself a known-stale doc. The skeletal baseline pins EC via `ExternalDependencyRecord` but treats it as a stable owner.
- failure mode: any change to EC's write/enforce contract cascades to 4 members; EC's *current* contract is in flux.
- affected artifacts: Import Graph §3; DOC80 §13 ExternalDependencyRecord.
- recommended action: set EC's `ExternalDependencyRecord.dependency_status = partial` (as BDSM was), and make the EC-seam contract a named hard obligation, not an assumed-stable import.
- **B-2 [BUG-risk]** `AssertionDedupeOutcome` is computed at DOC82 resolution time but executed at EC write time, with no stated re-validation. Two concurrent `AssertionCandidateEmission`s for the same proposition (e.g. two chat windows extracting the same fact) can each compute `dedupe_basis = no_match` against the pre-write snapshot, then EC serially writes both → duplicate Assertions. EC's write serialization does not prevent a check-then-act race when the *check* ran upstream.
- failure mode: duplicate canonical Assertions under concurrent extraction.
- affected artifacts: Owner Map §1 (`AssertionDedupeOutcome`); DOC82 §1.4; Import Graph DOC82↔DOC83.
- recommended action: state the rule — EC re-validates the dedupe basis against current state inside its serialized write (compare-and-swap), or `AssertionDedupeOutcome` carries a `dedupe_basis_generation_id` optimistic-concurrency token.
- **B-2 [GAP]** `EpisodePolicyEpoch` pins *delivery* in-flight to a policy generation, but the **extraction pipeline's** policy-generation boundary is unclear. ABC §7.7 Step 0 gates extraction once; nothing states whether a candidate that started extraction under policy gen N and resolves under gen N+1 is re-gated.
- recommended action: name an extraction-side policy-generation boundary (or state explicitly that Step 0's gate is re-evaluated at resolution).
- **B-3 [CONFIRMED]** The four named invariants the prompt calls out *do* have named enforcement: `can_orient_only` (ADQ-405 fixture + OPA-024), removed/blocked-edge-never-injected (`membership.removed_or_blocked_edge_used_for_injection` + `fixture.membership.removed_edge_appears_nowhere`), no-learning-without-proof (`proof.learning_signal_without_context_packet_proof`), DAMS eligibility ceiling (`dams.eligibility_ceiling_violation`). One light gap: the foundational "EC is sole durable writer" invariant has *proof-certificate* lints but no named lint that a **non-EC actor performed a durable write** (only `membership.edge_confirmed_without_EC_write` exists, membership-specific).
- recommended action: add a general `proof.durable_write_by_non_ec_actor`-style lint name.
- **B-4 [BUG]** The B3 one-owner patch is **partially applied**. Four Owner Map rows still literally carry two docs in the `owner`/`owns` cell with a parenthetical disclaimer: `LibrarySourceBinding` ("DOC82 + DOC25"), `SafeLabelPolicy + approved vocabulary` ("DOC86 (policy) + PropA/EC (registry)"), `RenderBundle + PromptTextPackage` ("DOC24 + KDA"), `false-suppression sampling` ("DOC85 + DOC8"). §1.2's own rule says `owner_map.compound_schema_owner` "fires on any row that names two owners under `owns`" — so the Owner Map as written fails its own lint on these four rows. The fix was applied in prose, not structurally.
- failure mode: the compound-owner lint fires on the canonical Owner Map; Stage 7 drafters see two owners.
- affected artifacts: `DOC80_Owner_Map.md` §2, §5, §6.
- recommended action: actually split each into two single-owner rows (the B3 prescribed fix), e.g. `LibrarySourceBinding` → DOC25 owns; the DOC82 seam is a separate `consumes` relationship, not an `owns` entry.
- **B-5 [BUG]** New import-graph issue: the §2 lateral-import table lists **both** `DOC82 → DOC83` and `DOC83 → DOC82`, with inconsistent from/to column semantics (one row puts the schema *owner* in "from", the other puts the *producer* in "from"). Both rows actually describe the single dependency *DOC83 imports DOC82*; rendered as two rows they read as a DOC82↔DOC83 cycle, and §5.6's acyclicity proof addresses only the B1 DOC81/84/86 fix — it never proves the DOC82/83 pair. G-3 asserts "no other cycle"; this is a different one. (Per §2 this is in scope — a *new* cycle, not the settled one.)
- failure mode: phantom cycle; §5.6 proof incomplete; Stage 6 consumes an unprovable graph.
- affected artifacts: `DOC80_Import_Graph.md` §2, §5.6.
- recommended action: normalize from/to to one convention; collapse to a single DOC83→DOC82 edge; reclassify the `AssertionCandidateEmission` *data handoff* as an intra-family control flow (extend the existing "external control flows, not member imports" carve-out); re-state §5.6 to cover the pair.
- **B-5 [BUG]** Genuine backward dependency: DOC83's `TopicCollectionDirective` references DOC87's Topic identity (`DOC83 → DOC87`, §2), but ADQ-220 inserts the DOC87 *slice* "between E6 and E7" — i.e., **after** DOC83 (E5/E6). DOC83 imports a member sliced later. §5.6 claims "No member imports upward." (This flags the *slice-position consequence*, not DOC87's existence — that is settled.)
- failure mode: Stage 7 drafts DOC83 before DOC87's Topic object exists.
- affected artifacts: Import Graph §2, §5.6; plan §12 slice order; DOC83 §4 / DOC87 §2.1.
- recommended action: either re-sequence so DOC87's Topic-identity is declared before E5/E6, or declare DOC83↔DOC87 a co-drafted pair (see E-3).
- **B-6 [GAP]** No data-scale model. DOC80 §15 is a hot-path *latency* budget, not a *scale* story. The two DOC80-family-owned operations that blow up at 10⁹ Assertions are `CascadingSourceInvalidation` fan-out (a widely-cited source revocation) and conflict-set projection over `AssertionRelationEdge` (ABC §3.4 derives conflict sets as projections). Neither has a stated bound.
- recommended action: fold-in — name a scale assumption / bound for CascadingSourceInvalidation fan-out and conflict-set projection.
##### 3.C — Round-1 patch verification
- **B1 — partially landed.** The narrow `DOC86→DOC81`→`DOC81→DOC86` fix landed, but B1's *goal* (acyclic import graph) did not: the DOC82↔DOC83 phantom cycle and the DOC83→DOC87 backward edge remain (see B-5).
- **B3 — partially landed.** Four Owner Map rows still have two docs under `owns` (see B-4); the split was done in prose, not structurally.
- **B9 — did not propagate.** DOC82 lifecycle ownership, `AssertionCandidateEmission`, `NonAssertionExtractionOutcome`, and the compute-budget envelope all landed in the *skeletal artifacts* — but B9's re-homing was never propagated to the **OP-A Candidate Disposition**: OPA-001 still says "DOC72 emits Assertion schema," OPA-004 "DOC73 emits EvidenceRecord/EvidenceSupportEdge," OPA-005 "DAMS V5 emits classification," and OPA-011/012 treat DOC8 as a runtime learning participant — all contradicting B9 / B6 / ADQ-221. Stage 5R *augmented* OP-A (added OPA-025–030) but never *reconciled* OPA-001–024. **This is the highest-leverage must-fix.**
- **DR-006 — verification itself is wrong.** DR-006 records SM-202 as "verified consistent" with ABC §7.8, but it verified only the *structure* (7-value + separate `AssertionDedupeOutcome`, correct source-ref citation). The actual ABC R0.2 §7.8 enum is `{ durable_eligible, durable_eligible_confirmation_required, session_scoped, ephemeral_reroute, candidate_only_pending_issueframe, review_queue, reject_not_memory }`. SM-202's parenthetical lists a *different* seven (`discard_not_memory / retain_ephemeral_observation / retain_session_note / record_friction_event / update_issue_frame / retain_as_evidence_only / create_or_merge_assertion`) — a paraphrase of the §7.7 decision-tree *outcomes*, not the §7.8 disposition enum. Per §5 the Matrix is not edited here — **re-open DR-006** in the Conflict Register. This does not contradict §2's settled item ("it is the 7-value ABC §7.8 enum" — true); it flags that the artifacts misquote *which* seven.
##### 3.D — Better ideas / improvements
- **D-1 [BETTER_IDEA]** The split-by-plane axis is correct (planes are stable and owner-aligned; split-by-lifecycle or split-by-consumer would be worse). But one plane is missing: **retention/erasure**.
- what the architecture currently does: no member owns deletion/retention/legal-hold (see A-1).
- what would be better: a 9th member (retention/erasure lifecycle) or an explicit DOC81 cross-plane erasure-propagation contract — same justification that produced DOC87 (cross-plane, fits no existing member, in tension with the audit model).
- cost/risk: low to decide now (a naming/ownership decision); very high to retrofit at Stage 7 (erasure touches every member).
- **D-2 [BETTER_IDEA]** Borrow two established patterns.
- what the architecture currently does: temporal state is spread across `AssertionTemporalProfile` + `AssertionStalenessState` + `AssertionLifecycleState`; the durable layer is implicitly event-sourced (JSONL audit log + replay) but never named as such.
- what would be better: (a) explicitly model **bitemporal** (valid-time vs transaction-time) axes on Assertion — litigation needs "what did I know about X *as of* date D," and time-window warrant degradation needs it; (b) explicitly frame the EC durable layer as **event-sourced** — audit log = event store, SQLite current views = projections — which gives recovery (A-1), replay, and temporal queries a principled home for free.
- cost/risk: naming-level now; expensive to reframe after Stage 7 schema bodies exist.
- **D-3 [SUGGESTION]** Two invariants are stated as prose + lints but could be expressed more powerfully.
- what the architecture currently does: warrant degradation is prose ladder + triggers; membership injection rules are prose + lints.
- what would be better: express warrant transitions as a **closed labeled state machine** — every transition (promotion or degradation) has a named trigger; *no spontaneous transitions* — which is checkable as a structural property. Express **injection-eligibility as a total function** over `MembershipLifecycleState` (`injection_eligible: State → bool`, `{removed, blocked} → false`) rather than a prose rule plus one lint.
- cost/risk: cheap now, clarifies Stage 7 drafting.
- **D-4 [SUGGESTION]** Two confusingly-named schemas.
- `NonAssertionExtractionOutcome` — named by negation, and overlaps confusingly with ABC §7.5's `ExtractionOutputKind` (which already enumerates the non-assertion kinds). A Stage 7 drafter will not know the difference. Rename to a positive term and state its relationship to `ExtractionOutputKind`.
- `SourceBoundSynthesisProjection` — "projection" is already used for `SemanticProjection`, `ProjectionInvalidationPolicy`, and conflict-set projections (derived views). This object is a *conditional compatibility wrapper*, not a derived view. Rename (e.g. `...Adapter`/`...Wrapper`).
- cost/risk: trivial now, mildly painful after charters cite the names.
- **D-5 [SUGGESTION — light]** Owner Map single-owner placements are mostly sound. One watch-item: `TopicRiskClass` is placed at DOC81 (policy) but gates `TopicActivationState` transitions owned by DOC87 — a risk classification of a Topic is arguably an organization (DOC87) concern feeding policy. Defensible either way; flag for the E1/DOC87 charters. `DynamicHeaderLedger` (DOC84 per DR-004) is a second watch-item already logged — DR-004 notes ADQ-305 names no owner and leaves a Stage 6 escalation path.
##### 3.E — What will Stage 6 / Stage 7 discover?
- **E-1 [GAP]** The **DOC85 (E9 / learning) charter** is the hardest and cannot be *finalized*. ADQ-221 is resolved at the headline level but explicitly defers "specific BDSM surfaces DOC85 may consume" to the DOC85/E9 charter — and BDSM v6.5 is itself being revised "alongside" DOC85. Chicken-and-egg: the charter waits on BDSM surfaces; BDSM revision waits on the new memory architecture.
- which charter hits the wall: DOC85 / E9.
- recommended pre-emptive fix: explicitly make the DOC85 charter two-phase — charter the architecture / write-back / proof-gating now; defer the BDSM-consumption section — and sequence it last among the slice charters.
- **E-3 [GAP]** The freshly-inserted **DOC87 slice** has live dependencies in *both* directions — backward to DOC83 (Topic identity, see B-5) and forward to DOC84 (membership consumption) — but is in no declared lockstep pair. Stage 7 will hit dependency inversion.
- which slice hits the wall: DOC87, and DOC83's `TopicCollectionDirective`.
- recommended pre-emptive fix: declare DOC83↔DOC87 a co-drafted pair (at least for the Topic-identity contract), or re-sequence the Topic-identity portion before E5/E6.
- **E-2 [GAP]** The DOC82↔DOC72 storage seam ("DOC72 stores graph payload") is not named as a Stage-6 deliverable. The Stage 7 DOC82 draft and the DOC72 defer-amendment both need the storage contract; OPA-001 — which should carry it — is stale (see 3.C).
- which slice hits the wall: E3/E4 (DOC82) and the DOC72 amendment.
- recommended pre-emptive fix: name the DOC82-schema ↔ DOC72-storage contract as an explicit Stage 6 obligation and fix OPA-001 to describe it correctly.
- **E-4 [BUG — light]** The DOC80 §18 end-to-end golden scenario states the phase order as "extraction → membership → policy → delivery → proof → learning." Policy is listed *after* extraction, but policy gates extraction (ABC §7.7 Step 0). A fixture author following §18 verbatim will build the round-trip in the wrong order.
- which slice hits the wall: the §18 golden-scenario fixture (Stage 6).
- recommended pre-emptive fix: correct §18's canonical phase order so policy precedes extraction.
##### 3.F — *(removed — ADQ-221 resolved between rounds)*
##### Overall round-2 assessment
- [ ] Stage 5R clean — Stage 6 may begin
- [x] **Stage 5R needs another patch round (Stage 5R')** — must-fix items:
1. **OP-A reconciliation pass** — re-check every OPA-001–024 row against the 8-member Owner Map; rewrite OPA-001 (Assertion schema → DOC82, not "DOC72 emits"), OPA-004 (Evidence* → DOC82), OPA-005 (classification → DOC83 spine, DAMS is substrate-only per SM-020), OPA-011/OPA-012 (learning participant is DOC85, not DOC8 per ADQ-221/B6). Highest leverage — Stage 6 charters consume these as cross-doc obligations.
2. **Split the four surviving compound-owner Owner Map rows** (`LibrarySourceBinding`, `SafeLabelPolicy + approved vocabulary`, `RenderBundle + PromptTextPackage`, `false-suppression sampling`) into single-owner rows — the B3 patch is otherwise only applied in prose.
3. **Fix the import graph** — normalize the §2 from/to convention so the DOC82↔DOC83 phantom cycle collapses to one edge; resolve the DOC83→DOC87 backward dependency (re-sequence or co-draft); re-state §5.6 to cover both.
4. **Re-open DR-006** in the Conflict Register — SM-202's enumerated seven values do not match ABC R0.2 §7.8; the matrix fix routes there (not edited in Stage 5R).
- [ ] ARCHITECT_STOP — none. The 8-member decomposition, owner boundaries, and import-graph *intent* are consistent with D-SEED-1 and D-SEED-2; everything above is patchable without re-slicing.
Items A-1 (retention/erasure), D-1, D-2, B-1, B-6, E-1 are architecturally significant but can be handled as a new ADQ + fold-ins rather than blocking Stage 6 — except note that the retention/erasure ownership question (A-1/D-1) is cheap now and very expensive later, so it is worth resolving in the same Stage 5R' pass.
---
## 2. ChatGPT — Consolidated Red-Team Response and Stage 5R2 Patch Instructions
*This is ChatGPT's full consolidated document — it spans the round-2 review, follow-up discussion on networking and task-sharing, retention/erasure analysis (including the DOC88 proposal that was subsequently declined), and ChatGPT's own recommended Stage 5R2 patch instructions. The architect-adjudicated landing — what is actually authorized for Stage 5R2 — is in §4 below.*
**Document purpose:** Consolidated response to the Stage 5 and Stage 5R red-team prompts, including follow-up discussion, Claude review/adjudication, networking/task-sharing clarifications, retention/erasure/legal-hold analysis, and final recommended Stage 5R2 patch instructions.
**Intended recipient:** Claude Code, operating inside the `wbrody/Elnor-Specs` repository.
**Status:** Red-team response and patch instruction. This is **not** an operative DOC80 spec and **not** a replacement for the governing flattening plan. It should be used to create a Stage 5R2 skeletal architecture cleanup patch.
**Primary artifacts under review:**
- `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`
- `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`
- `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md`
- `Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md`
- `Memory Rebuild Docs/Flattening/Execution Ledger/OP-A Disposition/OP_A_Candidate_Disposition.md`
- `Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md`
- `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md`
---
#### 0. Executive disposition
**No `ARCHITECT_STOP`.** The DOC80 family architecture is directionally correct and should not be redrawn from scratch. The move from 7 members to 8 members by adding **DOC87 — Organization and Membership Plane** is correct and should stand.
**But Stage 5R is not clean enough for Stage 6 slice charters.** It needs a **Stage 5R2 cleanup / stabilization patch** before slice charters begin.
The most important final position is:
> Stage 5R2 should be a cleanup and stabilization patch, not a second design round. It should fix stale obligations, ownership hygiene, import-graph semantics, DOC8/DOC85 language, DOC83/DOC87 ordering, SM-202/DR-006, EC dependency assumptions, and the two architect-tier ADQs for retention/erasure and network/sharing. It should not draft full networking schemas, full DOC88 schemas, or new broad product layers.
The basic target family should remain:
```text
DOC80 — Core / contracts / proof / registries
DOC81 — Scope and policy
DOC82 — Canonical knowledge / source / evidence
DOC83 — Extraction / temporal / working state
DOC84 — Delivery / prompt / proof / DAMS
DOC85 — Learning architecture and proof-gated adaptation
DOC86 — UI / Inspector / Search
DOC87 — Organization / membership
```
**Stage 6 may begin only after Stage 5R2 closes the must-fix items below and passes a short regression review.**
---
#### 1. What is settled and should not be re-litigated
##### 1.1 DOC80 is a real spec family
The D-SEED decisions remain sound:
```text
D-SEED-1: DOC80 is a spec family, not a single document.
D-SEED-2: DOC80 is a real owner doc family in the ELNOR hierarchy.
```
Do not collapse DOC80 back into a single monolith. The memory system is inherently cross-cutting and needs bounded member specs.
##### 1.2 DOC87 is the right addition
I originally hesitated to add DOC87 because additional docs increase import complexity. After deeper review and Will's product direction, I now agree DOC87 is correct.
Membership / organization is not truth, evidence, extraction, delivery, UI, policy, or learning. It is the durable organization layer 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 Episode.
This object is user-pinned, suggested, rule-matched, source-derived, removed, blocked, stale, or candidate.
```
DOC87 should own this. DOC82 should own canonical knowledge/source/evidence. DOC86 should own user-facing surfaces. DOC84 should consume membership for delivery. DOC83 should create/propose membership candidates through extraction routes.
##### 1.3 DOC85 remains separate and must be substantive
DOC85 should not be folded into DOC84. Learning must remain downstream of final-prompt proof and must not become delivery mechanics.
However, DOC85 must not be a thin shell around phantom DOC8. It should own the **memory-learning architecture**. BDSM can be consumed as a partial, pinned substrate where real. Legacy DOC8 is capability-mining / lineage only unless expressly re-adopted.
##### 1.4 DOC86 remains separate
DOC86 should remain the UI / Inspector / SearchAffordance member. UI command closure, Inspector disclosure, safe labels, and SearchAffordance preflight deserve their own owner surface and should not be buried in DOC84 delivery.
##### 1.5 Do not restore the old 11-value `AssertionCandidateDisposition`
The retired 11-value Concept Model enum should stay retired. The removed values such as `retain_as_cu_component`, `create_directive_candidate`, `create_procedure_candidate`, and `evaluation_only` should be handled by `NonAssertionExtractionOutcome` and owner-specific routes, not by reviving the old assertion-disposition axis.
##### 1.6 DOC8 is not the current runtime learning owner
ADQ-221's direction should stand:
```text
BDSM = partial dependency / substrate where pinned and real.
DOC8 = capability-mining / lineage input only.
DOC85 = substantive memory-learning architecture owner.
```
Any lingering Owner Map row that says or implies `DOC8 computes`, `DOC8 executes`, or `DOC8 owns runtime learning` is stale and must be patched.
---
#### 2. Highest-level answer to the red-team prompts
##### 2.1 Does the structure unify and improve the memory system?
**Yes, at the ownership and conceptual-boundary level.** The architecture creates a real memory-control-plane family and separates the major concerns that were previously blurred:
```text
truth identity;
source support;
extraction route;
organization / membership;
scope / policy eligibility;
delivery product;
prompt rendering / proof;
learning;
UI / inspection.
```
That is the right unification. The goal is not to make every memory operation pass through fewer documents. Some cross-document seams are irreducible because EC writes, DOC72 stores graph payload, DOC24 assembles packets, KDA renders, DOC11 owns final runtime truth, DOC23 owns tasks, DOC25/DOC73 own source/corpus mechanics, and PropA/EC own policy execution.
The improvement is definitional and architectural:
```text
old state: memory concepts scattered across DOC72 / DOC73 / DOC24 / KDA / DOC8 / DOC15 / patches;
new state: memory-control-plane ownership is explicitly assigned and retired names are lintable.
```
##### 2.2 Is it coherent?
**Mostly.** The 8-member family is coherent. The remaining incoherence is not in the macro-family structure. It is in the artifacts that Stage 6 will consume:
```text
OP-A rows are stale.
Owner Map still has compound / non-doc owners.
Import Graph mixes schema imports with runtime and command flows.
DOC8 still appears as runtime learning owner in some rows.
DOC83 references DOC87 Topic identity before DOC87 is drafted.
SM-202 / DR-006 has enum-value mismatch.
VersionedClaim and WorkSession remain unresolved.
```
Those defects are patchable without re-slicing the family.
##### 2.3 Can it be improved?
Yes. The most important improvements are:
1. Mechanically clean all owner rows so `schema_owner` is singular and every split is a separate named artifact.
2. Split import graph edges into distinct edge kinds.
3. Treat EC as a partial/moving dependency with an explicit `ECSeamContract`.
4. Add DOC87 Topic identity stub before DOC83 needs it.
5. Reconcile OP-A now, not at Stage 6.
6. Open ADQs for retention/erasure/legal hold and network/sharing forward compatibility.
7. Keep networking and DOC88 from exploding Stage 5R2 into a second design round.
---
#### 3. Mandatory Stage 5R2 must-fix list
These items should be completed before approving Stage 6 slice charters.
##### 3.1 Reconcile OP-A against the new 8-member ownership model
This is the highest-leverage defect.
Stage 5R added new rows OPA-025–030 for DOC87 and the DOC83↔DOC82 handoff, but it did **not** reconcile OPA-001–024 against the new 8-member ownership model.
Fix at least these rows:
```text
OPA-001:
old / stale: DOC72 emits Assertion schema.
correct: DOC82 owns Assertion family schema/lifecycle; DOC72 stores graph payload; EC executes writes.
OPA-004:
old / stale: DOC73 emits EvidenceRecord / EvidenceSupportEdge.
correct: DOC82 owns EvidenceRecord / EvidenceSupportEdge; DOC73 owns CU/source-bound synthesis and may supply source-bound inputs.
OPA-005:
old / stale: DAMS emits classification.
correct: DOC83 owns extraction spine / classification route; DAMS is a DOC84 substrate, not owner.
OPA-011 and OPA-012:
old / stale: DOC8 is runtime learning participant.
correct: DOC85 owns memory-learning architecture; BDSM partial substrate where pinned/real; DOC8 capability-mining only.
```
Add a Stage 5R2 OP-A reconciliation section:
```text
OP-A Stage 5R2 reconciliation result:
- every OPA-001–024 row reviewed against 8-member Owner Map;
- stale owner references replaced;
- rows that remain valid marked confirmed;
- rows needing Stage 6 per-slice follow-up marked charter_gate;
- no OP-A row may contradict DOC80_Owner_Map.md.
```
Add lint / check:
```text
opa.row_contradicts_owner_map
opa.stale_doc8_runtime_learning_reference
opa.stale_dams_owner_reference
opa.stale_doc72_assertion_schema_reference
opa.stale_doc73_evidence_owner_reference
```
##### 3.2 Mechanically clean the Owner Map
The Owner Map states the one-owner rule correctly, but still contains rows that visually or actually violate it. Explanatory notes are not enough. The table must be mechanically clean so linting can work.
Patch rule:
```text
No owner cell may contain a plus sign, slash-combined owners, or a non-doc owner label.
If two docs seem to own one thing, split the row into separate named artifacts.
```
Fix these known rows:
###### LibrarySourceBinding
Current problem: owner cell appears as DOC82 + DOC25 or otherwise as a cross-doc owner.
Patch:
```text
LibrarySourceBinding
schema_owner: DOC25
consumers: DOC82, DOC87
LibrarySourceBindingConsumptionContract
schema_owner: DOC82
consumes: DOC25 LibrarySourceBinding
purpose: source-bound discipline through SourceEnvelope
LibraryAsOrganizationalContainer
schema_owner: DOC87
consumes: DOC25/DOC73/DOC82 source refs
purpose: Library as user-facing organizational/source collection
```
###### SafeLabelPolicy + approved vocabulary
Patch:
```text
SafeLabelDisclosurePolicy
schema_owner: DOC81
purpose: policy/disclosure meaning for safe labels
ApprovedSafeLabelVocabularyRegistry
schema_owner: PropA / EC, or DOC81 if that is the chosen policy registry owner
purpose: approved safe-label vocabulary; must not derive labels from protected content
SafeLabelRenderContract
schema_owner: DOC86
purpose: how safe labels appear in UI / Inspector / rendered notices
```
###### RenderBundle + PromptTextPackage
Patch:
```text
RenderBundle
schema_owner: KDA
PromptTextPackage
schema_owner: DOC24
DOC84RenderConsumptionContract
schema_owner: DOC84
consumes: RenderBundle and PromptTextPackage
purpose: DOC80-family delivery/proof integration
```
###### Procedural taxonomy + standing-procedure / skill / task
Patch:
```text
ProceduralTaxonomy
schema_owner: DOC72
SkillLifecycle / AppSkill lifecycle seams
schema_owner: DOC3
ProcedureExtractionRoute / ProcedureCandidateRoute
schema_owner: DOC83
consumes: DOC72 / DOC3 procedural contracts
```
###### False-suppression sampling
Patch:
```text
FalseSuppressionSampling
schema_owner: DOC85
consumes: DOC84 delivery/proof outcomes, DOC82 assertion outcomes, DOC81 policy partitions
legacy_DOC8: capability_mining_only
```
###### DAMS rows / contamination-risk rows
Do not use `DAMS V5` as an owner. DAMS is a substrate section inside DOC84.
Patch:
```text
DAMSAttenuator
AttenuatorContributor
ResolvedAttenuator
OmissionCostComputation
ContaminationRiskComputation
ContaminationRiskThresholdRule, if delivery-side
schema_owner: DOC84, unless the threshold rule is policy-owned by DOC81.
section: DAMS substrate.
```
If `contamination_risk threshold rule` is policy semantics:
```text
ContaminationRiskThresholdRule
schema_owner: DOC81
ContaminationRiskComputation
schema_owner: DOC84
```
Add lints:
```text
owner_map.owner_cell_contains_plus_sign
owner_map.non_doc_owner_label
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
```
##### 3.3 Split the Import Graph into edge kinds
The Import Graph currently mixes schema imports, runtime handoffs, command flows, and storage/execution flows. This creates phantom cycles such as DOC82↔DOC83 and makes the acyclicity proof fragile.
Patch `DOC80_Import_Graph.md` into four edge tables:
```text
1. schema_import
2. runtime_instance_flow
3. command_or_control_flow
4. storage_or_execution_flow
```
Each row should include:
```text
from
to
edge_kind
artifact_or_event
schema_owner_of_artifact
runtime_executor_if_any
cycle_allowed? no by default for schema_import
notes
```
Normalize DOC82/DOC83 as:
```text
schema_import:
DOC83 imports DOC82-owned AssertionCandidateEmission contract.
runtime_instance_flow:
DOC83 produces AssertionCandidateEmission instances for DOC82/EC resolution.
```
Normalize DOC86/DOC81 as:
```text
schema_import:
DOC86 imports DOC81-owned PolicyStamp / EffectiveMemoryPolicy reference / disclosure-state contracts.
command_or_control_flow:
DOC86 sends inspect / restamp / disclose / membership-control command events to EC.
EC invokes DOC81 policy re-evaluation.
```
Normalize DOC87/DOC84:
```text
schema_import:
DOC84 imports DOC87-owned MemoryMembershipEdge contract.
runtime_instance_flow:
DOC84 consumes current membership state for ContextProduct planning.
```
Add lints:
```text
import_graph.runtime_flow_listed_as_schema_import
import_graph.command_flow_listed_as_schema_import
import_graph.storage_flow_listed_as_schema_import
import_graph.bidirectional_schema_import_without_architect_approval
import_graph.upward_schema_import_to_policy
```
##### 3.4 Resolve the DOC83 → DOC87 ordering problem
DOC83 owns `TopicCollectionDirective`, but that directive references Topic identity, now owned by DOC87. If DOC87 is drafted after DOC83, DOC83 will depend on an undefined Topic object.
Preferred fix: **DOC87 identity stub before DOC83 drafting.**
Add a small DOC87-owned identity contract that lands before DOC83/E5 drafting:
```text
TopicIdentityContract
MembershipTargetRef
OrganizationContainerRef
TopicRef
LibraryRef
ProjectMembershipRef
```
Rules:
```text
DOC87 owns Topic identity and membership target refs.
DOC83 may reference TopicIdentityContract when drafting TopicCollectionDirective.
Full DOC87 membership semantics can still be drafted after DOC83, but the identity stub must exist first.
```
Alternative acceptable fix: declare DOC83↔DOC87 co-drafted for Topic identity and TopicCollectionDirective only.
Do not collapse DOC87 back into DOC82 or DOC86.
##### 3.5 Purge DOC8-as-runtime-owner language
Patch all rows and prose that imply legacy DOC8 is a current runtime learning owner.
Replace any language like:
```text
DOC8 computes utility
DOC8 executes learning
DOC8/BDSM compute
DOC8 runtime dependency
```
with:
```text
DOC85 owns memory-learning architecture.
BDSM is a partial substrate consumed where pinned and real.
Legacy DOC8 is capability-mining / lineage input only unless explicitly re-adopted.
EC executes durable learning write-back.
```
Add lints:
```text
doc85.runtime_dependency_on_legacy_doc8
doc85.learning_computation_owned_by_phantom_doc8
learning.utility_without_final_prompt_proof
learning.writeback_without_ec_execution
```
##### 3.6 State the DOC82 ↔ DOC83 disposition / resolution seam
There is a real issue around `AssertionCandidateDisposition`, but I now agree with Claude that simply moving the enum to DOC82 is too blunt. The better final resolution is to make the seam explicit.
Final seam:
```text
DOC83 owns extraction triage and candidate emission.
DOC83 may emit a recommended AssertionCandidateDisposition as part of AssertionCandidateEmission.
DOC82 owns AssertionCandidate, AssertionResolution, AssertionDedupeOutcome, canonical assertion resolution, and the anti-overlap rule preventing duplicate disposition/resolution enums.
ABC §7.8 anti-overlap rule is owned/enforced by DOC82 because DOC82 owns resolution.
```
Do **not** restore the old 11-value enum.
Do **not** let both DOC82 and DOC83 define overlapping disposition/resolution enums.
Add lint:
```text
assertion.overlapping_resolution_disposition_enum
assertion.doc83_final_resolution_without_doc82
assertion.doc82_resolution_missing_doc83_emission_ref
```
##### 3.7 Re-open DR-006 / SM-202 enum mismatch
The Stage 5R artifacts state that `AssertionCandidateDisposition` is the 7-value ABC §7.8 enum. Claude found that SM-202’s enumerated seven names may not match the actual ABC §7.8 values; DR-006 verified structure but not values.
Patch action:
```text
Re-open DR-006 in Conflict_Disagreement_Register.md.
Verify the actual ABC §7.8 values against:
- Supersession_Matrix.md SM-202;
- DOC80_Retired_Names.md row for AssertionCandidateDisposition;
- DOC80_Owner_Map.md rows for AssertionCandidateDisposition / AssertionDedupeOutcome;
- DOC83/DOC82 section maps.
```
Do not invent the final enum values in Stage 5R2 unless the source is verified. If mismatch remains unresolved, gate the DOC82/DOC83 charters.
##### 3.8 Resolve or charter-gate VersionedClaim and WorkSession
###### VersionedClaim
Current state: pending.
Recommended final disposition:
```text
VersionedClaim remains DOC73-owned.
DOC82 defines/consumes a VersionedClaim_to_AssertionVariant_Lineage_Table.
```
Add charter requirement:
```text
DOC82/DOC73 charter must define:
- 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
```
###### WorkSession
Current state: pending.
Recommended final disposition:
```text
WorkSession → DOC83
Use as light temporal grouping.
Not user-visible by default.
WorkEpisode remains coherent work unit.
EpisodeSegment remains finer boundary / policy/surface segment.
```
If not retained, add Retired Names / Supersession row mapping WorkSession into WorkEpisode with rationale.
Add lint:
```text
worksession.disposition_unresolved_at_doc83_charter
```
##### 3.9 Mark EC as partial / moving and add ECSeamContract
EC is too load-bearing and too stale/moving to be treated as a stable external dependency.
Patch ExternalDependencyRecord:
```text
external_doc: EC
status: partial / moving
volatility: moving
requires_seam_contract: true
```
Add `ECSeamContract` with at least:
```text
durable write execution;
command execution;
policy/scope execution;
membership write execution;
learning write-back execution;
source revocation / deletion execution when later adopted;
audit/replay;
transaction ordering;
compare-and-swap / generation revalidation;
read-model refresh;
no non-EC durable writer.
```
Concurrency rule:
```text
EC must revalidate AssertionDedupeOutcome against current state inside serialized write, or AssertionDedupeOutcome must carry dedupe_basis_generation_id / optimistic concurrency token.
```
Policy-generation rule:
```text
A candidate started under policy generation N must re-gate at resolution/write if policy generation has changed before durable write.
```
Add lints:
```text
ec.dependency_not_marked_partial_or_moving
ec.durable_write_without_ec_execution
ec.dedupe_write_without_generation_revalidation
ec.policy_generation_changed_without_regate
ec.learning_writeback_without_ec_execution
```
##### 3.10 Add retention / erasure / legal hold / clawback ADQ
Do **not** draft DOC88 in Stage 5R2.
But open an architect-tier ADQ:
```text
ADQ — Data lifecycle, retention, erasure, legal hold, revocation, and clawback ownership.
```
Question:
```text
Should data lifecycle / retention / erasure / legal-hold / clawback be:
A. a DOC81 cross-plane policy/lifecycle contract;
B. a 9th DOC80-family member;
C. a separate cross-ELNOR owner spec, likely DOC88;
D. deferred with only revocation/degradation rules in DOC80 for now?
```
State the hard sub-question explicitly:
```text
Does privileged clawback require hard destruction, revocation-as-degradation, tombstone/redaction, or a hybrid?
How does that reconcile with append-only audit logs, MemoryFlowCertificates, proof spine, legal hold, and replay/recovery?
```
My final lean:
```text
DOC88 is probably real eventually, because deletion/legal hold applies across memory, Libraries, corpora, uploaded documents, task graphs, task presets, task artifacts, work products, published views, audit/proof ledgers, derived indexes, projections, and learning signals.
But DOC88 should not be drafted as a side effect of Stage 5R2. It is cross-ELNOR, outside the immediate DOC80 flattening scope, and should be decided through the ADQ after the erasure-vs-audit-spine tension is resolved.
```
Minimal Stage 5R2 placeholder:
```text
DOC80 V5 recognizes source/memory revocation and deletion as cross-plane lifecycle concerns.
Full retention/erasure/legal-hold/clawback ownership is architect-decision gated.
No DOC80 member may equate retired/suppressed/stale with erased.
```
Add temporary lints / pending names only if needed:
```text
erasure.retired_used_as_erased
erasure.legal_hold_bypassed_without_adq_resolution
revocation.learning_signal_survives_revoked_source
```
##### 3.11 Add network / sharing forward-compatibility ADQ
Do **not** draft full networking schemas in Stage 5R2.
But open an ADQ:
```text
ADQ — DOC80 V5 network and sharing forward compatibility: scope and depth.
```
Recommended answer:
```text
DOC80 V5 remains local-first, single-principal, single-node, and single-EC-writer unless later extended.
Multi-device sync, mobile sync, cross-user memory, shared Projects, shared Topics, shared Libraries, and remote write authority are out of scope for V5.
Durable objects should still carry stable IDs / generation refs sufficient for future replay and conflict detection.
```
Phase 1 published/shared views should be recognized as a **separate concrete seam**:
```text
DOC73 Library/Corpus share pages exist or are near-roadmap.
DOC23 Task shared pages / task artifacts / deliveries exist or are near-roadmap.
DOC80 should govern memory-derived exposure on those surfaces, but not own DOC73 or DOC23 mechanics.
```
Stage 5R2 should add OP-A seam rows, not full schema bodies:
```text
OPA — DOC80 ↔ DOC73/DOC25: memory exposure on published Library/Corpus pages.
OPA — DOC80 ↔ DOC23: memory exposure on shared task surfaces.
OPA — DOC80 ↔ DOC81: publish/view/revoke/learn-from-published-view policy decision to be designed if ADQ approves.
```
Boundary invariant:
```text
DOC23 owns task graph, task page mechanics, task artifacts, task deliveries, task-specific share manifests, and task-run behavior.
DOC80 owns only memory-derived exposure, policy/proof/disclosure/learning/memory promotion effects on shared task surfaces.
DOC73/DOC25 own Library/Corpus/source mechanics.
DOC80 governs only memory-derived exposure, policy/proof/disclosure/learning/membership effects on published Library/Corpus surfaces.
```
Do not add full schemas such as `NetworkCompatibilityEnvelope`, `PublishedViewEnvelope`, or `TaskSharedMemoryExposureContract` in Stage 5R2 unless Will separately resolves the ADQ and authorizes that scope. Those are Stage 7 charter material.
##### 3.12 Correct the §18 golden-scenario phase order
The Stage 5R golden scenario order lists policy after extraction / membership in places. That is wrong.
Correct order:
```text
request / source observation
→ scope / policy preflight where applicable
→ extraction admission
→ extraction route / source prep
→ candidate emission
→ canonical resolution
→ membership proposal / confirmation
→ policy re-check for use/delivery
→ context product planning
→ DOC24 / KDA rendering
→ final prompt proof
→ learning eligibility
→ UI / Inspector explanation
```
Rule:
```text
Policy gates extraction at ABC §7.7 Step 0 and gates delivery / movement / learning again at use time.
```
##### 3.13 Add DOC81 / DOC87 non-overlap invariant
Now that DOC87 exists, distinguish membership from scope.
Add rule:
```text
ScopeContainerRelation is policy/scope topology.
MemoryMembershipEdge is organization.
Membership does not imply scope containment.
Scope containment does not imply UI membership.
Membership does not imply access permission.
Membership does not imply source authority.
Membership does not imply truth authority.
```
Add lints:
```text
membership_edge_used_as_scope_container_relation
scope_container_relation_used_as_ui_membership
membership_edge_used_as_policy_authority
membership_edge_used_as_source_authority
membership_edge_used_as_truth_authority
```
##### 3.14 Add lightweight MemoryObjectClassificationTable
Before charters, add a minimal table to prevent object drift.
Columns:
```text
object_family
owner
truth_apt?
source_bound?
durable?
derived/projection?
policy_gated?
delivery_eligible?
ui_visible?
learning_eligible?
notes
```
Do not add speculative `network_compatibility_required?` column yet. Network/sharing belongs in ADQ until scope is decided.
Seed rows:
```text
Assertion — DOC82 — truth_apt yes — durable yes
AssertionVariant — DOC82 — truth_apt yes — durable yes
ConsolidatedUnderstanding — DOC73/DOC82 consumption — source_bound yes — reusable truth no
EvidenceRecord — DOC82 — evidence yes — truth no
EvidenceSupportEdge — DOC82 — support relation yes
MemoryMembershipEdge — DOC87 — organization yes — truth no — source authority no
TopicLens — DOC87/DOC86 split — organization/search lens — truth no
TopicCollectionDirective — DOC83 — extraction directive — truth no
IssueFrame — DOC83 — workbench — truth no
RecentActivityRollup — DOC73/DOC83 consumption — orientation only
NullResultMemory — DOC83 — bounded absence history — not universal absence
ContextProduct — DOC80/DOC84/DOC24/KDA seam — delivery product — truth no
ResumeCard / ResumeProjection — derived projection — evidence no
LearningSignal — DOC85 — utility signal — truth no
```
##### 3.15 Embedding model migration refs
Add fold-in:
```text
AssertionIdentitySignature and semantic_equivalence dedupe must record embedding_model_ref / embedding_generation_id where embeddings contribute to equivalence or similarity.
```
Migration rule:
```text
Embedding model migration invalidates or rechecks semantic-equivalence dedupe, related projections, vector indexes, and affected retrieval hints.
```
Add lint:
```text
embedding.semantic_equivalence_without_model_generation
embedding.model_migration_without_dedupe_recheck_plan
```
##### 3.16 Observability / health seam
Add fold-in:
```text
DOC80 core owns health signal vocabulary, or EC/Q owns MemoryPlaneHealthReadModel with DOC80 member contributions.
```
Counters to seed:
```text
source_revocation_backlog
membership_restamp_backlog
policy_restamp_failures
proof_artifact_missing_count
topic_future_watch_budget_exhausted
search_affordance_preflight_failure_count
learning_signal_suppression_count
review_queue_depth
contested_assertion_rate
warrant_distribution
```
Add lint:
```text
member.missing_health_counters
```
##### 3.17 Quotas / scale / local-first budgets
Extend `FamilyWideComputeBudget` or add `MemoryOperationQuota` as a fold-in.
Fields / constraints:
```text
max_topic_future_watch_runs
max_review_queue_backlog
max_source_invalidation_fanout_per_cycle
max_learning_replay_per_window
max_search_affordance_prefetch
max_membership_restamp_batch_size
max_revocation_cascade_batch_size
background_yield_to_hot_path
```
Add lints:
```text
quota.topic_future_watch_unbounded
quota.review_queue_unbounded
quota.source_revocation_fanout_unbounded
quota.membership_restamp_unbounded
quota.learning_replay_unbounded
```
##### 3.18 CognitiveDiff / ResumeCard
Do not create canonical `CognitiveDiff` now.
Patch:
```text
Demote CognitiveDiff to ResumeProjection / ResumeCard unless Will separately approves a canonical CognitiveDiff object.
```
ResumeCard definition:
```text
A derived presentation over IssueFrame, RecentActivityRollup, PriorDeliveryLedger, MemoryCoordinationTrace, and DOC87 membership.
Not truth-bearing.
Not evidence.
Invalidated when source refs invalidate.
```
Add lint:
```text
cognitive_diff.canonical_without_architect_approval
resume_card_used_as_evidence
```
##### 3.19 SemanticProjection / ProjectionInvalidationPolicy
Narrow projection ownership.
Patch:
```text
SemanticProjectionContract → DOC80 core, if cross-family.
DeliveryProjection → DOC84.
UIProjection → DOC86.
OrganizationProjection → DOC87.
KnowledgeProjection / SourceBoundSynthesisProjection → DOC82.
```
Rules:
```text
Projection never owns truth.
Projection must carry source refs, generation id, invalidation policy, projection owner, and proof/read-model refs.
```
Add lints:
```text
projection.used_as_canonical_truth
projection.owner_missing
projection.missing_invalidation_policy
projection.missing_source_refs
```
##### 3.20 Safe label ownership cleanup
See §3.2. Also add strict rules:
```text
Safe labels must come from approved vocabulary.
Safe labels must not derive from protected source content.
Not-disclosable material may require suppression rather than label.
Inspector and prompt rendering share disclosure discipline.
```
##### 3.21 DynamicHeaderLedger owner/finalizer split
Patch if still unresolved:
```text
DynamicHeaderLedger schema_owner = DOC84.
DOC24/KDA may finalize manifest/header content.
DOC80 core owns proof constraints if cross-family.
```
Add lint:
```text
dynamic_header_ledger.owner_unresolved_at_doc84_charter
```
##### 3.22 DOC15 import seam check
DOC15/CIL may have injection hierarchy, token budgets, context assembly, and memory/context/self-learning audit material. It should not be imported only into DOC86 if it also affects DOC84 delivery or DOC85 learning.
Add 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 lint:
```text
doc15.context_budget_import_missing
```
##### 3.23 DOC26 / UnifiedWorkspaceLibrary citation check
If DOC26 is referenced, verify it is a real current owner doc and the cited authorization exists.
Patch:
```text
If DOC26 import is valid: pin it and correct citation.
If invalid: remove import or mark aspirational/parked.
```
Add lint:
```text
import_graph.invalid_authorization_citation
```
---
#### 4. Retention, erasure, legal hold, clawback, and DOC88 — final position
Will raised a broader product point: deletion, legal hold, clawback, and erasure will apply not only to memory but also to Libraries/corpora, uploaded documents, task graphs, task presets, task artifacts, work products, published/shared surfaces, indexes, and proof/audit ledgers.
That observation is correct. It **does** strengthen the case that a separate cross-suite lifecycle spec — likely DOC88 — will eventually be needed.
However, I agree with Claude’s final pushback that Stage 5R2 should **not** draft DOC88 or insert a full data-lifecycle schema set. That would be a major cross-ELNOR design project, outside the immediate DOC80 skeleton cleanup.
##### 4.1 The key distinction
Policy answers:
```text
May this action happen?
Who may see it?
What may be disclosed?
What destination/audience is allowed?
What obligations attach?
```
Lifecycle / retention / erasure answers:
```text
Once action is authorized, what happens to the object and every derivative?
What is purged, tombstoned, archived, hidden, retained, invalidated, or redacted?
What audit/proof survives?
What happens under legal hold?
```
Those are different enough that a separate owner may be justified.
##### 4.2 The hard unresolved question
The real unresolved question is not “do we need deletion someday?” The question is:
```text
When a privileged source is clawed back or a Library/source is deleted, does the system need hard destruction, revocation-as-degradation, tombstone/redaction, or a hybrid?
How does that reconcile with append-only audit logs, MemoryFlowCertificates, proof spine, legal hold, and replay/recovery?
```
Do not draft DOC88 until that is answered.
##### 4.3 Stage 5R2 action
Add one architect-tier ADQ as described in §3.10.
Also add a minimal non-final rule:
```text
DOC80 recognizes deletion / revocation / legal hold / clawback as cross-plane lifecycle concerns.
Retired / stale / suppressed / reference-only / archived are not synonyms for erased.
No member may treat a source as usable after revocation without re-evaluation through the eventual lifecycle policy.
```
No full DOC88 schema set in Stage 5R2.
---
#### 5. Networking, mobile, published views, Library/Corpus sharing, and task sharing — final position
Will clarified that networking is likely future Phase 2 and mobile is likely, while Phase 1 already includes or will include:
```text
DOC73 web-shared Library / Corpus pages;
DOC23 task pages / task artifacts / task deliveries shared or rendered outside the full DOC20 shell;
future mobile / syncing / shared-memory systems.
```
This matters, but Stage 5R2 must remain disciplined.
##### 5.1 Distinguish Phase 1 sharing from Phase 2 networking
Phase 1 published/shared views:
```text
Library / Corpus share page;
task page;
task artifact page;
task delivery page;
read-only or snapshot publication;
link-recipient view.
```
Phase 2 networking:
```text
mobile app;
multi-device sync;
shared Projects;
shared Libraries;
shared Topics;
shared task workspaces;
multi-user memory;
remote write authority;
conflict resolution;
eventual consistency.
```
##### 5.2 Stage 5R2 action
Do not draft:
```text
NetworkCompatibilityEnvelope;
PublishedViewEnvelope;
TaskSharedMemoryExposureContract;
PublishedLibraryCorpusExposureContract;
large policy-action additions;
full network lints and fixtures.
```
Instead, open an ADQ as described in §3.11 and add OP-A seam rows for the Phase 1 memory-exposure seams.
##### 5.3 Required boundary statements
Add these now:
```text
DOC80 V5 is local-first, single-principal, single-node, and single-EC-writer unless later extended.
Multi-device sync, cross-user memory, mobile sync, shared Project writes, and remote write authority are out of scope for V5 unless a later ADQ/spec adopts them.
DOC80 must not accidentally prevent future networking: durable objects should use stable IDs, generation refs, and owner/proof refs sufficient for future replay/conflict analysis.
```
For task sharing:
```text
DOC23 owns task graph, task page mechanics, task artifacts, task deliveries, task-specific share manifests, and task-run behavior.
DOC80 governs only memory-derived exposure, policy/proof/disclosure/learning/memory-promotion effects on shared task surfaces.
```
For Library/Corpus sharing:
```text
DOC73/DOC25 own Library/Corpus/source mechanics.
DOC87 owns organizational membership.
DOC80/DOC81/DOC84/DOC86/DOC85 govern memory exposure, policy/proof/disclosure/learning effects where memory-derived content appears on published Library/Corpus pages.
```
##### 5.4 Charter input if ADQ approves Phase 1 sharing as live
If Will resolves the ADQ by saying Phase 1 sharing must be supported in DOC80 V5, then Stage 6/7 charters should include actual published-view contracts. Until then, keep schemas out of Stage 5R2.
---
#### 6. Source revocation / deletion cascade — final position
Even if full DOC88 is ADQ-gated, a basic revocation cascade needs to be named now as a cross-plane concern.
Revocation is not necessarily erasure. It may be:
```text
invalidate support;
restamp policy;
hide membership;
suppress delivery;
invalidate carryover;
stop learning;
safe-label UI;
retain tombstone/audit.
```
Stage 5R2 should add a named workflow story:
```text
source_revocation_cascade:
SourceArtifact revoked
→ DOC82 EvidenceSupportEdges invalidated / verify_required
→ Assertions recompute warrant
→ DOC87 source-derived memberships restamped / removed / hidden
→ DOC84 PriorDeliveryLedger / CarryoverCapsule invalidated
→ DOC85 learning signals ineligible for future utility
→ DOC86 Inspector safe-labels or suppresses according to disclosure policy
→ EC executes durable writes / receipts
```
Add lints:
```text
revocation.support_edge_survives_revoked_source
revocation.membership_survives_revoked_source_without_restamp
revocation.carryover_capsule_survives_revoked_source
revocation.learning_credit_after_revocation
revocation.inspector_leaks_revoked_source
revocation.published_view_not_invalidated_after_revocation
```
---
#### 7. Recovery / replay / corruption — final position
DOC80 should not own all backup/corruption recovery, but it depends on it.
Add a seam:
```text
Recovery / replay is EC / DOC72 / DOC25 owned, with DOC80-family rebuild hooks.
DOC80 members must classify artifacts as canonical or derived.
Every derived DOC80-family artifact must name rebuild sources.
Every durable DOC80-family mutation must be represented in replay/audit sources.
```
Add lints:
```text
recovery.derived_artifact_without_rebuild_source
recovery.proof_artifact_missing_canonical_ref
recovery.membership_edge_without_replay_source
recovery.learning_signal_without_replay_or_audit_source
```
This is especially important because EC is a partial/moving dependency and because retention/erasure/legal hold may eventually affect audit retention.
---
#### 8. Evaluation of Claude’s latest comments
##### 8.1 I agree with Claude on the central process correction
Claude’s strongest point is that Stage 5R2 must be a cleanup/stabilization patch, not a second design round. I agree.
The Stage 5R2 patch should **not** include full schema bodies for networking, DOC88, published views, or massive new policy/lint surfaces unless Will resolves an ADQ authorizing that scope.
##### 8.2 I agree OP-A is the top must-fix
Claude is right that OP-A was augmented but not reconciled. Since Stage 6 charters consume OP-A as cross-doc amendment obligations, stale OP-A rows are dangerous.
##### 8.3 I agree with the four-edge-kind import graph
Claude credits the four-edge-kind model as better than merely patching individual arrows. I agree. It addresses the entire class of false-cycle / false-import issues.
##### 8.4 I agree with `TopicIdentityContract` stub
Claude’s upgrade is right: resolve DOC83→DOC87 by adding a small DOC87 identity stub before DOC83 drafting, instead of co-drafting all of DOC83/DOC87 or reordering the full slice graph.
##### 8.5 I agree with EC partial/moving dependency + ECSeamContract
This should be adopted. EC is too important and too moving to be an implicit stable dependency.
##### 8.6 I agree with Claude’s caution on networking and DOC88
My earlier networking and DOC88 schema proposals were too detailed for Stage 5R2. The ideas are useful, but their status should be:
```text
ADQ / Stage 6-7 charter input, not Stage 5R2 schema patch.
```
##### 8.7 I modify Claude slightly on Phase 1 sharing
I do not want Phase 1 sharing ignored. Because DOC73 and DOC23 already contain sharing/published-surface concepts, Stage 5R2 should add explicit ADQ/OP-A seam rows and boundary invariants. But I agree full schemas should wait.
##### 8.8 I modify Claude slightly on retention / DOC88
I still lean toward DOC88 eventually, because the lifecycle issue crosses memory, tasks, libraries, source artifacts, work products, published views, proof/audit, and learning. But I agree Stage 5R2 should not create DOC88. It should open the architect-tier ADQ.
##### 8.9 I agree some external reviews were unreliable
Do not restore the old 11-value `AssertionCandidateDisposition`. Do not act on any `ARCHITECT_STOP` claim unless it cites exact artifact text and actually contradicts D-SEED-1 or D-SEED-2. Confident, formatted red-team output should be checked against the artifacts.
Add process rule:
```text
Any red-team finding labeled architect_stop must cite exact file/path/section evidence and identify a contradiction with D-SEED-1 or D-SEED-2 before it enters Architect Decision Queue.
```
---
#### 9. Stage 5R2 patch plan for Claude Code
Claude Code should make a Stage 5R2 patch with the following structure.
##### 9.1 Files to patch
At minimum:
```text
Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md
Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md
Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md
Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md
Memory Rebuild Docs/Flattening/Execution Ledger/OP-A Disposition/OP_A_Candidate_Disposition.md
Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md
Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md
```
Potentially patch:
```text
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R_Red_Team_Adjudication.md
Memory Rebuild Docs/DOC80 Target Baseline/README or Stage 5R patch summary, if present
```
##### 9.2 Required outputs
Claude Code should create or update:
```text
Stage_5R2_Patch_Summary.md
Stage_5R2_Self_Audit.md
Stage_5R2_Regression_Review_Prompt.md
```
Recommended paths:
```text
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2_Patch_Summary.md
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2_Self_Audit.md
Memory Rebuild Docs/Flattening/Reviews/Prompts/Stage_5R2_Regression_Review_Prompt.md
```
##### 9.3 Stage 5R2 patch checklist
Claude Code must complete these before asking Will to proceed:
```text
[ ] OP-A reconciliation complete.
[ ] Owner Map has no compound or non-doc owner rows.
[ ] Import Graph has edge-kind tables.
[ ] DOC83→DOC87 TopicIdentityContract stub or equivalent ordering fix added.
[ ] DOC8 runtime-owner language removed.
[ ] DOC82↔DOC83 disposition/resolution seam stated.
[ ] DR-006 re-opened or resolved against actual ABC §7.8 values.
[ ] VersionedClaim charter gate added.
[ ] WorkSession charter gate or final disposition added.
[ ] EC marked partial/moving and ECSeamContract added.
[ ] Retention/erasure/legal-hold/clawback ADQ added.
[ ] Network/sharing forward-compatibility ADQ added.
[ ] V5 single-principal/single-node/local-first/single-EC-writer non-goal added.
[ ] DOC81/DOC87 non-overlap invariant added.
[ ] MemoryObjectClassificationTable skeleton added.
[ ] Embedding-model migration refs added or charter-gated.
[ ] Revocation cascade workflow story added.
[ ] Recovery/replay seam added or charter-gated.
[ ] Observability/health seam added or charter-gated.
[ ] Quota/compute fold-in added or charter-gated.
[ ] CognitiveDiff demoted or ADQ-gated.
[ ] SemanticProjection narrowed.
[ ] SafeLabel ownership decomposed.
[ ] DynamicHeaderLedger owner/finalizer split resolved or charter-gated.
[ ] DOC15 seam check added.
[ ] DOC26 citation check added.
[ ] Golden scenario phase order corrected.
```
---
#### 10. What Claude Code should **not** do
```text
Do not redraw the DOC80 family except for DOC87 already accepted.
Do not remove DOC87.
Do not add DOC88 directly in Stage 5R2.
Do not draft full networking, mobile, sync, collaboration, account, CRDT, or remote-authority schemas.
Do not add NetworkCompatibilityEnvelope / PublishedViewEnvelope / TaskSharedMemoryExposureContract unless Will resolves an ADQ authorizing that scope.
Do not restore the old 11-value AssertionCandidateDisposition enum.
Do not treat DOC8 as runtime learning owner.
Do not use DAMS V5 as an owner label.
Do not let DOC84 own membership.
Do not let DOC86 own policy.
Do not let DOC87 own scope or policy.
Do not treat Library membership as source authority.
Do not treat Project membership as policy/scope authority.
Do not treat CU as reusable truth.
Do not make ResumeCard / CognitiveDiff truth-bearing.
Do not leave any owner row with two owners in the owner cell.
Do not list runtime flow as schema import.
Do not let stale OP-A rows survive.
```
---
#### 11. Suggested Stage 5R2 regression-review prompt
Use this after Claude Code completes Stage 5R2.
```text
Review the Stage 5R2 patch to the DOC80 skeletal target baseline artifacts.
Files to review:
- DOC80_Skeletal_Target_Baseline.md
- DOC80_Owner_Map.md
- DOC80_Import_Graph.md
- DOC80_Retired_Names.md
- OP_A_Candidate_Disposition.md
- Conflict_Disagreement_Register.md
- Architect_Decision_Queue.md
- Stage_5R2_Patch_Summary.md
- Stage_5R2_Self_Audit.md
Questions:
1. Does Stage 5R2 reconcile stale OP-A rows, especially OPA-001, OPA-004, OPA-005, OPA-011, and OPA-012?
2. Does the Owner Map now mechanically enforce one schema owner per row, with no compound or non-doc owner labels?
3. Does the Import Graph now distinguish schema imports, runtime instance flows, command/control flows, and storage/execution flows?
4. Does the DOC83→DOC87 dependency have a clean TopicIdentityContract stub or equivalent charter-safe ordering fix?
5. Is DOC8 completely removed as a current runtime learning owner while BDSM remains a partial/pinned substrate and DOC85 owns learning architecture?
6. Is the DOC82↔DOC83 disposition/resolution seam clear without restoring the retired 11-value enum?
7. Is DR-006 / SM-202 either resolved or explicitly re-opened and charter-gated?
8. Are VersionedClaim and WorkSession resolved or properly charter-gated?
9. Is EC treated as a partial/moving dependency with a named ECSeamContract?
10. Are retention/erasure/legal-hold/clawback and network/sharing forward compatibility handled as architect ADQs rather than unapproved schema expansions?
11. Are Phase 1 Library/Corpus sharing and task-sharing memory exposure seams captured without moving DOC73 or DOC23 mechanics into DOC80?
12. Are DOC81/DOC87 non-overlap, memory-object classification, revocation cascade, recovery/replay, observability/quota, embedding migration, CognitiveDiff, SemanticProjection, SafeLabel, DOC15, DOC26, and golden-scenario-order issues either patched or charter-gated?
13. Do any remaining issues block Stage 6 slice charters?
Disposition options:
- Stage 5R2 clean — Stage 6 may begin.
- Stage 5R2 needs minor cleanup only — list exact edits.
- Stage 5R2 still blocked — identify blocker and exact artifact location.
- ARCHITECT_STOP — only if there is a concrete contradiction of D-SEED-1 or D-SEED-2.
```
---
#### 12. Final audited recommendations
##### 12.1 Final must-fix list
The final must-fix list is:
```text
1. OP-A reconciliation.
2. Owner Map mechanical one-owner cleanup.
3. Import Graph edge-kind restructuring.
4. DOC83→DOC87 TopicIdentityContract stub / ordering fix.
5. DOC8 runtime-owner language purge.
6. DOC82↔DOC83 disposition/resolution seam.
7. DR-006 / SM-202 correction.
8. VersionedClaim and WorkSession resolution/charter gates.
9. EC partial/moving + ECSeamContract.
10. Retention/erasure/legal-hold/clawback ADQ.
11. Network/sharing forward-compatibility ADQ.
12. Stage 5R2 non-goals and boundary invariants.
```
##### 12.2 Final fold-ins
Fold in or charter-gate:
```text
DOC81/DOC87 non-overlap invariant.
MemoryObjectClassificationTable.
Embedding-model migration refs.
Source revocation cascade.
Recovery/replay seam.
Observability/health read model.
MemoryOperationQuota / compute budget.
CognitiveDiff → ResumeProjection.
SemanticProjection narrowing.
SafeLabel decomposition.
DynamicHeaderLedger owner/finalizer split.
DOC15 import seam check.
DOC26 citation check.
Golden-scenario phase-order fix.
Algebraic invariants:
- policy meet is monotonic conservative;
- membership never increases warrant;
- source revocation never increases warrant;
- learning cannot increase epistemic warrant beyond non-learning ceiling;
- reference-only cannot render substantive content;
- no final-prompt proof = no utility credit.
```
##### 12.3 Final non-goals for Stage 5R2
```text
No DOC88 draft.
No full network or mobile design.
No full published-view schema set.
No task-system redesign.
No corpus/source mechanics redesign.
No broad new object families except ADQ-gated future decisions.
```
##### 12.4 Final disposition
```text
Stage 5R: not clean enough for Stage 6.
Stage 5R2: required.
Architecture: sound.
Family: DOC80–DOC87 retained.
DOC87: correct and retained.
DOC85: substantive learning architecture, not DOC8 shell.
DOC88: likely future cross-ELNOR lifecycle spec, but ADQ-gated, not drafted now.
Networking/sharing: Phase 1 seams acknowledged; full schemas ADQ/Stage 7 gated.
Stage 6 charters: begin only after Stage 5R2 regression pass.
```
---
#### 13. Short version for Claude Code
If Claude Code needs the shortest possible instruction, use this:
```text
Create a Stage 5R2 cleanup patch. Do not redesign the DOC80 family.
Patch the Stage 5R artifacts so Stage 6 charters can safely begin.
Must fix:
1. Reconcile stale OP-A rows against the 8-member Owner Map.
2. Split all compound / non-doc Owner Map rows into single-owner rows.
3. Split Import Graph into schema_import, runtime_instance_flow, command_or_control_flow, storage_or_execution_flow.
4. Add DOC87 TopicIdentityContract stub or equivalent before DOC83 TopicCollectionDirective drafting.
5. Remove all DOC8-as-runtime-learning-owner language.
6. State DOC82↔DOC83 disposition/resolution seam and ABC §7.8 anti-overlap rule; do not revive retired 11-value enum.
7. Reopen or resolve DR-006 / SM-202 enum mismatch.
8. Resolve or charter-gate VersionedClaim and WorkSession.
9. Mark EC partial/moving and add ECSeamContract.
10. Add architect ADQs for retention/erasure/legal hold/clawback and network/sharing forward compatibility.
11. Add non-goal: DOC80 V5 is local-first, single-principal, single-node, single-EC-writer unless later extended.
12. Add DOC81/DOC87 non-overlap and basic revocation/recovery/observability/quotas as fold-ins or charter gates.
Do not draft DOC88.
Do not draft full networking/published-view/task-sharing schemas.
Do not re-slice the family.
Do not use DAMS V5 or DOC8 as owner labels.
Do not leave Stage 5R2 without a regression-review prompt and self-audit.
```
---
## 3. Codex — Red-Team Reviews
*Codex worked with direct filesystem access, so its citations include file:line references. Treat those as reviewer assertions to verify against the repo, not as already-verified facts.*
**Document purpose:** Three Codex chat outputs responding to the Stage 5 and Stage 5R red-team prompts, combined into a single document per Will's instruction. Codex's outputs include filesystem-resolved file:line citations characteristic of an editor-integrated environment; treat those citations as reviewer assertions to verify against the repo, not as already-verified facts.
**Contents:**
- Part 1 — Stage 5 (Round 1) review
- Part 2 — Stage 5R (Round 2) review
- Part 3 — Stage 5R deeper pass (cross-artifact drift audit)
---
### 3.1 Round 1 — Stage 5 Skeletal Target Baseline
#### Summary
The 7-member DOC80 family architecture is broadly sound, but I would patch the skeletal baseline before Stage 6 charters begin. The main issues are ownership-row ambiguity, one wrong import direction, incomplete retired-name coverage, and an ABC §7.8 enum mismatch.
#### A. Family member list findings
- [A1] [CONFIRMED] Seven members is defensible. DOC83, DOC85, and DOC86 each have enough 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 split respects the plan §12 lockstep pairs: E1/E2 → DOC81, E3/E4 → DOC82, E7/E8 → DOC84.
- affected family member(s) / section(s): DOC81, DOC82, DOC84
- recommended action: no split change.
- [A3] [SUGGESTION] DOC80 core is mostly scoped correctly, especially ReasonCode registry, ContextProduct registry, and PromptShellRegistry. A few rows should more clearly distinguish contract ownership from implementation/execution ownership.
- affected family member(s) / section(s): DOC80 core, DOC81, DOC84
- recommended action: clarify that DOC80 owns cross-cutting contracts/registries/proof spine, while downstream members execute or implement them.
#### B. Per-schema ownership handoff findings
- [B1] [BUG] The Owner Map violates its own "one and only one owner per schema" rule in several rows by putting multiple owners in the `owns` field.
- schema(s) affected: `AssertionRelationEdge`, `EffectiveMemoryPolicy`, `MemoryContextPlan`, `RenderSafetyProof`, `PromptShellLearningContract`, `SearchAffordance`, `TopicRiskClass`
- recommended handoff change: split each into one canonical schema/contract owner plus separate consumers/stores/executors.
- [B2] [CONFIRMED] Assertion → DOC82 is architecturally clean if the three-way split is enforced: DOC82 defines schema, DOC72 stores graph payload/topology, EC executes writes.
- schema(s) affected: `Assertion`, `AssertionVariant`, `AssertionCandidate`, `AssertionResolution`
- recommended handoff change: keep the handoff, but patch any OP-A wording that still says DOC72 emits the Assertion schema.
- [B2] [CONFIRMED] ConsolidatedUnderstanding retained at DOC73 is clean under ADQ-219, provided the wrapper remains conditional and does not become a permanent local redefinition.
- schema(s) affected: `ConsolidatedUnderstanding`, `SourceBoundSynthesisProjection`
- recommended handoff change: keep the E3/E4 reconciliation gate explicit and blocking.
- [B2] [CONFIRMED] MemoryContextPlan + ContextProduct are cross-cutting enough for DOC80 core contract/registry ownership; DOC84 remains the runtime delivery implementation/consumer.
- schema(s) affected: `MemoryContextPlan`, `ContextProduct`
- recommended handoff change: keep in DOC80 core, with DOC84 implementation wording tightened.
- [B3] [GAP] `WorkSession` appears in ABC/Round D material but is not explicitly handed off, imported, or retired in the skeletal baseline.
- schema(s) affected: `WorkSession`
- recommended handoff change: add an owner/import row or state that it is retired/renamed into `WorkEpisode`.
#### C. Import graph findings
- [C1] [BUG] The multi-owner rows weaken the §18 proof for "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 owner plus stores/consumes/executes roles.
- [C1] [CONFIRMED] The target-package files are path-resolvable locally.
- plan §18 condition affected: §4.5
- recommended action: no availability patch.
- [C2] [BUG] The lateral import `DOC86 → DOC81` appears backwards. The stated reason says UI consumes policy-plane data, which implies DOC81 → DOC86 or an EC command handoff, not a DOC86 import into DOC81.
- plan §18 condition affected: intra-family import graph / no-cycle proof
- recommended action: reverse or restate the edge to avoid implying a cycle.
#### D. Owner boundaries findings
- [D1] [CONFIRMED] The skeleton preserves the major non-absorption boundaries: DOC23 task graph, DOC20 UI implementation, DOC11 runtime truth, DOC3 procedural lifecycle, DOC9 self-repair, and implementation planning are not absorbed wholesale.
- [D2] [SUGGESTION] Boundary preservation is mostly sound, but the ambiguous "owns + impl" rows could be read as implicit absorption of external executor/implementation authority.
#### 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 old intermixed usage.
- [E2] [SUGGESTION] `Premise` as memory object should not be allowed indefinitely in broad "DOC72 / DOC73 legacy citation contexts." The alias expiry exists later in the file, but the main row should point to that expiry.
- [E3] [BUG] The `AssertionCandidateDisposition` retired-name row does not match ABC R0.2 §7.8. ABC's actual 7-value enum uses `durable_eligible`, `durable_eligible_confirmation_required`, `session_scoped`, `ephemeral_reroute`, `candidate_only_pending_issueframe`, `review_queue`, and `reject_not_memory`; the baseline carries a different 7-value list.
#### F. New canonical object families findings
- [F1] [CONFIRMED] I did not find an unauthorized new canonical family requiring `ARCHITECT_STOP`. The listed new families are 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 section/owner maps: `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 DOC86 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 senior enum.
- [G2] [GAP] ABC §21 normalization objects are not fully represented in the skeletal baseline, especially warrant consequence, domain profile, budget, promotion receipt, and considered-item structures.
#### Overall assessment
No `ARCHITECT_STOP` finding surfaced against D-SEED-1 or D-SEED-2. The skeletal architecture is sound in its family split and broad owner-boundary strategy, but it should be patched before Stage 6: fix Owner Map single-owner discipline, correct the DOC86/DOC81 import direction, add the missing retired-name coverage, reconcile the ABC §7.8 enum mismatch, and add the missing canonical object slots so charters do not scramble to recover them later.
---
### 3.2 Round 2 — Stage 5R Skeletal Target Baseline
#### Summary
Stage 5R is materially better than Stage 5: DOC87 is the right architectural move, DOC85 is no longer a phantom DOC8 seam, and proof/membership/external-dependency concepts are now named. But the patched baseline is not clean enough for Stage 6 yet.
The highest-leverage issue this round surfaces is that Stage 5R says "one owner, acyclic graph," but the actual tables still encode compound/pending ownership and new import-cycle ambiguity. Separately, the architecture is still missing a memory lifecycle/governance layer for erasure, retention, export, recovery, cross-user sharing, and consistency semantics.
#### 3.A — What did this miss?
- [A-1] [GAP] Memory lifecycle governance is not a first-class concern.
- what's missing: retention, deletion/erasure, right-to-be-forgotten, export/portability, backup/recovery, source revocation propagation, and memory deprecation lifecycle.
- why it matters: a source can be deleted after it has produced Assertions, memberships, prompt products, proofs, and DOC85 learning signals; the skeleton has invalidation pieces but no end-to-end erasure/reversal lifecycle.
- recommended action: add a Stage 5R' ADQ deciding whether this is DOC80 core cross-cutting governance or a new member/slice; add OP-A rows for DOC25/DOC72/DOC24/DOC85/EC erasure propagation.
- [A-2] [GAP] Shared/collaborative memory is not modeled.
- what's missing: principals, tenants, collaborators, shared Project memory, access-set ownership, and cross-user memory boundaries.
- why it matters: "user shares a Project" or "collaborator revokes a Library" cannot be reasoned through cleanly with only DOC81 policy + DOC87 membership edges.
- recommended action: add an explicit cross-user/collaboration decision gate before DOC87/DOC81 charters; if V5 excludes cross-user memory, state that as a non-goal.
- [A-5] [GAP] The architecture lacks a family-wide ordering and consistency model.
- what's missing: transaction IDs, idempotency keys, ordering guarantees, bitemporal valid-time/transaction-time semantics, cross-device/eventual consistency behavior, and replay rules.
- why it matters: policy changes mid-turn, membership confirmation racing with source deletion, and DOC85 write-back racing with EC warrant degradation can produce different states depending on arrival order.
- recommended action: add a core "MemoryMutation / Transaction / Ordering" invariant, or explicitly require each member charter to define mutation ordering against a shared event envelope.
#### 3.B — Where will this break?
- [B-5] [BUG] The Stage 5R import graph is not actually acyclic as written.
- failure mode: the lateral table includes `DOC82 → DOC83` and `DOC83 → DOC82`; it also reverses several DOC87 consumption edges (`DOC84 → DOC87`, `DOC86 → DOC87`, `DOC87 → DOC82`) relative to the stated owner-to-consumer convention.
- affected artifacts: `DOC80_Import_Graph.md`; `DOC80_Skeletal_Target_Baseline.md`
- recommended action: separate "schema import" from "instance/event/control-flow emission"; rewrite the lateral table using one edge convention and re-run the acyclicity proof.
- [B-4] [BUG] The one-owner rule is still not cleanly implemented.
- failure mode: owner rows still contain compound/pending/non-owner placeholders: `VersionedClaim = PENDING`, `LibrarySourceBinding = DOC82 + DOC25`, `SafeLabelPolicy + approved vocabulary = DOC86 + PropA/EC`, `RenderBundle + PromptTextPackage = DOC24 + KDA`, `False-suppression sampling = DOC85 + DOC8`, and `DynamicHeaderLedger = PER ADQ-305 RESOLUTION`.
- affected artifacts: `DOC80_Owner_Map.md`
- recommended action: split every compound row into one schema per row with one concrete owner; remove `PENDING` from owner cells before Stage 6.
- [B-2] [BUG] Source deletion/revocation will race with learning and delivery.
- failure mode: user deletes a source while DOC84 has already rendered it and DOC85 is mid-learning-cycle; proof-gated learning says "content was delivered," but source revocation says support must be invalidated.
- affected artifacts: DOC82, DOC84, DOC85, DOC80 proof spine, OP-A table
- recommended action: add a revocation/erasure precedence invariant: source revocation must cancel, quarantine, or mark downstream learning and delivery artifacts with a named state.
- [B-3] [GAP] Several invariants are lint-named but not enforcement-point-named.
- failure mode: `can_orient_only`, "removed/blocked membership edge never reaches injection," and "no learning signal without proof" are easy to check after drafting, but the skeleton does not always name the runtime gate that prevents violation.
- affected artifacts: DOC83, DOC84, DOC85, DOC87, DOC80 proof lints
- recommended action: for each invariant, name the enforcing decision point and owner in the relevant charter packet, not only the Stage 9 lint.
- [B-6] [SUGGESTION] Scale failure is likely around invalidation and membership recomputation.
- failure mode: at 10^9 Assertions, cascading invalidation, policy restamp, Topic membership, and SearchAffordance preflight become graph-wide fanout unless bounded by partitions/materialized views.
- affected artifacts: DOC81, DOC82, DOC87, DOC84, DOC86
- recommended action: add partitioning/read-model/incremental recomputation obligations to DOC80 §15 compute budget and DOC87 fixtures.
#### 3.C — Round-1 patch verification
- B1 cycle fix is partially broken: the original `DOC86 → DOC81` cycle was removed, but the Stage 5R graph introduces new ambiguity/cycles around `DOC82↔DOC83` and reversed DOC87 consumption edges.
- B2 DOC87 addition landed conceptually, but import directions around DOC87 are inconsistent with the owner/consumer prose.
- B3 contract/impl split is only partially applied: the Owner Map still contains compound or non-concrete owner cells, including `VersionedClaim`, `LibrarySourceBinding`, `SafeLabelPolicy + approved vocabulary`, `RenderBundle + PromptTextPackage`, `False-suppression sampling`, and `DynamicHeaderLedger`.
- B9/SM-202 verification is not clean: ABC R0.2 §7.8 defines `durable_eligible`, `durable_eligible_confirmation_required`, `session_scoped`, `ephemeral_reroute`, `candidate_only_pending_issueframe`, `review_queue`, `reject_not_memory`; the Supersession Matrix SM-202 row still lists the older `discard_not_memory` / `retain_ephemeral_observation` / `create_or_merge_assertion` style values. Reopen or correct DR-006; route through the Conflict Register, not a direct matrix edit.
- B9 OP-A cleanup did not fully land: OPA-001 still says "DOC72 emits Assertion schema + identity contracts," contradicting DOC82 ownership of Assertion schema and lifecycle.
- ADQ-221 status is internally inconsistent: the ADQ file says resolved, but the skeletal self-audit still says ADQ-221 is open/pending in places, and OP-A-011/012 still route learning through DOC8 language rather than the resolved BDSM-partial / DOC8-capability-mining model.
#### 3.D — Better ideas / improvements
- [D-2] [BETTER_IDEA] Add an event-sourced memory mutation envelope.
- what the architecture currently does: each member owns schemas and lints, with MemoryCoordinationTrace tying proof together.
- what would be better: a shared mutation/event envelope carrying actor, policy epoch, source epoch, transaction time, valid time, idempotency key, proof refs, and rollback/invalidation refs.
- cost / risk of changing now vs at Stage 7: cheap now as a named core invariant; expensive later because every slice will invent local ordering.
- [D-2] [BETTER_IDEA] Treat provenance as a graph, not only a trace.
- what the architecture currently does: MemoryCoordinationTrace explains flows for proof/Inspector/learning.
- what would be better: a PROV-style provenance graph from SourceArtifact → ExtractionResult → AssertionCandidateEmission → Assertion/Edge/Membership → ContextProduct → final prompt → learning signal.
- cost / risk of changing now vs at Stage 7: naming it now gives every charter a shared preservation/erasure/audit target.
- [D-3] [BETTER_IDEA] Express policy, membership, and warrant as lattice/monotonicity laws.
- what the architecture currently does: prose says policy meets, membership grants no truth, and warrant degradation is conservative.
- what would be better: state algebraic invariants: policy can only narrow without explicit restamp; membership cannot increase truth/warrant; source revocation monotonically lowers eligibility until re-proof.
- cost / risk of changing now vs at Stage 7: low now; otherwise these become scattered lint prose.
- [D-5] [SUGGESTION] Rename vague "state" rows into decision/contract rows.
- what the architecture currently does: names like `Pipeline park/resume state`, `SearchAffordance runtime eligibility`, and `False-suppression sampling` read like mechanisms, not owned contracts.
- what would be better: use names like `SuspendedContextAssembly`, `SearchAffordanceEligibilityDecision`, and `FalseSuppressionSamplingPolicy`.
- cost / risk of changing now vs at Stage 7: cheap now; painful after fixtures and section anchors exist.
#### 3.E — What will Stage 6 / Stage 7 discover?
- [E-1] [BUG] E0 cannot write the memory-object taxonomy cleanly while owner cells remain pending or compound.
- which charter / slice will hit the wall: DOC80 core / E0
- recommended pre-emptive fix: make Owner Map one-owner-clean before charters start.
- [E-1] [GAP] DOC87's charter will need transaction and conflict semantics that the skeleton does not provide.
- which charter / slice will hit the wall: DOC87 organization/membership slice
- recommended pre-emptive fix: define membership transition ordering, conflict resolution, and idempotency before writing fixtures.
- [E-2] [GAP] E7/E8 will hit unresolved DOC24/KDA/DynamicHeader boundaries.
- which charter / slice will hit the wall: DOC84 delivery/prompt/proof
- recommended pre-emptive fix: split `RenderBundle`, `PromptTextPackage`, and `DynamicHeaderLedger` into concrete owner rows with explicit DOC24/KDA amendment obligations.
- [E-3] [GAP] DOC83→DOC87→DOC84 coordination is under-specified.
- which charter / slice will hit the wall: DOC83 extraction, DOC87 membership, DOC84 delivery
- recommended pre-emptive fix: define when a membership candidate becomes eligible for ContextProduct planning and what happens if it is removed/blocked during assembly.
- [E-4] [SUGGESTION] The end-to-end golden scenario is too happy-path unless it includes revocation, policy change, and stale membership.
- which charter / slice will hit the wall: Stage 6 fixtures across E0/DOC87/E7/E9
- recommended pre-emptive fix: require at least one fixture where a source is deleted or policy changes after extraction but before delivery/learning.
#### 3.F — *(removed — ADQ-221 resolved between rounds)*
#### Overall round-2 assessment
- [ ] Stage 5R clean — Stage 6 may begin (with ADQ-221 still gating only the DOC85/E9 charter)
- [x] Stage 5R needs another patch round (Stage 5R') — must-fix items: import-graph direction/cycle cleanup, one-owner Owner Map cleanup, SM-202/DR-006 consistency, stale OP-A-001 Assertion ownership wording, ADQ-221 stale references, and a named memory lifecycle/governance decision.
- [ ] ARCHITECT_STOP — name the D-SEED contradiction or other show-stopper
---
### 3.3 Deeper Pass — Cross-Artifact Drift Audit
I took a deeper pass. My bottom line is stronger than before: DOC87 is the right architectural correction, but Stage 5R still needs a patch before Stage 6. The biggest new thing I found is not another object placement issue; it is cross-artifact drift. The Stage 5R artifacts, plan, matrix, OP-A, conflict register, and master ledger do not yet agree on what the architecture is.
**Must-Fix**
1. **The governing plan was not actually amended for DOC87.**
`Flatten_and_Unify_Plan_V2_1c.md` (line 872) still has E6 followed directly by E7, with no organization/membership slice. The Stage 5R skeleton says plan §12 was amended, but the plan file does not reflect it. Stage 6 charters will be built from the plan, so this is a real gate problem.
2. **SM-202 is still inconsistent with ABC §7.8.**
ABC's actual enum is `durable_eligible`, `durable_eligible_confirmation_required`, `session_scoped`, `ephemeral_reroute`, `candidate_only_pending_issueframe`, `review_queue`, `reject_not_memory`. The Supersession Matrix row still lists the older `discard_not_memory` / `retain_ephemeral_observation` / `create_or_merge_assertion` style enum. DR-006 says this was verified fixed, but the file disagrees. That needs Conflict Register correction plus matrix patch authorization.
3. **OP-A still carries stale ownership.**
`OP_A_Candidate_Disposition.md` (line 16) still says DOC72 emits Assertion schema and identity contracts. That contradicts DOC82 ownership. OPA-004 similarly says DOC73 emits EvidenceRecord/EvidenceSupportEdge, and OPA-011/012 still route learning through DOC8 despite ADQ-221 resolving DOC8 as capability-mining only.
4. **The one-owner rule is still leaky.**
`DOC80_Owner_Map.md` (line 41) still has `VersionedClaim = PENDING`, `DynamicHeaderLedger = PER ADQ-305 RESOLUTION`, and several compound rows disguised with prose disclaimers. If the rule is "one schema, one owner," then rows like `SafeLabelPolicy + approved vocabulary`, `RenderBundle + PromptTextPackage`, and `LibrarySourceBinding` need to become separate atomic rows.
5. **The import graph still mixes schema imports, event production, and control flow.**
The `DOC82 ↔ DOC83` pair is acceptable as a handoff, but not as two schema imports in an acyclic graph. Same problem around DOC87: some rows point from consumer to owner while others point owner to consumer. The graph needs typed edge kinds: `imports_schema_from`, `produces_instance_of`, `executes_via`, `stores_in`, `renders_from`.
6. **ADQ-221 status drift remains.**
ADQ says resolved, RUN_STATE says resolved, but skeletal/owner-map text still says BDSM pending or DOC8/DOC85 language that predates the resolution. This matters because E9 will otherwise draft against a phantom dependency.
**Deeper Architecture Gaps**
The biggest missing architectural concern is **memory lifecycle governance**. Round D has `CascadingSourceInvalidation`, retention expiry, and deleted/clawed-back source handling, so the concept exists. But Stage 5R does not elevate it to a family-level lifecycle: retention, erasure, export, revocation, backup/recovery, and learning rollback are scattered. I would add a core `MemoryLifecycleGovernance` section or ADQ before Stage 6.
A second gap is **principal / tenant / collaborator modeling**. DOC81 has policy, DOC87 has membership, DOC20 has Project UI, but there is no clear model for shared Projects, cross-user Libraries, collaborator revocation, data subject requests, or access-set ownership. If cross-user memory is out of scope, say so explicitly. If it is in scope, it needs a decision now.
A third gap is **ordering and consistency**. The architecture has proofs and traces, but not a shared mutation model. It needs something like `MemoryMutationEnvelope` or `MemoryTransactionRecord` carrying actor, policy epoch, source epoch, transaction time, valid time, idempotency key, and rollback/invalidation refs.
**Concrete Failure Scenarios**
- User deletes a source while DOC85 is mid-learning-cycle. Current pieces can detect deletion and proof-gate learning, but there is no clear precedence rule: deletion/revocation should quarantine or cancel downstream learning artifacts.
- A Topic membership is confirmed while DOC84 is assembling a prompt. Does delivery use the old membership snapshot, block, or restart? DOC87/DOC84 need an ordering rule.
- A task agent emits an Assertion contradicting a high-warrant existing Assertion. The pieces exist, but the skeleton does not name a conflict-review path with ownership and fixture expectations.
- A shared Project is revoked by one collaborator after another user's session has injected its derived memory. No principal/collaboration model means no answer.
- A 200-page PDF enters a Topic context. DOC25/DOC82/DOC83/DOC87/DOC84 all participate, but budget/backpressure semantics are too abstract to fixture.
**Improvements**
I would add three cross-cutting records before Stage 6:
1. `MemoryMutationEnvelope`
One shared event/mutation wrapper for writes, membership changes, source invalidation, policy restamps, delivery proofs, and learning write-back.
2. `MemoryProvenanceGraph`
Not a replacement for MemoryCoordinationTrace, but a durable provenance graph: SourceArtifact → ExtractionResult → AssertionCandidateEmission → Assertion/Membership → ContextProduct → final prompt → learning signal.
3. `MemoryLifecycleGovernancePolicy`
Covers retention, source deletion, erasure, export, backup/recovery, portability, and revocation propagation.
I would also make the invariants more algebraic: membership never increases truth/warrant; policy may only narrow without explicit restamp; source revocation monotonically lowers eligibility until re-proof; learning cannot upgrade warrant without canonical evidence.
**Stage 6 Risk**
E0 cannot safely write the taxonomy while owner cells are pending/compound. DOC87 cannot write fixtures without mutation ordering. E7/E8 cannot charter cleanly while DOC24/KDA/DynamicHeader ownership is still prose-dependent. E9 cannot proceed until all DOC8/BDSM stale references are patched.
My recommendation remains: Stage 5R needs a Stage 5R′ patch. No D-SEED contradiction, so no `ARCHITECT_STOP`, but I would not start Stage 6 charters until the plan, matrix, OP-A, owner map, and import graph are made internally consistent.
---
## 4. Synthesis and Architect Adjudication
*This is the consolidated synthesis of the three reviewers above plus Will's architect decisions on DOC88, networking, and the privileged-clawback default. It is the operative work package for Stage 5R2.*
**Status:** Consolidated synthesis of three red-team passes (Claude + ChatGPT + Codex) plus architect adjudication.
**Scope:** Memory Control Plane flatten — DOC80 family (DOC80–DOC87), Stage 5R Skeletal Target Baseline.
**Verdict:** No `ARCHITECT_STOP`. Stage 5R is directionally correct. It needs **one stabilization patch round (Stage 5R2)** before Stage 6 slice charters. One architect ADQ to open (networking/sharing). Retention/erasure/legal-hold resolved without an ADQ — see §6.
**Revision history:** R1 (2026-05-27) covered Claude + ChatGPT (four documents, plus architect domain-knowledge collapse of DOC88). R2 (2026-05-27) folds in three Codex chat outputs and updates the must-fix list accordingly.
**Audience:** (1) Will, as the full review record; (2) Claude Code, as the authorized Stage 5R2 work package. The "Instructions for Claude Code" block at the end (§10) is the operative hand-off.
---
#### 1. Verdict
The 8-member decomposition is sound, the lockstep mapping holds, DOC87 was the right addition, and the import graph's *intent* is consistent with the D-SEED constraints. There is **no `ARCHITECT_STOP`** — nothing requires re-slicing the family.
Stage 5R is **not clean**. It needs a **Stage 5R2 stabilization patch** — not a second design round, but more than cosmetic. Several items in it are architectural (OP-A reconciliation, the import-graph restructure, the EC seam, the cross-artifact drift reconciliation surfaced by Codex). The distinguishing rule: Stage 5R2 *stabilizes the skeleton so Stage 6 charters do not inherit known defects*; it does **not** open new design surface or introduce new canonical object families.
After Stage 5R2, run one short regression check (§9) and then Stage 6 slice charters may begin.
---
#### 2. How this review was produced
Two red-team prompts were run against the Stage 5R artifacts, routed to three reviewers (Claude, ChatGPT, Codex) for decorrelated critique, then synthesized.
- **Round 1 (Stage 5 format, sections A–G)** — Claude and Codex each produced one review.
- **Round 2 (buckets 3.A–3.F)** — Claude and Codex each produced one review; Codex produced a third "deeper pass" focused on cross-artifact drift.
- **ChatGPT produced four documents** across the cycle:
1. A round-2 review in the required format.
2. A networking-compatibility document (answer to a separate follow-up question Will asked).
3. A task-sharing document (answer to another separate follow-up question).
4. A consolidated Stage 5R2 patch list reacting to Claude's findings — followed by a DOC88 proposal, followed by a final convergence document.
- **Codex produced three chat outputs:** a Stage 5 (round 1) review, a Stage 5R (round 2) review, and a "deeper pass" focused on cross-artifact drift (the plan file, ADQ-221 status, OP-A staleness all read against the actual repo files).
- **Will contributed three architect inputs** that materially shaped the landing: the networking question, the task-sharing question, and — decisively — domain knowledge on privileged clawback and legal hold (§6).
**Process observation, for future rounds.** Each reviewer's output quality tracked the *prompt type*, not its diligence. ChatGPT, handed leading follow-up questions ("should we account for X?"), predictably answered "yes" and built a large speculative layer — the networking, task-sharing, and DOC88 documents collectively proposed ~15 new schemas, ~50 lints, and ~20 fixtures, all routed at "Stage 5R2." When handed a review to react to, ChatGPT was disciplined and converged tightly. Codex, working with direct filesystem access, was strongest on cross-artifact drift findings — it caught discrepancies between what the Stage 5R artifacts *claim* (e.g., "plan §12 amended for DOC87") and what the actual companion files (plan, ADQ register, OP-A, matrix) *contain* — a class of finding that text-only reviewers cannot reliably produce. Claude's subtractive stroke compressed overreach and surfaced the systematic OP-A staleness early. **For the next cycle, feed the second and third reviewers the consolidated review and ask them to argue for cuts — not open-ended "should we also consider Y" prompts. Keep at least one reviewer with direct filesystem access** for cross-artifact drift detection.
---
#### 3. Convergence — what reviewers independently found
Three independent passes (and four documents from one of them) agree on the following. This is the high-confidence core; treat it as settled.
- **No `ARCHITECT_STOP`; Stage 5R2 needed.** Unanimous across all three reviewers.
- **OP-A Candidate Disposition is stale.** Stage 5R *augmented* OP-A (added OPA-025–030 for DOC87) but never *reconciled* OPA-001–024 against the 8-member ownership model. Highest-leverage defect. (Claude originally surfaced this; ChatGPT and Codex both confirmed.)
- **The Owner Map one-owner rule is only partially applied.** Compound/non-doc/placeholder owner rows survived the B3 patch.
- **The import graph mixes schema imports with runtime/control flow.** The DOC82↔DOC83 pair reads as a cycle; DOC87 edge directions are inconsistent with the owner-to-consumer convention (Codex).
- **DOC8 is still treated as a runtime learning owner** in Owner Map rows, contradicting ADQ-221.
- **Retention/erasure/legal-hold was unaddressed** (resolution in §6 — all reviewers initially over-built this; it has since collapsed).
- **Recovery/replay, concurrency/ordering, observability, and scale/quota** are unstated or unowned.
- **VersionedClaim and WorkSession** are unresolved matrix-gap dispositions.
Each reviewer also caught things the others missed:
**ChatGPT caught (Claude adopted):**
- The compound-owner problem is **at least six rows, not four** — adds `Procedural taxonomy … | DOC72 + DOC3` and the DAMS rows labeled `owner = "DAMS V5"` (a non-member, non-doc owner label).
- The **four-edge-kind import graph** (`schema_import` / `runtime_instance_flow` / `command_or_control_flow` / `storage_or_execution_flow`) — a better fix than "normalize the from/to notation."
- The **DOC81/DOC87 non-overlap invariant** — `MemoryMembershipEdge` ≠ `ScopeContainerRelation`.
- The **EC `ECSeamContract`** — naming the EC seam explicitly.
- The **DOC87 `TopicIdentityContract` stub** — minimal Topic-identity contract landing before DOC83 drafting.
**Claude caught (others missed or under-weighted):**
- The **systematic OP-A staleness** — Claude surfaced it first; both other reviewers then confirmed once shown.
- The **DOC83→DOC87 backward-dependency / slice-ordering inversion** — DOC83's `TopicCollectionDirective` imports DOC87 Topic identity, but ADQ-220 slices DOC87 after E6.
- The **SM-202 / DR-006 enum-value mismatch** — independently confirmed by Codex with the same actual ABC §7.8 enum.
- The **DOC85-charter chicken-and-egg** — ADQ-221 defers BDSM-surface specifics to DOC85/E9 while BDSM v6.5 is itself being revised alongside DOC85.
- The **§18 golden-scenario phase mis-ordering** — policy listed after extraction.
**Codex caught (Claude and ChatGPT missed — new in R2):**
- **Cross-artifact drift as a pattern.** The Stage 5R artifacts assert architectural facts that companion files do not actually reflect. Codex flagged three concrete instances:
- **The plan file (`Flatten_and_Unify_Plan_V2_1c.md`) may not actually have been amended for DOC87.** Codex (citing line 872) reports that E6 is still followed directly by E7 with no organization/membership slice inserted. The Stage 5R skeletal baseline says plan §12 was amended; the plan file does not reflect it. **Independent verification required** — Filesystem MCP was unavailable when this synthesis was produced, so the claim is propagated from Codex but not verified here. If confirmed, this is potentially the single most consequential finding of the cycle: Stage 6 charters are built from the plan, and the plan would be missing DOC87.
- **ADQ-221 status drift.** The ADQ file and RUN_STATE say resolved; some skeletal/Owner Map prose still treats BDSM as "pending" or routes learning through DOC8/DOC85 language that predates resolution.
- **OP-A staleness** (independently confirmed; this is the same finding Claude originally surfaced).
- **Owner Map placeholder strings beyond compound owners** — `VersionedClaim = PENDING` and `DynamicHeaderLedger = PER ADQ-305 RESOLUTION` are literal non-owner placeholders in owner cells, on top of the compound rows.
- **Inverted/inconsistent DOC87 import edge directions** — some lateral rows point owner→consumer, others consumer→owner. Specifically: `DOC84 → DOC87`, `DOC86 → DOC87`, `DOC87 → DOC82`.
- **DOC87 charter requires transaction/conflict semantics** — membership transition ordering, conflict resolution, idempotency need to be defined before DOC87 fixtures can be written.
- **Naming candidates for cross-cutting cross-slice concepts** — `MemoryMutationEnvelope` (shared event-sourced mutation wrapper with actor / policy-epoch / source-epoch / transaction-time / valid-time / idempotency-key / proof-refs / rollback-refs) and `MemoryProvenanceGraph` (durable PROV-style provenance graph distinct from MemoryCoordinationTrace). Naming, not drafting.
- **ABC §21 normalization objects not all placed.** Codex's list (subtracting those Stage 5R already addressed): `WarrantEvaluationResult`, `WarrantConsequenceRegistry`, `DomainProfileWarrantPolicy`, `IngestionCostBudget`, `PromotionGateRecord`, `ConsideredItemLedger`, `PromptShellExposure`. (TopicLens → DOC87, MemoryMembershipEdge → DOC87, domain-profile registry → DOC80 core §12, WorkSession → DOC83 already addressed.)
---
#### 4. Stage 5R2 — consolidated must-fix list (before Stage 6 charters)
Twelve items. All three reviewers' final positions converge on this list with Codex contributing items #2 (placeholder rows), #3 (DOC87 edge direction check), and #10 (cross-artifact drift reconciliation).
1. **Reconcile OP-A.** Re-check every OPA-001–024 row against the 8-member Owner Map. Known stale rows:
- **OPA-001** — Assertion schema → **DOC82** (not "DOC72 emits"); DOC72 *stores* graph payload; EC writes.
- **OPA-004** — `EvidenceRecord` / `EvidenceSupportEdge` → **DOC82** (not DOC73 emitter).
- **OPA-005** — classification/extraction spine → **DOC83**; DAMS is a **DOC84** substrate, not an owner (SM-020).
- **OPA-011 / OPA-012** — learning participant → **DOC85**; legacy DOC8 is capability-mining only (ADQ-221).
- Add any missing OPA rows surfaced by Stage 5R2 (EC seam; DOC83↔DOC87 co-drafting; legal-hold on non-memory destructive jobs — see §6).
*Rationale: OP-A rows are the cross-doc amendment obligations Stage 6 hands to DOC72/DOC73/etc. Stale rows propagate the wrong architecture into the amendments.*
2. **Mechanically clean the Owner Map.** Three classes of violation to fix:
- **(a) Compound/non-doc owners (6 rows).** No owner cell may contain "+" or a non-doc/non-member label.
- `LibrarySourceBinding` (DOC82 + DOC25) → DOC25 owns; DOC82/DOC87 *consume* via separate contracts.
- `SafeLabelPolicy + approved vocabulary` (DOC86 + PropA/EC) → `SafeLabelDisclosurePolicy` → DOC81; `ApprovedSafeLabelVocabularyRegistry` → PropA/EC; `SafeLabelRenderContract` → DOC86.
- `RenderBundle + PromptTextPackage` (DOC24 + KDA) → `RenderBundle` → KDA; `PromptTextPackage` → DOC24.
- `false-suppression sampling` (DOC85 + DOC8) → DOC85; DOC8 reference removed (capability-mining only).
- `Procedural taxonomy + standing-procedure / skill / task` (DOC72 + DOC3) → split into the DOC72 taxonomy row and the DOC3 procedural-memory-seam row.
- DAMS rows labeled `owner = "DAMS V5"` → **DOC84**.
- **(b) Placeholder strings (2 rows).** Codex found these in addition to the compound rows. They must be resolved to a concrete owner before Stage 6:
- `VersionedClaim = PENDING` — resolved by item #8 (recommended: VersionedClaim retained as DOC73-owned lineage, with DOC82 defining a `VersionedClaim → AssertionVariant` lineage table).
- `DynamicHeaderLedger = PER ADQ-305 RESOLUTION` — resolve via DR-004 and the ADQ-305 escalation path; recommended owner is DOC84.
- **(c) Verify** the Owner Map's own `owner_map.compound_schema_owner` lint passes after the cleanup.
*The B3 one-owner patch was applied in prose, not structurally. The Owner Map as written fails its own lint on the compound rows.*
3. **Restructure the import graph into four edge kinds** — `schema_import`, `runtime_instance_flow`, `command_or_control_flow`, `storage_or_execution_flow`. This dissolves the DOC82↔DOC83 phantom cycle. **Codex additionally flagged inverted/inconsistent DOC87 edge directions** (`DOC84 → DOC87`, `DOC86 → DOC87`, `DOC87 → DOC82`) — some pointing owner→consumer, others consumer→owner. Verify every DOC87 edge against a single owner-to-consumer convention as part of the restructure. Re-state §5.6's acyclicity proof to cover the normalized graph.
4. **Resolve the DOC83→DOC87 backward dependency.** DOC83's `TopicCollectionDirective` imports DOC87 Topic identity, but DOC87 is sliced after DOC83 (ADQ-220, between E6 and E7). Fix: carve out a minimal DOC87-owned **`TopicIdentityContract`** (with `MembershipTargetRef`, `ContainerRef`) that lands before DOC83 drafting.
5. **Purge DOC8-as-runtime language** from the Owner Map learning rows. DOC85 owns the memory-learning architecture; BDSM is a partial substrate consumed where pinned and real; legacy DOC8 is capability-mining / lineage only. No row may say DOC8 computes or executes runtime learning behavior. *(Codex additionally noted residual "BDSM pending" prose in skeletal text that contradicts ADQ-221's resolved status — see item #10.)*
6. **State the DOC82↔DOC83 disposition/resolution seam.** Do **not** relocate the enum. `AssertionCandidateDisposition` is defensibly owned by DOC83 (it is a triage-routing output; ABC §7.8 sits inside ABC §7, the Extraction Spine). The real risk is that ABC §7.8's two-stage model (disposition + dedupe-outcome) is now split across DOC83 and DOC82, making its anti-overlap rule an unenforceable inter-member obligation. Fix: state the seam explicitly; assign the ABC §7.8 anti-overlap rule to **DOC82** (which owns resolution/dedupe); `AssertionCandidateEmission` carries a *recommended* disposition into DOC82.
7. **Re-open DR-006 in the Conflict Register.** SM-202's parenthetical "ABC §7.8 7-value enum" misquotes the enum. The actual ABC §7.8 `AssertionCandidateDisposition` enum is:
`durable_eligible`, `durable_eligible_confirmation_required`, `session_scoped`, `ephemeral_reroute`, `candidate_only_pending_issueframe`, `review_queue`, `reject_not_memory`.
SM-202 instead lists: `discard_not_memory`, `retain_ephemeral_observation`, `retain_session_note`, `record_friction_event`, `update_issue_frame`, `retain_as_evidence_only`, `create_or_merge_assertion`. DR-006 recorded "verified consistent" but verified structure, not values. Correct SM-202, the Retired Names alias rows, and any Owner Map citation against ABC §7.8 *as written*. **This fix must be done by someone reading ABC §7.8 directly — not propagated from this document's paraphrase.** *(Independently confirmed by Codex with the same actual ABC §7.8 enum values.)*
8. **Resolve or charter-gate VersionedClaim and WorkSession.** Recommended dispositions (architect to confirm): WorkSession retained as a light temporal grouping under DOC83, not user-visible by default; VersionedClaim retained as DOC73-owned lineage, with DOC82 defining a `VersionedClaim → AssertionVariant` lineage table. If unresolved, they block the relevant DOC82/DOC83 charters and the Owner Map cleanup in item #2(b).
9. **Mark EC as `partial / moving` and add an `ECSeamContract`.** EC is the sole durable writer/executor for policy, scope, membership, learning write-back, and durable Assertion writes — and EC is itself a known-stale doc. Set `ExternalDependencyRecord(EC).dependency_status = partial`. Add a named `ECSeamContract` covering durable write execution, command execution, policy/scope execution, membership write execution, learning write-back, audit/replay, transaction ordering, and compare-and-swap / generation revalidation.
10. **Cross-artifact drift reconciliation (NEW in R2 — surfaced by Codex).** Stage 5R patches were applied to the primary artifacts but not consistently propagated to dependent companion files. Items #1 (OP-A), #2 (Owner Map placeholders), and #7 (SM-202) are all instances of the same pattern. Codex surfaced two additional instances that must be verified and reconciled in Stage 5R2:
- **(a) Plan file DOC87 amendment.** Codex claims (citing `Flatten_and_Unify_Plan_V2_1c.md` line 872) that the actual plan file still has E6 followed directly by E7, with no organization/membership slice inserted, despite the Stage 5R skeletal baseline asserting plan §12 was amended. **This must be verified by reading the plan file directly.** If the claim is correct, patch the plan to insert the DOC87 slice between E6 and E7 per ADQ-220's resolution. *Note: this synthesis was produced without Filesystem MCP access, so the claim is propagated from Codex but not verified here.*
- **(b) ADQ-221 status consistency.** The ADQ register and RUN_STATE say resolved; some prose in the skeletal baseline and Owner Map still says "BDSM pending" or routes learning through DOC8/DOC85 language predating resolution. Reconcile the language to match the resolved status.
- **(c) Standing maintenance discipline.** Add a Stage 5R2 closing step: after every artifact patch, sweep companion files (OP-A, ADQ register, RUN_STATE, plan, matrix, conflict register) for consistency. The cross-artifact drift pattern is generic — future patch rounds need a structural defense, not just one-time reconciliation.
11. **Open one architect ADQ: network/sharing forward-compatibility.** See §7. Do **not** draft envelopes or contracts in Stage 5R2.
12. **Add two DOC80-core statements:**
- **V5 non-goal:** "DOC80 V5 is local-first, single-principal, single-node, single-EC-writer unless a later spec explicitly extends it. Multi-device sync and cross-user memory are out of scope for V5."
- **Manual deletion / unreachability:** "EC can delete any memory object on request. A memory object that is not reachable for retrieval/injection is, by the same token, not reachable for use — unreachability is self-limiting." (Supports the retention/erasure landing in §6.)
---
#### 5. Stage 5R2 fold-ins — recommended, non-blocking
Fold these into Stage 5R2 if cheap; none block Stage 6 charters on their own.
- **Legal-hold flag + invariant** (the retention/erasure landing — see §6): a DOC81 `LegalHoldState` flag (held / not held, with scope), plus the invariant that every automated destructive job checks it and skips held objects. Emit **OP-A rows** for the non-memory destructive jobs that must also honor it (DOC72 §42 cleanup/folding, DOC23, DOC25).
- **Confirm `CascadingSourceInvalidation` fans out to all five planes** — DOC82 support edges, DOC87 memberships, DOC84 prior-delivery/carryover, DOC85 learning eligibility, DOC86 inspector. This is a wiring check on an existing primitive, not a new mechanism. (This is the *real* "source revocation" finding — see §6.)
- **DOC81/DOC87 non-overlap invariant** — `MemoryMembershipEdge` ≠ `ScopeContainerRelation`; membership does not imply scope containment, access, source authority, or truth.
- **Name `MemoryMutationEnvelope` as a cross-cutting concept (Codex).** A shared event-sourced mutation wrapper carrying actor, policy epoch, source epoch, transaction time, valid time, idempotency key, proof refs, and rollback/invalidation refs. **Name only; defer schema body to Stage 7.** This subsumes the concurrency revalidation rule below and gives every slice a shared ordering target so they don't each invent local ordering.
- **Name `MemoryProvenanceGraph` as a cross-cutting concept (Codex).** A durable PROV-style provenance graph from `SourceArtifact → ExtractionResult → AssertionCandidateEmission → Assertion/Edge/Membership → ContextProduct → final prompt → learning signal`. Distinct from `MemoryCoordinationTrace` (per-request); the provenance graph is the durable cross-request artifact. **Name only; defer schema body to Stage 7.**
- **Verify ABC §21 normalization-object placement (Codex).** Confirm or add Owner Map rows for: `WarrantEvaluationResult` (likely DOC82 §1.8 — Claude's round-1 F2 also flagged this), `WarrantConsequenceRegistry`, `DomainProfileWarrantPolicy`, `IngestionCostBudget`, `PromotionGateRecord`, `ConsideredItemLedger`, `PromptShellExposure`. Anything missing should be slotted; nothing requires a new family member.
- **Lightweight memory-object classification table** — one row per family (object_family, owner, truth-apt?, source-bound?, durable?, derived/projection?, policy-gated?, delivery-eligible?, UI-visible?, learning-eligible?). Drop any `network_compatibility_required?` column (premature). Prevents CUs / Topics / membership edges / rollups from drifting back into truth stores.
- **Embedding-model-migration refs** — `AssertionIdentitySignature` and `semantic_equivalence` dedupe should record `embedding_model_ref` / `embedding_generation_id`; migration invalidates or re-checks affected dedupe results and projections.
- **Observability / health seam** — name where memory-plane aggregate health lives (counters for source-invalidation backlog, membership-restamp backlog, policy-restamp failures, missing proof artifacts, runaway future-watch, search-affordance preflight failures, learning-signal suppression).
- **Scale / quota assumptions** — name bounds for `CascadingSourceInvalidation` fan-out and conflict-set projection; extend the family-wide compute budget toward a `MemoryOperationQuota`.
- **§18 golden-scenario phase-order fix** — policy precedes extraction. **Codex sharpened this**: the golden scenario should explicitly include a revocation case and a policy-change-mid-extraction case, not just a happy path.
- **Concurrency revalidation rule** — EC revalidates `AssertionDedupeOutcome` against current state inside its serialized write (compare-and-swap), or the outcome carries a `dedupe_basis_generation_id` token. *(If `MemoryMutationEnvelope` is named, this rule becomes one of its enforcement requirements.)*
- **`CognitiveDiff` → `ResumeProjection` / `ResumeCard` rename** — defined as a derived presentation, not truth and not evidence.
- **DOC87 charter prerequisite (Codex E-1 from round 2).** The DOC87 charter cannot write fixtures without membership transition ordering, conflict resolution, and idempotency. Add this as a named charter-input obligation in the OP-A row for E7 (DOC87). Naming the `MemoryMutationEnvelope` above largely satisfies this if DOC87 declares its membership transitions as `MemoryMutationEnvelope` instances.
---
#### 6. DOC88 / retention / erasure / legal hold — full analysis and final landing
This section is unchanged from the R1 synthesis; included here for completeness so this document stands alone.
##### 6.1 How it escalated
- Both round-2 reviews flagged retention/erasure/legal-hold as a missing owner — `retired` ≠ erased; tension with the append-only audit/proof spine. (Codex also flagged this in both its round-2 and deeper-pass documents.)
- ChatGPT's consolidated patch list (doc 6) recommended: a DOC81 cross-plane retention/erasure contract; **do not create DOC88 yet**.
- Will then asked, as a separate question, whether the broader deletion/clawback requirements "argue for a separate DOC88." ChatGPT's next document (doc 7) flipped to **"create DOC88"** — a cross-ELNOR Data Lifecycle / Retention / Erasure / Legal Hold / Revocation / Clawback spec, with ~20 schema families and ten lints.
- ChatGPT's final document (doc 8) walked that back: **do not draft DOC88 in Stage 5R2**; open an architect ADQ; name the destruction-vs-degradation tension.
The flip from "no DOC88" to "DOC88" was driven by the *framing of a leading follow-up question*, not by new evidence.
##### 6.2 The architect input that collapsed it
Will supplied the domain knowledge that resolves this. Two facts:
1. **Hard destruction of privileged material is extraordinarily rare.** In a 20-plus-year securities-litigation career: twice, both email. The probability of it ever being required *inside ELNOR* is slim, and if it happens it is the kind of thing handled by a human manually deleting the item. The only residual edge case — a memory so buried it cannot be located and deleted — is self-limiting: if it cannot be reached to delete, it cannot be reached to retrieve or inject either.
2. **Legal holds can occur and are not as rare, but a hold is not a deletion mechanism.** A hold is the opposite — a temporary "do not delete anything in this scope" freeze. Will's stated handling: "turn off all potentially relevant deletion until the appropriate time."
##### 6.3 Why this collapses DOC88
The reviews treated "retention / erasure / legal hold / clawback" as one bundle and let the rarest, hardest member — automated hard destruction with a cross-suite cascade — set the architectural ceiling. That is backwards.
- **Hard destruction** is twice-in-a-career and manual. It needs no spec, no owner doc, no cascade engine. The architecture owes it exactly one guarantee: a memory object is **addressable and deletable by EC**. → One sentence in DOC80 core (must-fix item 12).
- **Legal hold** is a *pause on the things that already delete*, not new machinery. ELNOR's destructive paths are a finite, knowable set: DOC72 §42 nightly graph cleanup / entropy jobs, semantic folding, retention-driven auto-prune, archive-after-N, compaction. A hold suspends those over a scope until released. → A DOC81 `LegalHoldState` flag + the invariant that automated destructive jobs honor it (fold-in, §5).
- **Source revocation as degradation** — the genuinely common case — *already has its mechanism*: `CascadingSourceInvalidation`. The real finding was the narrow wiring check that it reaches all five planes. → Fold-in, §5.
The "destruction vs degradation vs tombstone vs audit-spine tension" mostly dissolves. Degradation does not fight the append-only audit model. A hold destroys nothing. Manual hard destruction is one human-driven append-an-event.
##### 6.4 Final landing
- **DOC88 is off the table.** It was sized for an automated destruction-cascade engine ELNOR does not need. It is also outside the memory-flatten's scope.
- **Retention/erasure is no longer an ADQ.** It collapses to:
1. **DOC80 core** — one sentence: EC can manually delete any memory object on request; unreachable = uninjectable (must-fix item 12).
2. **DOC81** — a `LegalHoldState` flag plus the invariant that automated destructive jobs check it (fold-in, §5).
3. **OP-A rows** — for the non-memory destructive jobs that must also honor the hold (DOC72 §42, DOC23, DOC25). Cross-doc obligations — OP-A rows, not a spec.
- **Architect decision recorded:** **Degradation, not destruction, is the privileged-clawback default in ELNOR.**
---
#### 7. Networking / sharing — analysis and the one ADQ
ChatGPT's networking and task-sharing documents proposed `NetworkCompatibilityEnvelope`, `PublishedViewEnvelope`, `TaskSharedMemoryExposureContract`, ~40 lints/fixtures, all routed at Stage 5R2. Codex's round-2 review independently flagged the same gap (shared/collaborative memory not modeled; principal/tenant/collaborator missing).
**Assessment:** the *recognition* is fair across all three reviewers — ELNOR is currently single-user by accident. But ChatGPT's *response* is scope creep. It violates the round-2 prompt §5 (no schema bodies) and plan §11.3 (new canonical family = `architect_stop`). A speculative envelope guessed before the network design is settled is as likely to mislead Stage 7 drafters as to help them.
**The genuinely cheap insurance** is three things: (1) stable IDs / generation refs on durable objects — *mostly already present* (`AssertionIdentitySignature`, `policy_generation_id`, `EpisodePolicyEpoch`, `MemoryCoordinationTrace`); confirm it; (2) the explicit V5 non-goal sentence (must-fix item 12); (3) one ADQ.
**The ADQ to open (must-fix item 11):** network/sharing forward-compatibility. Decide whether Phase-1 sharing is near-term roadmap. If yes, the DOC80-side obligation is to name the seams as OP-A rows (DOC80↔DOC23 task-shared surfaces; DOC80↔DOC73/DOC25 Library/Corpus published surfaces) plus an invariant — *not* the envelope/contract schemas. Schema bodies are Stage 7 work, gated on the ADQ.
---
#### 8. Reviewer-by-reviewer disposition
| Item | Source | Disposition |
|---|---|---|
| No `ARCHITECT_STOP`; Stage 5R2 needed | All three | **Adopt** — settled |
| OP-A reconciliation (OPA-001/004/005/011/012 stale) | Claude (ChatGPT + Codex confirmed) | **Adopt** — must-fix #1 |
| Six compound/non-doc owner rows; DAMS→DOC84 | Both (ChatGPT more complete) | **Adopt** — must-fix #2(a) |
| Owner Map placeholder strings (`PENDING`, `PER ADQ-305 RESOLUTION`) | **Codex** | **Adopt** — must-fix #2(b) |
| Four-edge-kind import graph | ChatGPT (Claude adopted) | **Adopt** — must-fix #3 |
| Inverted DOC87 import edge directions | **Codex** | **Adopt** — must-fix #3 (verify during restructure) |
| DOC83→DOC87 ordering inversion | Claude | **Adopt** — must-fix #4 |
| DOC87 `TopicIdentityContract` stub as the fix | ChatGPT (Claude adopted) | **Adopt** — must-fix #4 |
| Purge DOC8-as-runtime language | All three | **Adopt** — must-fix #5 |
| `AssertionCandidateDisposition` → DOC82 ("BUG", relocate) | ChatGPT | **Modify** — downgrade BUG→GAP; do *not* relocate; state the seam (must-fix #6) |
| DOC82↔DOC83 disposition/resolution seam | Claude | **Adopt** — must-fix #6 |
| SM-202 / DR-006 enum-value mismatch | Claude (Codex independently confirmed) | **Adopt** — must-fix #7 |
| VersionedClaim / WorkSession unresolved | All three | **Adopt** — must-fix #8 |
| EC `partial/moving` + `ECSeamContract` | ChatGPT (Claude adopted) | **Adopt** — must-fix #9 |
| **Plan file DOC87 amendment may not have landed** | **Codex** | **Adopt — must-fix #10(a) — VERIFY FIRST** |
| **ADQ-221 status drift in skeletal/Owner Map** | **Codex** | **Adopt** — must-fix #10(b) |
| **Cross-artifact drift as a pattern** | **Codex** | **Adopt** — must-fix #10 framing; #10(c) adds standing discipline |
| DOC81/DOC87 non-overlap invariant | ChatGPT | **Adopt** — fold-in |
| **Name MemoryMutationEnvelope** | **Codex** | **Adopt** — fold-in (name only, no schema) |
| **Name MemoryProvenanceGraph** | **Codex** | **Adopt** — fold-in (name only, no schema) |
| **Verify ABC §21 normalization objects** | **Codex** | **Adopt** — fold-in |
| **DOC87 charter ordering/conflict/idempotency prerequisite** | **Codex** | **Adopt** — fold-in (charter-input OP-A row) |
| Embedding-migration refs | Claude/ChatGPT | **Adopt** — fold-in |
| §18 phase-order fix + revocation scenarios | Claude (Codex sharpened) | **Adopt** — fold-in |
| Concurrency revalidation rule | Both | **Adopt** — fold-in |
| Memory-object classification table | ChatGPT | **Adopt (lightweight)** — fold-in |
| Observability / quota seams | All three | **Adopt** — fold-in |
| `CognitiveDiff` rename | ChatGPT | **Adopt** — fold-in |
| **`SuspendedContextAssembly` / `SearchAffordanceEligibilityDecision` / `FalseSuppressionSamplingPolicy` renames** | **Codex D-5** | **Defer** — nice-to-have; not blocking; can be charter-time |
| Retention/erasure as a 9th member / DOC81 cross-plane contract | Claude (early) / ChatGPT doc 6 | **Superseded** by §6 landing |
| **DOC88 cross-ELNOR lifecycle spec** | ChatGPT doc 7 | **Reject** — see §6; collapses to a DOC81 flag + invariant + OP-A rows |
| `NetworkCompatibilityEnvelope` / `PublishedViewEnvelope` / `TaskSharedMemoryExposureContract` / new policy actions | ChatGPT docs 4–5 | **Route to ADQ** — not Stage 5R2 |
| ~40 networking/lifecycle lints + ~20 fixtures | ChatGPT docs 4–5, 7 | **Route to ADQ / Stage 7** — premature |
---
#### 9. Stage 5R2 exit check
After Stage 5R2, run one short regression review before Stage 6 charters:
> Does Stage 5R2 close: OP-A staleness; Owner Map one-owner violations (including placeholders); import-graph edge-kind ambiguity and the DOC83→DOC87 ordering and DOC87 edge directions; the DOC8/DOC85 language; the DOC82↔DOC83 seam; SM-202/DR-006; the EC seam; VersionedClaim/WorkSession; **and the cross-artifact drift (plan file DOC87 amendment, ADQ-221 status consistency)?** Is the network/sharing ADQ open? Are the DOC80-core non-goal and manual-deletion statements present, and is the DOC81 `LegalHoldState` flag + invariant in place? — If yes, Stage 6 slice charters may begin.
---
#### 10. Instructions for Claude Code
You will be given the four red-team review documents (this synthesis plus the three reviewer files) alongside ChatGPT's consolidated patch instruction document. **Read this synthesis first; it tells you what is authorized and what is not.**
**Authorized for Stage 5R2** — the twelve must-fix items in §4 and the fold-ins in §5. That is the entire Stage 5R2 work package. It is a stabilization patch: it cleans the four primary artifacts (Skeletal Baseline, Import Graph, Owner Map, Retired Names), the plan file, OP-A, the Conflict Register, and the ADQ register; and it adds a small number of named statements/contracts. It does **not** open new design surface.
**NOT authorized — do not act on these even though ChatGPT's documents propose them:**
- **Do not create DOC88.** ChatGPT proposed a cross-ELNOR Data Lifecycle / Retention / Erasure / Legal Hold / Revocation / Clawback spec. It is declined (§6). Retention/erasure/legal-hold is handled by: (a) one DOC80-core sentence; (b) a DOC81 `LegalHoldState` flag + invariant; (c) OP-A rows for non-memory destructive jobs. No new doc, no new member, no `LifecycleRequest` / `LifecycleEffectPlan` / `DeletionMode` / `DataObjectClass` schema set.
- **Do not draft `NetworkCompatibilityEnvelope`, `PublishedViewEnvelope`, `TaskSharedMemoryExposureContract`, `PublishedLibraryCorpusExposureContract`, or new `MemoryPolicyAction` values.** Networking/sharing is routed to a single architect ADQ (§7). Stage 5R2 adds only the ADQ and the V5 non-goal sentence. Schema bodies are Stage 7 work, gated on the ADQ.
- **Do not draft `MemoryMutationEnvelope` or `MemoryProvenanceGraph` schema bodies.** Codex named these as cross-cutting concepts to name now. **Name them in the relevant skeletal sections; do not write field lists.** Schema bodies are Stage 7 work.
- **Do not add the ~40 networking/lifecycle lints or ~20 fixtures** from ChatGPT's documents. They presuppose schemas that do not exist yet.
- **Do not restore the retired 11-value `AssertionCandidateDisposition` enum.**
- **Do not relocate `AssertionCandidateDisposition` to DOC82.** It stays at DOC83; state the seam instead (§4 item 6).
- **Do not redraw family boundaries.** DOC87 is the only family change, and it is already accepted.
**Three specifics that require direct source reading, not propagation from this document:**
- **The plan file DOC87 amendment (must-fix #10(a)):** Codex claims `Flatten_and_Unify_Plan_V2_1c.md` line 872 still shows E6 followed directly by E7 with no DOC87 slice. **Verify this by reading the plan file directly before patching.** This synthesis was produced without Filesystem MCP access, so the claim is reviewer-reported and not independently verified here. If verified, insert the DOC87 organization/membership slice between E6 and E7 per ADQ-220 — and check the entire §12 slice sequence for consistency with the resolved ADQ-220 state.
- **SM-202 / ABC §7.8 (must-fix #7):** the corrected enum values must be taken from ABC R0.2 §7.8 *as written in the repo*. The values in §4 item 7 of this document are believed correct but must be verified against the source file before the fix is committed. Re-open DR-006 in the Conflict Register.
- **`CascadingSourceInvalidation` fan-out (fold-in, §5):** verify against the actual DOC82/DOC84/DOC85/DOC86/DOC87 skeletal sections that the invalidation reaches all five planes.
**Cross-artifact discipline (new in R2):** After every artifact patch, sweep the dependent companion files for consistency. The Stage 5R cycle revealed that patches landed in the four primary artifacts but not in OP-A, the plan, the ADQ register / RUN_STATE prose, or SM-202. This is a generic pattern, not a one-time bug. As a Stage 5R2 closing step, after applying must-fix items #1–#9 and #11–#12, sweep:
- OP-A Candidate Disposition (item #1 directly addresses this)
- Owner Map placeholder rows (item #2(b))
- Plan file §12 slice list (item #10(a))
- ADQ-221 status references in skeletal and Owner Map prose (item #10(b))
- SM-202 / Retired Names / DR-006 (item #7)
- Any prose in the skeletal baseline that asserts an architectural fact whose canonical home is a different file — verify the canonical file matches
**Process reminder:** per standing maintenance discipline, update OP-A at the close of the Stage 5R2 session — move absorbed obligations, update statuses, add new rows (including the new legal-hold OP-A rows, any network/sharing seam rows if the ADQ confirms Phase-1 sharing, the EC seam rows, and the DOC87 charter-ordering prerequisite row), and log the action. Stage 5R2 increments file versions; do not reuse filenames.
---
*End of synthesis R2. This document consolidates three red-team passes (Claude, ChatGPT, Codex — Codex contributing the cross-artifact drift dimension new in this revision) and the architect adjudication for the DOC80 Stage 5R Skeletal Target Baseline round-2 review. The operative hand-off is §4 (must-fix), §5 (fold-ins), §6 (DOC88 landing), §7 (the one ADQ), and §10 (Claude Code instructions).*