Most vendors run audits the way restaurants pass health inspections: quietly, annually, and only the result is public. We do it the other way. Every month we audit our own running system in front of the customer — cooking-show style, with the cameras on the stove.
What "cooking-show" means in practice
A cooking-show audit is read-only by construction (Class C). The auditor cannot change configuration, restart services, rotate keys, or mutate state. It can only look, hash, list, and report. That constraint is the point: an audit that can fix things on the fly is an audit that can also hide things on the fly. Ours cannot.
The monthly pass walks the same checklist every time, against the same live boxes:
- Which services are running, on which hosts, on which ports.
- Which configuration files differ from the last snapshot, and by how many lines.
- Which approvals were issued, by whom, against which tool calls.
- Which gates and falsifiers are currently in the published state.
- Which dependencies have moved versions since last month.
- Which logs are being written, where, with what retention.
The output is a short report with file paths, hashes, counts, and a one-line conclusion per check. No prose interpretation, no marketing. If you want to read it, you can — the report is one of the six receipts we keep public.
What we publish
We publish three things from each monthly audit:
- The check-list itself (so you can see what we did not look at).
- The pass/fail per check, with the artifact that proves it.
- The list of items the audit caught that we then had to fix — and how long it took to fix them.
That third item is the one that matters. An audit that never catches anything is either too shallow or being edited before publication. Ours catches things. Last quarter it caught a stale environment variable that had been broken for nine days, a webhook endpoint that was silently dropping leads, and a loopback port collision that knocked our own probes off-line for an afternoon. Those are not flattering. They are in the receipts anyway.
Why this exists at all
Themesis has a useful post on what happens when systems are trained on small deceptions — the bad behavior compounds and escalates (AI Misalignment: Anthropic's Studies and More, Class E). The lesson generalises beyond model training. If the people running a system are allowed to quietly paper over small failures, the next failure is easier to paper over, and the one after that is easier still. By the time anyone external looks, the gap between the marketing and the machine is large enough to fall through.
A monthly read-only audit is the cheapest known countermeasure. It is not virtue. It is mechanical hygiene.
What we will not claim about the audit
We will not claim the audit is exhaustive. It is bounded — it checks the things on the list, and only those things. We will not claim it proves the system is correct. It proves only that the checked items were in the stated state at the stated time. We will not claim it replaces an external auditor; eventually we want one, and the monthly self-audit is the prep work that makes an external review cheap rather than catastrophic. The full posture is on our what we do not claim page.
What it costs you, the client
Nothing extra. The audit runs on our infrastructure on a schedule, the report goes into the same shared folder where your other receipts live, and you get a one-line notification when it is filed. If a check failed and we are working on it, the report says so and gives a target date. If we missed the target, the next month's report says that too.
The honest version of the pitch
We are not the only firm that audits itself. We are one of the few that publishes the misses. If a monthly catch-and-publish loop sounds like the kind of partner you want — rather than the kind you have to police — that is the workshop we built for.
- Read more about the underlying philosophy in our transparency architecture overview.
- See the full receipt list at six receipts.
- Read the limits in plain language at what we do not claim.
- Want a walk-through of the audit applied to your own stack? Start at the workshop.