A memory layer an application can inspect#
CleverMemory began with a practical question: how can an application tell the difference between something its documents establish and an answer that merely sounds right?
Finding related text does not settle that question. Neither does a confident score. What makes the difference is usually the part that gets thrown away first: which document a passage came from, where on the page it sat, which revision it belonged to, and whether a later one replaced it. An answer that keeps those attached can be checked. An answer that does not has to be trusted.
That is the product CleverMemory is being built to support: proof-carrying document intelligence, where a supported answer carries machine-checkable mathematical proof back to the documents behind it. It can also ask for clarification, show a conflict, or explain why the record is not enough. It is a general layer for applications, not a feature tied to coding agents or a single kind of project.
Built by Jason Varland#
CleverMemory is a hobby, not a day job. I write the engine in Rust in the evenings and on weekends, around a full-time career and a family, and I would rather say that plainly than let a polished site imply a team and a payroll. The work here is real; the pace is spare-time.
The day job has mostly been quality engineering, and it kept turning out to be the same job in different clothes: decide what evidence makes a system safe to ship, then make that evidence part of the work instead of a report someone writes afterward. The last few years put me hands-on with the AI side directly: production voice agents that resolved most customer-service calls without a person in the loop, agent workflows built on graph orchestration and local models, and AI-assisted migrations that compressed months of test conversion into weeks. Watching what those systems could do, and noticing how little of it anyone could check afterward, is where this project comes from.
Language models can be excellent readers and writers. That does not make the text they produce a durable record, and it does not prove that a retrieved passage supports a specific answer. What convinced me the problem was about documents rather than text was watching how much gets thrown away before the interesting work starts. Extraction is treated as a cleanup step: pull the words out, drop the table borders, drop the headings, drop the revision marks. By the time anything reasons over the material, the row that told you what a number was has gone, and so has the exhibit stamp that told you the clause no longer applied. The answer can still come out right. It can no longer be checked, which for a regulated decision is close to the same thing as being wrong.
That is why this problem is fun. An answer that carries its own proof is the first version I have seen where the evidence travels with the work instead of trailing it. Getting that right over real documents, with their revision marks, their exhibit stamps, and their tables that stop meaning anything once the borders are gone, is a puzzle I would pick on purpose.
What will be public, and what stays ours#
The sauce is secret; the meal is fully inspectable. One part of CleverMemory stays ours: the code and data that tie everything together. That piece is not public; everything you need to check what it tells you is, because checking the result does not depend on it.
What customers and technical reviewers should get is a clear product boundary:
| Public and reviewable | Private to CleverMemory |
|---|---|
| What goes into and comes out of the product | The internal representation and algorithms |
| Machine-checkable proof, source references, response status, and stated limits | How candidate relations are interpreted, connected, and selected |
| The pack interchange contract and source terms | Pack-building methods and proprietary product data |
| Evaluation rules and approved public results | Unreleased tests, tuning work, and engine source |
This lets an organization inspect the behavior that affects its application without handing out the design that produces it.
The question I would ask in your position#
CleverMemory is currently one person, working in spare time, and an engine that stays partly private. For a component that sits under a regulated decision, that is a legitimate concern and it would be strange of me to leave it unstated.
Three things are meant to carry the risk rather than my assurances. The pack format is a published contract, so the data a deployment depends on is not locked inside an engine only I can read. The evaluation rules were published before any results existed, so a future claim can be checked against a standard set in advance rather than one written to fit. And the proof is committed to being verifiable by an independent implementation, which is the difference between a product you can audit and a vendor you have to believe.
Source escrow, support commitments, and continuity terms are a commercial conversation rather than a website claim. If they are a blocker for you, they are a reasonable thing to raise in a first conversation, and I would rather have that conversation early than discover it at procurement.
Current status#
CleverMemory is in validation. Small controlled tests exercise source-linked answers, missing information, and repeated-run stability. Time-scoped recall, counts, and multi-document questions are in validation, alongside the recall engine and the pack pipeline. The report and transform capability described on the technical overview is a design target under the current plan rather than tested behavior. The software, public packs, supported configurations, and broader evaluation results have not been released. Because this is a spare-time project, I do not promise dates; the updates page records what actually happened and when.
For the current record, see Updates. For a product or technical conversation, email hello@clevermemory.ai or request a briefing.