SECTION_15A_REWRITE_PREVIEW.md
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/SECTION_15A_REWRITE_PREVIEW.md
ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/SECTION_15A_REWRITE_PREVIEW.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z
---
# §15 Rewrite Preview — OP-A conventions & discipline after the memory flatten
**Generated:** 2026-05-28 · Stage 5R3 Pass 2. **This is a preview, not a final draft.**
**Where this lands:** OP-A V3.18 has no literal `## 15` heading; its scope/conventions/discipline prose lives in §1 ("How to use this document"), §2 (Status Key), and the "Scope rule for folding sources" block (§3). This preview drafts the **conventions section the V4 form should carry** to reflect the post-flatten 8-member DOC80 family. Will folds it into the V4 conventions section at ratification (numbering TBD — shown here as §15A).
---
## §15A.1 — DOC80 family naming convention
The memory system is the **Memory Control Plane (DOC80 family)** (ADQ-210). It has **8 members**, each owning one or two E-slices:
| Member | E-slice(s) | Domain |
|---|---|---|
| DOC80 | E0 | Core / contracts (ContextProduct, PromptShellVariant, MemoryContextPlan, ReasonCode registry) |
| DOC81 | E1 + E2 | Scope & Policy |
| DOC82 | E3 + E4 | Knowledge + Source/Evidence |
| DOC83 | E5 + E6 | Extraction + Temporal |
| DOC87 | E_org | Organization & Membership (sits between E6 and E7) |
| DOC84 | E7 + E8 | Delivery + Prompt/Proof |
| DOC85 | E9 | Learning |
| DOC86 | E10 | UI / Inspector / Search |
Convention: cite the **member doc** (`DOC83`) for ownership and the **E-slice** (`E5`) when referring to the charter or the conceptual band. DAMS is **one substrate inside DOC84**, not its own doc. DOC87 was added at Stage 5R (ADQ-220) — the family is 8, not 7; any prose that says "7-member family" is stale.
## §15A.2 — Owner-cell discipline (one-owner rule, B3)
Every schema has **exactly one `schema_owner`** (B3). An OP-A row's target cell names that owner. After the flatten:
- A row whose concern is a memory schema names its **DOC80-family owner** (DOC81–DOC87, or DOC80 core).
- A row outside the memory-flatten boundary keeps its **current owner** (DOC1–DOC50, DOC72, DOC73, DOC24, DOC25, EC) — these are NOT re-chartered.
- When a concern spans owners, it is **split** into one row per owner (see §15A.5), never given two owners in one cell.
- "Producer owns generation; consumer owns the contract" seams (e.g. RecentActivityRollup: DOC73 generates, DOC83/DOC80 own the consumption contract) are recorded as **two rows with an explicit dependency**, not one ambiguous row.
The target cell shows `current → V4 owner` so the retarget is auditable at a glance.
## §15A.3 — `legacy_id_aliases` convention
When a V4 row's identity changes, the old ID is preserved in a **`legacy_id_aliases`** cell so cross-references don't break:
- **Merge winners** absorb the loser's ID. Example: `OBL-D25-V16-CACHE-BATCH-01` carries `legacy_id_aliases: OBL-D25-D24-V16-CACHE-BATCH-01` (D10 dup-merge).
- **Split children** carry the parent ID. Example: `OBL-D87-NEW-12-CORPUS-ORG-01` carries `legacy_id_aliases: OBL-D73-NEW-12`.
- A row whose ID is **unchanged** shows `—` — the `obl_id` is already its own V3.18 trace.
Never silently rename a row; always leave the alias breadcrumb. Retired names are also logged in `DOC80_Retired_Names.md` (lineage-only).
## §15A.4 — Charter-input cross-ref convention
Each DOC80-family charter has a single first-read: its section in **`STAGE_6_CHARTER_INPUT_INDEX.md`**, which aggregates (a) the OPA V4 rows targeting that owner, (b) resolved-deferred ADQ rows, (c) Conflict Register entries, (d) `minimum_completion_for_v5` for any AC-00x obligation, (e) open seams, (f) pre-conditions. Conventions for citing:
- ADQ rows are cited by number with their pinned charter, e.g. *ADQ-405 → E6*.
- Cross-doc seams use the `OPA-0xx` namespace, e.g. *OPA-024* (RecentActivityRollup E6 lint), *OPA-032* (DOC83↔DOC87 Topic identity).
- A charter that is a **pre-condition** for another names it explicitly (e.g. DOC87 publishes the `TopicIdentityContract` stub that DOC83/E5 imports before drafting `TopicCollectionDirective`).
## §15A.5 — Bucket discipline (carry-forward for future patch rounds)
Every retarget decision is classified into one of three buckets. **Future OP-A patch rounds reuse this discipline:**
- **Bucket A — high confidence:** one OP-A row → exactly one V4 owner (a clean move into the family, or a "stays" outside the boundary). No architect judgment. Most rows land here.
- **Bucket B — splits (medium confidence):** one OP-A row → multiple V4 rows under different owners, split on a *resolved* boundary (schema-vs-executor, extraction-vs-ingestion-vs-UI). `architect_review_required = no` — the split is mechanical once the boundary is known. Child IDs carry `split_parent` provenance.
- **Bucket C — architect judgment:** the row hedges its own schema home, or names an owner conflict the Owner Map doesn't resolve. Held as a **RESERVED placeholder** (target unchanged, `pending_architect_review` flag, pointer to the Bucket C entry + a proposed ADQ). **Keep Bucket C small (≤10).** If it grows, the section→owner model is under-specified — push rows back into A/B by tightening the model, don't punt.
Rule of thumb: a row only enters B if the *single OP-A row must become multiple V4 rows*; it only enters C if a *new architectural decision* is genuinely required. Everything else is A.