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.
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.
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 six of our eight scheduled jobs, not all of them. The remaining two are named in our build log rather than quietly omitted.
- 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 →