ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Memory Rebuild Review Packs/Archived Memory Rebuild Zips/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/02_Concept_Model_and_Canonical_Knowledge_Resolution.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Memory Control Plane V5 — Concept Model and Canonical Knowledge Resolution **Document type:** Pre-spec concept model. **Purpose:** Establish the conceptual and contract structure for the new flattened memory architecture before writing the operative DAMS V5 / Memory Control Plane specification. --- ## 0. Core thesis ELNOR memory must distinguish five things that previous drafts sometimes blurred: ```text Source = where information came from. Route = why/how ELNOR looked for or captured it. Memory object = what kind of knowledge was produced. Organization = how the user/system groups and finds it. Delivery = how DOC24 injects or exposes it to the model. ``` The most important normative rule: ```text Extraction route MUST NOT determine canonical knowledge identity. ``` If the same substantive truth-apt statement is extracted through a Topic, Library/corpus, chat, Project mode, task output, or manual user action, it must resolve through one shared pipeline: ```text SourceEnvelope → ExtractionRouteContext → AssertionCandidate → AssertionResolution → Assertion / AssertionVariant → EvidenceSupportEdges + memberships → DOC24 context product ``` --- ## 1. The nine functional planes These planes are organizing principles and contract boundaries. They are not necessarily separate documents. ### 1.1 Source and Evidence Plane **Function:** Where information comes from and what evidence supports memory. Includes: - SourceArtifact - ArtifactSegment - document / PDF / email / browser page / note / chat source - task output - Library source - external LLM carryover - source spans - source hashes - source authority class - prompt-injection-risk flags - materialization state - OCR/extraction quality Primary questions: ```text What source did this come from? Was it actually observed? What span supports it? How authoritative is the source? What policy and visibility apply? What quality/risk issues exist? ``` ### 1.2 Stored Memory Object Plane **Function:** What ELNOR actually stores as memory. Includes: - DOC72 graph nodes - Assertion / AssertionVariant - EvidenceRecord - ConsolidatedUnderstanding - Directives - Procedures - Entities - Goals - Obligations - Work products - NullResultMemory - WorkEpisode - RecentActivityRollup - IssueFrame / WorkingStateEvent - IncidentObservation / FrictionEvent - MemoryFlowCertificate Primary questions: ```text What does ELNOR know? What role does this memory object have? Can it support an assertion? Can it be injected, and if so how? ``` ### 1.3 Organization and User Interaction Plane **Function:** How memory is grouped, browsed, searched, and made useful. Includes: - Project mode - Library - TopicLens - TopicCollectionDirective - Search affordances - Knowledge Manager - Topic page - Library page - Inspector / Why included Primary questions: ```text How does the user find, browse, search, manage, and pull memory? Which objects are grouped together for reuse? Which surfaces may drive extraction? ``` ### 1.4 Temporal and Working-State Plane **Function:** What happened over time and what is currently live. Includes: - WorkSession - WorkEpisode - EpisodeSegment - EpisodePolicyEpoch - RecentActivityRollup - IssueFrame - WorkingStateEvent - cognitive diff - resume card Primary questions: ```text What happened recently? What is the current problem state? What is settled, open, ruled out, stale, or blocked? ``` ### 1.5 Policy and Permission Plane **Function:** What is allowed. Includes: - EC compiled PolicyDecisionEngine - PropA policy semantics - MemoryPolicyDecision - PolicyObligation - PolicyStamp - PolicyStampInvalidation - ScopeMembrane - visibility classes - incognito / collection controls - export / carryover / delegation gates - privacy settings and UI read-models Primary questions: ```text Can this be collected? Can it be extracted? Can it be written? Can it be retrieved? Can it render inline? Can it be exported, delegated, carried over, or learned from? What must the UI disclose? ``` ### 1.6 Scope Resolution and Coordination Plane **Function:** How ELNOR relates Projects, Topics, Libraries, episodes, sources, and memories. Includes: - ScopeIdentityRoot - ScopeEquivalenceBinding - ScopeContainerRelation - ScopeMembrane - ScopeAffinity - ScopeResolutionTrace Primary questions: ```text Are these references the same underlying work/knowledge context? Is this Library part of a Project or merely useful to it? Is this Topic cross-scope? Is this memory direct, secondary, analogical, background, or blocked? What should be collapsed for capacity scoring? ``` ### 1.7 Extraction and Ingestion Plane **Function:** How observations become candidate or durable memory. Includes: - ExtractionContextPlan - source classification - collection mode - significance gate - extraction depth - TopicCollectionDirective - Library ingestion state - DOC25 ingestion result - DOC1 write gate - DOC72 write - PropA classification - EC command / receipt Primary questions: ```text Should this be collected? Should it be extracted? Should it be candidate-only or durable-eligible? What source scope and policy apply? Which memberships should be added? ``` ### 1.8 Runtime Assembly and Delivery Plane **Function:** What reaches the LLM now. Includes: - MemoryContextPlan - Context products - DOC24 packet lifecycle - ContextAssemblyTrace - CandidateInjectionManifest - PacketInjectionManifest - FinalPromptInjectionManifest - KDA render patches - DOC11/OpenClaw final runtime truth Primary questions: ```text What should be injected directly? What should be offered as searchable? What should be reference-only? What should be blocked? What prompt shell and render form should be used? ``` ### 1.9 Learning and Evaluation Plane **Function:** How the system improves. Includes: - BDSM utility ledgers - DOC8 computation - friction events - false-suppression sampling - storage/extraction learning - organization learning - injection learning - UI learning - policy/classification learning - task-output learning signals - prompt-shell learning Primary questions: ```text Did we store the right thing? Did we organize it correctly? Did we inject the right amount in the right form? Did the user search because we failed to inject? Did the prompt shell help? ``` --- ## 2. Source / route / object / organization / delivery distinction ### 2.1 Source Where information came from. Examples: ```text case law brief PDF email web page chat note task output Library source deep corpus segment user direct statement ``` ### 2.2 Extraction route Why and how ELNOR looked for or captured the information. Examples: ```text library_ingestion corpus_deep_extraction topic_collection chat_capture project_mode_capture task_output_extraction manual_user_add nightly_backfill ``` ### 2.3 Canonical memory object What kind of memory was produced. Examples: ```text Assertion EvidenceRecord ConsolidatedUnderstanding Directive Procedure IssueFrameUpdate NullResultMemory EntityUpdate IncidentObservation FrictionEvent ``` ### 2.4 Organization / membership Where that memory is grouped or made visible. Examples: ```text Topic membership Library membership Project link Episode link IssueFrame link Entity graph edge ``` ### 2.5 Delivery product How DOC24 injects or exposes it. Examples: ```text Assertion Packet Topic Notice Topic Slice Library Notice Library Source Slice Recent Work Orientation IssueFrame Orientation Directive Block Procedure Block Warning / Constraint Search Affordance Reference-only notice ``` --- ## 3. Canonical Assertion pipeline ### 3.1 Definition An **Assertion** is a canonical, domain-agnostic, truth-apt memory object. It represents something ELNOR may rely on, hedge, verify, supersede, contest, or withdraw. Examples: ```text “Ninth Circuit scienter pleading requires facts supporting a strong inference of intent or deliberate recklessness.” “DOC24 owns packet assembly; KDA renders prepared bundles.” “Will prefers to be called Will.” “This mix sounds harsh around 3kHz.” “Qwen3-Embedding-0.6B via MLX is the locked embedding model.” ``` Not all truth-apt statements become durable Assertions. Some become incidents, friction events, CUs, working-state updates, directives, procedures, evidence-only records, evaluation-only claims, or nothing. ### 3.2 Why `Assertion`, not `Claim` or `Premise` - **Claim** is too overloaded: legal claim, evaluation claim, claim-extractor output, ordinary truth claim. - **Premise** is best treated as a use role: an Assertion used as a premise in reasoning. - **Understanding** is too vague. - **ConsolidatedUnderstanding** already has a source-bound synthesis meaning in DOC73. Therefore: ```text Assertion = canonical truth-apt object. Premise = delivery/use role for an Assertion. Claim = namespaced legacy/domain/evaluation term only. CU = source-bound synthesis. ``` ### 3.3 Assertion structure ```ts type Assertion = { assertion_id: string; canonical_question?: string; canonical_statement?: string; domain_profile_ref?: DomainProfileRef; variants: AssertionVariant[]; support_edges: EvidenceSupportEdgeRef[]; contrary_support_edges: EvidenceSupportEdgeRef[]; lifecycle_rollup: AssertionLifecycleRollup; memberships: AssertionMembership[]; }; ``` ```ts type AssertionVariant = { variant_id: string; statement: string; scope_conditions: ScopeCondition[]; source_support_refs: EvidenceSupportEdgeRef[]; contrary_support_refs: EvidenceSupportEdgeRef[]; temporal_profile: AssertionTemporalProfile; lifecycle_state: AssertionLifecycleState; staleness_state: AssertionStalenessState; default_use_warrant: AssertionUseWarrant; }; ``` ### 3.4 AssertionCandidate A staged extracted truth-apt statement. ```ts type AssertionCandidate = { candidate_id: string; statement: string; source_refs: SourceRef[]; source_span_refs?: SourceSpanRef[]; route_context_ref: ExtractionRouteContextRef; proposed_scope_conditions?: ScopeCondition[]; proposed_support_role: | "primary_source" | "secondary_source" | "party_argument" | "user_statement" | "model_synthesis" | "task_output" | "system_observation"; }; ``` ### 3.5 AssertionResolution ```ts type AssertionResolution = { candidate_ref: AssertionCandidateRef; resolution: | "merge_to_existing_assertion_variant" | "create_new_assertion_variant" | "create_new_assertion" | "retain_as_cu_component" | "retain_as_evidence_only" | "retain_as_issue_frame_update" | "record_incident_or_friction" | "create_directive_candidate" | "create_procedure_candidate" | "reject_not_memory"; target_ref?: ContentReference; dedupe_basis: | "source_span_duplicate" | "canonical_question_match" | "semantic_equivalence" | "authority_citation_match" | "manual_user_merge" | "no_match"; confidence: number; requires_review: boolean; }; ``` --- ## 4. Assertion temporal profile and lifecycle ### 4.1 Temporal profile ```ts type AssertionTemporalProfile = | "instant_status" | "session_lifetime" | "short_incident" | "rolling_operational" | "project_bounded" | "source_bounded" | "domain_assertion" | "standing_preference" | "procedure_heuristic" | "historical_fact"; ``` Examples: | Statement | Likely profile | Default disposition | |---|---|---| | “Qwen is not working.” | instant_status / short_incident | incident_observation / friction_event | | “Qwen3-Embedding-0.6B via MLX is locked.” | rolling_operational | Assertion if source-supported | | “Specs were underspecified and caused memory failures.” | project_bounded diagnosis | IssueFrameUpdate + AssertionCandidate | | “Ninth Circuit scienter requires deliberate recklessness.” | domain_assertion | Assertion | | “Call me Will.” | standing_preference | Directive, not Assertion | | “This mix sounds harsh around 3kHz.” | source_bounded / project_bounded | Assertion or IssueFrameUpdate depending context | ### 4.2 Lifecycle state ```ts type AssertionLifecycleState = | "candidate" | "provisional" | "active" | "confirmed" | "contested" | "superseded" | "retired" | "audit_only"; ``` ### 4.3 Staleness state ```ts type AssertionStalenessState = | "not_time_sensitive" | "fresh" | "stale_possible" | "verification_required" | "stale_confirmed" | "source_changed" | "coverage_gap_suspected"; ``` ### 4.4 Use warrant ```ts type AssertionUseWarrant = | "assert" | "hedge" | "verify_before_use" | "orientation_only" | "search_only" | "do_not_inject"; ``` ### 4.5 Degradation ladder Assertions degrade in use warrant before deletion: ```text assert → hedge → verify_before_use → orientation_only → search_only → do_not_inject ``` Triggers: - time window expires; - source document changes; - contrary source appears; - user corrects it; - policy generation changes; - authority sweep expires; - repeated poor outcomes after injection; - confidence drops; - object was only session-bound; - supporting CU becomes stale/source-changed. --- ## 5. Extraction output taxonomy The extraction agent should not juggle every memory theory. It should choose from a small taxonomy: ```ts type ExtractionOutputKind = | "assertion_candidate" | "evidence_record" | "consolidated_understanding" | "directive_candidate" | "procedure_candidate" | "issue_frame_update" | "incident_observation" | "friction_event" | "null_result_memory" | "entity_update" | "not_memory"; ``` Decision tree: 1. What is the source? 2. Why am I extracting? 3. What did I find? 4. Resolve / write / route. 5. Add memberships. --- ## 6. ConsolidatedUnderstanding A **ConsolidatedUnderstanding** is a source-bound synthesis over a document, corpus, Library, episode, or body of source material. It answers: ```text What does this source set appear to show when synthesized? ``` It may generate or support Assertions, but it does not replace the Assertion pipeline. Example: ```text CU: “The Marex briefing record shows plaintiff relied on confidential witnesses, insider sales, and accounting irregularities to plead scienter, while defendants attacked particularity and innocent inferences.” ``` Potential output from that CU: - EvidenceRecord: what the brief said. - AssertionCandidate: “Insider sales may support scienter if unusual or suspicious.” - IssueFrameUpdate: “Marex scienter theory may need stronger support on timing/amount.” - Topic membership: Ninth Circuit scienter / Marex knowledge. --- ## 7. Topic A Topic has two separable powers. ### 7.1 TopicLens User-visible semantic lens / saved view over memory. It can: - group existing knowledge; - show pinned members; - show rule-matched members; - support Topic Notice; - support Topic Slice; - let user search / pull more; - show coverage/freshness health. It owns no raw truth. ### 7.2 TopicCollectionDirective Governed extraction rule. It can: - backfill from existing memory; - scan selected documents or Libraries; - watch future eligible sources; - propose members; - create AssertionCandidates; - create EvidenceRecords; - create TopicMembershipEdges. It must not bypass policy, user approval, or collection controls. ```ts type TopicCollectionDirective = { directive_id: string; topic_ref: TopicRef; source_scope: | { kind: "all_eligible_sources" } | { kind: "selected_library"; library_ref: LibraryRef } | { kind: "selected_documents"; source_refs: SourceRef[] } | { kind: "future_stream"; source_classes: SourceClass[] }; extraction_goal: string; compiled_match_criteria: MatchCriterion[]; extraction_depth: "shallow" | "standard" | "deep"; collection_mode: | "backfill_existing_memory" | "extract_from_selected_sources" | "watch_future_sources" | "suggest_only"; output_targets: Array< | "assertion_candidate" | "evidence_record" | "topic_membership" | "issue_frame_update" | "null_result" >; policy_decision_ref: MemoryPolicyDecisionRef; review_required_before_durable_promotion: boolean; }; ``` --- ## 8. Library and corpus User-visible term: **Library**. Internal processing terms: `Corpus`, `SourceCollection`, `CorpusIndex`, `SharedCorpusView`, `MaterializationState`. A Library/corpus can produce: - SourceArtifacts / ArtifactSegments; - EvidenceRecords; - ConsolidatedUnderstandings; - AssertionCandidates; - Topic membership candidates; - IssueFrame updates; - NullResultMemory; - Library Source Slices. It does not own the reusable proposition. Assertions own that. --- ## 9. IssueFrame and WorkingStateEvent An IssueFrame is a live workbench state for a problem being worked. It contains: - open questions; - hypotheses; - rejected paths; - decision checkpoints; - blocking source needs; - next actions; - linked AssertionCandidates where truth-apt statements appear. It is not another Assertion system. ```ts type IssueFrameUpdate = { update_id: string; issue_frame_ref?: IssueFrameRef; update_kind: | "open_question" | "hypothesis" | "rejected_path" | "decision_checkpoint" | "blocking_source_needed" | "next_action"; text: string; linked_assertion_candidate_refs?: AssertionCandidateRef[]; source_refs: SourceRef[]; }; ``` If an IssueFrame update contains a truth-apt statement, it may create or reference an AssertionCandidate. A question or next action does not create an AssertionCandidate. --- ## 10. Canonical knowledge resolution rule Normative language for V5: ```text Extraction route MUST NOT determine canonical knowledge identity. A truth-apt statement extracted from a Topic, Library/corpus, chat, Project mode, task output, or manual user action MUST enter the common AssertionCandidate → AssertionResolution → Assertion/AssertionVariant pipeline. Topic, Library, Project, Episode, and Task context MAY add route metadata, source support, policy constraints, review requirements, memberships, and learning signals. They MUST NOT create parallel truth objects. ConsolidatedUnderstandings are source-bound syntheses. They MAY generate or support Assertions but do not replace the Assertion pipeline. Topics are lenses and optional collection directives. They MAY drive extraction but own no raw truth. Premise is a use role for an Assertion in reasoning or injection, not a separate truth store. ``` --- ## 11. Policy plane Policy is above the coordination plans. It applies to: - collection; - extraction; - classification; - write / promotion; - retrieval; - rendering; - injection; - export; - delegation; - carryover; - learning; - UI visibility; - inspection. Use typed decisions, not scalar safety floors. ```ts type MemoryPolicyDecision = { decision_id: string; object_ref: ContentReference; action: | "capture" | "retrieve" | "render_inline" | "render_reference" | "export" | "delegate" | "mutate" | "learn_from" | "carryover_generate"; destination?: | "local_model" | "cloud_model" | "external_llm" | "subagent" | "share_link" | "task_runtime" | "user_visible_ui"; principal_ref?: PrincipalRef; surface_ref?: SurfaceRef; content_fidelity: "none" | "redacted" | "reference_only" | "full"; locality: "blocked" | "local_only" | "approved_external"; learning_scope: "none" | "same_scope_only" | "partitioned" | "global_allowed"; mutation_authority: "none" | "candidate_only" | "durable_allowed"; obligations: PolicyObligation[]; reason_codes: ReasonCode[]; policy_generation_id: string; }; ``` --- ## 12. Scope coordination Scope coordinates, but does not own truth, policy, delivery, rendering, or writes. It answers: ```text Are these things equivalent? Are they related but not equivalent? Is this a direct, secondary, analogical, or background relation? What policy membrane applies? Should signals collapse for capacity scoring? ``` Core components: ```text ScopeIdentityRoot ScopeEquivalenceBinding ScopeContainerRelation ScopeMembrane ScopeAffinity ScopeResolutionTrace ``` --- ## 13. Coordination plans ### 13.1 ExtractionContextPlan Governs collection/extraction/write eligibility. ```ts type ExtractionContextPlan = { plan_id: string; source_ref: SourceRef | SurfaceEventRef; applicable_project_ref?: ProjectRef; applicable_library_ref?: LibraryRef; applicable_topic_refs: TopicRef[]; recent_episode_refs: WorkEpisodeRef[]; issue_frame_refs: IssueFrameRef[]; collection_decision: | "do_not_collect" | "observe_only" | "extract_candidate" | "extract_durable_eligible" | "deep_extract"; extraction_depth: "none" | "shallow" | "standard" | "deep"; allowed_model_class: | "local_only" | "cloud_allowed" | "cloud_allowed_with_redaction"; proposed_links: Array<{ target_kind: "project" | "library" | "topic" | "episode" | "issue_frame" | "entity"; target_ref: string; confidence: number; }>; policy_decision_ref: MemoryPolicyDecisionRef; reason_codes: ReasonCode[]; }; ``` ### 13.2 MemoryContextPlan Governs injection / exposure. ```ts type MemoryContextPlan = { plan_id: string; request_ref: RequestRef; direct_items: WarrantedMemoryItem[]; assertion_packets: AssertionPacket[]; topic_notices: TopicNotice[]; topic_slices: TopicSlice[]; library_notices: LibraryNotice[]; library_source_slices: LibrarySourceSlice[]; recent_work_items: RecentWorkOrientation[]; issue_frame_items: IssueFrameOrientation[]; directive_blocks: DirectiveBlock[]; procedure_blocks: ProcedureBlock[]; warnings: WarningConstraint[]; search_affordances: SearchAffordance[]; blocked_items: BlockedContextItem[]; policy_generation_id: string; context_compiler_generation_id: string; }; ``` ### 13.3 UserContextSurfacePlan Governs visible UI state. ```ts type UserContextSurfacePlan = { plan_id: string; visible_project_indicator?: ProjectIndicator; visible_library_indicator?: LibraryIndicator; visible_topic_notice?: TopicNoticeCard; visible_recent_work_card?: RecentWorkCard; visible_search_affordances: SearchAffordance[]; inspector_available: boolean; hidden_internal_refs: { scope_trace_ref?: string; context_plan_ref?: string; manifest_ref?: string; }; }; ``` ### 13.4 MemoryCoordinationTrace ```ts type MemoryCoordinationTrace = { trace_id: string; request_ref: RequestRef; source_refs: SourceRef[]; scope_resolution_ref: ScopeResolutionTraceRef; policy_generation_id: string; extraction_plan_ref?: ExtractionContextPlanRef; memory_context_plan_ref?: MemoryContextPlanRef; user_surface_plan_ref?: UserContextSurfacePlanRef; doc24_manifest_refs?: string[]; kda_patch_refs?: string[]; final_prompt_manifest_ref?: string; learning_event_refs?: string[]; }; ``` --- ## 14. Injection products DOC24 should inject context products, not generic memory dumps. ```text Direct Memory Item Assertion / Premise Packet Topic Notice Topic Slice Library Notice Library Source Slice Recent Work Orientation IssueFrame Orientation Directive Block Procedure Block Warning / Constraint Search Affordance Blocked / Reference-Only Notice ``` Every product should specify: - purpose; - allowed source types; - allowed memory roles; - policy prerequisites; - token budget; - prompt shell; - rendering template; - learning target; - inspection fields. --- ## 15. Memory Use Contract When memory context is injected, use a compact preamble: ```text [ELNOR MEMORY CONTEXT — USE RULES] Use each item according to its label. - Source-backed or Assertion items may be relied on according to their warrant. - Topic and Library Notices mean more information exists; do not infer unseen contents. - Recent Work and Episode summaries are orientation only, not evidence. - Working Hypotheses are not settled facts. - Reference-only items may be mentioned as unavailable but not substantively used. [/ELNOR MEMORY CONTEXT] ``` Each injected item should carry: ```text Role Warrant Source support Freshness Scope relation Policy/render state ``` --- ## 16. Learning targets Learning must be target-specific: ```text storage_extraction classification_policy organization_membership scope_resolution topic_notice_vs_slice library_notice_vs_source_slice packet_length prompt_shell warrant_assignment ui_surface ``` This avoids reducing all learning to “card X helped.”