The Burry stack
A sketch of how an examination runs inside Burry: what your agent sends, what happens to it, and why the result can be checked.
- 1 pacioli
The engine. Open source, deterministic.
Structured rows in: bank flows, ledger claims, stated balances, pledged receivables. A checklist out: the questions an examiner would ask, each tied to the rows and the calculation behind it. No model decides anything here. The same book always yields the same checklist, and every number in every finding resolves to a source row.
python3 examine.py sample/book.json --text
- 2 readers
Files become rows. Models may read, never judge.
A bank export is a CSV; the loader maps its columns by name. A PDF statement or a scanned borrowing base goes through a model that extracts rows and marks every cell it could not read as unknown. A model may also phrase a finding in plain language, behind a shell that locks every number and falls back to deterministic prose if one changes. It cannot add, remove or upgrade a finding.
python3 examine.py checking.csv savings.csv --text
- 3 burry
The service. What your agent calls.
One call sends a book and returns the checklist. Each question is open until closed by a document or by the recipient's own answer, and an answer never changes the grade. The checklist travels as a link, so a founder can hand it to every fund in a round and a lender's committee can put it on a screen. The API and the MCP tool are in build; the format they return is already published.
checklist.schema.json
Core design principles
- The bank is not the judge.
- The books drive the payments, so a false story produces real money movements that match it. Burry holds two records against each other and trusts neither. The read is where they diverge and what could not be compared.
- A claim is not an observation.
- What the company says a payment was for and what an independent record shows are different evidence objects, and they stay different all the way to the checklist. Rewording a claim cannot promote it.
- Graceful degradation.
- Without the learned readers, the exact checks run alone. Without a collection of rows, the engine says what it lacked instead of guessing. Without provenance, a finding carries the label unavailable, never an invented source.
- Never a verdict.
- A question is tied, when it stands on exact identifiers and arithmetic, or flagged, when the evidence supports a question and not a conclusion. Nothing Burry returns says that anyone committed fraud. An empty list means nothing left to ask, not clean books.
FAQs
- Why not just hand the PDFs to a model?
- Because a model reading a statement will produce a confident paragraph and no way to check it. Burry uses models only at the edges, to turn pages into rows and to phrase findings, and keeps the examination itself deterministic so that every question can be re-performed from the rows it names.
- What does it take to add a check?
- A reader is one file that takes rows and returns findings, one frozen exam with the planted case and its honest twin, and one probe that grades the reader against the exam. The exam is the definition of done, and no exam is ever weakened to let a change pass. The contract is in the repo under docs/readers.md.
- What does the engine catch today?
- Money returning to where it started. Totals that do not foot. Balance movements the transactions do not explain. Activity with no paper behind it. One receivable pledged twice. Claims whose implied cash never arrived. Confirmation domains that resemble, but are not, the authorized one. Streams whose rhythm a small model trained on honest money cannot rebuild.
- How does my agent call it?
- Today: clone the engine and run it on rows. The hosted call, one API key, one request with the files, the checklist back as JSON in the published schema, and the MCP tool that wraps it, are the next thing we ship. The checklist format will not change when they do.