How it works

Development preview · no public release yet

CleverMemory reads the documents an application is allowed to remember and turns them into a temporal evidence graph the application can question. When it returns a supported answer, the application also gets the evidence that supports it. When the record is not enough, it says so.

Documents are the material this product is designed around, because layout, revision, and attribution carry meaning that plain text loses. Other textual material an application already holds, such as notes, messages, logs, and records, can be given to it as well.

Everything that crosses the product boundary is on this page. One part of CleverMemory stays ours: the code and data that tie everything together behind that boundary. That piece is not public; everything you need to check what it tells you is. This page is not installation documentation.

The flow#

1. Give it documents

   The application provides the documents, notes, messages, logs, or other textual records CleverMemory may use.

2. Keep the workspace under local control

   The current product direction is local-first: memory belongs with the application using it, not in a required hosted model service.

3. Ask a question

   The application sends a question and any scope or time constraints that matter to the decision.

4. Inspect the response

   The result is an answer, a clarification request, a surfaced conflict, or an explanation of what could not be established.

What the evidence graph is#

The customer-facing name for how CleverMemory represents what it has read is the Temporal Evidence Graph. Four things stay connected in it, because separating them is what makes an answer unreviewable:

• the wording of a passage, exactly as the source put it;
• where it appeared, since a number in a total row and the same number in a footnote are not the same claim;
• when it applied, separately from when it entered the record; and
• what it came from, so any conclusion can be traced back to a source.

That name is product language for an observable set of behaviors. It is not a file format or an interface, and how the representation is built and searched stays inside the product boundary.

What “mathematical proof” means#

When CleverMemory marks an answer as supported, the response is designed to carry a machine-checkable mathematical proof. It can be checked without asking a language model to judge its own answer.

The word carries more than a citation list, and the difference is the point. A citation tells you where something came from. A proof also has to tell you how the answer was reached from there: which records were selected and on what grounds, which were set aside and why, which relationships were followed, which values were superseded by later ones, and which units or scopes were applied. Every step between the documents and the answer is part of the object, not just its endpoints.

Where the answer is computed rather than quoted, the operations themselves are part of it: what was grouped and by which key, what was counted, what was listed, what was filtered out, what arithmetic was performed on which inputs, and which mentions were merged into a single identity on what evidence.

Take the spend example on the home page. "GBP 14,542.00" cites three records, but the records alone do not justify it. What justifies it is the sequence: the five matched rows selected by legal name and vendor ID rather than by the shared word "Aurora", the −48.00 credit applied beside the retained original rather than written over it, and the unit held at GBP by the ledger's own header rule rather than converted at an invented rate. Drop that middle and you have three quotations and an assertion sitting next to each other, which is exactly what looks like proof without being it.

Aggregates are where this gets strictest, because the output is a single value with no visible seams. A count is not proved by its number. It is proved by its members: the set that was counted, the record behind each member, the boundary the count claims to be complete over, and the merge decisions that concluded two mentions were one thing. Answer "four approved suppliers" and the proof has to carry the four, the schedule rows they came from, and the reason two spellings of a vendor name collapsed into one of them. A bare four is an assertion, and it is the kind that stays wrong quietly until somebody reconciles it by hand.

This is the distinction the research literature calls how-provenance, and it is stricter than the where and why varieties, which stop at naming the source. Part 7 of the Foundations series covers the difference and why it is hard to preserve through a computation.

That is a precise but bounded claim. The proof does not certify that an original document is truthful, that the available records are complete, or that a deployment meets a law or industry standard. Source quality, access, retention, and regulatory controls still belong to the application and the organization operating it.

This distinction matters in regulated work: mathematical proof strengthens the answer boundary, while governance establishes whether the inputs and the wider system are fit for the decision.

What can check the proof#

A proof is only worth the word if something other than the system that produced it can check it. Otherwise "machine-checkable" is a stronger way of saying trust us, and this product would be arguing against itself.

So the release requirement is specific: the proof must be checkable by an implementation independent of the engine that produced it. A checker reads the response, the cited records, the recorded operations, and the declared rules, then re-runs the derivation and returns a verdict, without calling back into CleverMemory. Checking is replaying the steps, which is only possible because the steps are in the object. If the engine is wrong, an independent checker is what catches it, which means the checker cannot be a component of the engine.

That artifact does not exist publicly yet. Until it does, treat "machine-checkable" as a stated design commitment rather than something you can exercise, and hold the release to it.

What an application can receive#

Two qualifications apply to every row. An answer may be returned narrowed: proven over a stated subset of the material in scope, with the receipt for that narrowing attached. A consumer can then tell the difference between an answer proven over everything admitted and one proven over the part that matters, and can judge whether the narrowing covers its own next question. And every response, a full answer included, carries a counted census of what remains unestablished. A supported result and an exact shortfall can coexist in one response; the shortfall is reported, never smoothed over.

Exact field names and serialization are not frozen. The important contract is the behavior: a consumer should be able to distinguish these outcomes without parsing polished prose or guessing from a confidence score.

Two further shapes are design targets rather than behavior exercised in controlled tests today. A supported answer can be returned as a formatted, evidence-linked report that preserves how its sources represented the information, and a document can be transformed through its declared format with an account of what was preserved, changed, recalculated, or omitted. Those are described in Reports and transforms below and are not part of the tested boundary below.

What a response looks like#

Four illustrative envelopes, one per outcome. They show the shape of the contract. The field names are not frozen, and the engine that produces a response is not part of the boundary. The fictional documents behind these envelopes, with a fully worked response, are in the case file.

outcome: answer
answer: "GBP 14,542.00"
proof: machine-checkable
sources: OPS-002 matched rows, credit ADJ-4422-A,
         ledger currency rule

outcome: clarify
question: "Aurora Components LLC or Aurora
           Circuit Works Ltd.?"
context: two legal suppliers share one word

outcome: conflict
subject: devices affected by IR-2026-024
records: "field report 021, remote sweep: 42" /
         "field report 022, physical check: 17"
state: disagreement shown, not chosen

outcome: gap
established: seals intact, no visible damage,
             assemblies never powered
missing: any bench-test result (HTL-2026-044A
         has not been run)

Reports and transforms#

Design target · no public release yet

An evidence graph is the middle of the trip, not the end of it. Turning documents into inspectable evidence is only half of what the records were for. The other half is turning supported evidence back into something a person can read, file, review, or send. This section describes what that output has to satisfy. It is a statement of the product's design target under the current plan, not released behavior, and no public artifact demonstrates it yet.

Asking a complex question#

The response to a narrow question can be a value. The response to a real question usually cannot. Ask what a set of documents establishes about an obligation, a timeline, or a counterparty, and a single sentence either oversimplifies it or hides the parts that were uncertain.

The design target is a fully formatted, evidence-linked report that shows what the documents establish, where every conclusion came from, which alternatives remain, and exactly what is missing.

What a report has to preserve#

A report that flattens its sources into prose has thrown away the thing that made the sources worth citing. Where information appeared can change what it means, so the output has to honor how the source represented it.

Each of these is a requirement on the output, and each is separately testable: a reviewer can check whether the structure survived without knowing anything about how the system produced it.

Transforming a document#

The same round trip runs in the other direction. Instead of asking what the documents establish, an application can ask for a new document produced through an existing one's declared format.

The worked example is already on this site, because it belongs to the same case file as everything else. The quarterly close summary used "Aurora" for two different supplier matters, and the correction on record attaches a dated clarification instead of overwriting the original. Reissuing that summary is not a find-and-replace problem. Two mentions resolve to legal names with vendor IDs, every figure stays put, and the reason for the change belongs on the face of the document. Use case 07 shows the before and after, and the correction thread publishes the original exchange in full, so what follows can stay about the contract rather than the artifact.

The account has four categories:

On the summary the account is short enough to say out loud: the figures and both original passages are preserved, and two "Aurora" mentions are changed to legal names with vendor IDs, with clarification VRM-2026-09 named as the cause. A busier document would add recalculated and omitted entries on the same pattern.

The account is the point of the feature, not paperwork attached to it. Producing a plausible revised document is not difficult. Anyone who has reconciled two copies side by side, a finger moving down both pages, knows exactly how slow that work is. That is the danger: a plausible revision is indistinguishable from a correct one until somebody reconciles it by hand, which is the work this was supposed to remove.

What this does not claim#

A reissued summary is a document produced through a declared format, with every change reported as such. Whether the resulting document may be issued, filed, or relied on is a decision for the organization issuing it, and depends on approvals, controls, and review that sit outside this product.

How this would be integrated#

There is no released integration surface, so this is direction rather than commitment, and it is the area most likely to change before a release.

The development system today is a local workspace with a command-line surface and a loopback service boundary. That shape implies an application talks to CleverMemory as a local service it controls, rather than linking a library into its own process or calling a hosted endpoint. Documents are handed to the workspace; questions and scope constraints are sent per request; responses come back in the four shapes described above.

What a release has to settle, and what this page will state when it can: the packaging and supported platforms, the wire format and its versioning, which languages get a supported client, how documents are added and removed, what happens when a document cannot be read, and the resource envelope for a given corpus size. Until those are published, this page is not sufficient for an integration estimate, and should not be used as one.

Runtime direction#

The current development system uses a local workspace, a command-line surface, and a loopback service boundary. The public release may package those surfaces differently.

Five design requirements are already clear:

• Local-first. The operator controls the memory workspace and the material placed in it.
• Same question, same answer. Asked twice against the same pack, a question returns the same answer, and keeps doing so. A different pack may legitimately produce a different answer, because the evidence changed. That is the pack moving, not the system wobbling, and the two must never be confusable: the answer is a function of the question and the pack it was asked against. Pack builds are deterministic too: the same input produces a byte-identical pack, and an answer names the exact pack snapshots it was derived from, so two answers can always be traced to the same or to different evidence.
• Representation fidelity. What a document's structure carried has to survive into the answer. Tables stay tables, quoted wording stays exact and attributed, ordered material keeps its order, and a superseded value is shown as superseded rather than replaced.
• No LLM, embedding model, vector database, GPU, or hosted inference in the recall path, and no learned weights or adaptive ranking anywhere in it. CleverMemory does not use those components to build or follow an answer path, and it does not adjust its behavior based on the answers it gives. An application can still use them elsewhere in its own stack.
• Ordinary hardware. The runtime is designed for CPU-based systems without a dedicated GPU. Supported machines and measured limits will be published with a release.

These are product requirements, not public performance results. There are no approved latency, throughput, capacity, memory-use, or operating-cost numbers yet.

The inspection boundary#

The public side should be sufficient for integration, review, and evaluation. You could not rebuild the engine from it, and you should not need to.

What release documentation will add#

The first public documentation will include verified installation steps, supported platforms, response schemas, compatibility rules, data-flow and network boundaries, backup and deletion guidance, known limitations, and measurements from named test systems.

Until those artifacts exist, this page should not be used as a security, privacy, regulatory, capacity, or procurement assurance.

Common questions#

Is this AI?#

Not in the sense most people mean it, and the distinction is worth stating plainly because the category name says "intelligence" and the year invites the assumption.

There is no trained model in the recall path. Nothing in it was learned from a corpus, and no answer changes because a temperature or sampling setting changed. The behavior comes from an explicit representation and explicit rules over it, which is the only reason an answer can carry a proof at all. You cannot exhibit the derivation for a step that was produced by inference from weights, because there is no derivation, only an output.

The practical test is repeatability. Ask the same question twice against the same pack and the same answer comes back, and keeps coming back. Ask it against a different pack and the answer may differ, because the evidence differs. Those two are not the same phenomenon and the difference is the whole point: an answer that changed because the documents changed is correct behavior, and an answer that changed on its own is a defect. Systems built on sampling cannot draw that line cleanly, which is why they tend to describe the second as the first.

A useful way to place it: this is closer to a database with a hard semantics problem than to an assistant. It does not chat, summarize, brainstorm, or write prose. It answers from documents and shows the work.

That is a description of today, not a permanent commitment. If a learned component ever earns a place, the likeliest place is reading rather than answering, and two things would have to hold: it would be named on this page, and the boundary between what was derived and what was inferred would stay visible in the response. A system that blurred those two would give up the only property that makes this worth using.

If there is no language model, how does it read language?#

The right question, and the honest answer has a public half and a private half.

The public half is what the recall path is not. It does not call a language model, an embedding model, or a vector index. It is also not string matching. Keyword search, regular expressions, and fuzzy comparison cannot make the distinctions this product is built on: they cannot separate a negation from an assertion, a superseded clause from a governing one, or a total row from a line item that happens to carry the same number. If those techniques were sufficient, the Foundations series would not need ten parts to explain what is hard here.

The private half is how the system actually resolves language into typed, time-scoped, position-aware records. That part stays ours; it is not something I can publish.

What you can hold us to is behavior rather than mechanism. The response contract is public, the failure modes are enumerated, and the evaluation rules were published before any results existed. Weak interpretation shows up in that frame as wrong answers and unjustified declines.

How is this different from retrieval-augmented generation?#

Retrieval-augmented generation retrieves passages by similarity, then asks a language model to compose an answer from them. Two consequences follow from that shape. The retrieval step selects for relatedness rather than for logical role, so a superseded clause and the clause that governs look equally attractive. The generation step produces fluent text whether or not each step is supported.

CleverMemory has neither step. No similarity ranking decides what counts as evidence, and no generation stage turns evidence into prose. The response is assembled from records that satisfy the question's requirements, and it carries those records with it.

This is not an argument that RAG is bad. It is very good at discovery, and an application can use it, and a language model, everywhere else in its stack. The claim is narrower: at the point where an answer has to be defensible, relatedness is the wrong selection criterion.

What document formats does it handle?#

The release will publish the supported list. The design position is that a format is only usable if its structure survives reading: a document whose table rows, headings, and revision marks can be recovered is worth substantially more to this system than the same words as a flat string. Where structure cannot be recovered, the response should say so rather than answer as though it could.

What about scans and photographed pages?#

A scan has geometry a person can see and a machine has to infer. That inference belongs in the record as an inference, with the uncertainty attached, rather than being silently promoted to the same standing as a structure the file declared. Coverage and accuracy on scanned material will be reported separately when they are measured; treat it as an open area rather than a solved one.

Does this replace our document management system?#

No. A DMS decides what exists, who may see it, and how long it is kept. CleverMemory answers questions from the documents it is given and shows what the answers rest on. It has no opinion about retention, permissions, or filing, and those remain the responsibility of the systems and people around it.

Is this only for AI assistants or coding agents?#

No. Any application that needs durable, inspectable memory is in scope. An AI assistant can use CleverMemory, but so can workflow software, an internal business system, a research tool, or an application in a regulated environment.

Does it replace a language model or search system?#

No. CleverMemory is a memory layer. An application may still use search, embeddings, a database, or a language model for other jobs.

Can we evaluate it now?#

Not through a public release. If you are assessing the architecture or have a candidate application, request a technical briefing.

Where you go next depends on what you came to check. If you want to see the contract exercised rather than described, the case file takes one question through the whole thing: answer, proof, sources, and the narrowing receipt. If you want the standard the release will be held to, the evaluation rules were published before any results existed, so the release is measured against a standard that predates the outcome. Reports and transforms above covers the two shapes this page marked as design targets, and the pack format preview, the pack inventory, the glossary, and how CleverMemory compares fill in the rest.

And if what you actually came for was the install guide: that page does not exist yet. When it does, it will be announced in the updates record, and it will have to earn the claims this page has made.