§1 The published paper is the wrong artifact

A finished paper is a polished summary of what worked. It almost never reflects what actually happened: the false starts, the claims that were demoted when better evidence came in, the experiments that failed silently, the decisions to abandon a thread that someone else might have followed.

For human research this loss has always been costly. For agentic research it is also a missed opportunity: an agent that produced 700 events on the way to a paper has, in those 700 events, the actual record of how the research happened — including which beliefs were updated by which observations and which experiments terminated as failures. That record is currently locked inside agent transcripts and orchestration logs, where it cannot be queried, replayed, audited, or reused.

Research Ledger Lite is a minimal experiment in giving that record a first-class home.

§2 Seven event types

The schema names the kinds of things that actually happen during research:

• claim — a hypothesis or assertion.
• evidence — an observation, dataset, or experimental result.
• experiment — the metadata of an experiment that was run.
• decision — an adopted direction or cut-line.
• failure — a non-result, including failed reproductions.
• belief_update — a change in belief, linked to the prior and the evidence that caused it.
• artifact — a produced object: paper, code, dataset, figure.

Every event must be anchored. An anchor is an observable that a reader could in principle inspect: a commit hash, an output file path, a command transcript, a timestamp. Events without anchors are agent narration; the schema rejects them.

§3 Three layers, clear roles

The ledger is built from three storage layers, each with a different job:

• JSONL — the canonical event log. One event per line, hash-chained so any retroactive edit is detectable.
• Markdown — the human-readable layer. Per-event notes when useful, plus summary reports and the schema spec itself.
• SQLite — the derived index. Rebuilt from JSONL by ledger.py index. Used for queries and joins.

The choice is deliberate: JSONL + Git gives integrity and version history; Markdown gives readability and embeddability into existing research notes; SQLite gives query power without committing the project to a heavier database. None of the three layers is the source of truth on its own — the source of truth is the JSONL hash chain — but the three together make the ledger usable.

§4 Replay test: 733 events → 38 ledger events

To check that the schema actually captures something real, we replayed a full autonomous-research run through it. The source was an ARA run on a beyond-transformer architecture exploration (2026-05-17-beyond-transformer-v4), which produced 733 raw events — tool calls, sub-agent invocations, partial outputs, retries.

After mapping into the 7-event schema, the same run condensed to 38 ledger events: 12 claims, 9 pieces of evidence, 7 experiments (some of which were failed reproductions and re-emerged as failure events), 5 decisions, 3 belief updates, 2 artifacts. The 695 events that did not survive the map were intermediate scaffolding — tool noise, retries, internal sub-agent chatter — not research events.

The compression ratio (~5%) is not a target; it is a property of this particular run. It does suggest that the schema is doing real selection work: it forces the question “what observable does this event anchor to?” and rejects the events that are scaffolding rather than substance.

The replay script and the resulting events.jsonl are included in the repo at replay/ara-2026-05-17-beyond-transformer-v4/, so anyone can inspect both the raw input and the schema output and decide whether the mapping is fair.

§5 Platform-independent on purpose

It would be tempting to tie this schema to a specific research platform. We are not doing that, for three reasons:

• Researchers and agents not using any particular platform still need to record process.
• A schema that survives across platforms is a stronger schema. If only one platform can read it, it has fewer constraints to satisfy.
• Markdown + Git + SQLite are universally available. The ledger should run with no external service.

So Research Ledger Lite at v0 is deliberately standalone. The integration question — how a research platform should ingest or export ledger files — is left for a later version, once the schema has been used by at least one independent project outside its origin.

§6 Try it

The code, schema, and the ARA replay are available at github.com/t46/research-ledger-lite under MIT. The README is the entry point; schema.md is the field-by-field spec.

This is part of a wider exploration on what lightweight, agent-friendly infrastructure for research process integrity could look like. A companion artifact, Citation / Claim Audit Kit, audits whether paper citations actually support the claims they are attached to.