Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/E1_E2_Design_Review_Prompt.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# DOC81 (E1/E2) Scope & Policy Charter — Design Red-Team Commission

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Date issued:** 2026-06-01
**Architect:** Will Brody. **You produce the review; Will saves it and adjudicates. You do NOT need to write files.**

**You are:** an expert independent **design red-teamer** for the DOC81 Scope & Policy charter — the scope-and-policy plane of ELNOR's 8-member memory control plane (the "DOC80 family"). DOC81 is what DOC82/83/84/85/86/87 + EC all gate, cap, and surface on, so a weak contract here propagates everywhere. The draft is `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/DOC81_Scope_Policy_Charter_Draft.md` (§0–§14, ~1,381 lines).

---

## 0. Calibration — read this first (it sets the whole tone)

This is **not** a "did it land?" checklist and **not** a fidelity audit (an independent CODEX pass already verified fidelity — every schema present, citations trace, E0 bound by reference, the carried-PropA bodies corrected; do not re-run that). This is a **substantive engineering design review**, and your job is to **find what's wrong and make it better.**

Assume the worst, productively: this charter was drafted fast by a single agent and corrected by exactly one fidelity audit. **Assume there are bugs, design weaknesses, inconsistent or missing contracts, and real improvement opportunities — and find them.** A review whose bottom line is "looks good, ratify" is a **failed review** unless you have genuinely tried to break it and could not. We would rather you over-flag and let the architect decline than under-flag and let a defect reach Stage 7. The benchmark depth is the Stage 5R / E0 multi-day red-team syntheses, not a one-screen verdict.

**Push on all of:** Will it produce **bugs** at runtime? Are there **missing, inconsistent, or wrong** codes / naming / enums / schemas / contracts / lints / fixtures? Does it **compose consistently** with the rest of the planned DOC80 family *and* the current operative specs it folds in or references? And — the question that has been most useful — **what would it take to make this an A / A+ foundation?** Be concrete about the gap.

**What is genuinely settled (flag, don't relitigate):** the 8-member family decomposition, the ratified **E0/DOC80 core contracts** DOC81 binds to, and the resolved **ADQ** decisions. If you think one is wrong, say so as `ARCHITECT_STOP` or `OOS-ADVISORY` with full reasoning — don't silently work around it, but don't treat the review as a referendum on them. **DOC81's own design is fully open** — schemas, the meet algorithm, the scope model, the policy lifecycle, the PropA split, naming, the invariants: critique and improve all of it freely.

Type findings **BUG / GAP / INCONSISTENCY / SUGGESTION / BETTER_IDEA / CONFIRMED / ARCHITECT_STOP**. Cite `§+line` for every finding. Think simultaneously as **Coder + Product Designer + Integration Architect** (the architect is a securities litigator building a personal OS; legal-confidentiality correctness matters).

---

## 1. Read order (paths repo-relative; fetch directly)

**The target + its spec**
1. `…/E1_E2_DOC81_Scope_Policy/DOC81_Scope_Policy_Charter_Draft.md` — THE TARGET.
2. `…/E1_E2_DOC81_Scope_Policy/Charter_Opening_Brief.md` + `Charter_Input_Deck.md` — scope, the 20 draft targets, owned objects, the lockstep.
3. `…/E1_E2_DOC81_Scope_Policy/Reviews/E1_E2_Fidelity_Audit_CODEX.md` + `…/E1_E2_CODEX_Audit_Fix_Record.md` — what the fidelity pass already checked and fixed (so you spend your effort on *design*, not re-auditing).

**What it binds to / composes with (the consistency surface — this is half the review)**
4. `…/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` — the ratified DOC80 core. Verify DOC81's bindings to E0 (`EffectiveMemoryPolicyRef`, `MemoryFlowCertificate`, the policy-generation carrier §8.3, the §12.1 invariants, the §22 egress vocab) actually *work* — not just that they're cited.
5. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`, `…/Import Graph/DOC80_Import_Graph.md`, `…/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` (§DOC81 + §10/§11) — ownership + the acyclic graph + the architecture being formalized.
6. `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/STAGE_6_CHARTER_INPUT_INDEX.md` — **what every downstream charter (DOC82/83/84/85/86/87) will consume from DOC81.** Use it for the cross-charter-wiring check.
7. `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — §12.2 (the E1/E2 lockstep intent), §18 (golden scenario), §19 (final-acceptance bar). Use it to judge whether the charter *fulfilled the plan's intent*, not just its letter.
8. `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — the ADQs (310/315/316/313/308/213/406/PASS2-02).

**The current operative specs DOC81 folds in / references (consistency with existing specs)**
9. `Current Specs/Miscellaneous Specs/MultiDoc_PropA_R6_3_Compiled_Operative_Spec.md` (PropA — the policy content folded into §7) and `OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/OPA_V3_18.md §6.25` (the carried-PropA bodies). Is the DOC81/PropA *split* (DOC81 owns the policy gates; PropA keeps its machinery) clean and complete?
10. `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` (Round D — the scope/policy semantics source).
11. **EC Core Addendum A** (`Current Specs/EC Core/EC_Core_Addendum_A_V3_3_Compiled_Operative_Spec.md`) — EC is DOC81's *executor*. Spot-check that what DOC81 asks EC to do (scope resolution, policy enforcement, the §1 collection gate, restamp, the cascade write) is consistent with what EC actually specifies.

---

## 2. What to review — the lenses (each gets a section in your output)

### 2.A Plan-fidelity + intent (the floor, not the focus)
Did the charter fulfil the flatten plan's *intent* for DOC81 — the E1/E2 lockstep (scope identifies, policy decides), the scope+policy split, the PropA fold, the cross-cutting invariants — or only its letter? Did anything the plan/Skeletal/Owner Map called for get watered down, mis-scoped, or quietly dropped? (State this briefly; spend your depth on 2.B–2.H.)

### 2.B Bugs — try to break it
Walk **real flows** and find where the contracts produce wrong results, race, deadlock, fail **open**, or leak. At minimum:
- The **`EffectiveMemoryPolicy` meet** (§3.2): is the per-dimension most-restrictive meet actually correct? Incomparable lattice points, missing axes, conflicting obligations, the `disclosure_class` total-order the draft imposed (§13.2) — does the meet stay well-defined and conservative in every case?
- **Fail-closed**: walk for any path that fails *open* — unknown scope, unclassified source, missing policy generation, a contract whose unhappy-path default isn't conservative.
- **Policy monotonicity** (§6.3): can policy widen without a `PolicyStampRestamp` through *any* path (cache, learning, restamp-of-restamp, episode boundary)? Can a restamp exceed original ceilings (ADQ-316)?
- **The 5-plane `CascadingSourceInvalidation`** (§5.2): does revocation actually reach all five planes, in the right order, idempotently? Any plane silently skipped, or a re-proof path that wrongly raises eligibility?
- **Concurrency**: policy-generation changes mid-pipeline, restamp racing a read, scope resolution under concurrent writes, the cascade firing during a write. Does the E0 consistency model + EC serialization actually cover these for DOC81's objects?
- **The capability/disclosure separation** (§4.1) and **scope ≠ membership ≠ authority** (§6.2): find any path that collapses or conflates them.

### 2.C Missing / inconsistent contracts, codes, naming, schema
- **Missing contracts** DOC81 *should* own but doesn't (a policy/scope capability the family will need with no home).
- **Inconsistent naming/types** across the ~26 schemas: snake_case vs camelCase, branded-ID discipline, enum-member style, timestamp encoding, reason-code/lint/fixture naming. Pick one convention and flag every deviation.
- **Schema quality** — grade each load-bearing schema **A / B / C / D** with a one-line reason: discriminated unions where they belong, optionality marked, exhaustive enums, no leaky abstractions, no mis-typed primitives. Be specific about any C/D.
- **Coding-agent guess-points**: imagine a Stage-7 author implementing DOC81. Every field/enum/invariant where they'd have to ask "what should X be here?" is a defect — list them.
- The **two open flags** (§13.4 `PolicyMembraneDecision.crossing_disposition`; §13.5 `relation_to_destination` vs `E0OutboundDestinationClass`) and the **two reconciliations** (§13.1 `ScopeAffinity` union; §13.2 `disclosure_class` total-order): settle each — are they right? propose the resolution.

### 2.D Consistency with the rest of the family + current specs (the other half)
- **Cross-charter wiring** (use file 6): will DOC82 (write-gating), DOC83 (extraction re-gate + `ExtractionRoutePolicyEnvelope`), DOC84 (`PolicyCappedDAMSInput` + `EffectiveMemoryPolicy` cap), DOC85 (learning eligibility), DOC86 (the DOC81→DOC86 export), DOC87 (non-overlap, `TopicRiskClass`), and EC (executor) each be able to bind to what DOC81 produces? Name any consumer that *can't*.
- **E0 binding integrity**: do the references to E0 contracts actually compose, or is there a seam that looks wired but isn't?
- **PropA split** (§7.3): is "DOC81 owns the policy gate / PropA keeps the machinery" clean for all 8 carried rows + the DSPy + source-exclusion + suppression obligations — or does DOC81 either over-reach into PropA's internals or under-specify the gate?
- **EC consistency** (file 11): does EC actually provide the execution DOC81 assumes (collection gate, scope computation, policy enforcement, restamp, cascade write)?

### 2.E Failure modes / unhappy paths
For each contract, confirm empty / degraded / error / blocked / suppressed / revoked / fail-closed states are specified. Flag any happy-path-only contract. Watch specifically for Will's named failure modes here: **silent policy widening, fail-open, capability/disclosure collapse, scope/membership confusion, over-aggressive policy, policy-unsafe or scope-leaky machinery, magical context behavior.**

### 2.F Better patterns / how to make it better (push hard here)
Even where DOC81 is correct, propose **better architecture**. Consider: information-flow-control / capability-security models for the meet; established policy-engine patterns (OPA/Rego, AWS Cedar, XACML) for the dimensional decision + obligations; lattice formalization for `disclosure_class`/scope; event-sourcing/bitemporality (as E0/PBE use) for the policy-stamp lifecycle; Phase-2-networking and multi-principal readiness in the scope/policy model. For each: cite the current draft text and your alternative, with the trade-off.

### 2.G The A / A+ bar
State plainly where DOC81 sits today (a letter grade) and **exactly what it would take to reach A and A+** — the specific, ordered set of changes. This is the single most useful output: the gap to excellence, made concrete.

### 2.H Lints / fixtures coverage
Are there load-bearing invariants with no named lint? Fixtures that can't actually be implemented or that would pass while the thing they "test" is broken (the kind of all-pass fixture the fidelity audit already caught once)? Is the golden-scenario (plan §18) reflected?

---

## 3. Specific questions — answer each, with reasoning + `§+line`

1. **The meet algorithm (§3.2).** Walk a concrete request (a privileged source, two applicable policies with different per-axis values, one obligation) through the meet. Is the result correct, conservative, and deterministic? Where could it go wrong?
2. **Restamp (§3.4) + monotonicity (§6.3).** Is `PolicyStampRestamp` the *only* widening path, and is the ceiling bound (ADQ-316) actually enforceable from the schema? Walk a downgrade and an attempted illegal widen.
3. **The 5-plane cascade (§5.2).** Is the fan-out complete and ordered? Does it compose with E0's `SourceRevocationCascade` shape without double-coverage or a gap?
4. **`LegalHoldState` (§6.1).** Does the destructive-job invariant actually bind *every* destructive job (DOC72 §42 cleanup, DOC23 retention, DOC25 source-deletion) — or only the ones named? Is there a job that could skip the check?
5. **`collection_mode` suppression (§7.1).** DOC81 owns the governance, EC §1 enforces. Is the suppress/exclude semantics watertight (a "privacy topic" truly never collected), and is the EC seam real?
6. **The PropA fold (§7.3).** Now that the 8 carried rows are landed against their real bodies — is the policy-gate-vs-PropA-machinery split correct for each? Any row where DOC81's gate is too thin to be enforceable, or reaches into PropA's internals?
7. **`AssertionRelationEdge` scope checks (§8, ADQ-315).** Is `relation_kind → required scope checks + render gating` specified densely enough that EC can implement it without guessing?
8. **The DOC81→DOC86 export (§9).** Does it give DOC86 everything it needs (PolicyStamp, EffectiveMemoryPolicy ref, disclosure_class, restamp eligibility, safe-label constraints) with no upward dependency — and is `disclosure_class` (DOC81) vs `AvailabilityDisposition` (DOC86) cleanly separated after the fix?
9. **Scope model (§2).** Is the scope identity/topology/affinity model (`ScopeResolutionResult` + `minimum_conservatism_floor`) sufficient and sound, or under/over-built? Is `ScopeAffinity`'s union value-set (§13.1) right?
10. **Ratification readiness.** Is this an A/A− foundation a downstream charter author can build on without hitting an undefined seam? If not, what specifically blocks it?

---

## 4. Brutal questions — answer last, don't soften
1. Production-grade, or good-first-attempt? Why?
2. Single biggest weakness? Single biggest improvement opportunity?
3. Where will the **first runtime bug** come from?
4. What would a skeptical Stage-7 schema author, Stage-8 fixture author, and Stage-9 lint author each say is missing?
5. If *you* had drafted DOC81 from the same inputs, what would you do **differently** (not just better)?
6. Does it go to ratification now, or does it need a revision round first?

---

## 5. Output
A single Markdown document. Structure: **Summary + verdict** (`RATIFY` / `MINOR_FIXES_THEN_RATIFY` / `DESIGN_REVISION_NEEDED` / `ARCHITECT_STOP`) with the single biggest strength and weakness; then a section per lens (§2.A–§2.H) and per specific question (§3.1–§3.10) and the brutal questions (§4). **Value-tier the findings**: Blocking / Substantive / Minor / Considered-and-declined (show the value-vs-cost reasoning on declines). **Grade the load-bearing schemas A–D.** Give the **A/A+ gap** as a concrete ordered list. For every defect, give a **paste-ready fix** anchored to the draft (`§`, a verbatim quote, the replacement). End with the **ranked top 5–10 changes**.

Cite `§+line` on every finding. Match the depth of the Stage 5R / E0 syntheses — if your review is shorter than the combined substance of the draft's open questions, you didn't dig deep enough. **A confirm-only review is a failed review.** Save your output as `…/E1_E2_DOC81_Scope_Policy/Reviews/E1_E2_Design_Review_<your_model_name>.md` (or return it inline; Will saves it). **Start** by confirming repo access and your one-line bottom line, then the review.