ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/Stage_5R_Skeletal_DOC80_Review_Prompt.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Red-Team Review — DOC80 Stage 5R Skeletal Target Baseline (Round 2) This is a **broad architectural review** of the patched Stage 5R skeletal DOC80 baseline. We want substance, not box-checking. Round 1 found real issues; we patched them; this round needs to confirm the patches are right AND surface anything round 1 missed, anything that's broken, anything that could be materially better. The architecture decisions made here propagate through every slice charter (Stage 6), every slice draft (Stage 7), and the final spec (Stage 10). Errors here are very expensive; ideas here have very high leverage. **Be substantive.** "Looks good" is the failure mode. "Here's a scenario where this falls over" / "Here's a capability you're making harder than necessary" / "Here's a better way to express this invariant" / "Here's an entire concern that isn't addressed" — that's the value. --- ## 1. Where to find the files **Repository:** github.com/wbrody/Elnor-Specs — branch `main`. Use exact paths (folders have spaces, capitalization matters). If you have repo read access, fetch these paths directly. Otherwise Will will attach them. ### Primary review targets (the four Stage 5R artifacts — all rewritten end-to-end from round 1) 1. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` — the main skeletal architecture. **8 family members** (DOC80 core + DOC81 scope/policy + DOC82 knowledge/source/evidence + DOC83 extraction/temporal + DOC84 delivery/prompt/proof + DOC85 learning + DOC86 UI/Inspector/Search + DOC87 organization/membership). Per-schema ownership handoff from DOC72 / DOC24 / DOC73. Owner boundaries with 15+ external docs. 2. `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md` — directed import graph (DOC80 at top; slice members downstream); external owner-doc imports with pinning; plan §18 import-graph proof. 3. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md` — schema-by-schema ownership table (owns / stores / executes / generates / consumes). One-owner rule. 4. `Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md` — 22 retired-name entries with allowed historical context + alias expiry. ### Context for understanding what changed at Stage 5R - `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R_Red_Team_Adjudication.md` — finding-by-finding adjudication from round 1, with status changes and reviewer guardrails. **Read this first** to know what's in the patched artifacts and why. - `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5_Skeletal_DOC80_Review_Response.md` — verbatim round-1 review (Claude-synthesizer + ChatGPT×2 + Gemini-style with guardrails). ### Context (read-only; do NOT re-review) - `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — plan §18 (skeletal spec gate) governs this stage. - `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md` — canonical "old → new" mapping (49 rows; not edited at Stage 5R). - `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — 43 rows (42 resolved + 1 open: ADQ-221 charter-gate). - `Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md` — 6 resolved disagreements. - `Memory Rebuild Docs/Flattening/Execution Ledger/OP-A Disposition/OP_A_Candidate_Disposition.md` — 30 cross-doc obligations. - `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/12_ABC_Consolidated_Structural_Patch_R0_2.md` — senior structural patch (DR-001: senior to Concept Model). - `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/13_Round_D_Policy_Scope_UI_Micro_Patch_R0_2.md` — senior policy/scope/UI patch. --- ## 2. What is settled (do not re-litigate) Round 1 settled the following. Re-opening them needs concrete evidence of contradiction with D-SEED-1 (DOC80 = spec family) or D-SEED-2 (DOC80 = real owner doc in ELNOR hierarchy). Bring evidence, or move on: - **D-SEED-1 / D-SEED-2 / D-SEED-3 / D-SEED-4** — pre-resolved seed decisions. - **41 Stage 4 architect decisions** (ADQ-201 through ADQ-405 less ADQ-220 / ADQ-221) — all resolved at Stage 4 with reviewer-mediated approval; comments on those should go through the Architect Decision Queue, not this review. - **ADQ-220 (DOC87 creation)** — resolved at Stage 5R by reviewer-with-architect. - **The plan §12 lockstep mapping** (E1+E2→DOC81, E3+E4→DOC82, E7+E8→DOC84) — verified correct against the engine map at round 1. - **`AssertionCandidateDisposition` is the 7-value ABC §7.8 enum.** The 4 retired Concept Model §17.3 values stay retired; their capabilities are re-homed via `NonAssertionExtractionOutcome` (DOC83), not by reviving the old enum. - **The specific import cycle that was fixed:** `DOC81 → DOC84 → DOC86 → DOC81`. The B1 fix replaced `DOC86 → DOC81` with `DOC81 → DOC86`. (A *different* new cycle would be a finding — see §3.5 — but re-opening the round-1 cycle is settled.) **Resolved between rounds (2026-05-26, inter-round):** - **ADQ-221 — BDSM / DOC8 status.** Resolved by architect: BDSM `dependency_status = partial` (operative source = `DOC24_Addendum_A_BDSM_V6_5_DRAFT_v0_3_1.md` — well-drafted but incomplete; will be revised alongside the new memory system); DOC8 = capability-mining input only (skeleton sketch; useful concepts but needs rewrite). Specific BDSM surfaces DOC85 may consume are deferred to the DOC85/E9 charter at Stage 6 (where DOC85 drafting coordinates with BDSM revision). Do NOT re-litigate this in round 2; if review surfaces something that contradicts the resolution, raise it under §3.B (where will this break?) rather than re-opening ADQ-221. --- ## 3. The broad architectural review (this is the main work) Six buckets. Bucket A is the most important. Buckets B and F have the most leverage. Buckets C and E are most likely to find ARCHITECT_STOP-grade issues. ### 3.A — What did this miss? *(open-ended; primary value)* Round 1 surfaced 19 patches. We expect round 2 to surface more. Specifically: **A-1.** Memory-system concerns the skeletal architecture doesn't address at all. Anything load-bearing for a deployed memory control plane that isn't in any of the 8 family members? Examples to think about (NOT a complete list — generate your own): privacy / right-to-be-forgotten / data subject access requests; multi-tenant isolation; replication / sync across devices; cold-start / new-user onboarding; export / portability; backup / recovery; disaster / corruption recovery; rate limiting / abuse; sandboxed evaluation; deprecation lifecycle of memory itself (not the spec); cross-user memory (if any); shared / collaborative memory; offline mode; eventual consistency; clock skew; conflict resolution; cryptographic guarantees; observability beyond MemoryCoordinationTrace. **A-2.** User-facing scenarios that would expose gaps. Walk through 3-5 concrete user scenarios end-to-end against the architecture and identify where it breaks down or has no answer. Examples to generate or use: "user pastes a 200-page PDF and asks about it in a Topic context"; "user shares a Project with another user"; "user revokes a Library after extracts were already injected into past sessions"; "user asks 'what do I know about X' in a fresh chat"; "task agent emits an Assertion that contradicts an existing high-warrant Assertion in the user's memory"; "Topic auto-creates after a single message — what now?"; "user deletes a source while DOC85 is mid-learning-cycle." **A-3.** Integration points with adjacent specs that are unspecified. The Owner Map shows the seams (DOC82↔DOC72, DOC82↔DOC73 via ADQ-219, DOC83↔DOC23, DOC83↔DOC1 Write Gate, DOC81↔EC/PropA, DOC84↔DOC24/KDA, DOC85↔BDSM/DOC8, DOC86↔DOC20, etc.). Pick the seams and probe — is the contract clear enough that the OTHER side (DOC72 / DOC24 / DOC73 / DOC20 / etc.) could write an amendment against it without ambiguity? **A-4.** Edge cases the architecture doesn't handle. Pick 3-5: empty memory; corrupted memory; memory across multiple devices; memory at extreme scale (10⁹ Assertions); memory under adversarial input (prompt injection from a source); memory under a policy change mid-turn; memory under a model version change. **A-5.** Concerns that aren't named explicitly but should be. Things like: how does the architecture handle non-determinism? Where are the consistency guarantees stated? What's the timing model? What's the ordering model for concurrent writes? Are there budget / quota semantics? ### 3.B — Where will this break? *(failure-mode analysis)* **B-1.** Architectural fragilities. Where is the design most brittle? What single change to an external doc (DOC72, DOC73, DOC24, etc.) would cascade through the most DOC80 family members? **B-2.** Race conditions, ordering dependencies, coordination problems. Where would two members of the family disagree about state if updates arrived in different orders? Specifically scrutinize: the AssertionCandidate → AssertionResolution path; the DOC81 EpisodePolicyEpoch boundary at policy-generation change; DOC87 MembershipLifecycleState transitions (candidate → confirmed); DOC83 → DOC84 ContextProduct candidate flow; DOC85 learning write-back through EC. **B-3.** Assumed invariants that aren't enforced. The architecture declares invariants (`can_orient_only`, "removed or blocked edge must never reach injection", "no learning signal without proof", "DAMS may rank only eligible candidates"). For each, where is the enforcement? Is it just prose in a section header, or does it have a named lint / fixture / runtime check? **B-4.** Multi-component disagreements. The Owner Map's one-owner rule + closed verb set is supposed to prevent compound ownership. Walk through the rows and look for compound owners that survived the B3 patch — anything labeled with two owners under `owns`. Also look at rows where `stores` / `executes` / `generates` / `consumes` are vague enough that two docs could disagree about who's responsible. **B-5.** New import-graph issues. The B1 cycle fix and DOC87 insertion changed the graph topology. Walk it carefully: is there any *new* cycle, missing edge, wrong-direction edge, or orphan node? Specifically scrutinize the DOC81 → DOC86 new edge (does it actually carry what it claims to carry?); the DOC87 inbound edges (DOC80 / DOC82 / DOC83); the DOC87 outbound edges (DOC72 store / EC write / DOC84 consume / DOC86 render); the lateral DOC83 → DOC87 (TopicCollectionDirective references DOC87 Topic identity). **B-6.** Scaling issues. At 10× the Assertion count, where does this architecture stop being O(reasonable)? ### 3.C — Did the round-1 patches actually land cleanly? *(verification — but not the framing)* Round 1's 11 BLOCKERS and 8 FOLD-INS were applied at Stage 5R. The adjudication file maps each finding to a patch. Spot-check at least these — if any look broken or partially applied, that's a finding: - **B1 cycle fix** — `DOC86 → DOC81` deleted; `DOC81 → DOC86` added; correct direction; correct cargo. - **B2 DOC87 added** — family count 7→8 propagated; `MemoryMembershipEdge` moved off DOC84; `TopicActivationState` moved off DOC86; Library decomposed; plan §12 amended; membership lints + fixtures + OPA rows present. - **B3 contract/impl split eliminated** — Owner Map has no `owns` row with two docs; the legitimately compound schemas were split into two named schemas (e.g. `RecentActivityRollup` vs `RecentActivityRollupConsumptionContract`). - **B6 DOC85 rescope** — DOC85 is now substantive (architecture + write-back + warrant-degradation producers), not a thin DOC8 seam. - **B8 proof-spine lints** — `proof.*` family named; failure-mode → proof-artifact → lint mapping table named at DOC80 §9.4. - **B9 lifecycle home + handoff + compute budget** — Assertion lifecycle fully at DOC82; `AssertionCandidateEmission` named at the E3↔E5 seam; `NonAssertionExtractionOutcome` at DOC83; family-wide compute-budget envelope at DOC80 §15. - **B10 process vocab out of runtime core** — `DispositionMove` and `LedgerInvalidationState` moved out; lint `core.process_vocabulary_in_runtime_object` named. Don't write a separate paragraph for each — just flag the ones that broke. CONFIRMED-with-no-issues is implicit unless you say otherwise. ### 3.D — Better ideas / improvements *(this is high-leverage — bring your best thinking)* The architecture as proposed is one decomposition. There may be cleaner ones, or improvements that would materially raise the ceiling. Bring them. **D-1.** Alternative decompositions. Is 8 members the right number? Is the split-by-plane the right axis (vs split-by-lifecycle or split-by-consumer)? The DOC87 addition was good — are there other members that should exist? (e.g., a dedicated DOC88 for cross-cutting observability / Inspector backend; a dedicated DOC89 for retention / right-to-be-forgotten lifecycle; etc.) Or are there members that should collapse (e.g., DOC85 into DOC84)? **D-2.** Established patterns from prior art. Is this leaving value on the table by not borrowing from existing memory / orchestration architectures? Examples to consider: vector database lifecycle patterns; event-sourcing for write-back; CRDT-style conflict resolution; differential dataflow for membership recomputation; provenance graphs (W3C PROV-style); capability-based security models for policy; bitemporal modeling for the (valid-time, transaction-time) axes of memory. **D-3.** Better expressed invariants. Are there invariants that the architecture asserts in prose but could be expressed more powerfully — as type constraints, as schema relationships, as monotonicity / lattice properties, as algebraic laws? **D-4.** Better-named objects. Are any of the named schemas confusingly named in a way that will mislead Stage 6 / Stage 7 drafters? Suggest renames. **D-5.** Better-located objects. The Owner Map places each schema in one home. Are any of those placements wrong in a way that will cause Stage 6 / Stage 7 pain? (Distinct from B3 — B3 was about compound owners; D-5 is about wrong-single-owner.) ### 3.E — What will Stage 6 / Stage 7 discover? *(forward-looking)* The skeletal architecture has to survive Stage 6 (slice charters) and Stage 7 (slice drafts). Where will those stages run into walls that the skeletal architecture missed? **E-1.** Charter difficulties. For each family member, what's the hardest part of writing its charter? Are there charters that can't be written without a Stage 5R' patch first? **E-2.** Slice-draft walls. For each slice (E0-E10 + the new DOC87 slice between E6/E7), what part of the draft will hit "I don't have enough from the skeletal architecture to write this"? **E-3.** Cross-slice coordination. Lockstep pairs (E1/E2, E3/E4, E7/E8) are designed to be drafted together. The new DOC87 slice is freshly inserted. Are there coordination problems between DOC87 and its neighbors (E6 extraction; E7 delivery)? **E-4.** Fixture writability. Stage 6 writes golden fixtures. The skeletal baseline names some (the end-to-end round-trip scenario; the membership fixtures). For each, do you see how the fixture would actually be written, or is the architecture too abstract? ### 3.F — *(intentionally removed — ADQ-221 was resolved between rounds; see §2 "Resolved between rounds")* --- ## 4. Return your findings in THIS format ``` # DOC80 Stage 5R Skeletal Target Baseline — Round-2 Red-Team Review Findings ## Summary ## 3.A — What did this miss? - [A-1 .. A-5] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] - what's missing: - why it matters: - recommended action: ## 3.B — Where will this break? - [B-1 .. B-6] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] - failure mode: - affected artifacts: - recommended action: ## 3.C — Round-1 patch verification - ## 3.D — Better ideas / improvements - [D-1 .. D-5] [SUGGESTION | BETTER_IDEA] - what the architecture currently does: - what would be better: - cost / risk of changing now vs at Stage 7: ## 3.E — What will Stage 6 / Stage 7 discover? - [E-1 .. E-4] [BUG | GAP | SUGGESTION] - which charter / slice will hit the wall: - recommended pre-emptive fix: ## 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) - [ ] Stage 5R needs another patch round (Stage 5R') — list the must-fix items - [ ] ARCHITECT_STOP — name the D-SEED contradiction or other show-stopper ``` --- ## 5. What we are NOT asking for - **Do NOT re-litigate the settled questions** listed in §2. If you have evidence that a settled question actually contradicts D-SEED-1 or D-SEED-2, raise it as an ARCHITECT_STOP in §3.B — but the bar is "evidence of contradiction," not "I'd prefer differently." - **Do NOT propose Supersession Matrix edits here.** Matrix-related findings route to the Conflict / Disagreement Register at Stage 5R; the Matrix itself is not edited at Stage 5R. - **Do NOT draft schema internals** (field lists, types, JSON shapes). Stage 5R is about *naming* objects, *placing* them in owners, and *stating* invariants. Schema bodies come at Stage 7. - **Do NOT generate boilerplate or hedge.** "Looks reasonable" / "appears sound" / "I generally agree" without specifics is not useful. Either find something or say "I went through bucket X and have nothing to add." --- ## 6. Where Will saves your reply `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5R_Skeletal_DOC80_Review_Response.md` If multiple reviewers, use the per-stage folder: `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5R/.md`.