Elnor Repo Reader

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

---

# DOC80 E0 — Charter Draft Self-Audit

**Generated:** 2026-05-28 · audits `DOC80_Core_Charter_Draft.md` (Stage 6 E0 R1, 1083 lines) against the E0 Commission Prompt before red-team. **`DOC80_Core_Charter_Draft.md` was not modified** during this audit (per instruction — Will decides whether to revise).

**Method:** every finding below was verified against the actual draft text and the cited source file (Skeletal Baseline, Owner Map, ADQ ledger, Supersession Matrix), not against the drafter's intent. Line numbers refer to `DOC80_Core_Charter_Draft.md` unless a source file is named.

**Headline:** the draft is structurally complete and citation-accurate on the items checked, with **two defects that should be fixed before red-team** — one substantive (an unsourced 14-member enumeration presented as cited, against Hard Constraint §4) and one trivial (a self-contradicting arithmetic note in §17.2). Verdict: **NEEDS_REVISION_BEFORE_RED_TEAM** (both fixes are light; see fix list).

---

## 1. Acceptance-criteria check (Commission §5, item by item)

| # | §5 criterion | result | evidence |
|---|---|---|---|
| 1 | `DOC80_Core_Charter_Draft.md` exists at the specified path | ✅ | `E0_DOC80_Core/DOC80_Core_Charter_Draft.md`, 1083 lines |
| 2 | All 17 §1–§17 top-level sections present, substantive | ✅ | §1–§17 all present (+ a §0 "how to read"); each carries schemas/tables/prose, not stubs |
| 3 | All 20 draft targets addressed | ✅ | mapped: T1→§1.1/1.3/1.4; T2→§2.1; T3→§2.2; T4→§3.1; T5→§3.2; T6→§2.3; T7→§3.3; T8→§2.4; T9→§4; T10→§5.1; T11→§5.2; T12→§6; T13→§9; T14→§10; T15→§8.1; T16→§7; T17→§11; T18→§12; T19→§14; T20→§13 |
| 4 | All 8 ADQ rows have explicit landing sites in §17.1 | ✅ | §17.1 table lands 203/208/210/211/310/313/403/404, each to a section |
| 5 | All Skeletal §10/§11 fold-ins have landing sites in §17.2 | ⚠️ | all land, **but the count-reconciliation note is internally inconsistent** — see Finding B (§5 of this audit / §8) |
| 6 | ABC §21 placement check completed for all 7 objects | ✅ | §13.1 table covers all 7; dispositions 4→DOC82, 2→DOC84, 1→DOC25; none→DOC80; none needs a new member |
| 7 | Every §3.3 full schema has a paste-ready TS body | ✅ | 15/15 present as `interface … {…}` (verified §3 of this audit) |
| 8 | Every NAMED-only concept scoped but no field schema | ✅ | MemoryMutationEnvelope / MemoryProvenanceGraph / ResumeProjection / ResumeCard — 0 interface bodies (§4 of this audit) |
| 9 | `OPEN_FOR_ARCHITECT_REVIEW` items are SMALL (≤5) | ✅ | §16.1 has 2 items |
| 10 | Cross-charter consumption notes explicit for every consumed-elsewhere contract | ✅ (1 minor) | 21 "Cross-charter consumption" blocks; §4.1/§4.2 lean on the shared §4.3 note — acceptable, noted in §6 of this audit |
| 11 | Read-once-understandable by a cold Stage-7 author / red-teamer | ✅ | §0 conventions block + per-section Source lines + §17 landing tables make it self-orienting |
| 12 | (Hard Constraint §4) every contract/field/lint/fixture traces to a citation, else flagged | ❌ | **the 14 `ContextProductKind` values are presented as SM-060-sourced but SM-060 fixes only the count, not the names** — see Finding A |

**Acceptance-criteria verdict:** 10 clean, 1 minor (cross-charter distributed at §4), **2 fail** (criterion 5 note arithmetic; criterion 12 traceability of the 14 kinds).

---

## 2. Citation spot-check (8 claims verified against source)

| # | draft claim (location) | cited source | source actually says | verdict |
|---|---|---|---|---|
| 1 | ReasonCode registry owned by DOC80 core; producers own namespaced entries (§2.1) | ADQ-310; Owner Map line 86 | ADQ-310: "DOC80 core/contracts member owns the canonical ReasonCode registry and namespace rules; EC/PropA/DOC24/DOC8/DOC20 own producer-specific entries." Owner Map line 86 = `ReasonCode | DOC80 core | …namespaced producer entries`. | ✅ accurate |
| 2 | missing profile → conservative default (highest restrictiveness) (§2.2) | ADQ-313 | ADQ-313 verbatim: "missing profile → use 'conservative' default profile (highest restrictiveness)." | ✅ accurate (verbatim) |
| 3 | warrant-degradation registry in core; producers DOC85; per-trigger owners (§2.4) | Owner Map line 171; ADQ-312 | Owner Map line 171 = `Warrant-degradation-trigger registry | DOC80 core (MOVED from DOC85…) | DOC85 owns the producers…`. ADQ-312 owner table matches the nine trigger→owner pairs in §2.4. | ✅ accurate |
| 4 | "The 14 fixed ContextProduct kinds (SM-060)" + 14 enumerated names (§3.1, lines 284–290) | SM-060 | SM-060 = "ContextProduct (registry product) — **fixed registry of 14 product kinds**." States the **count only**; does **not** enumerate the kinds. | ⚠️ **partial miscitation** — count sourced; the 14 names are unsourced (Finding A) |
| 5 | MemoryFlowCertificate executors EC/DOC1/DOC24/KDA/DOC11/DOC85 (§3.3) | Owner Map line 150; ADQ-207 | Owner Map line 150 lists exactly those executors; ADQ-207 = mandatory for "durable write, render, export, carryover, delegation, learning attribution." | ✅ accurate |
| 6 | MemoryCoordinationTrace = per-request, ties three plans (§3.4) | SM-100; Owner Map line 204 | SM-100 = "connects ExtractionContextPlan / MemoryContextPlan / UserContextSurfacePlan + manifests + proofs + learning events." Owner Map line 204 = `MemoryCoordinationTrace | DOC80 core | SM-100, ADQ-209`. | ✅ accurate |
| 7 | restamp cannot exceed original ceilings (§12) | ADQ-316 | ADQ-316: "Restamp may keep, downgrade, or block … CANNOT grant access beyond original ceilings." | ✅ accurate |
| 8 | RenderSafetyProof contract @ DOC80 core; execution @ DOC84; DOC11 finalizes (§4.2) | Owner Map lines 147–148 | line 147 = `RenderSafetyProof (contract) | DOC80 core | DOC84 executes; DOC11 finalizes`; line 148 = `RenderSafetyProof (execution) | DOC84`. | ✅ accurate |

**Citation verdict: 7/8 fully accurate; 1/8 partial miscitation** (#4 — the SM-060 citation supports the *count* of 14 but is silently extended to cover the *enumeration*, which it does not). No other line-number citation tested was wrong.

---

## 3. Schema completeness check (15 full schemas)

Criteria per Commission §3.2: (a) producer, (b) consumer, (c) executor *if applicable*, (d) lifecycle states *where applicable*, (e) unhappy paths, (f) ≥2 lints + ≥1 fixture.

| # | schema (§) | (a) prod | (b) cons | (c) exec | (d) lifecycle | (e) unhappy | (f) ≥2 lint / ≥1 fix | status |
|---|---|:--:|:--:|:--:|:--:|:--:|:--:|---|
| 1 | ReasonCode (§2.1) | ✅ | ✅ | n/a (registry) | ✅ active/deprecated/retired | ✅ | ✅ 4 / 3 | complete |
| 2 | ReasonCodeRegistry (§2.1) | ✅ | ✅ | n/a | ✅ (entry state) | ✅ | ✅ (shares §2.1) | complete |
| 3 | DomainProfile (§2.2) | ✅ | ✅ | n/a | ✅ active/deprecated/retired | ✅ | ✅ 3 / 3 | complete |
| 4 | DomainProfileRegistry (§2.2) | ✅ | ✅ | n/a | ✅ | ✅ (fallback) | ✅ | complete |
| 5 | PromptShellVariant (§2.3) | ✅ | ✅ | DOC84 selects | ✅ active/deprecated/retired | ✅ | ✅ 4 / 3 | complete |
| 6 | PromptShellRegistry (§2.3) | ✅ | ✅ | n/a | ✅ | ✅ | ✅ | complete |
| 7 | PromptShellLearningContract (§2.3) | ✅ DOC85 | ✅ | n/a | n/a (contract) | ✅ | ✅ | complete |
| 8 | ContextProduct / ProductionContract (§3.1) | ✅ | ✅ | ✅ DOC24 | ✅ planned→…→delivered | ✅ incl. empty | ✅ 5 / 4 | complete **but 14-kind enum unsourced (Finding A)** |
| 9 | MemoryContextPlan (§3.2) | ✅ | ✅ DOC24 | ✅ DOC84 impl | ✅ degraded_mode (4) | ✅ | ✅ 3 / 3 | complete |
| 10 | MemoryFlowCertificate (§3.3) | ✅ | ✅ | ✅ EC + 5 | ✅ issued/withheld | ✅ | ✅ 6 / 3 | complete |
| 11 | ContextPacketProof (§4.1) | ✅ | ✅ (DOC85 gate) | ✅ DOC24/DOC11 | ✅ pass/fail | ✅ (in §4.3) | ✅ (in §4.3) | complete (lints/fix/unhappy in shared §4.3) |
| 12 | RenderSafetyProofContract (§4.2) | ✅ | ✅ | ✅ DOC84 / DOC11 | ✅ pass/fail | ✅ (in §4.3) | ✅ (in §4.3) | complete (lints/fix/unhappy in shared §4.3) |
| 13 | WarrantDegradationTriggerRegistry (§2.4) | ✅ DOC85 | ✅ DOC82/DOC81 | ✅ per-trigger owners | ✅ active/deprecated/retired | ✅ | ✅ 3 / 2 | complete |
| 14 | MemoryPlaneHealthReadModel (§9.1) | ✅ members | ✅ EC/Q/ops | ✅ EC/Q host | n/a (read model) | ✅ (§9.3) | ✅ 3 / 2 | complete (lifecycle N/A, correctly) |
| 15 | MemoryOperationQuota (§10.2) | ✅ DOC80 | ✅ members | ✅ background ops | n/a (config) | ✅ (§10.3) | ✅ 6 / 3 | complete (lifecycle N/A, correctly) |
| (+) | MemoryCoordinationTrace (§3.4, bonus 16th) | ✅ | ✅ | ✅ | ✅ open→completed/degraded/blocked | ✅ | ✅ 3 / 2 | complete |

**Schema verdict: 15/15 (+1 bonus) structurally complete on all six sub-criteria.** Two legitimate `n/a` lifecycle cases (config/read-model objects) are correctly handled. Two proof schemas (#11, #12) carry their lints/fixtures/unhappy paths in the shared §4.3 rather than per-subsection — acceptable (the proof spine is one coherent unit) but noted. The only schema-level defect is the **content** of #8's enum, not its structure (Finding A).

---

## 4. NAMED-only enforcement

Verified by `grep -cE "^interface <name> "` against the draft:

| concept | interface body present? | required |
|---|---|---|
| `MemoryMutationEnvelope` (§5.1) | **0** | 0 ✅ |
| `MemoryProvenanceGraph` (§5.2) | **0** | 0 ✅ |
| `ResumeProjection` (§5.3) | **0** | 0 ✅ |
| `ResumeCard` (§5.3) | **0** | 0 ✅ |

All four are scoped in prose only (what they carry, producer, consumer, placement) with the field schema explicitly deferred to Stage 7. **NAMED-only enforcement: PASS** (Commission Hard Constraint §6 honored). §5.1 even carries the `EmbeddingProvenanceFields` / `HotPathCostDeclaration`-style field conventions for *other* schemas without leaking an envelope body.

---

## 5. Fold-in count verification (the noted 14 → 17)

The §17.2 table lands these rows: **§10:** 10.1, 10.2, 10.5, 10.6, 10.7, 10.9, 10.12, 10.13, 10.14, 10.15, 10.16, 10.17 = **12**. **§11:** 11.1, 11.2, **11.3**, 11.4, 11.8, 11.9 = **6**. **Table total = 18.**

- **Input Deck enumerated 17** (12 §10 + 5 §11 — the §11 list is {11.1, 11.2, 11.4, 11.8, 11.9}, no 11.3). **All 17 land** — none silently dropped. ✅
- The draft **additionally lands §11.3** (extraction-side EpisodePolicyEpoch re-gate → §8.3), a real Skeletal fold-in beyond the Input Deck's list. That is overshoot, not a defect. ✅
- **BUT the reconciliation note (line 1073) is internally wrong:** it says "12 §10 rows + **5** §11 rows = **17**," while its own table shows **6** §11 rows = **18**. **Finding B** — the note must be corrected to "12 §10 + 6 §11 = 18 landing rows: the 17 Input-Deck fold-ins plus §11.3 (landed in §8.3 beyond the Deck's list)."

**Fold-in verdict: all 17 Input-Deck fold-ins land (nothing dropped), +1 bonus (§11.3); the §17.2 note's arithmetic contradicts its own table and must be fixed.**

---

## 6. Cross-charter consumption check

Every contract section carries a **"Cross-charter consumption"** block (21 instances). Spot-checked: §2.1 (E1/E2 ReasonCode), §2.2 (DOC81/82/25/84), §2.3 (DOC84/24/KDA/85), §2.4 (DOC85/82/81), §3.1 (DOC84/24/86/83/87), §3.2 (DOC84/24/83/86/81), §3.3 (EC/85/84/11/1/24), §3.4 (all planes/86/85/84), §4.3 (DOC24/11/84/85/86/EC), §5.1–5.3 (per concept), §6–§14 (all present).

**One minor note:** §4.1 (ContextPacketProof) and §4.2 (RenderSafetyProofContract) do not carry their *own* consumer line — they rely on the shared §4.3 "Cross-charter consumption" block for the proof spine. This is defensible (the spine is one unit) but a strict per-contract reading wants a consumer ref in each subsection. **Not blocking.**

**Cross-charter verdict: PASS** (every contract has a consumer reference; §4.1/§4.2 inherit from §4.3).

---

## 7. Phantom-feature scan (red-team lens)

Reading as a skeptic hunting fabricated capabilities:

**Finding A (substantive) — the 14 `ContextProductKind` values (§3.1, lines 284–290).** The draft enumerates `assertion_pack | evidence_pack | source_excerpt | orientation_rollup | resume_card | membership_context | topic_lens_context | null_result_notice | policy_disclosure_notice | inspector_explanation | search_affordance_result | carryover_capsule_view | friction_summary | reference_only_notice` under a comment "The 14 fixed ContextProduct kinds (SM-060)." **SM-060 fixes the count (14) but does not enumerate the kinds**, and the canonical enumeration (likely in ABC R0.2 §1.3 / Round D R0.2 / Concept Model §17, none of which are in the E0 read-list) was never consulted. Several names map to real family objects (`null_result_notice`, `reference_only_notice`, `carryover_capsule_view`, `resume_card`), but the set as a whole is a **reconstruction presented as canonical** — exactly the "unregistered content type / phantom" failure mode the registry is meant to prevent (Commission §1.6), and a breach of Hard Constraint §4 ("if you can't trace, flag"). **This is the one genuine phantom-feature finding.**

**Lower-severity notes (design-latitude enums, not phantom but worth labeling).** Writing paste-ready interfaces forces value-set choices; the following enums are reasonable but **not citation-backed at the value level**, and none is *flagged* as proposed: `ReasonCodeCategory` (10 values, §2.1), `DriftResponse` (3 values, §7), `RenderSafetyCheck` (6 values, §4.2), `MemoryContextPlanDegradedMode` (4 values, §3.2). Each maps to real invariants/scenarios and falls within the "namespace rules / contract design" authority the ADQs grant DOC80, so these are defensible — but a red-teamer will ask "where do these come from?" Recommend a one-line "proposed value set — Stage 7 confirms" qualifier on each.

**Cleared (verified sourced).** `MemoryFlowKind` (6, ADQ-207), `WarrantDegradationTriggerKind` (9, ADQ-312), `MemoryPlaneHealthSignal` (10, Skeletal §10.15), `MemoryOperationQuota` fields (8, Skeletal §10.16), `DependencyStatus` (5; partial/moving/aspirational/phantom/stable all attested across Owner Map + Import Graph) — all enumerations trace to a source that lists the members. **Lint and fixture *names* are not phantom** — the Commission (§6, §3.2) explicitly directs the drafter to coin them ("you name them; you don't implement them").

---

## 8. Internal-consistency scan (cross-references)

| cross-ref tested | claim | verified target | verdict |
|---|---|---|---|
| §3.2 → §3.1 (`ContextProductKind`, `requested_products`) | §3.1 defines `ContextProductKind` | §3.1 lines 286–290 define it | ✅ consistent |
| §11.3 → §1.5 (consistency model / single-EC-writer = replay source) | §1.5 states the single-EC-writer ordering model | §1.5 (the Skeletal §11.2 block) states exactly that | ✅ consistent |
| §8.2 → §5.1 (`MemoryMutationEnvelope` carries transaction_time/valid_time) | §5.1 scopes the envelope as bitemporal carrier | §5.1 names actor/policy-epoch/transaction-time/valid-time as carried (prose) | ✅ consistent |
| §17.2 note → §17.2 table (fold-in counts) | note: "5 §11 rows = 17" | table lists 6 §11 rows = 18 | ❌ **inconsistent (Finding B)** |

**Internal-consistency verdict: 3/4 cross-references consistent; the §17.2 note vs. its own table is the one self-contradiction** (already captured as Finding B).

---

## 9. Verdict

### NEEDS_REVISION_BEFORE_RED_TEAM

The draft is structurally complete (17/17 sections, 20/20 targets, 8/8 ADQ landings, 15/15 schemas, NAMED-only clean, 7/8 citations exact, all Input-Deck fold-ins landed, cross-charter notes present) and would survive most of red-team intact. But it carries **one substantive traceability defect (Finding A)** that violates Hard Constraint §4 and is the precise failure mode the architect fights, plus **one trivial self-contradiction (Finding B)**. Both are cheap to fix; neither is architectural. Fixing them before red-team prevents the 14-kinds issue from consuming reviewer attention on something already known to be unverified, and removes a self-evident arithmetic error. The draft is ~95% ready; this is a touch-up, not a rework.

---

## 10. Fix list (specific, ordered by severity)

1. **[substantive — Finding A] §3.1 ContextProduct 14 kinds (lines 284–290 + the line-281/284 "(SM-060)" attributions).** The count (14) is SM-060-sourced; the *names* are not. Do one of: **(a)** verify the enumeration against the canonical 14-kind registry (ABC R0.2 §1.3 / Round D R0.2 / Concept Model §17 — outside the E0 read-list) and re-cite to that source; or **(b)** relabel the enum comment as *"illustrative reconstruction — the count (14) is fixed by SM-060; the specific kinds must be confirmed against the canonical registry at Stage 7"* and add a one-line `OPEN_FOR_ARCHITECT_REVIEW` entry in §16.1 (raising it from 2 → 3 flags, still ≤5). **(b) is the minimum honest fix.**
2. **[trivial — Finding B] §17.2 count-reconciliation note (line 1073).** Change "12 §10 rows + 5 §11 rows = 17" to "12 §10 + 6 §11 = 18 landing rows — the 17 Input-Deck-enumerated fold-ins plus §11.3 (extraction-side re-gate), landed in §8.3 beyond the Deck's §11 list." (All 17 Deck fold-ins land; §11.3 is an intentional bonus — say so.)
3. **[minor — phantom scan] design-latitude enums.** Add a "proposed value set — Stage 7 confirms" qualifier to `ReasonCodeCategory` (§2.1), `DriftResponse` (§7), `RenderSafetyCheck` (§4.2), and `MemoryContextPlanDegradedMode` (§3.2), so red-team does not mistake reasonable design choices for cited canon. (Optional but recommended.)
4. **[optional — cross-charter] §4.1 / §4.2.** Add a one-line consumer reference to each proof subsection (or an explicit "consumers: see §4.3") so a strict per-contract reading finds a consumer in-section.

**Nothing else flagged.** Citations (7/8 exact), NAMED-only enforcement, schema structural completeness, ABC §21 coverage, fold-in landing completeness, and retired-name compliance all pass. Items 3 and 4 are optional polish; items 1 and 2 are the pre-red-team fixes.