We keep receipts on our own automations.
Including the ones that failed.
In plain English
- What it does
- Every night, the automated jobs we run write down what they were supposed to produce and what they actually produced. This page is that record, and it includes the nights ours came up empty.
- Why it helps
- Software that fails loudly gets fixed. Software that fails quietly — the report that still arrives on time with last week's numbers in it — is what actually costs you money, because everyone keeps trusting it. This is us proving we check ourselves for that, rather than asking you to assume it.
- What you need
- Nothing. Read it, or hand it to whoever does your due diligence.
- How long
- Two minutes to read. If you want to try the same idea on your own file, the notarizer does it in about a second.
Anyone can tell you their systems are working. The failure that costs money does not throw an error — the job runs, the log fills, the exit code is zero, and nothing actually happened. So our scheduled jobs write a signed receipt every time they run, recording what each one claimed against what it actually produced. This page is that ledger, and how you would check it without taking our word for anything.
What a receipt actually records
Each run declares its outputs up front. Afterwards the file is hashed again and compared — so “the job succeeded” has to survive contact with whether anything changed on disk.
Claimed vs. produced
The declared outputs, hashed before and after the run, with the newest date found inside each text file recorded alongside. A report can be freshly written and still contain last week's numbers; the receipt captures both facts.
The exit code tells the truth
A tool that exits zero without touching its declared output fails the receipt, whatever it says about itself. That is the whole design: the scheduler learns about the lie at the moment it happens, rather than the following week when someone opens the file.
Chained, so history cannot be quietly edited
Every receipt carries the hash of the one before it. Rewriting or deleting any entry breaks every link after it, and the break is visible to anyone holding the ledger.
What it was built from — and a refusal to work from stale data
A run can also declare its inputs, recorded by hash and by the newest date found inside them. That matters most where a person is least able to check: an AI writing a summary of numbers that stopped updating last week reads exactly like one writing about today. So a job can be given a limit, and if its data is staler than that, it does not run and nothing is written at all — a warning attached to a finished draft is a note nobody reads. What this proves is bounded: which files the run could see, and that those bytes have not changed since. Not that the program read them correctly.
Anchored in public, so it binds us too
A signed ledger only proves integrity against people without the key — which does not include us. So the chain head is published to this site on a schedule. Once a head is public, its history cannot be rewritten by anyone, ourselves included.
How you would check it
The anchors file is plain text and append-only. Each line is the state of the ledger at the moment it was published.
To settle any dispute about work we say we did: take the anchor line that was public on the date in question — this file's history lives in a public repository, in CDN caches and in web archives, all of which are witnesses we do not control — then ask us for the ledger and hash its last line at that receipt count. If the hashes match, the history you are holding is the history that existed then. If we had edited anything behind that anchor, they would not.
Do it yourself, on your own file
The limit stated below — that our receipts are signed with a key only we hold — has an answer, and you can use it right now. Notarize a file in your browser: it hashes the file, signs a receipt with an Ed25519 key generated on your device, and hands you the public half so anyone can verify it without trusting us, without an account, and without uploading a byte. Drop the file back in later — changed or not — and it will tell you which.
And what the AI did
The receipts above answer “did the job run and produce what it claimed”. There is a harder question about the jobs that call a model, and it is the one every business deploying AI is about to be asked: what did the AI do, and how do you know it was right? That page is built from this same chain — which model was called, what it was entitled to read, whether a named person approved it, and whether it later turned out wrong. It leads with the refusals and the runs nobody approved, and it never claims the AI was right.
What this does not prove
- The signatures are not third-party-verifiable yet. Receipts are signed with a local key, which proves nobody without that key altered them — it does not prove we didn't, before publishing. Public anchoring is what closes that gap today; a keypair whose public half you can hold is the next step.
- It covers all ten of our scheduled jobs — and only those. Work done by hand, or by a person at a keyboard, leaves no receipt here. A ledger of the automated half is not a ledger of everything, and reading it as one would be a mistake we would rather you not make.
- A receipt proves an output changed, not that it is correct. Whether yesterday's date in today's report is a problem depends on the cadence, which is a judgment call — so the date is recorded as evidence and a separate check decides.
- The tool that produces these is not public yet. It is stdlib-only, tested, and being prepared for release; we would rather ship it late than link an install command that does not work.
If your automations report success, and you have not checked
That is the normal state of things, and it is where this whole line of work came from — our own stack, failing quietly, four days in a row. We audit for exactly that: the jobs that run, report success, and produce nothing. You get the findings with the evidence for each one, including the ones that turn out to be fine.
Ask about an automation audit See the open-source detector →