Sample — synthetic data. Every number on this page was generated by the engine from synthetic books · no live customer data anywhere
The Seam Ledger · working demo

Don't take our word for it. Verify it.

The Seam Ledger — the first product built on the Terakota engine — watches the seam between AppFolio and QuickBooks: every week it reads both sets of books, names every disagreement it can see — and names what it can't — in one honest report. This page holds a real report the engine produced from a synthetic week, and its actual receipts, which your browser can verify right now. Nothing leaves your machine.

Read the report → Verify the receipts →
seam report · Jun 1 – 7, 2026
matched41 entries ✓ both sides agree
missing2 entries one side only, past the lag
drifted5 entries paired, a dimension disagrees
edited-after-rekey1 entry changed after it matched
backdated1 entry escalated — closed month
net variance−$927.00
coverageevery sweep complete ✓ disclosed
⛭ receipts below · hash-chained · verify them yourself
The artifact

One page. The whole week, named.

This is what lands in the inbox: the week at a glance, every exception with days outstanding, silent changes, exactly what was covered — and the method, including what the engine deliberately does not claim to see. This is the engine's real output, not a mock-up. The pilot's own configuration names the two sides — here AppFolio as primary, QuickBooks as comparison — while the engine underneath stays vendor-neutral by design, so it never bends to one platform.

report.html · synthetic week
the sample banner is rendered into the artifact itself open in its own tab →
The six verdicts

Every entry lands in a class. Same books, same answer — every time.

These six words are the report's whole vocabulary — fixed rules, no guessing. If you can read this list, you can read the report.

matchedBoth sides agree on every dimension. The quiet majority — counted, never assumed.
missingOne side has it, the other doesn't — and it's old enough that processing lag can't explain it.
driftedPaired, but a dimension disagrees: amount, date, account, or detail.
edited after re-keyIt matched last week; someone changed one side since. The silent-change catcher.
backdatedA new entry wearing an old date — escalated when it lands in a closed month.
watchedToo young to accuse. Unpaired entries inside the lag window are watched, not claimed.
The proof

These are the report's receipts. Check them.

Every report arrives with its receipts — a tamper-evident record of what was read, what was found, and what was delivered. You don't have to take the math on our word: one click asks your own browser to check the record, right here. The check runs entirely in your browser — nothing about you is sent anywhere.

Don't take the report's word for it. Check it.

The report claims four things. Press the button and your browser re-does the math on the receipts — on your device, in about two seconds — and tells you whether each claim holds. This is the same check your auditor could run, not an animation.

  • The record is complete — every receipt links to the one before it, back to the very first.
  • Nothing in the record has been altered — every fingerprint recomputes from the receipt's actual bytes.
  • The report above is exactly what was recorded — byte for byte.
  • The standalone verifier — a separate program, not the engine — recorded the same chain head and the same report fingerprint.
CHAIN VERIFIED — REPORT MATCHES

The first three checks run on the raw receipt bytes alone; the fourth compares your browser's result against the standalone verifier's published verdict. This in-page check proves hash linkage and report binding. The full standalone verifier — canonical-form checks, input-hash recomputation, delivery intent/confirmation pairing — must pass before any report is released; these artifacts already carry its verdict (verification.json). One honest limit: a wholesale rewrite of history would be internally consistent too — which is why every report prints its chain head. Any prior head you hold detects a rewrite.

For your auditor — the cryptographic detail

Each receipt's fingerprint is sha256(content ‖ previous fingerprint) — it covers the receipt's bytes and the fingerprint before it, all the way back to the first record. Change one byte of history and every link after it breaks. Below: the actual chain behind the report above, and the step-by-step log of the check. The report's own embedded stamp covers the chain up to its attestation (4 records); verification.json covers the full chain including the delivery receipts appended after it.

…
Loading the receipts…reading /demo/receipts.jsonl
    The method, honestly

    What we claim. What we don't.

    ◆Fixed rules, in writingA cent off is a drift — $0 tolerance. A 3-day window for near-matches, 5 days before "missing" is claimed, 7 days grace before "backdated". Renames are mapped at onboarding, never fuzzy-matched.
    ✕Blind spots, disclosedA hard delete leaves nothing to observe; an edit reverted between sweeps is invisible by construction. Every report says so — we disclose what we can't see instead of pretending to see it.
    ◆Honest coverageIf a sweep couldn't reach everything, the report says partial — and a clean-but-partial week never gets the green tick. "Covering X" renders from records, not copy.
    Private beta · taking a few design partners

    Now run it on a week of your books.

    Built for bookkeeping firms and property managers running AppFolio with a QuickBooks general ledger. A pilot takes read-only access to your AppFolio and QuickBooks — we can never change your books — your data stays in your custody, and your first Seam Honesty Report arrives inside a week, receipts included.

    Request a design-partner pilot → See the engine underneath →
    Read-only access · your custody, always · synthetic-data demos