A litigation tracker starts as a spreadsheet. Someone adds a column for the source, then a column for the date it was checked, then a tab for the documents. Six months later the sheet and the documents have drifted apart, and nobody can say which rows were verified against what. Recordbench is what that spreadsheet turns into when the answer has to hold up.

Document corpus
Source-linked claims
Published views
Separate workspaces

Provenance

Every claim knows where it came from

A summary, an extracted fact, a synthesis: each one is a node with edges back to what it was derived from, and a record of who produced it. That is a named person, or a named model acting on a person’s behalf, stored with the prompt it was given.

Correct a node and everything downstream of it is marked stale until it is re-derived or explicitly re-reviewed. A correction lands once instead of being retyped everywhere it was copied, and the rows that depended on it say so.

AI origin survives acceptance. A machine-produced claim that a human has checked stays marked as machine-produced, and a human’s verification is never silently overwritten by a later machine pass.

Citations

Citations are stored as data, not as strings somebody typed

The record holds the parts; the format is applied on the way out. That form is Indigo Book, which is Bluebook-compatible and public domain, so a change of citation style never touches the record.

Anchors serialize the same way: a quote, its offsets and a page, rather than a link back into an application. A claim survives being read outside the tool, and it can be relocated in a document that has since been revised.

Storage

A workspace is a directory

The canonical record is an append-only assertion log. The SQLite index next to it is rebuildable from that log, and full text is stored content-addressed, so every capture pins a snapshot hash whether or not the text was kept.

You can zip it, sync it with anything that syncs files, and read it with ordinary tools. Merging two copies is set union, which is why there is no server in the middle. A collaboration server, when there is one, is another peer rather than a new centre.

Working surface

The whole review surface runs on the researcher’s own machine

A browser interface talks to a loopback API, so nothing leaves the machine. It carries the review queue and the document reader with its annotation layer. Endorsing a claim happens there, and so does re-anchoring one when a source moves underneath it.

The front page of a workspace is the investigation itself, written as an essay over its own chapters. Every figure in it is a live count, and every claim opens onto the provenance behind it. A reader can check the piece without leaving it.

The edges

What it is not

If one of these is a dealbreaker, it is better to find out now than in month three.

Not a chat interface: Retrieval and question-answering happen elsewhere. Recordbench consumes those answers and holds them to account; it does not try to be the place you ask.
Not a document management system: It is not a replacement for wherever your files live. It captures documents, pins snapshots of them, and records what was derived from which page.
Not hosted: Today it runs locally, for one researcher on one machine, over live research corpora. That is a deliberate order of operations rather than a missing feature: the format is serializable first, and the server is a peer added later.

Specifics

What it is made of

Workspace: A plain directory: append-only log, rebuildable SQLite index, content-addressed blobs
Provenance: A dependency graph with agents, revisions, anchors and staleness
Citations: Structured records rendered to Indigo Book; verified extraction with eyecite
Interchange: JSON-LD over Web Annotation and PROV-O
Interface: A command line tool, plus a local web app over a loopback API
Built with: Python core, Svelte and TypeScript front end, low dependency floor
Sync: File sync. Merging two copies is set union