Engine-managed recall
A bounded path from records to context
The Engine manages storage, scope, retrieval and context admission. A stored record does not automatically become part of a model request.
- 1
Stored
Retain session evidence within configured storage and retention limits.
- 2
Eligible
Restrict candidates to the relevant scope, such as one selected session.
- 3
Recalled
Rank relevant fragments and assemble a selection within the recall budget.
- 4
Admitted
Fit selected evidence alongside the task and other context under runtime limits.
- 5
Submitted
Inspect retained checks for exact memory blocks at the provider request boundary.
Persistence and access describe different things
Session records can survive a process restart or planned worker rotation. That persistence does not give the model unrestricted database access. In the session-recall path, the model receives the context admitted by the Engine.
The underlying storage adapter may load or scan eligible stored fragments. The distinction is who manages retrieval and what is delivered to the model, rather than a claim that a database is never searched or that other systems all work alike.
Inspection in Sense
What Memory Atlas shows
Memory Atlas is a read-only projection of retained session evidence. Its graph and list are inspection views over existing records, with source references available for review.
Saved sources
Inspect available fragment text, source references, correction evidence and saved snapshots for a selected session and turn. A snapshot describes the captured record, not necessarily today's live store.
Recall paths
See which fragments were selected for recall and distinguish them from records that were merely stored. Relationships describe retained storage and delivery evidence; the graph does not infer a new authoritative set of facts.
Model delivery
Inspect the recorded model identity and whether an exact recalled block survived into the provider request. Assembly alone, absent checks and confirmed submission remain distinct states.
Evidence limits
Submission shows that evidence reached a request boundary. It cannot prove the model relied on it internally, that a retained statement is true, or that another model in the workflow received the same material. Delivery to Observer's separate opinion model is not instrumented by Atlas in this version.
Memory Atlas does not edit memory, change recall policy, grant permissions or control execution. It is separate from Execution Atlas, which explores retained execution structure and timing.
Fictional walkthrough
One project, an attributable correction
A user first records Harbour's reference as HARBOR-314, then corrects it to HARBOR-620. The source record matters: a correction to one project is not a general user preference.
Illustration only · no live model or database connection
Stored note
Harbour project reference: HARBOR-314. Folder colour: teal.
- Source
- Fictional user note A
- Evidence state
- Stored. Recall selection and provider submission are not established by storage alone.
- Model reliance
- Unknown. This illustrative view cannot establish internal model use.
A later, attributable correction can replace the current value without making the original note disappear from historical evidence.
Working features, research and future integration
Implemented · session scope
Bounded session recall and Atlas
Session storage, compaction, scoped recall, correction-aware evidence preparation, source inspection and provider-delivery observations are implemented. Controlled runs have retained memory through worker rotations. The public example above is an illustration, not access to that private operational interface.
Research · live validation pending
Delivery and Engine stress studies
A controlled twelve-arm study completed with retained lifecycle and delivery evidence; model compliance varied by method. A harder comparison of Native only and Native with Simplified preparation is prepared locally: 100 turns per isolated governed arm, 200 turns total. The new study has no live results yet; its live validation is pending.
Future product capability
User memory across sessions
This session-recall feature does not establish a general persistent user profile across conversations. Separate synthetic-user studies are research, not proof of real-user availability. Production user memory needs explicit ownership, consent, retention, correction and deletion standards before it is offered.
Future integration · separate authority
Memory-to-NNLSL learning
NNLSL is an existing, separate non-neural learning research system. Atlas does not automatically promote session notes into it, and recalling a note is not training. Any future bridge requires explicit permission, learning standards and its own validated promotion process.
How the evidence is read
Correct answers and delivered memory
Observer can score a recall or unknown-value question separately from inspecting memory submission. A correct answer alone does not establish that recall was necessary.
Configured and exercised features
Matched studies preserve separate arms, model settings, mandatory safeguards, checkpoint evidence and raw outcomes in private reports. Feature activity requires retained runtime evidence; a configured option or an untriggered memory-growth limit is not a successful feature test.