Elnor Repo Reader

10_Source_Context_Primer.md

Memory Rebuild Docs/Memory Rebuild Review Packs/Archived Memory Rebuild Zips/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/10_Source_Context_Primer.md

Generated 2026-06-09T01:23:58.539Z from commit dbaa25962edc11ab30e8d4ca1715f9ae5bf77331. Worktree: clean.

Open text page · Open raw txt · Open path URL

# Source Context Primer — ELNOR Memory / DAMS V5 Review

**Status:** review helper, not an operative spec.  
**Purpose:** give fresh review windows enough owner-boundary context to review the DAMS V5 / Memory Control Plane materials without re-reading every operative document.

---

## 1. Core ELNOR invariants

- **EC is the sole durable writer.** Q and UI surfaces issue commands and render read-models; they do not write durable truth directly.
- **Q is a read/control surface.** Every visible control must map to a real EC command, route, explicit no-op/degraded receipt, telemetry event, and refreshed read-model.
- **OpenClaw / DOC11 own final runtime truth.** DOC24/KDA may assemble and render packets, but final prompt delivery proof must reconcile with what the final runtime actually emitted.
- **No phantom controls or phantom affordances.** If a prompt or UI says something can be searched, opened, pulled, paused, or inspected, there must be a real command/route or an explicit degraded/no-op receipt.
- **Desired config is not effective truth.** Effective runtime state must distinguish desired state, effective state, and divergence reason codes.
- **Policy is compiled once.** Runtime consumers use EC/PropA compiled policy decisions; they do not freehand-compose collection, visibility, source-policy, sharing, or exposure logic.

---

## 2. Owner boundaries

| Owner | Owns | Does not own |
|---|---|---|
| DOC72 | knowledge graph shape, node schemas, entity/procedure/goal/directive payload contracts, six-dimension knowledge framework, graph hygiene | packet assembly, rendering, final prompt truth, policy evaluation internals |
| DOC73 | PBE/deep source/corpus surfaces, CUs/source-bound synthesis, VersionedClaim-like source artifacts, RecentActivityRollup, source/corpus extraction semantics | canonical Assertion truth unless mapped into DOC72/DAMS resolution; final delivery |
| DOC25 | document ingestion, SourceArtifact, ArtifactSegment, parsing/materialization, parser output quality for documents | canonical truth, context-product delivery |
| EC Core | durable writes, effective runtime state, compiled policy evaluator, task/background orchestration, command closure, settings/effective-state read-models | truth schemas, rendering templates, final prompt assembly |
| PropA | semantic policy inputs, source eligibility, visibility, sharing/redaction/exposure policy semantics, policy decision vocabulary | durable writes, render templates, canonical truth |
| DOC24 | packet lifecycle, context assembly, delivery directives, candidate/packet/final-prompt manifests, Packet Inspector, runtime use of compiled utility bundles | canonical knowledge shape, policy internals, KDA rendering internals, DOC8 computation |
| KDA | deterministic rendering from prepared bundles, render variants/templates, token counts, KdaManifestPatch, reference-only rendering discipline | retrieval, selection, promotion, packet manifests, final prompt assembly, LLM calls at render time |
| BDSM/DOC8 | utility learning, attribution computation, compiled learning bundles, phrasing/prompt-shell utility, final-prompt-proof-gated learning | epistemic confidence, policy override, source eligibility, truth ownership |
| DOC23 | task graph execution, modules, ports, task agent surfaces; task outputs may feed memory | memory organization, canonical Assertion identity |
| DOC20/Q | UI surfaces, inspectors, visible controls, project/library/topic indicators | durable truth writes, policy decisions |
| Project proposal | explicit per-surface Project mode, Library/folder bindings, output routing, carryover commands | global focus mode, new memory store, hidden capture authority |

---

## 3. Core memory distinctions for reviewers

```text
Source = where information came from.
Route = why/how ELNOR looked for or captured it.
Canonical Object = what kind of knowledge was produced.
Organization = how the user/system groups, searches, or views it.
Delivery = how DOC24/KDA expose it to the model.
```

Key invariant:

```text
Extraction route must not determine canonical knowledge identity.
```

A Topic, Library/corpus, Project mode, task output, chat, or external carryover can cause extraction, but the extracted truth-apt statement must resolve through the same AssertionCandidate → Assertion/AssertionVariant path.

---

## 4. Reviewer-specific owner reminders

### DOC72

Treat DOC72 as canonical knowledge-shape owner. If the patch introduces a durable truth object, ask whether DOC72 owns its shape and EC owns its write path.

### DOC73 / DOC25

Treat CUs and source/corpus/document extraction as source-bound. A CU may generate/support Assertions, but it is not reusable truth unless resolved into the canonical Assertion pipeline with sufficient source support.

### DOC24 / KDA

DOC24 selects/assembles and owns manifests. KDA deterministically renders prepared bundles and returns patches. KDA must not become selector or prompt assembler.

### BDSM / DOC8

Utility learning requires final-prompt proof. Utility may tune salience, placement, product choice, prompt-shell variants, and search strategy only inside policy/source/warrant bounds. It may not change truth or override policy.

### EC / PropA

Policy applies at collection, extraction, write, retrieval, rendering, export, delegation, carryover, learning, and UI disclosure. A policy stamp for one action is not automatically valid for another.

### Project mode

Project mode is explicit and per-surface. It is useful but optional. Memory must still work in default mode through prompt, entities, recent episodes, Topics, Libraries, user directives, and ordinary graph retrieval.

---

## 5. What reviewers should watch for

- Does any Topic, Library, Project, CU, RecentActivityRollup, IssueFrame, task output, or learning ledger become a parallel truth store?
- Does any route create a different canonical object for the same substantive assertion?
- Does any extraction path bypass DOC72/DOC73/DOC25/EC ownership?
- Does any delivery path bypass DOC24/KDA/DOC11 final prompt proof?
- Does any prompt shell imply unseen Topic/Library contents?
- Does any policy/scope uncertainty behave like same-scope rather than failing closed?
- Does any reference-only item render a substantive compact summary?
- Does any learning path update truth instead of delivery utility?

---

**End of Source Context Primer.**