ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/10_Source_Context_Primer.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # 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.**