Holdfast

Memory for long projects · whatholds.com

27 July 2026

I run a research institute with about fifty projects on the books, and every one of them is the kind of thing that takes months. Physics derivations, a formal mathematics library, protein folding, a language system. The work is slow in a particular way: most of what you learn on a hard problem is which roads are closed.

For a long time I kept losing that. I would open a new session with an AI agent, spend the first hour explaining the project, and then watch it walk confidently into something we had already proved does not work. Weeks later I would find the note where we proved it.

So I built Holdfast. It is the memory. Every decision, every claim carrying a tag that says how well we actually know it, and every dead end carrying the measurement that killed it, written down as the work happens, by the agents doing the work. Then a new session gets handed the current version of all of it automatically, in about two thousand tokens instead of the hundred and ninety thousand it takes to read the files.

The nearest thing I can point at is a Cursor rule that writes itself out of the work.

What I did not expect was what it did to the honesty. When a claim has to carry the test that would prove it wrong, you find out quickly which of your claims cannot carry one. Mine could not, in seven places. I know which seven now, which is the part that matters.

Jonathan WashburnRecognition Physics Institute · jon@recognitionphysics.org

What it does

Hands a new session the current state, not the files.
The store is append-only, so a record is updated by writing another one with the same id. What a session receives is the resolved value of every record after supersession, which is a different thing from the newest file and a different thing again from everything ever written.
about 2,000 tokens, against about 190,000 to read one project's memory whole
Records the dead ends, and refuses the ones that do not say what killed them.
A killed route has to name the measurement or the argument that killed it, and it has to say what the kill does not cover, because a negative result with no scope gets read later as holding everywhere. Both are checked when the record is written.
Reads back at whatever depth you want.
Start at the whole portfolio, drop into one project's binding decisions and open questions, drop again into a single claim, and from there into the conversation and the commits that produced it. Each level is a fixed budget, so the cost of orienting does not grow with the size of the store.
Watches the store for what no single session can see.
Scheduled passes over everything, looking for the things that are only visible from outside one conversation: work held on a decision nobody made, a project left alone while it still holds open questions, evidence that has stopped resolving, a claim whose tag its own record no longer supports. They propose and never edit, because a reader can say what a record is about and only its author can say what it kills.

Every claim carries how well it is known

This is the part that changed how I work. A tag is not a confidence level, it is a statement about what kind of support exists, and the weakest link sets it. Three hypotheses do not compose into a theorem.

THEOREM	Proved, and the proof checks.
MEASURED	An actual measurement, ours.
EXTERNAL-MEASURED	An actual measurement, somebody else's.
DERIVED-UNFORMALIZED	Derived on paper, not yet checked by a machine.
HYPOTHESIS	A prediction, with the thing that would break it named.
MODEL	A choice we made, not a fact we found.
OPEN	Not yet derived. A target, never an impossibility.

The tag cannot be promoted by agreement. What promotes it is the real gate: a compiler, a test, an instrument. That gate lives outside Holdfast, and Holdfast holds you to it.

What it refuses

A record that cannot be used later is worse than no record, so some of them are simply not accepted. This is the actual message, not an illustration of one.

record 2: a killed route needs `what_killed_it`, the measurement
or argument that killed it, not a description of the route

Refused on write. Restating the route is the commonest way a dead end fails to save anyone time.

A real record

This one is from Holdfast's memory of building Holdfast, this month. I was about to add a feature that scores generated prose for how much it sounds like the person who wrote the project, and the store stopped me: the measurement was already on file, from a different effort, and it said the instrument does not work.

Killed route

RouteScoring generated prose for how much it sounds like its author, and showing that number.

What killed itMeasured twice. Best fingerprint distance gave an AUC of 0.57 with a 95 percent interval from 0.38 to 0.74, straddling chance and failing a bar set in advance at 0.65. Pattern density as an authorship classifier gave 1.17x discrimination, falling to 1.04x once a boundary bug was fixed.

What the kill does not coverIt kills the score as a gate or as a number on the page. It does not kill generating prose grounded in real writing samples.

Do not revive unlessAn authorship instrument clears a bar set in advance with its lower interval bound above chance, on held-out text from more than one author.

N-route-holdfast-voice-match-score · written by the session that tried it

Four fields, and the last two are the ones that make it worth keeping. Without the scope, a later session reads this as "voice work does not work" and abandons something that does. Without the revival condition, the idea is dead forever rather than dead until the evidence changes.

In use

Holdfast runs against the Recognition Physics Institute's own work. The store was created on 16 July 2026; these are its numbers eleven days later, computed the same way every time and on record like everything else.

Measured 27 July 2026	Value
Projects under memory	51
Records	6,894
Live claims	2,527
Dead ends recorded, with what killed each one	498
Of those, saying what the kill does not cover	457
Live claims carrying a test that could break them, with evidence that still resolves	2,459
Live claims carrying no such test	7
Citations checked against the tree, of 12,229 made	11,671
Of those, pointing at a file that has moved or gone	146

The seven and the 146 are the point. A memory that only reported the good numbers would be a dashboard. Those are defects in my own work, they are on the page because the tool found them, and every one of them is now a thing I can fix.

The number was wrong three times

That last row is worth telling properly, because it is the failure mode a tool like this has to survive.

It first read 1,060. Then a bug turned up: the check was stripping the leading dot off every hidden file, so every rule and config the store cites read as missing. Corrected, 292. Then, this morning, sorting the 292 by what each one probably was showed that most of them were never file paths in the first place. The field also holds commit hashes, references to other records, artifacts on other machines, and paths with a note typed after them. The check understood one shape and quietly failed the rest. Corrected again, and told to answer "I cannot check that" as a distinct answer from "it is gone": 285.

Then the new check got caught overreaching in the other direction, and this is the part I would want to know about somebody else's tool. It had decided that 19 citations were unreadable free text. They were real files: one directory in that tree is named Millennium Prize Problems, and a rule that split on spaces took the first word and gave up. Nothing in the check's own tests could see this, because every test agreed with it by construction. What saw it was asking the opposite question: is anything I just called uncheckable sitting right there in the file list? That question now runs on every pass and prints what it finds. 146, with 558 citations named as unanswerable and counted apart.

So the count fell by a factor of seven without a single file being repaired. Every drop was a defect in the instrument, not an improvement in the work. That is the ordinary case rather than bad luck, and it is why every number here prints its denominator: 457 of 498 can be checked at a glance in a way that 92 percent cannot.

What it will not do

It will not write your claims for you. No language model sits in the path that produces or scores a record. Records are written by whoever did the work and read back by arithmetic; retrieval is ordinary keyword ranking rather than embeddings. The tool therefore cannot invent a finding, which is the only reason its answers mean anything.
It will not tell you whether you are right. It holds what kind of support a claim has and what would refute it. Deciding is the compiler's job, or the instrument's, or yours.
It will not tell you the project is going well. There is no score. Every count it reports comes paired with the cheapest way to fake that count, because a single number gets satisfied in the cheapest way available.
It is not a wiki and not a notes app. Nobody sits down to write in it. The record is a by-product of the work, produced at the end of a session by the agent that did the work, or it does not get produced at all.

Status

Holdfast works and is in daily use across fifty-one projects, inside Cursor and Claude Code. It is stdlib Python with no service to sign up for and nothing to host: the store is plain text files in your repository, and the tools are exposed to your agent directly.

It is not packaged for anyone else yet. If you are carrying a project that has lasted long enough to have forgotten something expensive, I would like to hear from you, and I would rather hear the specific thing you lost than a request for a demo. jon@recognitionphysics.org