Elnor Repo Reader

# DOC81 (E1/E2) R2 — Design Red-Team + Delta Review Commission

**Repository:** github.com/wbrody/Elnor-Specs — branch `main` · **Date issued:** 2026-06-04
**Architect:** Will Brody. **You produce the review; Will saves it and adjudicates.**
**Target:** `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/DOC81_Scope_Policy_Charter_Draft.md` — now **R2** (~2,310 lines): R1 + ~90 adjudicated red-team fixes + 5 architect rulings + 2 fidelity fixes. This is the **pre-ratification design pass**. Run by multiple models independently.

**You are:** an expert independent design red-teamer. This review has **two parts, both mandatory**: **Part A** — did the R2 revision *land well* (the changed/new material, design-sound and internally consistent)? **Part B** — a **fresh substantive pass** over the whole charter: new bugs, missing pieces, better ideas, the A/A+ gap. The architect's instruction, verbatim in spirit: *reviews must not be only mechanical — substantive review every round; if you have ideas it's worth seeing what they are.*

## 0. Calibration

R2 roughly doubled the charter. **New lines = new seams**: assume R2's own additions introduced defects nobody has reviewed yet (the R1 reviews never saw the lattice module, the meet v2 pipeline, the ceiling-snapshot/restamp chain, the freshness keys, the run-state machinery, the §13.6 seed values). Dig there hardest. At the same time: ~90 findings from three R1 reviews are already adjudicated into this text — do **not** re-litigate the settled record. The adjudication card's declines (D1–D12), forks (F1–F10), and architect rulings (R-1–R-5, §1-bis) are decided; if you believe one is *wrong*, say so as `ARCHITECT_STOP` with full reasoning — never silently work around, never re-argue by default. A confirm-only review is a failed review **unless** you show your work (walked cases, attempted breaks) and the text genuinely holds.

## 1. Read order (repo paths; folder = `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/`)

1. The **target** R2 draft.
2. `E1_E2_Adjudication_Card.md` — the settled record: §1-bis architect rulings (incl. R-1 internal-use-permissive/egress-gated — the controlling product posture), F1–F10, U1–U33, D1–D12.
3. `Reviews/E1_E2_R2_Application_Fidelity_Audit_CODEX.md` + `Reviews/E1_E2_R2_Fidelity_ReAudit_CODEX.md` + `E1_E2_CODEX_Audit_Fix_Record.md` (R2 section) — what fidelity checking already covered (don't repeat it; design is your job).
4. Ground truth as needed: ratified E0 core (`../E0_DOC80_Core/DOC80_Core_Charter_Draft.md`), Owner Map / Skeletal / Import Graph (`Memory Rebuild Docs/DOC80 Target Baseline/`), Round D R0.2, EC Core Add A, the ADQ ledger.
5. Optional context: the three R1 reviews (`Reviews/`) — useful to avoid re-finding what's already adjudicated.

## 2. Part A — the R2 material, design-judged (not fidelity-rechecked)

For each new/changed mechanism, judge it as engineering — walk concrete cases, try to break it:

1. **§3.0 `PolicyLattice` + rank maps:** is the algebra airtight? Any chain ordering you'd dispute (esp. `same_firewall_only` between `same_scope_only` and `partitioned`)? Unknown-value behavior?
2. **§3.2 meet v2 (the heart):** walk at least three concrete scenarios end-to-end — (a) privileged source + two conflicting decisions + an obligation; (b) `hide_existence` + a more-open vector (the just-fixed leak case); (c) an egress action with only destinationless decisions. Step order sound? Sticky-restrictive interaction with floors and ceilings — any sequence where a value *rises* without a restamp, or over-tightens irrecoverably? Generation/freshness preconditions — too strict (re-plan storms) or too loose?
3. **§3.3–§3.4 obligations + membrane derivation + stamps/ceilings/restamps:** dominance closure complete? Conflict kinds exhaustive? `OBLIGATION_DISCLOSURE_VECTOR_CEILING` values right? Walk restamp-of-restamp against the root snapshot; try to construct a ratchet or an orphaned chain. R-2 authority rule (human only for firewalled crossings) — implementable as written?
4. **§4.0 (R-1 posture):** is the 4-item internal-block list *actually exhaustive* against every blocking mechanism elsewhere in the charter? Find any path that blocks internal use on a fifth basis — that's a Blocking finding (violates the architect ruling).
5. **§4.2/§4.5–§4.7:** vector↔scalar derivation edge cases; floor-effect seed cells; action closure/predicate minima; the `DestinationPolicyCrosswalk` rows — **substantively sanity-check the §13.6 SEED VALUES** (a securities-litigation practice is the first user: are these the right defaults for matter confidentiality, PO material, personal-private?).
6. **§5–§9:** cascade run-state (idempotency under re-fire + hold dominance — walk a revocation racing a restamp); legal-hold registry default-block; suppression ambiguity + backfill; traversal budgets (is depth 16 right?); the expanded UI export (anything DOC86 still can't render without guessing?).
7. **Internal consistency of R2 as a whole:** the doubled text — contradictions between sections, duplicate-but-divergent statements, lints referenced but never defined (or vice versa), §10/§11 roll-up vs the per-section reality.

## 3. Part B — fresh substantive pass (the "ideas" mandate)

Independent of the delta: **what's still missing or could be better?**

1. **New bugs:** with the full R2 machinery in view, walk the golden scenario (plan §18) end-to-end — collection → extraction → write → retrieval → delivery → render → export → revocation → legal hold. Where does it jam, race, or leak *now*?
2. **Missing contracts:** anything the scope/policy plane will need that still has no home (think: Phase-2 multi-principal arrival, agent delegation (the external-agent adapter capability now planned at DOC11 — does DOC81 give it the policy hooks it needs?), bulk import/migration of a legacy matter, time-travel/audit queries over policy history)?
3. **Better patterns:** simplifications — R2 added ~30 schemas; which could merge or collapse without losing capability? Any over-engineering a Stage-7 implementer will curse? (Simplicity is a product value: the architect flagged "mudpit" risk — complexity must stay invisible at runtime.)
4. **The A/A+ verdict, refreshed:** grade the R2 charter; the ordered, concrete gap to A+ from *here*. What single change adds the most value now?
5. **Ratification readiness:** is this text a foundation E3/E4 (knowledge), E5/E6 (extraction), E7/E8 (delivery), E_org, E9, E10 can build on without hitting an undefined seam?

## 4. Output

One Markdown document → save as `Reviews/E1_E2_R2_Design_Review_<your_model>.md` (or return inline). Structure: **verdict** (`RATIFY` / `MINOR_FIXES_THEN_RATIFY` / `DESIGN_REVISION_NEEDED` / `ARCHITECT_STOP`) + one-line bottom line; Part A findings; Part B findings + ideas; value-tiered (Blocking / Substantive / Minor / Considered-and-declined with reasoning); **paste-ready fixes** anchored `§+line`; seed-value table (§13.6) with confirm/change-per-cell recommendations; the refreshed A/A+ gap; ranked top changes. Walked-case work shown (the §2.2 scenarios at minimum). Cite `§+line` everywhere. **Start** with repo-access confirmation + your one-line bottom line.