Receipts
Every file on this page came out of a real Kontour build — not a sample written for a marketing page. Open one and read what the agent claimed, what actually ran, and what it got refused for. Then download it and re-check the verdict with one command. If our copy disagrees with the file, the file wins.
These all came out of Kontour's own pipelines. That shows the format is real and the checks run — it doesn't show that another team has adopted it. We haven't published an outside team's receipt yet; when we do, it will be on this page.
First time here?
Your agent finishes and reports back: tests pass, reviewed, ready to merge. You have two options — take its word, or redo the work yourself. A receipt is the third option. It's the answer sheet the agent hands in alongside the work: what it claimed, what it actually ran, what it skipped, and what it got refused for. You read it in about a minute, and you can re-grade it with one command instead of trusting the grade it gave itself.
1 · What it claimed
The assertions the work makes about itself: "the build passed," "this was reviewed," "this is ready to merge." Each one is its own line, not a single summary sentence you have to take or leave.
2 · What actually ran
The results behind each claim, recorded while the commands ran — not the agent's write-up afterwards. If a claim has nothing behind it, that shows up as an empty line rather than a missing one.
3 · What it comes out to
The verdict — which isn't stored in the file. It's worked out from the evidence every time you open it, so the file can't lie about it. Edit the verdict to say "verified" and the check still returns the real one. There's a demonstration further down.
Reading one takes no tools. Checking one takes a single command, printed with every receipt below.
One receipt, end to end
This is the whole of a real receipt — the shortest one we publish, chosen because you can hold all of it in your head. It records a single question: is this working tree ready to merge? The answer was no. Every value below is read out of the file; open it and check.
What was being asked
One claim, about one thing: merge readiness — recorded as a software-readiness-verdict. Not "is the code good," a specific narrow question with a policy attached to it. The subject is the working tree's content hash (798d536c54a9d1c0…), so this receipt can't quietly be re-pointed at different code.
How much it matters
Impact high. The policy grades claims by consequence, and high means: if this one is wrong, something bad ships. High-impact claims with nothing behind them get listed out rather than passed over.
What would have counted as proof
"A verified Veritas readiness evidence event supports the readiness verdict."
Written into the file before the answer, not after. That's what makes the verdict non-negotiable: the bar is in the artifact, so you can see whether it was cleared instead of being told it was.
What actually happened
"Veritas readiness verdict is not ready (run veritas-1783001840335). Blocking: required-veritas-cli-artifacts." — recorded with passing: false by veritas-governance-kit/readiness-adapter as the check ran, not written up afterwards by whatever was doing the work. The named blocker is required-veritas-cli-artifacts: a required standard wanted certain artifacts out of the run, and didn't get them.
What was skipped
Nothing, and that's checkable. The receipt carries one claim and one evidence record, and the record points at the claim. There's no claim sitting here without support. On bigger receipts that isn't always true — and where it isn't, the receipt says so instead of leaving it out.
The answer
Verdict not-ready, claim status disputed. Not "the agent decided no." The validator reads the failing evidence, applies the written policy, and works it out. Run it yourself and you get the same two words.
What you should take from it. Something wanted to merge. A standard said no. The receipt records which standard, what it wanted, what it got, and the refusal that followed — in a file you can re-check in one command without asking us or the agent whether it's telling the truth. Everything else on this site is this, at larger volumes.
What it doesn't tell you. Whether the code is correct. Whether the standard was the right standard. Whether someone rewrote the evidence before publishing — the pinned commit on each receipt is what lets you check that separately. A receipt narrows what you have to take on faith; it doesn't get it to zero.
This one is the Governance Kit's committed not-ready readiness record run through its adapter — the real refusal shape in the real format, not a live delivery stopped mid-run. We haven't published a receipt from a live blocked delivery yet.
Don't take our word for it
The verdict isn't stored in the receipt — it's recomputed from the evidence every time. So editing it does nothing. Download the blocked receipt above, open it in any editor, change every"status": "disputed" to"status": "verified", save, and re-run the check:
Same refusal. You can go further and delete the status field altogether — it isn't part of the format's required shape — and the answer still comes back disputed. To turn this receipt green you'd have to produce a passing check, which is the point.
What this doesn't protect against: someone rewriting the evidence records themselves before publishing. That's why every receipt here pins the commit it came from. The artifact is tamper-evident against edits after the fact, not unforgeable at the source.
Recompute, don't trust
Every bundle here is a Hachure trust.bundle — an open format we publish the schemas for but don't own the definition of. Download one and run it through @kontourai/surface, our implementation. A valid bundle prints its trust summary and exits 0; a malformed one exits non-zero.
Don't take one implementation's word for it either. Every bundle here also passes the separate hachure reference CLI — a different codebase reading the same file against the spec's own schemas: two implementations, same verdict. CI runs both on every published bundle, so this can't quietly go stale. Both are still maintained by us — the implementations are independent, the organization behind them isn't yet.
Each receipt page repeats the exact command for its own file and links the commit it came from, so you can trace the artifact back to the run that produced it.
The archive
Status counts are what the validator works out from each file, not what the file stores. Run the command on the card and you get the same numbers back.
Kontour Flow Agents — delivery workflow
The trust.bundle a Flow Agents delivery run emits as its own receipt: every workflow check (build, source-tree validation, verification) recorded as a claim with its evidence and status.
Check it yourself
npx @kontourai/[email protected] report --input flow-agents-delivery.trust.bundle --format summaryKontour Veritas Governance Kit — readiness adapter
A Veritas Governance Kit readiness evaluation with no blocking failures, projected into a Hachure trust.bundle whose software-readiness-verdict claim derives to verified.
Check it yourself
npx @kontourai/[email protected] report --input governance-readiness-ready.trust.bundle --format summaryKontour Veritas Governance Kit — readiness adapter
A readiness evaluation that a required standard blocks: the projected software-readiness-verdict claim derives to disputed, showing what a gate looks like when it refuses to pass.
Check it yourself
npx @kontourai/[email protected] report --input governance-readiness-not-ready.trust.bundle --format summaryKontour Flow Agents — ensure-session ownership guard
A Flow Agents workflow run's own receipt for its ensure-session ownership guard: two agents claiming the same work item are kept from colliding, recorded as claims with their evidence — including one pre-existing, unrelated test-suite gap the run discloses and waives rather than hides.
Check it yourself
npx @kontourai/[email protected] report --input flow-agents-ownership-guard.trust.bundle --format summaryNext
Receipts come out of Flow Agents — the gates that run inside your agent's loop and emit one of these at the end of every delivery. They refuse or escalate to you; they never quietly proceed.