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 served as soon as the engine has applied it. 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 a background worker indexes it for retrieval, ahead of any distillation. An MCP push_context can ask to block until that finishes (wait: "indexed") when you need to recall a fact in the turn you pushed it. Nothing derived from a log edits it: no distill, no page rewrite, no fact ever changes the bytes underneath. You and your agents can correct a source deliberately, in the app or through the SDK, and when you do, the correction is added to the source’s history rather than replacing what was there, so every earlier version is still readable. Any fact that quoted wording your correction removed is closed, not left citing text that is no longer there. Append-only 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. It is a model pass, so it lands after the push, not with it. 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 engine committed the fact, whether it has been superseded, and by what. Page bodies show current truth; superseded facts are closed, never silently deleted, so the trail of what changed survives.
• Lineage. Verbatim quotes from the log as evidence, a stated or inferred label, and, for an inferred fact, the facts it was derived from. That dependency chain is recorded today; acting on it automatically (closing a conclusion when its premise is superseded) is not built yet.

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. Every fact carries a stated or inferred label, and only stated facts are held to the verbatim-quote check.

​

Deterministic gates

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

1. The rebuilt page diff must equal exactly the edits the run declared. An undeclared byte change fails the run.
2. Fact renderings are frozen: the text of a committed fact can only change through a ledger event in the same run.
3. A stated fact must quote its log verbatim. Inferred claims are labelled inferred and are exempt from this check, which is exactly why the label matters.
4. The changelog on every page is composed by the server, not the model. The model cannot edit its own trail.
5. Fact edits and ledger events are a bijection: one event per edit, one edit per event, both directions checked.
6. Validators catch a page that renders a closed fact, two live values for a single-valued attribute, a fact whose value is not actually present in the block claiming to show it, and merge-conflict markers in prose.

On top of those, a page that shrank more than its declared removals account for (over 25% of its bytes, or two blocks) is refused too. Two different things happen when a run fails one of these, and which one you get depends on the failure. A deterministic quarantine pass runs first, before any gate. It drops the offending fact or event, and the batch commits without it. In most cases the sentence survives the drop: a claim whose quote does not match its source, a value that is not actually present in the block meant to render it, and an event that no block claims or that two blocks claim all leave their text on the page as plain prose. You lose the fact, you keep the sentence. The exception is a second assert for an attribute that already has one. There the duplicate is removed along with its sentence, because the page would otherwise carry the same claim twice with only one of them proven. The first assert keeps both. Whatever survives that pass and still trips a gate refuses the whole batch. That is where the rest of the list bites: an edit the run cannot account for byte for byte, a fact block with no ledger event behind it, a page rendering a closed fact, a cardinality conflict with a fact from an earlier run, merge markers in prose, and the shrinkage rule. Nothing from that run lands, the previous state stands, and the rows go back to pending to be retried. A row that keeps failing is eventually given up on rather than retried forever.

​

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. There is no human review queue today: a run either passes every gate and commits, or fails and is retried. Judgment calls the gates cannot catch are caught by you reading a page and correcting it, which is a push like any other.

​

Where to go next