The Memory Engine

The xysq Memory Engine turns raw AI work into context that improves instead of just accumulating. You push verbatim material in (session transcripts, uploaded files). The engine distills it into a context graph your tools can query. When something is wrong, you correct it once and the fix is visible on the next query. One rule runs through the whole design: the model proposes, code disposes. A model drafts every change to your memory. Deterministic code verifies, gates, and applies it. No invariant is enforced by a prompt.

​

Two layers, one trust chain

The engine stores your context in two layers. Verbatim logs sit at the bottom. Every push lands here first, byte for byte, and is indexed for retrieval within seconds. Logs are immutable: nothing downstream can edit them, ever. That immutability is what makes everything above checkable. The context graph sits on top. A background worker merges new content into readable pages made of addressable blocks, typically within minutes of a push. The work per push scales with the new content, not with the size of your corpus. There is no global recompute. The rule connecting the layers: the graph must cite the logs. A claim in the graph that cannot quote the log underneath it does not get committed.

​

The fact ledger

Between the two layers sits the fact ledger. Every fact in your graph is a ledger row carrying two things:

• Recency. When the fact became valid, whether it has been superseded, and by what. Page bodies show current truth; superseded facts are invalidated, never silently deleted.
• Lineage. Verbatim quotes from the log as evidence, a label for whether the claim was stated by a source or inferred, and a dependency chain. Superseding a premise flags every conclusion built on it.

A fact you see on a page is a rendered ledger row. Its text is frozen at commit and can only change through a new ledger event. Inferred claims are labeled as inferred and require multiple citations.

​

Deterministic gates

Every proposed change passes six families of checks, all enforced in code, before it touches your graph:

1. The assembled file diff must equal exactly the declared edits. Undeclared change is physically impossible.
2. New stated facts must quote the log verbatim. Unmatched claims quarantine for review instead of committing.
3. Fact renderings are frozen outside ledger events.
4. The changelog on every page is composed by the server, not the model. The model cannot edit its own trail.
5. Every fact edit maps to exactly one ledger event.
6. Validators catch contradictions, orphaned content, and malformed structure. A page shrinking suspiciously in one run parks for review instead of committing.

​

The write-ahead log

Every change follows the same write path: it is staged in full in a write-ahead log, checked by the gates, applied in ordered durable steps, and committed as a diff in your graph’s version-controlled vault. The payoff is recovery. A crash mid-apply replays deterministically from the staged record, without calling the model again. Queries always serve the last committed state, never a half-applied one. And because every change is a commit, you can diff any two points in your memory’s history and read exactly what changed, when, and on what evidence.

​

The boundary, stated plainly

The mechanical edit trail is guaranteed by code: every byte change is accounted for and the model cannot forge it. Semantic judgment (did the model link a fact to the right entity?) is audited and bounded, not guaranteed. Perfect recording of edits, not perfect memory. When judgment calls need a human, they land in the review queue.

​

Where to go next