Ledger Kernel · research-stack
POC · measured 2026-09-16 · every number is from the project's records, listed at the end
seq 1Argumentclaim.asserted · anchors[0]

Research you can hold to account.

Every deep-research tool can search, read and write. None can be held to what it wrote. Here every claim, model call, dollar and judgment is an event you can open, replay and check. The report is prose; the reason is a ledger.

report.md · Findings Stripe caches status codes and response bodies for keyed requests once endpoint execution begins, replaying even 500 server errors on subsequent retries. high confidence · docs.stripe.com “Stripe’s idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeds or fails. Subsequent requests with the same key return the same result, including 500 errors.” A1 fetch.done · status ok · docs.stripe.com bodies/<sha256_text>.zst · extracted text, bytes Stripe’s idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeds or fails. Subsequent requests with the same key return the same result, including 500 errors. start end the model cites url + quote · the kernel resolves fetch_ref and [start, end) · rungs exact → nfc → folded GATE-4 · every resolved anchor decoded from the store and compared byte-for-byte 451 / 451 · 0 mismatches

A finding in a real report, and the page it came from. The model cited a URL and a quote; the kernel found the quote in the bytes it had fetched and stored the offsets. The gate re-read every resolved anchor from the store: 451 of 451 matched, 0 mismatches.docs/GATE-POC.md check 4 · docs/SPEC-kernel.md §2 anchor resolution · the report: Gold-8 Verdicts, Q6

benchmarks 47 gated rows · 0 FAIL POC gate 7 of 8 · the miss is drawn side-by-side 5 of 8 · bar missed by one eight questions · 67 model calls
seq 2Planthree doors

Three doors.

Questionpremise · load_bearing
The problem The output of deep research is prose you have to trust. Five questions a reader asks of a report, the dead end each one hits, and our own earlier tool's numbers. problem.html →
Evalbench.result
The proof Eleven micro-benchmarks, eight gate checks and an eight-question side-by-side, every value a bench.result event. Seven of eight pass; the miss and the three worse verdicts are drawn. proof.html →
Argumentsynthesis
Try it Inside Claude Code or OpenCode over MCP, one config line. The report for anyone; ledger_query for the researcher. Status: proof of concept, not yet released. try.html →

Not released. Leave an address and we send one message when the MVP is readable — a report you can hold to account, with the ledger behind it.

Join the waitlist →

between them: how it works — the ledgers as rails, append-only, kill -9, replay at $0, budget — and the roadmap, FIX-590 → MVP → production.

seq 3Evalbench.result

The headline numbers, each with its file.

GATE · check 4
451 / 451
resolved anchors re-read byte-for-byte · 0 mismatches
PASS
BENCH · O-1
0 repeats
20 random kill -9 → resume · report hash equal
PASS
BENCH · U-4
78 / 78 · $0
replay served from the ledger · 0 calls · 0 reserves
PASS
BENCH · G-2
100 · 30 · 0
admitted · refused · over-cap, demand 400 vs cap 100
PASS
GATE · 8 checks
7 of 8
check 8 fails: 1 of 13 replays ≠ rebuild · #590
1 FAIL
E1 · side-by-side
5 of 8
not-worse 5 · worse 3 · the bar was 6
MISSED BY ONE
GATE · check 1
8 / 8 · 67 calls
gold-8 headless at the baseline's terminal state
PASS
BENCH · line
47 · 0 FAIL
gated rows at their POC targets · release · macOS aarch64
PASS

Every value is a bench.result event in the Eval ledger; the verdict is recomputed from value and target when the report renders, never read from a stored flag. The gate document is generated, never edited.docs/BENCH-POC.md (2026-09-16, commit 79c3370) · docs/GATE-POC.md · docs/E1-2026-09-16.md