ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# DOC80 — Import Graph

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Document status:** `target-baseline` (skeletal; companion to `DOC80_Skeletal_Target_Baseline.md`).
**Versioning discipline:** git-native — stable filename, no version suffix. Git history is the version record.
**Round:** Stage 5R2 (4-edge-kind restructure applied 2026-05-27 per synthesis must-fix #3).

This file proves the plan §18 import-graph conditions before slice charters are approved.

---

## 1. Intra-family imports — DOC80 → DOC8x (8 members after Stage 5R)

**Stage 5R correction (per B1 / G-3):** the round-1 graph contained a cycle `DOC81 → DOC84 → DOC86 → DOC81`. The wrong-direction edge `DOC86 → DOC81` was deleted; the correct edge `DOC81 → DOC86` was added to carry `PolicyStamp` + `EffectiveMemoryPolicy` reference + `disclosure_class` + restamp eligibility + safe-label constraints into the UI member. The round-1 §1 statement "no upward imports" was false; the corrected rule (below) is precise about external control flows.

**Rule:** DOC80 is the one core/contracts member; every other family member imports from DOC80. Lateral imports between non-core members exist at lockstep / pipeline boundaries (table §2). Control flows that go through an EXTERNAL doc (e.g. `DOC86 → EC → DOC81`) are external control flows, not member-to-member imports, and do not constitute a cycle.

```
                              ┌──────────────────────────────┐
                              │ DOC80  (Core / Contracts)    │
                              │  shared vocab, registries,   │
                              │  proof spine + lint family,  │
                              │  warrant-degradation-trigger │
                              │  registry, domain-profile    │
                              │  registry, MemoryCoord-      │
                              │  inationTrace, memory-object │
                              │  taxonomy, compute-budget    │
                              │  envelope, ExternalDep-      │
                              │  endencyRecord               │
                              └──────────────┬───────────────┘
                                             │ imports flow downward
       ┌─────────────┬─────────────┬─────────┴────────┬─────────────┬─────────────┬─────────────┐
       │             │             │                  │             │             │             │
       ▼             ▼             ▼                  ▼             ▼             ▼             ▼
┌──────────┐  ┌────────────┐  ┌──────────┐  ┌─────────────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│ DOC81    │  │ DOC82      │  │ DOC83    │  │ DOC87 (NEW)     │  │ DOC84    │  │ DOC85    │  │ DOC86    │
│ Scope+   │  │ Knowledge+ │  │ Extract+ │  │ Organization +  │  │ Delivery+│  │ Learning │  │ UI +     │
│ Policy   │  │ Source/Ev  │  │ Temporal │  │ Membership      │  │ Prompt/  │  │ (E9)     │  │ Inspr+   │
│ (E1/E2)  │  │ (E3/E4)    │  │ (E5/E6)  │  │ (new slice      │  │ Proof    │  │          │  │ Search   │
│          │  │            │  │          │  │  between E6/E7) │  │ (E7/E8)  │  │          │  │ (E10)    │
└────┬─────┘  └────────────┘  └──────────┘  └─────────────────┘  └──────────┘  └──────────┘  └──────────┘
     │
     └─────────────────────────────────────────────────────────────────────────────────────────►──┘
       NEW EDGE (Stage 5R B1): DOC81 → DOC86 carrying
       PolicyStamp + EffectiveMemoryPolicy ref + disclosure_class + restamp eligibility + safe-label constraints
```

### 2. Lateral imports between non-core members — 4 edge-kind tables (Stage 5R2 restructure per synthesis #3)

The Stage 5R single-table form mixed four genuinely distinct edge kinds, producing apparent cycles (e.g. DOC82 ↔ DOC83) and inconsistent DOC87 edge directions. **Acyclicity is asserted ONLY on the `schema_import` edge kind.** Runtime, command/control, and storage/execution flows may have different (often opposing) directions and do not constitute import cycles.

**Edge-kind definitions:**

- **`schema_import`** — A imports B's schema/contract definitions; A's text references B-owned types by name. **Must be acyclic.** Strict owner-to-consumer convention: `from = schema owner`, `to = consumer`.
- **`runtime_instance_flow`** — A produces instances at runtime against a B-owned contract; cargo is data, not schema. From = producer, to = consumer of the runtime instance.
- **`command_or_control_flow`** — A invokes a command or signals control to B at runtime; B executes. From = invoker, to = executor.
- **`storage_or_execution_flow`** — A's runtime payload is stored or executed by B (B is the system-of-record for that payload). From = schema owner, to = storage/executor.

#### 2.1 `schema_import` (must be acyclic — proof §5.6)

| from (schema owner) | to (consumer) | imported contracts | reason |
|---|---|---|---|
| DOC80 | DOC81 / DOC82 / DOC83 / DOC84 / DOC85 / DOC86 / DOC87 | shared vocab, registries (ReasonCode / ContextProduct / PromptShellRegistry / Warrant-degradation-trigger / Domain-profile / ExternalDependencyRecord), proof spine (ContextPacketProof / RenderSafetyProof / MemoryFlowCertificate), MemoryCoordinationTrace, memory-object taxonomy, compute-budget envelope | DOC80 is the one core/contracts member |
| DOC81 | DOC82, DOC83, DOC84, DOC85, DOC86, DOC87 | EffectiveMemoryPolicy contract, ScopeResolutionResult, PolicyStamp, disclosure_class, restamp eligibility contract, SafeLabelDisclosurePolicy | Policy/scope gates flow downstream |
| DOC82 | DOC83, DOC84, DOC85, DOC87 | Assertion family schemas (Assertion / AssertionVariant / AssertionCandidate / AssertionResolution / AssertionDedupeOutcome / AssertionCandidateEmission), EvidenceRecord, EvidenceSupportEdge, SourceEnvelope, ExtractionRouteContext, SourceBoundSynthesisAdapter (conditional per ADQ-219) | Knowledge contracts |
| DOC87 | DOC83, DOC84, DOC86 | TopicIdentityContract (MembershipTargetRef / OrganizationContainerRef / TopicRef / LibraryRef / ProjectMembershipRef), MemoryMembershipEdge, MembershipLifecycleState, MembershipSource, MembershipInvalidationPolicy, Topic, TopicLens organization semantics, TopicActivationState | Membership/organization contracts; DOC83 imports TopicIdentityContract before TopicCollectionDirective is drafted (OPA-032) |
| DOC83 | DOC84, DOC85 | ExtractionContextPlan, AssertionCandidateDisposition (ABC §7.8), AlternativeExtractionRouting, ExtractionRouteContext, ExtractionResult, ReviewQueueEntry, IssueFrame, RecentActivityRollupConsumptionContract, NullResultMemory, TopicCollectionDirective, FrictionEvent | Extraction outputs |
| DOC84 | DOC85, DOC86 | ContextProduct assembly contract, MemoryContextPlan implementation, RenderSafetyProof execution, DynamicHeaderLedger, PriorDeliveryLedger, CarryoverCapsule, CognitiveDiff/ResumeProjection, contamination_risk computation | Delivery contracts |

**Note:** the apparent "DOC82 ↔ DOC83" / "DOC83 ↔ DOC82" pair from the Stage 5R table is now correctly a single downward `DOC82 → DOC83` schema_import. The reverse arrow was a `runtime_instance_flow`, not a schema import. The phantom cycle is dissolved.

#### 2.2 `runtime_instance_flow` (cycles allowed; not a schema cycle)

| from (producer) | to (consumer of runtime instance) | instances |
|---|---|---|
| DOC83 | DOC82 | `AssertionCandidateEmission` instances (DOC83 produces against the DOC82-owned contract; DOC82 resolves) |
| DOC83 | DOC87 | membership candidates from extraction (DOC83 emits via TopicCollectionDirective; DOC87 owns candidate-to-confirmed lifecycle) |
| DOC83 | DOC84 | ContextProduct candidates, MemoryContextPlan inputs |
| DOC81 | DOC84, DOC85, DOC86 | EffectiveMemoryPolicy runtime values, PolicyStamp instances |
| DOC84 | DOC85 | ContextPacketProof + RenderSafetyProof runtime instances for learning eligibility |
| DOC84 | DOC86 | SearchAffordance runtime resolution, AvailabilityDisposition, ContextProduct delivery state |
| DOC85 | DOC81 | warrant-degradation signals (learning produces; policy plane consumes for restamp eligibility) |

#### 2.3 `command_or_control_flow` (cycles allowed; not a schema cycle)

| from (invoker) | to (executor) | commands / signals |
|---|---|---|
| DOC86 | EC | UI commands (inspect / restamp / disclose / membership-control / SearchAffordance preflight) |
| EC | DOC81 | policy re-evaluation triggers |
| DOC83 | EC | durable-write candidate hand-off |
| DOC87 | EC | membership write hand-off |
| DOC85 | EC | learning write-back commands |
| DOC81 | EC | policy enforcement commands |

#### 2.4 `storage_or_execution_flow` (cycles allowed; not a schema cycle)

| from (schema owner) | to (storage / executor) | payload |
|---|---|---|
| DOC82 | DOC72 | Assertion / AssertionVariant / AssertionRelationEdge / EvidenceRecord / EvidenceSupportEdge graph payload |
| DOC82 | EC | durable Assertion writes |
| DOC83 | DOC72 | IssueFrame / IssueFrameUpdate / WorkingStateEvent graph payload |
| DOC87 | DOC72 | MemoryMembershipEdge graph payload |
| DOC87 | EC | durable membership writes |
| DOC85 | EC | learning signal write-back |

### 2.5 `schema_import` acyclicity

Walking the §2.1 `schema_import` edges:

```
DOC80 → {DOC81, DOC82, DOC83, DOC84, DOC85, DOC86, DOC87}
DOC81 → {DOC82, DOC83, DOC84, DOC85, DOC86, DOC87}
DOC82 → {DOC83, DOC84, DOC85, DOC87}
DOC87 → {DOC83, DOC84, DOC86}
DOC83 → {DOC84, DOC85}
DOC84 → {DOC85, DOC86}
```

Topological order: `DOC80 < DOC81 < DOC82 < DOC87 < DOC83 < DOC84 < DOC85, DOC86`. **No upward `schema_import` edge.** Acyclic.

DOC87 specifically:
- **Inbound `schema_import`:** DOC80, DOC81, DOC82 — all upstream of DOC87.
- **Outbound `schema_import`:** DOC83, DOC84, DOC86 — all downstream of DOC87.
- **DOC83 → DOC87 is NOT a schema_import** — DOC83 produces *runtime instances* of DOC87-owned membership candidates (§2.2); DOC83 imports DOC87's TopicIdentityContract *schema* (§2.1, DOC87 → DOC83). The Stage 5R table's `DOC83 → DOC87` row was incorrectly typed; it is now §2.2 only.

All DOC87 edges follow a single owner-to-consumer convention in §2.1 (DOC87 owns; downstream consumes).

---

## 3. External owner-doc imports (pinned per Patch B7)

DOC80 family imports from external owner docs. Every entry below corresponds to an `ExternalDependencyRecord` in DOC80 §13.

| family member | imports from | imported objects | rule | pin status |
|---|---|---|---|---|
| DOC82 | DOC72 | six-dimensional knowledge + graph topology + procedural taxonomy + Assertion graph payload storage + Entity object | DOC72 retains; DOC82 consumes via graph payload refs | `ExternalDependencyRecord` required (B7) |
| DOC82 | DOC73 | ConsolidatedUnderstanding semantics (ADQ-219) | DOC73 retains; DOC82 consumes directly OR via `SourceBoundSynthesisAdapter` wrapper | `ExternalDependencyRecord` required |
| DOC82 | DOC25 | SourceArtifact + ArtifactSegment + parse-quality + materialization | DOC25 retains; DOC82 consumes via SourceEnvelope segment refs | `ExternalDependencyRecord` required |
| DOC83 | DOC73 | RecentActivityRollup generation (ADQ-405) | DOC73 retains generation; DOC83 owns consumption + invariant + lints | `ExternalDependencyRecord` required |
| DOC83 | DOC23 | task outputs, ClaimExtractorOutput | DOC23 retains; DOC83 consumes via ExtractionRouteContext | `ExternalDependencyRecord` required |
| DOC83 | DOC1 | Write Gate (promotion approval) | DOC1 retains; DOC83 routes through DOC1 | `ExternalDependencyRecord` required |
| DOC83 | EC | durable Assertion writes | EC retains writer authority | external control flow (not a schema import) — `ExternalDependencyRecord` still required for cross-doc protocol |
| DOC83 | DOC3 | procedural memory / skill lifecycle | DOC3 retains; DOC83 references seams | `ExternalDependencyRecord` required |
| DOC81 | PropA | policy rules | PropA retains; DOC81 compiles into EffectiveMemoryPolicy | `ExternalDependencyRecord` required |
| DOC81 | EC | policy enforcement, ScopeResolutionResult computation | EC retains executor; DOC81 defines contract | `ExternalDependencyRecord` required |
| DOC84 | DOC24 | packet assembly mechanics | DOC24 retains; DOC84 consumes via contract | `ExternalDependencyRecord` required |
| DOC84 | KDA | KdaManifestPatch + rendering | KDA retains; DOC84 consumes render contract | `ExternalDependencyRecord` required |
| DOC84 | DOC11 | final runtime truth + OpenClaw native session | DOC11 retains; DOC84 hands off final proof | `ExternalDependencyRecord` required |
| DOC84 | DOC15 | Cognitive Infrastructure Layer seams (delivery integration — verified per F5 follow-up; the round-1 §4.4 single-importer claim was incomplete) | DOC15 retains; DOC84 imports memory-touching delivery seams | `ExternalDependencyRecord` required |
| DOC85 | BDSM | learning computation, utility ledgers (ADQ-221 resolved: `dependency_status = partial`; operative source = BDSM v6.5 Draft v0.3.1) | BDSM retains computation; DOC85 consumes specific surfaces named at E9 charter; DOC85 drafting coordinates with BDSM revision work | `ExternalDependencyRecord` required with `dependency_status = partial`; `header_version = v6.5 Draft v0.3.1` |
| DOC85 | DOC8 (legacy) | capability-mining input ONLY — confirmed phantom per ADQ-221 / Stage 5R review §II-3 | DOC85 treats DOC8 as requirements source, NOT a dependency; no runtime contract | `ExternalDependencyRecord` with `dependency_status = phantom` (B7) |
| DOC85 | EC | warrant adjustment, classification updates | EC retains executor; DOC85 emits learning signals | external control flow + `ExternalDependencyRecord` |
| DOC86 | DOC20 | Project / Library / Inspector UI implementation | DOC20 retains implementation; DOC86 defines visible-control + safe-label contracts | `ExternalDependencyRecord` required |
| DOC86 | DOC15 | Cognitive Infrastructure Layer (memory-touching seams) | DOC15 retains; DOC86 imports relevant seams | `ExternalDependencyRecord` required |
| DOC86 | DOC26 | UnifiedWorkspaceLibrary / Project Mode Control Surface (aspirational; conditional on ADQ-202 / ADQ-404 — corrected per F4) | DOC26 retains; DOC86 has a conditional UI seam | `ExternalDependencyRecord` with `dependency_status = aspirational` |
| DOC87 | DOC72 | graph storage of `MemoryMembershipEdge` | DOC72 stores payload | external control flow + `ExternalDependencyRecord` |
| DOC87 | EC | durable membership writes | EC retains writer authority | external control flow + `ExternalDependencyRecord` |
| DOC87 | DOC25 | `LibrarySourceBinding` (per B2 step 6 — decomposed "Library"; LibrarySourceBinding lives at DOC82 / DOC25) | DOC25 retains; DOC87 imports for Library-as-container concept | `ExternalDependencyRecord` required |
| DOC80 core | EC | ECSeamContract pins: EC §1 (off-switch / incognito / collection gate; effective-state source), §3 (compiled policy engine; `policy_generation_id`), §4 (BackgroundJobOrchestrator; retention sweeps), §7 (migration / import), §8 (export / `full_raw_backup`) — per E0 §7.1, ADQ-406/407/408 | EC retains; DOC80 references, never redefines | `ExternalDependencyRecord` required (E0 discharge 2026-06-01) |

**DOC9 — not imported.** Per F4, DOC80 family does not import from DOC9 (self-repair). No seam exists in this skeleton.

---

## 4. Target-package imports (plan §3.5 frozen)

DOC80 family absorbs and operationalizes the seven plan §3.5 target-package files (consolidated into DOC80 family, not external imports).

| target-package file | absorbed into | role | pin |
|---|---|---|---|
| `12_ABC_Consolidated_Structural_Patch_R0_2.md` | DOC80 + DOC81 + DOC82 + DOC83 + DOC87 | Structural patch — senior to Concept Model per DR-001 | `Target_Freeze.md` row |
| `13_Round_D_Policy_Scope_UI_Micro_Patch_R0_2.md` | DOC81 + DOC86 + DOC87 (membership-edge invariants) | Policy/scope/UI micro-patch | `Target_Freeze.md` row |
| `02_Concept_Model_and_Canonical_Knowledge_Resolution.md` | DOC82 (with DOC80 contract) | Concept model — **junior to ABC R0.2 per DR-001** | `Target_Freeze.md` row |
| `03_DAMS_V5_Spec_Outline.md` | DOC84 (DAMS section) | DAMS V5 outline | `Target_Freeze.md` row |
| `05_Worked_Examples_and_Fixtures.md` | All members (fixture source) | Worked examples + fixtures | `Target_Freeze.md` row |
| `10_Source_Context_Primer.md` | (read-only context) | Primer | `Target_Freeze.md` row |
| `08_Coverage_Audit_and_Patch_Log.md` | (read-only audit reference) | Coverage audit | `Target_Freeze.md` row |

All seven files are `path_resolvable` per `Target_Freeze.md` (Stage 2). No `architect_stop` on availability.

---

## 5. Plan §18 import-graph conditions — proof (re-proven post Stage 5R)

### 5.1 ✓ No local redefinition of owner-doc schemas

**Asserted:** Every schema in `DOC80_Skeletal_Target_Baseline.md` §4 names a single owner. Schemas that handed off (Assertion → DOC82, MemoryMembershipEdge → DOC87, etc.) are defined ONLY at their new owner; DOC72 / DOC24 / DOC73 are amended to defer. ABC §7.8's `AssertionCandidateDisposition` 7-value enum and `AssertionDedupeOutcome` are defined at DOC82 only (the Concept Model §17.3 11-value enum stays retired per G-2).

**Enforced by:** `supersession.local_schema_redefinition` (plan §17.2); `owner_map.compound_schema_owner` (B3).

**Known risk:** DOC73 reconciliation per ADQ-219 — if reconciliation reveals divergence the `SourceBoundSynthesisAdapter` wrapper cannot cleanly absorb, that becomes `architect_stop`. (Stage 5R2b: convergence obligation also logged as OPA-035 — if adapter activates, DOC73 must converge OR architect blesses permanent divergence via new ADQ.)

**Stage 5R2b footnote — supersession-matrix coverage gaps for objects already cited in the import graph:**

The following objects appear in §2 (lateral imports) or §3 (external imports) but do NOT yet have a Supersession Matrix row. They are tracked in the Conflict / Disagreement Register (DR-002, DR-003, DR-007, DR-008) and become matrix rows at the next matrix update. Their presence in the import graph does NOT violate §5.1 — these are *additions*, not *redefinitions* — but the gap is logged so the lint `supersession.import_graph_object_without_matrix_row` can be added at Stage 9 once the matrix catches up:

| object | first appearance | gap reference | disposition |
|---|---|---|---|
| `LibrarySourceBinding` / `CorpusIndex` / `SourceCollection` (decomposed Library/Corpus) | §3 (DOC82 ← DOC25; DOC87 ← DOC25) | DR-002 (SM-040 matrix gap) | Library-as-organizational-container at DOC87; the bindings/index/collections at DOC82/DOC25; matrix row deferred to next matrix update |
| `VersionedClaim` (DOC73-owned legacy lineage) + `VersionedClaim → AssertionVariant` lineage table (DOC82) | Owner Map §4 / §1 | DR-003 (closed at Stage 5R2 per synthesis #8) | DOC73 retains VersionedClaim; DOC82 defines lineage table; charter requirements named in Owner Map row; matrix-row addition deferred |
| `AssertionCandidateEmission` (DOC82-owned; DOC83 generates) | §2.1 (DOC82 → DOC83) and §2.2 (DOC83 → DOC82 runtime) | **DR-008 (added at Stage 5R2b)** | Named E3↔E5 handoff object; matrix row deferred to next matrix update |
| `AlternativeExtractionRouting` (DOC83-owned; renamed from `NonAssertionExtractionOutcome` at Stage 5R2b) | §2.1 (DOC83 → DOC84 / DOC85) | **DR-007 (added at Stage 5R2b)** | Re-homes the 4 retired enum-value capabilities; matrix row deferred to next matrix update |

The Extraction trio (`ExtractionContextPlan` / `ExtractionRouteContext` / `ExtractionResult`) is partially covered — `ExtractionResult` family already maps under ABC §7 outputs, but the specific schema-row coverage for each member is queued for the same matrix update.

### 5.2 ✓ No dual-running type families

**Asserted:** Retired-name table covers every superseded family (22 SM-backed entries post F1 + 2 Stage 5R2b rename-only entries). Lints `supersession.dual_running_type_family`, `supersession.retired_name_used`, `supersession.retired_name_used_outside_allowed_historical_context` enforce at Stage 9.

**Stage 5R2b note:** the 2 rename-only entries (`NonAssertionExtractionOutcome` → `AlternativeExtractionRouting`; `SourceBoundSynthesisProjection` → `SourceBoundSynthesisAdapter`) are not Supersession Matrix rows (pure renames; no capability shift). They exist in the Retired Names table to enable lint detection of stale uses of the old names.

### 5.3 ✓ No retired names outside allowed historical context

**Asserted:** Each retired-name row has `allowed_historical_context`. Family-member sections use canonical names only.

### 5.4 ✓ Every cross-doc import has an owner

**Asserted:** §3 (this file) names the owner for every external import. Each import receives an `ExternalDependencyRecord` per B7. `external_dependency.unpinned` lint enforces.

### 5.5 ✓ Every required target-freeze file is attached or path-resolvable

**Asserted:** All seven plan §3.5 target-package files `path_resolvable` per Stage 2 `Target_Freeze.md`.

### 5.6 ✓ Acyclicity (re-proven post Stage 5R2 4-edge-kind restructure)

**Asserted:** Acyclic on the `schema_import` edge kind (§2.1). Topological order: `DOC80 < DOC81 < DOC82 < DOC87 < DOC83 < DOC84 < {DOC85, DOC86}`. No upward `schema_import` edge.

**Runtime instance flows (§2.2), command/control flows (§2.3), and storage/execution flows (§2.4) may have any direction**, including up the topological order; they are not import cycles. The Stage 5R apparent DOC82↔DOC83 cycle was a mis-typed schema_import that is actually a runtime_instance_flow (§2.2); the corrected typing dissolves the cycle.

**Lints (added at Stage 5R2):**
- `import_graph.runtime_flow_listed_as_schema_import`
- `import_graph.command_flow_listed_as_schema_import`
- `import_graph.storage_flow_listed_as_schema_import`
- `import_graph.bidirectional_schema_import_without_architect_approval`
- `import_graph.upward_schema_import_to_policy`

The acyclicity proof is enforced via the topological ordering above; any new schema_import edge must respect it.

---

## 6. Family-member section-map invariant

Each family member's top-level section map (DOC80_Skeletal_Target_Baseline §2) has a stable layout. Sections are added at the end of their owner; never renumbered or moved across the family-member boundary without an architect decision.

---

## 7. Validation

This import graph is **self-asserted at skeletal stage**. Stage 9 cross-slice lint pass verifies via `Cross_Slice_Lint_Report.md` + `Cross_Slice_Fixture_Report.md`.

Stage 5R architect review confirms the import graph is **structurally sound** as proposed; Stage 9 verifies every individual schema obeys the constraints once slices are drafted.