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

---

# DOC81 Scope & Policy Charter (E1/E2) — Commission Prompt for Claude Code

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Session type:** Fresh Claude Code session in the repo working directory.
**Authority:** Will Brody (architect). All architect decisions for this draft are pre-resolved upstream (Stage 4 / 5R / 5R2 / 5R3 + the **ratified E0 / DOC80 core**, 2026-06-01). Do NOT ask Will mid-draft except where this prompt says so.

**Mission:** produce a complete first draft of the **DOC81 Scope & Policy Plane** charter, drafted as the **E1 + E2 lockstep pair**. The draft becomes the operative DOC81 member spec after Will's review + red-team rounds + ratification. DOC81 is the scope-and-policy foundation that DOC82/83/84/86/87 + EC all consume.

---

## 1. Orientation (mandatory)

### 1.1 ELNOR in one paragraph
ELNOR is a **local-first AI orchestration platform** on OpenClaw (Node.js), single M4 Pro MacBook, isolated macOS user. Architect Will Brody (securities litigator); domain-agnostic personal-OS with legal-litigation as one profile. **Spec / red-team / design-hardening phase — nothing implemented.** The bar: specs dense enough that implementation cannot drift, guess, or recreate "phantom button / phantom memory / phantom wiring" failures.

### 1.2 The DOC80 family + where DOC81 sits
8-member family (ADQ-220): DOC80 (core — **RATIFIED**), **DOC81 (scope/policy — YOU ARE DRAFTING THIS)**, DOC82 (knowledge/source/evidence), DOC83 (extraction/temporal), DOC84 (delivery/prompt/proof; DAMS substrate), DOC85 (learning), DOC86 (UI/Inspector/Search), DOC87 (organization/membership). EC = Elnor Core, sole durable writer (`dependency_status = partial/moving`). **DOC81 defines contracts; EC executes them.**

### 1.3 Key terms
**EC** Elnor Core (executes scope resolution, policy enforcement, durable writes) · **PropA** MultiDoc Proposal A R6.3 (Knowledge-Pipeline Sensitivity & Self-Improvement; whole-section retargeted to DOC81) · **Round D** Policy/Scope/UI Micro-Patch R0.2 (the scope §3.x + policy §1.x source) · **ABC R0.2** Consolidated Structural Patch · **PolicyStamp** the durable policy stamp on an object · **EffectiveMemoryPolicy** the per-request meet of all applicable policy · **disclosure_class** the disclosure-meet axis (orthogonal to capability) · **DAMS** attenuator substrate inside DOC84.

### 1.4 Will's working style (binding)
- **No phantom features.** Every contract / field / lint / fixture must trace to (a) an ADQ, (b) a Skeletal §DOC81 / §10 / §11 fold-in, (c) an Owner Map row, (d) an OPA obligation, or (e) the ratified E0 draft. If you can't trace it, flag `OPEN_FOR_ARCHITECT_REVIEW` — do not invent.
- **Excellence + completeness over brevity.** A missed target is worse than overshoot.
- **Cite section numbers** inline (Owner Map line 80, Skeletal §10.4, ADQ-316, Round D §1.6, E0 §3.3, OPA `OBL-PROPA-NEW-V15-03`).
- **Paste-ready schemas over prose.** Write the TypeScript interface, not "an interface with a few fields."
- **Three lenses at once:** Coder + Product Designer + Integration Architect.
- Type mid-draft findings **BUG / GAP / SUGGESTION / CONFIRMED**.
- Output file `DOC81_Scope_Policy_Charter_Draft.md` — **no version suffix**; git history is the version record.

### 1.5 Failure modes to guard against
phantom buttons/memories · over-aggressive ingestion · silent auto-promotion · missing empty/degraded/error/blocked/suppressed/revoked states · under-specified schemas · cross-doc seams that sound wired but aren't · magical context behavior · **capability/disclosure meet collapsed into one** · **scope containment confused with membership or authority** (DOC81/DOC87 non-overlap) · **policy widened without a restamp** · living memory eroding static facts · silent degradation.

---

## 2. Read order (all paths repo-relative; read directly)

### 2.1 This charter folder (read first)
1. `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/Charter_Opening_Brief.md` — **the load-bearing brief**: scope, the 20 draft targets, the lockstep, exit criteria.
2. `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/Charter_Input_Deck.md` — the OPA rows, ADQs, fold-ins, owned objects, seams.

### 2.2 The ratified contracts DOC81 binds to (READ — do NOT redefine these)
3. `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md` — **the ratified DOC80 core.** DOC81 **consumes, by reference**: the ReasonCode registry (§2.1), the DomainProfile registry + `conservative` fallback (§2.2), the policy-generation carrier (§8.3), the `EffectiveMemoryPolicy` consumption-protocol reference (§3.x — note DOC80 holds only the *reference*; the schema is yours), `MemoryFlowCertificate` (§3.3), and the §12.1 invariants DOC81 gates. **Bind to these by E0 section number; never re-declare a registry DOC80 owns.**

### 2.3 The architecture you are formalizing (mandatory)
4. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` — read the **§"DOC81 — Scope and Policy Plane"** member section (the §1–§7 map) **and** §10.3 (LegalHoldState), §10.4 (DOC81/DOC87 non-overlap), §10.11 (CascadingSourceInvalidation 5-plane), §11.3 (policy-generation re-gate), §11.9 (monotonicity). Cite them.
5. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md` — DOC81-owned rows (62, 71–94, 194). This is the ownership truth; one owner per schema.
6. `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md` — DOC81 edges (→ DOC80, → PropA, → EC, → DOC86; EC → DOC81). Your contracts must respect this graph (it is acyclic; do not reintroduce the B1 cycle).
7. `Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md` — do not reintroduce retired names (`ScopeMembrane`, scalar `MemoryPolicyDecision`, scalar `PolicyMembraneDecision`, `ask_user`, etc.).

### 2.4 Decision authority
8. `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — ADQ-310, ADQ-315, ADQ-316, ADQ-313, ADQ-308, ADQ-213, ADQ-406, ADQ-PASS2-02 are your direct authority.
9. `OP-A and Operations and Trackers/OPA_V4.md` — read **§6 (PropA / DOC81 section)** for the 10 obligation rows, **§6.Z** (`OBL-D81-TOPIC-COLLECTION-SUPPRESSION-01`), and **§6.Z3** (`OBL-PROPA-LOCALFILEEXPORT-OUTBOUND-PATCH-01`). Every one needs a landing site.
9b. **`OP-A and Operations and Trackers/Archived DOC OP-A and Operations DOCS/OPA_V3_18.md` §6.25** — the **canonical carried bodies** for the 8 surviving PropA rows (`OBL-PROPA-NEW-01/02`, `-V15-01..06`); the V4 rows inherit their acceptance bodies from here (`OPA_V4.md §6` note). **Land each row against its ACTUAL body — the V15 family is DOC73 V1.5.1 learning-pipeline privacy/governance (LearningVisibilityScope / VerifierCalibrationLedger / SchemaMigrationPlan / DSPy targets), NOT sensitivity/collection — never a topic-level guess.** (Added 2026-06-01 after a CODEX fidelity audit caught the R1 draft mis-mapping 8 of 10 rows.)
10. **PropA R6.3** — `Current Specs/Miscellaneous Specs/MultiDoc_PropA_R6_3_Compiled_Operative_Spec.md` (the operative MultiDoc Proposal A spec; the Knowledge-Pipeline Sensitivity & Self-Improvement policy content now owned by DOC81). Read the sections the 10 OPA rows reference.
11. **Round D R0.2** (`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`) and **ABC R0.2** (`…/12_ABC_Consolidated_Structural_Patch_R0_2.md`) — the scope (§3.x) + policy (§1.x) semantics + the disclosure/capability separation (§1.6). The Round-D UI surfaces belong to DOC86/E10, not here, but the policy meaning is yours.

### 2.5 Cross-reference
12. `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md` — SM-010/011 (ScopeBoundary), SM-012 (MemoryPolicyDecision dimensional), SM-013 (EffectiveMemoryPolicy), SM-014 (PolicyMembraneDecision), SM-101 (EpisodePolicyEpoch), SM-102 (PolicyDisambiguationRequest), SM-104 (disclosure_class), SM-105 (SafeLabel), SM-106 (contamination_risk), SM-107 (PolicyCappedDAMSInput), SM-208 (CascadingSourceInvalidation).
13. `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — §12.2 (the E1/E2 lockstep two-pass), §17.4 (policy/scope/UI lint suite).

---

## 3. What to produce (the deliverable)

A single markdown file: **`Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/DOC81_Scope_Policy_Charter_Draft.md`** — the operative draft of the DOC81 member spec.

### 3.1 Required structure
```
# DOC81 — Scope & Policy Plane (Stage 6 E1/E2 Charter Draft R1)

## §1. Identity, scope, non-goals, and the E1/E2 lockstep
  §1.1 Member identity (family member 2 of 8)
  §1.2 What DOC81 owns / does NOT own (Owner Map)
  §1.3 The lockstep: scope identifies, policy decides (plan §12.2)
  §1.4 Binding to E0 (DOC80 core) — consume by reference, never redefine
  §1.5 Fail-closed default posture (conservative; ADQ-313)

## §2. Scope plane (E1 — declare)
  §2.1 ScopeIdentityRoot / ScopeEquivalenceBinding
  §2.2 ScopeContainerRelation / ScopeBoundary (topology only)
  §2.3 ScopeAffinity (direct/secondary/shared/analogical/background)
  §2.4 ScopeResolutionResult (+ minimum_conservatism_floor) + ScopeResolutionTrace
  §2.5 ScopePopulationHealth

## §3. Policy plane (E1 — declare)
  §3.1 MemoryPolicyDecision — the 5-axis dimensional vector (name the axes; SM-012)
  §3.2 EffectiveMemoryPolicy — the meet schema + meet algorithm (bind to E0 consumption-protocol ref)
  §3.3 PolicyMembraneDecision + PolicyObligation
  §3.4 PolicyStamp + PolicyStampScope + PolicyStampInvalidation + PolicyStampRestamp (ADQ-316)
  §3.5 PolicyDisambiguationRequest (DOC84 park/resume seam)
  §3.6 EpisodePolicyEpoch + policy_generation_id boundary (bind to E0 §8.3 carrier)

## §4. Capability / disclosure coordination (E2 — validate)
  §4.1 Capability meet vs disclosure meet — SEPARATION (Round D §1.6; orthogonal)
  §4.2 disclosure_class + SafeLabelDisclosurePolicy (ADQ-308)
  §4.3 ExtractionRoutePolicyEnvelope
  §4.4 PolicyCappedDAMSInput (eligibility ceiling) + contamination_risk threshold rule
  §4.5 TopicRiskClass (ADQ-213)
  §4.6 Fail-closed meet behavior (Skeletal DOC81 §4 / Round D §3.6) + capability/disclosure lints

## §5. Source revocation + cascading invalidation (E2)
  §5.1 CascadingSourceInvalidation envelope (B3 split)
  §5.2 The 5-plane fan-out WIRING CHECK (Skeletal §10.11) — the explicit charter obligation
  §5.3 Source-revocation monotonicity (Skeletal §11.9)

## §6. Cross-cutting invariants DOC81 owns
  §6.1 LegalHoldState + destructive-job invariant (Skeletal §10.3; OPA-033)
  §6.2 DOC81 / DOC87 non-overlap invariant + lints (Skeletal §10.4)
  §6.3 Policy monotonicity invariants + lints (Skeletal §11.9; ADQ-316)
  §6.4 Policy-generation re-gate boundary (Skeletal §11.3)

## §7. Topic-level privacy + source exclusion + PropA fold-in
  §7.1 collection_mode suppression governance (ADQ-406; OBL-D81-TOPIC-COLLECTION-SUPPRESSION-01)
  §7.2 Source-exclusion filter (OBL-PROPA-NEW-SOURCE-EXCLUSION-FILTER-01)
  §7.3 PropA sensitivity & self-improvement policy fold-in (the 10 OPA rows → landing sites)
  §7.4 PropA local_file_export outbound patch (OBL-PROPA-LOCALFILEEXPORT-OUTBOUND-PATCH-01; cross-doc note)

## §8. AssertionRelationEdge traversal scope checks (ADQ-315 — pinned to E1)

## §9. DOC81 → DOC86 export (Patch B1)

## §10. Invariant enforcement-point naming (runtime gate + Stage 9 lint + Stage 8 negative fixture per invariant)

## §11. Lints + fixtures roll-up (Stage 9 / Stage 8)

## §12. Cross-charter dependencies (what E1/E2 unblocks; what it binds to in E0)

## §13. Open items + architect-review flags (≤5)

## §14. Sources + lineage (ADQ landings table; OPA-row landings table; Owner Map / Skeletal refs)
```
(Deviation allowed if justified; default is to keep this skeleton.)

### 3.2 Per-section quality bar
Each contract section includes: **source citation block**; **paste-ready schema** (TypeScript-style); the **single owner** cell + producer / consumer / **executor (EC)** breakdown; **lifecycle states**; **unhappy paths** (empty / degraded / error / blocked / suppressed / revoked / fail-closed); **≥2 named Stage-9 lints**; **≥1 named Stage-8 fixture** (negative/invariant where applicable); and **cross-charter consumption notes** (which charter consumes this — DOC82/83/84/86/87/EC).

### 3.3 Required full schemas (E1/E2 owns these at body level — paste-ready)
`ScopeIdentityRoot`, `ScopeEquivalenceBinding`, `ScopeContainerRelation`, `ScopeBoundary`, `ScopeAffinity`, `ScopeResolutionResult`, `ScopeResolutionTrace`, `ScopePopulationHealth`, `MemoryPolicyDecision` (5-axis), `EffectiveMemoryPolicy` (+ meet algorithm), `PolicyMembraneDecision`, `PolicyObligation`, `PolicyStamp`/`PolicyStampScope`/`PolicyStampInvalidation`/`PolicyStampRestamp`, `PolicyDisambiguationRequest`, `EpisodePolicyEpoch`, `disclosure_class`, `SafeLabelDisclosurePolicy`, `ExtractionRoutePolicyEnvelope`, `PolicyCappedDAMSInput`, `contamination_risk` threshold rule, `TopicRiskClass`, `CascadingSourceInvalidation` envelope, `LegalHoldState`, the `collection_mode` suppression governance contract.

**Bind-by-reference, do NOT redefine** (they are E0's): `ReasonCodeRegistry`, `DomainProfileRegistry`, the policy-generation carrier, the `EffectiveMemoryPolicy` consumption-protocol reference, `MemoryFlowCertificate`.

---

## 4. Hard constraints (do not violate)
1. **DO NOT modify any file outside `Memory Rebuild Docs/Stage_6_Charters/E1_E2_DOC81_Scope_Policy/`.** Output is `DOC81_Scope_Policy_Charter_Draft.md` only. Everything else is read-only.
2. **DO NOT redefine an E0 (DOC80 core) contract.** Bind to the ratified E0 draft by section number. If you need a registry, you reference DOC80's — you never declare a local one (cf. ADQ-310: "do not invent local reason-code systems").
3. **DO NOT collapse capability meet and disclosure meet.** They are orthogonal (Round D §1.6).
4. **DO NOT let scope containment imply membership or any authority** (Skeletal §10.4 non-overlap).
5. **DO NOT allow a policy-widening path other than `PolicyStampRestamp`**, and restamp **cannot exceed original ceilings** (ADQ-316). Source revocation monotonically lowers (Skeletal §11.9).
6. **DO NOT phantom-create.** Every contract/field/lint/fixture traces to a citation or is flagged `OPEN_FOR_ARCHITECT_REVIEW`.
7. **DO NOT skip the unhappy paths** or the **fail-closed** default.
8. **DO NOT redraw family boundaries.** DOC81 owns exactly what the Owner Map says — `TopicCollectionDirective` stays DOC83; membership stays DOC87; truth stays DOC82; the registries stay DOC80; EC executes.
9. **DO NOT run `git`.** Will commits.
10. **DO NOT reintroduce retired names** (`DOC80_Retired_Names.md`).

---

## 5. Acceptance criteria
- `DOC81_Scope_Policy_Charter_Draft.md` exists at the specified path; all §1–§14 sections present + substantive.
- All 20 draft targets in `Charter_Opening_Brief.md` addressed.
- All pinned ADQs (310, 315, 316, 313, 308, 213, 406, PASS2-02) have explicit landing sites in §14.
- All 10 PropA OPA rows + the 2 E0-handed obligations have landing sites (§7).
- The **5-plane CascadingSourceInvalidation wiring check** is done (§5.2) with the six revocation lints from Skeletal §10.11.
- `LegalHoldState`, **policy monotonicity**, **DOC81/DOC87 non-overlap**, and **capability/disclosure separation** each have a runtime gate + a Stage-9 lint + a Stage-8 negative fixture (§10).
- Every required full schema (§3.3) has a paste-ready body; every E0 contract DOC81 consumes is **referenced by E0 section, not redefined**.
- The `EffectiveMemoryPolicy` **meet algorithm** is specified (monotonic restriction; conservative on missing/incomparable), not just the shape.
- `OPEN_FOR_ARCHITECT_REVIEW` items ≤ 5.
- Read-once-understandable by a Stage-7 schema-body author and a cold red-teamer.

## 6. How to be useful
Be specific; pick concrete schemas; lint-name + fixture-name liberally (2–4 lints, 1–3 fixtures per contract); cite Skeletal / Owner Map / ADQ / OPA / **E0 section** inline; use the Coder+Designer+IntegrationArchitect lens; don't soften (flag `GAP:` inline). Remember EC is the executor — for every DOC81 contract, name what EC does with it.

## 7. If you get stuck
- Skeletal/Owner Map row vs pinned ADQ conflict → flag §13 with both citations, propose the read you prefer, continue.
- A field could go to DOC81 vs DOC84/DOC87 → default to the **policy/scope** placement only if it is policy/scope semantics; otherwise leave it to the owning member and flag §13.
- Cannot locate PropA R6.3 or a referenced source → flag §13 and proceed against the OPA-row summaries; do NOT guess policy content.
- A draft target needs E0 content you cannot read → STOP, write `Charter_Draft_HALT.md` with the blocker, exit. Do not guess.
- Do NOT spawn subagents or explore beyond the read list.

## 8. Tone, length, format
Technical-spec voice; direct, declarative. Markdown; TypeScript-style schema blocks; tables for ownership/lifecycle; prose for rationale (no bullets for substantive rationale). Inline citations every claim. Length: substantial — DOC81 is a dense plane (scope + policy + meet + invariants); expect a member-spec-grade document (likely 1,500–3,000 lines). Match density to substance.

## 9. Time bound
One focused Claude Code session (~60–120 min). If you're spawning subagents, exploring beyond the read list, or writing outside the E1/E2 folder — you've drifted; return to §3 + §5.

---

**Begin by reading §2.1 (this folder's Opening Brief + Input Deck), then §2.2 (the ratified E0 draft — the contracts you bind to), then §2.3 (Skeletal §DOC81 + §10/§11 + Owner Map). Acknowledge the reads in your first response. Then draft `DOC81_Scope_Policy_Charter_Draft.md` per §3.1. Do not begin drafting until you've read at least §2.1 + §2.2 + the Skeletal §DOC81 section.**