Elnor Repo Reader

# DOC80 Memory Control Plane — Flatten-and-Unify Plan V2.1b — Final Execution-Ready Revision

**Former working name:** DAMS V5 / Memory Control Plane flattening plan  
**Current target name:** DOC80 Memory Control Plane  
**Version:** V2.1b — final execution-ready revision  
**Status:** Final execution-ready flattening plan. This is not the DOC80 Memory Control Plane spec itself. It is the controlling operations plan for flattening, preserving, completing, and improving the memory-spec corpus into/around that target.  
**Supersedes:** `04_Flatten_and_Unify_Plan_V2_1a_FINAL_FOR_EXECUTION.md`, `04_Flatten_and_Unify_Plan_V2_1.md`, `04_Flatten_and_Unify_Plan_V2.md`, and `04_Flatten_and_Unify_Plan_V1.md` for active execution purposes. V1, V2, V2.1, and V2.1a remain lineage only.  
**Primary review inputs addressed:** Round E V2, V2.1, and V2.1a red-team/confirmation reviews, ABC Structural Patch R0.2, Round D Policy/Scope/UI Micro-Patch R0.2, Source Context Primer, DAMS/DOC80 V5 outline, and Coverage Audit.  

---

## 0. Executive thesis

Flattening is **controlled redesign, capability preservation, and capability completion**.

It is not archival migration. It is not a cleanup pass whose job is to make the spec smaller. It is not an MVP reduction exercise. It is the process for using the current corpus — including operative specs, accepted drafts, partial addenda, proposals, red-team reviews, and aspirational-but-valuable concepts — to produce a coherent, cutting-edge memory-control specification family without losing the best material already developed.

The governing rule:

> **Flattening MUST unify overlaps, preserve or complete valuable current and aspirational capabilities, retire only contradicted / unsafe / owner-confused / duplicate-truth concepts, and prevent agents from simplifying away excellence.**

The target is not the fastest implementation. The target is the most capable, reliable, inspectable, local-first AI orchestration and memory system feasible.

---

## 1. Scope and non-goals

### 1.1 What this plan covers

This plan covers flattening the memory-related specification corpus into a coherent DOC80 Memory Control Plane target family, including:

- source and evidence handling;
- canonical knowledge objects;
- Topics, Libraries, Projects, Episodes, IssueFrames, and organization surfaces;
- policy and scope coordination;
- extraction and ingestion;
- runtime context products, DAMS capacity/salience, DOC24 delivery, KDA rendering, and final-prompt proof;
- self-learning / DOC8 / BDSM integration;
- UI / Inspector / SearchAffordance seams;
- cross-doc owner obligations and OP-A disposition.

### 1.2 What this plan does not absorb wholesale

Flattening MUST NOT redesign non-memory systems merely because they are adjacent. It may preserve seams and obligations into them, but it must not absorb or rewrite their full domains unless the architect explicitly approves.

Out of scope for wholesale absorption:

- DOC23 task graph execution mechanics;
- DOC20 general UI mechanics not tied to memory / scope / search / Inspector behavior;
- DOC11/OpenClaw runtime truth and native session mechanics;
- DOC3 executable skill lifecycle except where procedural memory / procedure knowledge seams are required;
- self-repair / DOC9 unless explicitly reactivated by the architect;
- general code implementation planning.

### 1.3 Incomplete-spec track

Many source specs are incomplete, draft, accepted-in-principle, or aspirational. Flattening detects and records those gaps. It does not automatically finish every incomplete owner spec.

For incomplete-but-valuable material, the default action is:

```text
preserve as completion obligation
→ identify owner doc / target section
→ state minimum completion required for DOC80 V5 core or future version
→ add OP-A candidate row if cross-doc obligation exists
```

---

## 2. Product philosophy and agent behavior

### 2.1 Architect preference

This project is not optimizing for smallest scope, fastest MVP, or ordinary business shipping constraints. Complexity is acceptable when it materially improves capability, reliability, safety, user control, inspection, learning, future extensibility, or long-term system quality.

Agents MUST NOT delete, weaken, or **unilaterally defer** a feature merely because it is complex, ambitious, aspirational, unusual, or outside standard MVP practice.

Agents SHOULD reduce:

- duplicate truth stores;
- duplicate policy evaluators;
- duplicate prompt assemblers;
- duplicate lifecycle systems;
- schemas with no consumer;
- UI controls with no command/read-model closure;
- route/context/membership objects pretending to be truth;
- unbounded hot-path mechanisms;
- policy-unsafe or scope-leaky machinery;
- owner confusion;
- ambiguous implementation surfaces.

Agents SHOULD NOT reduce capability merely to simplify.

### 2.2 Concrete challenge criteria

Do not use vague labels such as “bloated” as a reason to remove material. A concept may be challenged only for concrete reasons:

```text
duplicate_truth_store
duplicate_policy_evaluator
duplicate_prompt_assembler
duplicate_lifecycle_system
schema_with_no_consumer
ui_control_without_command_or_read_model
route_or_membership_object_pretending_to_be_truth
object_should_be_edge_function_table_or_projection
unbounded_hot_path_mechanism
policy_unsafe_or_scope_leaky
owner_confused
unsupported_by_source_fixture_or_authority
contradicts_target_architecture
contradicts_owner_boundary
contradicts_user_control_or_inspectability
not_local_first
not_hot_path_deterministic
not_source_supported
```

“Not aligned with architect product philosophy” is not an autonomous challenge reason. It may be used only when tied to a concrete mismatch above, such as local-first violation, no-phantom-control violation, policy-safety violation, owner-boundary drift, loss of user control, loss of inspectability, or hot-path non-determinism.

---

## 3. Source and target freeze

### 3.1 Source freeze

The source freeze is a commit/path/hash-indexed list of every document available to the flattening process. It includes current specs, addenda, operations trackers, active proposals, red-team reviews, archived lineage, parked future modules, and uncertain material.

No file is excluded merely because it is old, aspirational, incomplete, or not obviously memory-related. Instead, each file receives status and normative weight.

### 3.2 Canonical source status

Use one source-status vocabulary across all records:

```text
operative_current
active_target_baseline
draft_controlling_for_review
accepted_directionally
aspirational_valuable
speculative_unadjudicated
review_feedback
support_non_normative
superseded_lineage
parked_future_module
do_not_import
unknown_pending_review
```

### 3.3 Normative weight

```text
governs_now
controls_target_for_review
supports_target
candidate_completion_source
lineage_only
parked_decision
review_input_only
exclude_from_import
unknown_pending_review
```

### 3.4 Legal combinations

Agents MUST NOT combine source status and normative weight arbitrarily.

| source_status | allowed normative_weight |
|---|---|
| operative_current | governs_now, supports_target |
| active_target_baseline | controls_target_for_review |
| draft_controlling_for_review | controls_target_for_review, supports_target |
| accepted_directionally | supports_target, candidate_completion_source |
| aspirational_valuable | candidate_completion_source, supports_target |
| speculative_unadjudicated | candidate_completion_source, parked_decision |
| review_feedback | review_input_only |
| support_non_normative | supports_target, review_input_only |
| superseded_lineage | lineage_only, candidate_completion_source |
| parked_future_module | parked_decision, candidate_completion_source |
| do_not_import | exclude_from_import |
| unknown_pending_review | unknown_pending_review |

A lint MUST fail contradictory pairs.

### 3.5 Target freeze

The working target architecture is frozen from:

```text
12_ABC_Consolidated_Structural_Patch_R0_2.md
13_Round_D_Policy_Scope_UI_Micro_Patch_R0_2.md
02_Concept_Model_and_Canonical_Knowledge_Resolution.md
03_DAMS_V5_Spec_Outline.md
05_Worked_Examples_and_Fixtures.md
10_Source_Context_Primer.md
08_Coverage_Audit_and_Patch_Log.md
```

After the new spec is drafted, the formal target location is:

```text
01_CURRENT_ACTIVE_SPECS/DOC80_Memory_Control_Plane/
```

The target is not blind obedience. It is the working architecture to test and refine. If source audit reveals a better current-spec mechanism than the target, the agent must route the decision through the correct decision tier.

### 3.6 Target package correction rule

Every fresh-window execution packet must include all target-freeze inputs needed for that slice. If the slice depends on `02` or `05`, those files must travel with the packet. A slice cannot rely on the architect’s memory or prior chat context for target decisions.

### 3.7 TargetFreezeRecord and availability

The target-freeze package is tracked file-by-file so fresh-window execution packets do not silently omit required context.

```ts
type TargetFreezeRecord = {
  file_ref: string;
  target_role:
    | "active_target_baseline"
    | "structural_patch"
    | "policy_scope_ui_patch"
    | "outline"
    | "fixture_source"
    | "primer"
    | "coverage_audit"
    | "optional_context";
  availability_status:
    | "attached"
    | "path_resolvable"
    | "missing_must_attach"
    | "not_required_for_slice";
  required_by_slices: string[];
  blocks_if_missing: boolean;
  content_hash?: string;
};
```

If a source-freeze or target-freeze file changes hash, every affected SourceSectionDispositionRecord, SupersessionMatrixRow, CurrentSpecCapabilityRecord, SliceCharter, GoldenScenarioRecord, OP-A candidate row, lint result, and referenced artifact whose `source_refs` or `target_refs` include that file MUST set `invalidation_state = "invalidated_pending_refresh"` or an equivalent row-level status. Agents may not continue using stale rows as authoritative inputs.

```ts
type LedgerInvalidationState = "current" | "invalidated_pending_refresh" | "refreshed";

type InvalidationMetadata = {
  invalidation_state: LedgerInvalidationState;
  invalidated_by_hash_change_refs?: string[];
  refreshed_at?: string;
};
```

Any record type that depends on a source-freeze or target-freeze hash MUST either carry `invalidation_state: LedgerInvalidationState` directly or inherit it from a parent ledger row that is visible in the fresh-window packet.

### 3.8 Execution sequence

This plan is slice-based, but the work still has a required order. Fresh windows must follow this sequence:

1. **Source / Target Freeze.** Create and hash the source and target file set.
2. **Source-section disposition + capability inventory.** Classify all in-scope source sections and assign at least provisional capability tiers before any slice charter is approved. Untiered touched capabilities are treated as `load_bearing` until reviewed.
3. **Skeletal DOC80 spec and import-graph gate.** Draft the skeletal architecture, import graph, owner map, retired-name table, and section map. The architect must confirm this skeletal architecture before slice drafting begins.
4. **Per-slice charters.** Create slice charters, known overlaps, negative-space lists, fixtures, OP-A candidates, and expected improvement/preserve rationales.
5. **Slice drafting E0–E10.** Execute slices in dependency order, with E1/E2 scope-policy lockstep and E7/E8 delivery-proof lockstep.
6. **Slice validation.** Run slice-local and cross-slice lints/fixtures. Cross-slice fixtures may use mocked upstream outputs until final integration.
7. **Final acceptance / switchover proof.** Run final-switchover fixtures, retired-name/dangling-reference lints, OP-A disposition checks, and final acceptance proof.

Architect touchpoints are mandatory at: skeletal architecture confirmation; E1/E3/E7/E8 slice charter approval; any `architect_stop` item; and final acceptance.

---

## 4. Core flattening records

This plan uses one main execution ledger, but the ledger is a control index, not a prose dump. Large proofs, slice drafts, fixture traces, OP-A tables, and review comments live as artifact files referenced from the ledger by path/hash.

### 4.1 FlatteningExecutionLedger sections

The master ledger has fixed sections:

1. Source Freeze Index
2. Target Freeze Index
3. Source Section Disposition Index
4. Capability Inventory Index
5. Aspirational Capability Completion Register
6. Supersession Matrix Index
7. Overlap / Improvement Decision Index
8. Conflict / Disagreement Register
9. Architect Decision Queue
10. Slice Execution Index
11. OP-A Candidate Disposition Index
12. Fixture / Lint Status Index
13. MemoryCoordinationTrace Coverage Index
14. Final Acceptance Proof Index

### 4.2 Ledger concurrency model

Multiple fresh Claude Code / Codex windows may work on different slices. Therefore:

- The master ledger is a short index/control file.
- Each slice writes to a per-slice fragment:
  ```text
  ledgers/slices/E##_slice_name_ledger.md
  ```
- Each slice fragment contains only that slice’s rows and artifact refs.
- Merge into the master ledger occurs only at validation gates.
- Any cross-slice contradiction enters the Conflict / Disagreement Register before either row is overwritten.

### 4.3 Artifact reference

Every ledger row that depends on a separate artifact carries:

```ts
type LedgerArtifactRef = {
  artifact_ref: string;
  artifact_kind:
    | "slice_draft"
    | "preservation_proof"
    | "semantic_compression_proof"
    | "fixture_trace"
    | "lint_report"
    | "op_a_candidate_rows"
    | "architect_decision_packet"
    | "source_section_disposition_batch"
    | "supersession_batch"
    | "memory_coordination_trace"
    | "other";
  file_path: string;
  content_hash?: string;
  status: "draft" | "in_review" | "accepted" | "rejected" | "superseded";
  invalidation_state: LedgerInvalidationState;
};
```

---

## 5. Source section disposition

Capability inventories alone are insufficient. Negative-space rules, defaults, examples, UI states, invariants, and cross-doc obligations may be embedded in prose and not look like “features.”

Every source section in the frozen source set must receive a disposition.

```ts
type SourceSectionDispositionRecord = {
  record_id: string;
  source_file: string;
  source_section_ref: string;
  source_section_title?: string;
  disposition:
    | "absorbed"
    | "absorbed_with_redesign"
    | "federated_reference"
    | "external_owner_preserved"
    | "archived_lineage"
    | "parked_future_completion"
    | "rejected"
    | "unresolved";
  target_doc_ref?: string;
  target_section_ref?: string;
  capability_refs: string[];
  supersession_refs: string[];
  op_a_obligation_refs: string[];
  negative_space_notes?: string;
  preservation_rationale?: string;
  invalidation_state: LedgerInvalidationState;
  architect_review_required: boolean;
};
```

Completeness lint:

```text
source_section.unaccounted
source_section.rejected_without_reason
source_section.absorbed_without_target
source_section.external_owner_without_owner_ref
```

---

## 6. Capability inventory and preservation

### 6.1 Capability status

```text
operative_capability
partially_specified_accepted
aspirational_valuable
speculative_unadjudicated
superseded_lineage
parked_future_capability
non_capability_lineage
```

Aspirational-but-valuable capability is not disposable. It must be preserved as a completion obligation unless the architect rejects it.

### 6.2 Capability tier

```text
crown_jewel_must_showcase
crown_jewel_preserve
load_bearing
important
supporting
minor
lineage_only
unknown_untiered
```

Safe default:

> Any untiered capability touched by a slice is treated as `load_bearing` until the architect or an approved classification row assigns a lower tier.

source/capability inventory phase cannot exit until every in-scope source doc has capability rows with at least provisional tiers.

### 6.3 CurrentSpecCapabilityRecord

```ts
type CurrentSpecCapabilityRecord = {
  capability_id: string;
  source_file: string;
  source_section_refs: string[];
  capability_name: string;
  capability_status: CapabilityStatus;
  capability_tier: CapabilityTier;
  crown_jewel_pass: "none" | "preliminary" | "final";
  user_or_system_value: string;
  owner_doc?: string;
  target_disposition: DispositionMove;
  preservation_required: boolean;
  preservation_proof_ref?: string;
  completion_record_ref?: string;
  invalidation_state: LedgerInvalidationState;
  architect_review_required: boolean;
};
```

### 6.4 Seed crown-jewel / load-bearing families

The initial capability inventory must seed at least these families as load-bearing or crown-jewel until reviewed:

- DOC72 six-dimensional knowledge and graph shape;
- DOC72 procedural taxonomy and standing-procedure / skill / task escalation;
- DOC73 CU / VersionedClaim / RecentActivityRollup / source-bound synthesis discipline;
- DOC25 parse quality, materialization, SourceArtifact, ArtifactSegment, and prompt-injection isolation;
- DOC24 packet lifecycle, manifests, context assembly, injection slots, Packet Inspector, final-prompt proof;
- KDA reference-only-vs-excluded distinction, deterministic rendering, KdaManifestPatch, render safety metadata;
- BDSM/DOC8 final-prompt-proof-gated utility, partitioned learning, no second confidence system;
- PropA/EC source policy, dimensional policy, command closure, one compiled policy evaluator;
- DOC20 Project / Library / Inspector / visible-control command closure;
- DOC23 task outputs, Claim Extractor interfaces, task-output-to-memory seams;
- DOC3 procedural memory / skill lifecycle seams;
- TopicLens and TopicCollectionDirective;
- Library/corpus source collection and deep ingestion;
- Assertion / CU / Evidence / Directive / Procedure / IssueFrame / NullResult distinctions;
- MemoryCoordinationTrace and final proof chain.

---

## 7. Aspirational capability completion

Aspirational material is classified, preserved, and completed or deferred deliberately.

```ts
type AspirationalCapabilityCompletionRecord = {
  completion_id: string;
  capability_ref: string;
  source_refs: string[];
  value_statement: string;
  target_landing:
    | "include_in_doc80_v5_core"
    | "include_as_future_completion_obligation"
    | "federate_to_owner_doc"
    | "parked_for_architect_decision"
    | "reject";
  minimum_completion_for_v5:
    | "none_not_in_v5_core"
    | "conceptual_rule_only"
    | "schema_stub"
    | "schema_plus_owner_boundary"
    | "schema_plus_lints_and_fixtures"
    | "implementation_ready_contract";
  minimum_completion_set_by:
    | "architect"
    | "preapproved_target_rule"
    | "batch_decision_required";
  missing_to_complete: string[];
  owner_doc_target?: string;
  op_a_candidate_required: boolean;
  decision_ref?: string;
};
```

Agents may not decide the minimum completion depth for a feature entering DOC80 V5 core unless a pre-approved target rule covers it. Otherwise it enters the Architect Decision Queue.

---

## 8. Supersession matrix and retired-name control

### 8.1 SupersessionMatrixRow

Every named type, enum, schema, concept, product kind, policy object, scope object, prompt shell, and old/new overlapping mechanism in the frozen source set must appear in the Supersession Matrix, even if retained.

```ts
type SupersessionMatrixRow = {
  row_id: string;
  source_name: string;
  source_kind:
    | "type"
    | "enum"
    | "schema"
    | "concept"
    | "prompt_shell"
    | "context_product"
    | "policy_object"
    | "scope_object"
    | "ui_surface"
    | "procedure"
    | "other";
  source_refs: string[];
  disposition: DispositionMove;
  target_name?: string;
  target_refs: string[];
  approval_status:
    | "preapproved_auto_rename"
    | "architect_approved"
    | "agent_proposed"
    | "requires_architect_review"
    | "rejected"
    | "deferred";
  architect_decision_ref?: string;
  capability_preservation_proof_ref?: string;
  legacy_alias_allowed: boolean;
  alias_expiry?: string;
  retired_name_lint_pattern?: string;
  migration_effect:
    | "none"
    | "rename_only"
    | "semantic_change"
    | "object_to_edge"
    | "object_to_function"
    | "object_to_static_table"
    | "object_to_projection"
    | "local_schema_to_owner_schema"
    | "retired_without_replacement";
  requires_local_data_migration: boolean;
  invalidation_state: LedgerInvalidationState;
  allowed_historical_reference_context?: string[];
};
```

### 8.2 Required preservation proof

`capability_preservation_proof_ref` is required when disposition is:

```text
merge_into_target
split_into_multiple_targets
replace_by_edge
replace_by_function
replace_by_static_table
replace_by_projection
semantic_compression
federate_to_owner_doc
defer_completion
park_future_module
retire_as_superseded
reject
```

`retain_as_is` and `preserve_with_minor_update` do not require a capability-preservation proof unless the row changes, downgrades, narrows, or externalizes a load-bearing capability. `unresolved` is not an executable disposition and blocks affected slice completion.

### 8.3 Already-approved autonomy rule

Agents may autonomously apply a rename or supersession only when the row has:

```text
approval_status = preapproved_auto_rename OR architect_approved
```

An agent-proposed row cannot become its own authority.

### 8.4 Completeness lint

```text
supersession.source_concept_unaccounted
supersession.applied_without_approval
supersession.retired_without_preservation_proof
supersession.alias_expired_but_used
supersession.retired_name_used_outside_allowed_historical_context
```

### 8.5 Known names that require explicit supersession rows

At minimum, the matrix must include:

```text
PremiseFamily / PremiseVariant
generic Claim
ConsolidatedUnderstanding / SourceSetSynthesis
Assertion / AssertionVariant / AssertionCandidate / AssertionResolution
ScopeMembrane / ScopeBoundary / EffectiveMemoryPolicy
PolicyMembraneDecision / MemoryPolicyDecision
SearchAffordance
DAMS standalone ranking / DAMS context-product seam
Library / Corpus / SourceCollection / CorpusIndex
MemoryFlowCertificate / ContextPacketProof
ContextProduct / legacy memory card / KDA render card
TopicLens / TopicCollectionDirective / Topic facts
WorkingStateEvent / IssueFrameUpdate
UserContextSurfacePlan old and new variants
```

---

## 9. Overlap resolution and improvement

Overlap is not automatically a defect. It is the primary signal that multiple source docs may contain partial views of a better unified mechanism.

### 9.1 Canonical overlap key

```ts
type CanonicalOverlapKey = {
  sorted_concept_names: string[];
  owner_doc_refs: string[];
  overlap_domain:
    | "truth_identity"
    | "policy"
    | "scope"
    | "delivery"
    | "rendering"
    | "learning"
    | "ui"
    | "extraction"
    | "source"
    | "procedure"
    | "other";
};
```

Once an overlap key is resolved, later slices must consume the resolution by reference, not re-resolve it.

### 9.2 DispositionMove

Use one canonical move vocabulary across capability, supersession, overlap, and improvement records:

```text
retain_as_is
preserve_with_minor_update
absorb_as_target_rule
merge_into_target
split_into_multiple_targets
replace_by_edge
replace_by_function
replace_by_static_table
replace_by_projection
semantic_compression
federate_to_owner_doc
defer_completion
park_future_module
retire_as_superseded
reject
unresolved
```

### 9.3 OverlapResolutionRecord

```ts
type OverlapResolutionRecord = {
  overlap_id: string;
  canonical_overlap_key: CanonicalOverlapKey;
  source_refs: string[];
  target_refs: string[];
  overlap_kind:
    | "true_duplicate"
    | "partial_overlap"
    | "terminology_only"
    | "owner_boundary_overlap"
    | "false_overlap"
    | "target_improves_old"
    | "old_improves_target"
    | "requires_third_mechanism";
  resolution: DispositionMove;
  lost_or_changed_capabilities: string[];
  preservation_proof_ref?: string;
  semantic_compression_proof_ref?: string;
  architect_decision_ref?: string;
};
```

For `terminology_only` or `false_overlap` involving crown-jewel, load-bearing, policy, scope, truth identity, injection, final-prompt, or owner-boundary concepts, require second-agent confirmation or architect-batch review.

### 9.4 Preservation rationale

`retain_as_is` requires a positive rationale:

```text
- why existing structure is stronger or already correct;
- what capability it protects;
- what would be lost by replacing it;
- what fixture/invariant confirms it still works.
```

### 9.5 Semantic compression proof

When many local cases are replaced by one general rule, the proof must include:

```text
- at least two old behaviors that still work;
- no owner boundary weakened;
- no policy/scope/injection behavior weakened;
- no hidden lifecycle or truth-store change.
```

---

## 10. Conflict / Disagreement Register

Disagreement is signal. It must be recorded, not smoothed.

A conflict row is mandatory whenever two agents, two slices, or two ledger sections classify the same concept differently, including disagreements over owner, function, status, tier, disposition, target landing, or preservation proof.

```ts
type AuditDisagreementRecord = {
  disagreement_id: string;
  source_refs: string[];
  disagreement_kind:
    | "owner"
    | "function"
    | "schema_shape"
    | "source_status"
    | "normative_weight"
    | "capability_tier"
    | "supersession_disposition"
    | "target_landing"
    | "preservation_proof"
    | "op_a_disposition"
    | "other";
  position_a: string;
  position_b: string;
  proposed_resolution?: string;
  architect_required: boolean;
  status: "open" | "resolved" | "deferred";
  architect_decision_ref?: string;
};
```

No later row may silently overwrite an earlier contradictory classification. It must cite the resolved disagreement.

---

## 11. Architect decision tiers

### 11.1 Agent-autonomous

Allowed without architect review:

- formatting, typo cleanup, non-semantic section moves;
- applying architect-approved supersession rows;
- adding cross-references;
- moving content without meaning change;
- filling obvious source-path metadata;
- applying pre-approved lint fixes.

### 11.2 Batch-for-architect

Batch decisions into short packets. Do not interrupt the architect one item at a time.

Batch when:

- product-facing behavior changes;
- UI/UX behavior changes;
- aspirational valuable features need completion depth decisions;
- capability preservation vs redesign has multiple reasonable answers;
- old mechanism appears better than target but only adds to target;
- status/tier is unclear;
- overlap changes capability but not owner/policy/truth architecture;
- a decision affects Topics, Libraries, Projects, Search, Inspector, carryover, prompt shell, or user-visible injection behavior.

### 11.3 Immediate architect stop

Stop immediately when:

- policy/privacy/firewall behavior changes;
- durable truth ownership changes;
- new canonical object family is introduced;
- a crown-jewel capability is deleted, downgraded, or materially changed;
- final-prompt/injection architecture changes;
- EC/DOC72/DOC24/DOC73/KDA/BDSM owner-boundary conflict appears;
- an old mechanism would reverse or contradict ABC R0.2 or Round D R0.2;
- a protected/sensitive scope decision is ambiguous;
- there is no safe default.

### 11.4 ArchitectDecisionQueueItem

```ts
type ArchitectDecisionQueueItem = {
  decision_id: string;
  decision_tier: "batch_for_architect" | "architect_stop";
  status: "open" | "resolved" | "deferred";
  question: string;
  recommended_answer: string;
  alternatives: string[];
  decision_outcome?: string;
  architect_answer?: string;
  default_if_no_response?: string; // FORBIDDEN when decision_tier = architect_stop; allowed only for non-blocking batch items
  blocks_slices: string[];
  created_at: string;
  aging_state: "fresh" | "due" | "blocking";
  source_refs: string[];
};
```

A lint must fail `architect_stop` rows with `default_if_no_response`.

If `blocks_slices` is non-empty, the decision blocks those slices until resolved. `default_if_no_response` applies only to non-blocking batch items and may only be one of: `preserve_status_quo`, `defer`, `no_op`, or `create_unresolved_row`. A default may not create, delete, downgrade, expose, export, learn from, reassign ownership of, or change final-prompt behavior for any product-facing capability.

---

## 12. Dependency-ordered work slices

This plan uses dependency-ordered work slices. That means dependent systems are drafted together or in the order their contracts require. The word “DAG” is not used in the operating instructions; the plain rule is: **do not draft a thing before the thing it depends on is at least declared.**

### 12.1 Cross-cutting slice E0

**E0 — Cross-cutting contracts and import graph**

Purpose:

- define owner-doc imports;
- declare retired-name policy;
- define shared DispositionMove, evidence/proof refs, status vocabulary;
- create skeletal spec/import graph gate;
- prevent local-schema redefinition.

### 12.2 Scope and policy are lockstep

Round D makes scope and policy interdependent. Scope identifies identity, relation, containment, boundary, and uncertainty. Policy consumes scope information and computes capability and disclosure decisions.

Therefore:

```text
E1 — Scope/Policy seam, pass 1:
     declare scope objects, boundary inputs, policy objects, dimensional policy vector, and import dependencies.

E2 — Scope/Policy seam, pass 2:
     validate policy meet, disclosure meet, fail-closed behavior, UI disclosure, stamps, invalidation, and fixtures.
```

Do not draft policy as if scope were unavailable. Do not draft scope as if it emits final allow/block decisions.

### 12.3 Knowledge object slice

**E3 — Canonical knowledge objects**

Includes:

- Assertion / AssertionVariant / AssertionCandidate / AssertionResolution;
- CU / source-bound synthesis;
- EvidenceRecord / EvidenceSupportEdge;
- Directives;
- Procedures / standing procedures;
- IssueFrames / IssueFrameUpdates;
- NullResultMemory;
- IncidentObservation / FrictionEvent / FrictionPattern;
- source-bound and temporal object lifecycle.

This fixes the V2 gap where CUs and non-assertion memory had no slice home.

### 12.4 Source and extraction slices

```text
E4 — Source / Evidence / parse-quality gate
E5 — Canonical Extraction Spine and promotion/degradation lifecycle
E6 — Temporal / working-state / RecentActivity / episode integration
```

### 12.5 Delivery and learning slices

```text
E7 — Runtime context products + DAMS seam + DOC24/KDA delivery
E8 — Prompt shells / render safety / final-prompt proof / MemoryCoordinationTrace
E9 — Learning / DOC8 / BDSM / final-prompt-proof utility

Before drafting integration prose, E9 must reconcile: DOC8 actual current capabilities; BDSM V6.5 learning contracts; consumer assumptions from DOC24/KDA/DOC23/DOC72; missing learning-engine capabilities; final-prompt-proof constraints; and any phantom or aspirational DOC8 assumptions. E9 may preserve a future-completion obligation, but may not write as operative any learning capability that lacks an owner, input signal, durable artifact, runtime consumer, and final-prompt-proof eligibility rule.
```

DAMS MUST be drafted with Context Products and DOC24 delivery. DAMS is not a standalone ranking subsystem.

### 12.6 UI / Inspector / Search slice

```text
E10 — UI / Inspector / SearchAffordance / Project-Library-Topic visible controls
```

This slice must seed the Round D UI surfaces:

- review queue / batched architect decision card;
- policy restamp panel;
- blocked-item explanation panel;
- privacy / policy banner;
- Project auto-link quarantine chip;
- cross-project search expansion chip;
- task handoff scope-envelope confirmation;
- why-included / why-excluded / why-not-remembered Inspector;
- Topic Notice / Library Notice / Search More affordances.

Every UI surface needs:

```text
loading state
empty state
degraded state
error state
command or route
telemetry event
read-model refresh
safe-label policy
Inspector behavior
```

---

## 13. Slice charters and fresh-window execution packets

Each slice receives a fresh-window packet. The packet must include:

```text
slice objective
source docs to consume
target-freeze files required
source-section disposition rows already relevant
capability seed rows
known overlaps
known unresolved decisions
negative space / do-not-do list
required lints
required fixtures
required OP-A candidate rows
supersession matrix index, including retired-name and allowed-alias rows
expected improvement or preserve-as-is rationale
expected outputs
```

Slice charter completeness is a gate. Every slice charter must include `expected_improvement_or_preserve_rationale`, stating either the substantive improvement the slice expects to make or why preserving the existing structure may be the better design.

High-risk slices E1/E2/E3/E7/E8/E10 require pre-drafting review. For architecture-defining slices E1, E3, E7, and E8, architect approval is mandatory; second-agent confirmation may supplement but may not substitute for architect approval. E2 and E10 may proceed on architect approval or explicit architect-approved second-agent confirmation when no product, policy, privacy, durable-truth, or final-prompt decision remains open.

Lint:

```text
slice_charter.missing_required_source_doc
slice_charter.missing_negative_space
slice_charter.missing_fixture_map
slice_charter.missing_known_overlap
slice_charter.missing_expected_improvement_or_preserve_rationale
```

Negative-space lint:

```text
slice.implemented_declared_negative_space
slice.no_improvement_or_preserve_rationale
```

---

## 14. Golden scenarios and fixtures

Golden scenarios must be executable assertions, not one-line names.

Each fixture must state expected outcomes across dimensions:

```ts
type GoldenScenarioRecord = {
  scenario_id: string;
  name: string;
  source_inputs: string[];
  expected_extraction?: string;
  expected_policy?: string;
  expected_canonical_object?: string;
  expected_organization?: string;
  expected_injection?: string;
  expected_rendering?: string;
  expected_learning?: string;
  expected_ui?: string;
  expected_trace_or_proof?: string;
  gate_level: "slice_local" | "cross_slice" | "final_switchover";
  blocking_severity: "advisory" | "warning" | "blocker";
};
```

Cross-slice fixtures may be validated with mocked upstream outputs until final integration, but the mock must be a static artifact referenced by path/hash and must match the upstream slice's declared output contract. Final-switchover fixtures cannot rely on mocks.

Fixture-to-slice matrix is required:

```text
fixture_id
required_slices
required_owner_docs
expected_proof_object
blocking_severity
```

---

## 15. MemoryCoordinationTrace proof gate

Round D restored MemoryCoordinationTrace as the bridge among scope, policy, extraction, context planning, DOC24 manifests, KDA patches, final prompt proof, Inspector explanation, and learning.

V2.1 requires a MemoryCoordinationTrace Coverage section.

Required lints:

```text
memory_coordination_trace.missing
memory_coordination_trace.no_extraction_plan_for_why_not_remembered
memory_coordination_trace.no_policy_generation_id
memory_coordination_trace.no_final_prompt_manifest_when_learning_event_exists
memory_coordination_trace.inspector_explanation_without_trace
memory_coordination_trace.context_product_without_product_instance_id
```

---

## 16. OP-A disposition timing

OP-A cannot wait until implementation handoff for cross-doc changes discovered during flattening.

Before final integration review, every accepted cross-doc obligation must have either:

```text
proposed OP-A row ID
```

or:

```text
explicit no-row-needed reason
```

Each proposed row carries:

```text
target owner doc
target section/topic
obligation summary
blocking status
fixture/lint ref
migration/supersession implication
source refs
```

The actual OP-A file can be patched later, but candidate rows must exist before final integration review.

---

## 17. Lint suite

### 17.1 Ledger consistency lints

```text
ledger.deferred_without_completion_record
ledger.decision_ref_dangling
ledger.tiered_change_without_proof
ledger.artifact_ref_missing
ledger.conflict_overwritten_without_resolution
ledger.source_status_weight_illegal_pair
ledger.architect_stop_has_default
ledger.blocking_batch_item_has_default
ledger.default_changes_product_or_policy_behavior
```

### 17.2 Supersession lints

```text
supersession.source_concept_unaccounted
supersession.retired_name_used
supersession.local_schema_redefinition
supersession.dual_running_type_family
supersession.applied_without_approval
supersession.changed_capability_without_preservation_proof
supersession.missing_local_data_migration_flag
```

### 17.3 Source-section lints

```text
source_section.unaccounted
source_section.absorbed_without_target
source_section.rejected_without_reason
source_section.external_owner_without_owner_ref
```

### 17.4 Policy/scope/UI lints from Round D

```text
policy.bare_render_action
policy.unresolved_policy_ref
policy.undefined_policy_obligation
policy.export_stamp_without_destination
scope.fail_closed_candidate_tag_only
ui.hidden_ref_without_disclosure_class
ui.inspector_leak
ui.visible_action_without_command_route_or_noop
safe_label.derived_from_protected_content
blocked_notice.leaks_title_count_or_source
search_affordance.auto_pull_without_preflight
project.auto_link_sensitive_capture_without_quarantine
dams.eligibility_ceiling_violation
source.deleted_or_clawed_back_support_retained_as_fact
review_queue.gridlock_warning
reference_only.contains_substantive_summary
```

### 17.5 Fixture lints

```text
fixture.no_expected_outcomes
fixture.no_slice_mapping
fixture.final_switchover_scenario_not_run
fixture.cross_slice_gate_failed
```

---

### 17.6 Lint waivers

Lints may be waived only by the architect. A waiver is not a silent pass; it must carry a reason, scope, and replacement obligation where appropriate.

```ts
type LintWaiverRecord = {
  waiver_id: string;
  lint_id: string;
  affected_ref: string;
  waiver_reason: string;
  approved_by: "architect";
  expires_at?: string;
  replacement_obligation_ref?: string;
};
```

---

## 18. Skeletal spec and import graph gate

Before drafting long prose, create a skeletal DOC80 target with:

```text
spec family membership
owner-doc imports
canonical object families
section map
retired-name table
cross-doc owner map
required lints
required fixtures
OP-A candidate table placeholder
```

The architect must confirm the skeletal DOC80 architecture — object families, section map, owner map, import graph, and retired-name table — before any slice charter is approved.

No full slice draft may proceed until the import graph proves:

- no local redefinition of owner-doc schemas;
- no dual-running type families;
- no retired names outside allowed historical context;
- every cross-doc import has an owner;
- every required target-freeze file is attached or path-resolvable.

---

## 19. Final acceptance standard

Flattening is not complete until:

1. Source Freeze covers the corpus.
2. Target Freeze is explicit and current.
3. Every source section has a disposition.
4. Every named type/enum/schema/concept has a supersession row.
5. Every load-bearing/crown-jewel capability is preserved, redesigned with proof, deferred by decision, or rejected by decision.
6. Aspirational valuable capabilities have completion records.
7. Conflict / Disagreement Register has no unresolved blockers.
8. Architect Decision Queue has no unresolved stop items.
9. Golden fixtures pass at required gate level.
10. Lints pass or have architect-approved waivers recorded through `LintWaiverRecord`.
11. MemoryCoordinationTrace proof gates pass.
12. OP-A candidate dispositions exist for all accepted cross-doc obligations.
13. No old/new duplicate concept families remain live.
14. No final-prompt/injection/learning path lacks proof.
15. Every slice records either a substantive improvement or a positive preserve-as-is rationale.
16. Final integration reviewers can trace every material source concept to retained, redesigned, federated, deferred, parked, or retired status.

---

## 20. What V2.1b deliberately changes from V2.1a

V2.1b keeps V2.1a’s philosophy and applies the final Round E V2.1 review fixes:

- restores the Conflict / Disagreement Register;
- adds ledger concurrency through per-slice fragments;
- closes the “already approved” autonomy leak;
- treats untiered capabilities as load-bearing by default;
- adds SourceSectionDispositionRecord;
- makes preservation proofs mandatory for capability-changing moves;
- defines minimum completion depth for aspirational material;
- forbids silent defaults for architect-stop decisions;
- harmonizes status vocabulary;
- adds canonical overlap keys and disposition moves;
- adds MemoryCoordinationTrace coverage;
- moves policy/scope into a lockstep two-pass seam;
- gives CUs and non-assertion memory an explicit slice home;
- seeds crown-jewel/load-bearing capabilities;
- adds fresh-window execution packet rules;
- imports Round D UI surfaces, lints, and OP-A timing requirements;
- restores the per-slice improvement-or-preserve rationale gate;
- adds a single execution sequence and removes dangling phase references;
- fixes DispositionMove enum drift;
- tightens `default_if_no_response`;
- adds TargetFreezeRecord availability tracking and hash invalidation;
- adds `requires_local_data_migration` to SupersessionMatrixRow;
- adds supersession matrix index to fresh-window packets;
- permits mocked upstream outputs for cross-slice fixtures until final integration;
- requires architect confirmation of skeletal DOC80 architecture;
- requires architect approval for E1/E3/E7/E8 charters;
- adds E9 DOC8/BDSM capability reconciliation;
- adds LintWaiverRecord.

V2.1b applies the final confirmation-review cleanup:

- fixes duplicate numbering in the final acceptance list;
- corrects the §4 version label from V2.1 to V2.1b;
- adds `LedgerInvalidationState` and row-level invalidation recording so `invalidated_pending_refresh` has a schema home;
- adds `waiver_id` to `LintWaiverRecord` for stable ledger references.

---

## 21. Status and next use

This version is final for active flattening execution. Any follow-up review should be a confirmation check, not a philosophical re-review:

```text
Does V2.1b apply the agreed V2.1a confirmation-review fixes and serve as a safe active flattening execution plan for source/target freeze, skeletal DOC80 target-baseline work, and dependency-ordered slice drafting?
```

Do not re-review the Memory Control Plane architecture itself unless V2.1b contradicts ABC R0.2, Round D R0.2, or the architect’s product philosophy.