Receipts in CI: a pipeline that proves what the agent did.

The proof run

The pipeline also leaves its receipt note, zambo-receipt.md, as a job artifact on the pipeline page: pipeline, commit, ref, the step response, the closing response, and the workflow link. A reviewer who already lives on the pipeline page meets the record at the moment they are deciding whether to trust the run.

The first run failed, and the record says why

The template's first live run (pipeline 2944414222) did not produce a workflow. Its closing call was refused with HTTP 409, in the artifact, in plain text: closing an empty workflow is refused by design, and the template as first written called the close without making any step call first, even though its own header documented the step-then-close flow. The fix was small and is in the template's commit history: make the one summary call on the pipeline session first, then close, and print the workflow link in the note. The next run passed end to end. That is the point of running a template before calling it proven: the failure was public, specific, and fixable, and now the header says PROVEN with the pipeline named.

A second, unrelated failure surfaced in the same first pipeline: the kit's conformance-page check failed because its page generator let invalid test fixtures (one carries the literal timestamp "yesterday") poison the generated header date, and hardcoded a stale kit version. The generator now reads the kit version from CITATION.cff and only lets real timestamps compete for the header date. Fixed in the same evening's commits, and the check has been green since.

How it works

1. Include the template. The job lives in aer-1/ci/gitlab-ci-receipt.yml in the kit repository. Copy the job into your .gitlab-ci.yml or include the file.
2. Flip one variable. ZAMBO_RECEIPT_MINT defaults to off (artifact summary only). Set it to "true" and the job also mints through the public endpoint at https://zambo.dev/mcp. No token, no secret, no stored credential.
3. The job runs last, and cannot break your build. It is a .post job with when: always and allow_failure: true. A receipt problem is recorded in the note; it never fails the pipeline.
4. Steps, then close. Calls made with the pipeline session id (gitlab-ci- plus the pipeline id) each return an AER-1 receipt. A final workflow_close binds them into one workflow with one root digest. Extend the step list to record one call per job if you want per-job receipts instead of one summary call.
5. The record lands where reviewers already look. The note is a job artifact on the pipeline page, with the workflow link inside. An optional MR note is off by default.

Can CI check whether an agent actually ran the tests it claims?

Yes, when the test run itself goes through a receipt-issuing call. The agent runs the tests as a tool call, and the call returns an AER-1 receipt that commits to the inputs and the saved output at the moment the call ran. CI then checks the claim against the record: fetch the receipt, recompute its hash, and compare. If the saved output was edited afterwards, or the claimed result was never recorded, the check fails.

That is exactly the shape of the proof run above. The kit's own selftest, conformance, chain-vector, and cross-verify jobs ran inside pipeline 2944444147, and the same pipeline closed as workflow d4582939-a1dd-457a-b618-d2d3c3dda0b3 under root a29b4589bc31d93e4299c6182b1323f6c496601edbb489116b2f4bd56b0e546b. The test record and the run record are one checkable set, and the root was recomputed from the step receipt id alone and matched. A claim of "tests passed" that has no receipt behind it, or whose saved output no longer hashes to the receipt, does not survive that check.

The limit stays narrow: the receipt proves the saved result was not changed since it was saved. It does not prove the tests were the right tests, or that passing them makes the code correct.

What this run proves, and what it does not

The claim stays narrow on purpose. The closing root commits to the exact set of step receipts, and each receipt commits to the output saved when its call ran. Recompute and any later change to a saved output, or to the set, breaks the match. That is what the recompute above demonstrates.

Two honest limits. First, it does not grade the work: a receipt proves the record was not changed since it was saved, never that the answer was right. Second, this proof run exercised the free close: the workflow page is in its free state, unsealed. Sealing, the step that keeps the page, badge, and PDF pack permanent, is the paid Day Pass step ($0.99 at zambo.dev/day-pass/) and was exercised separately, not in this pipeline. Nothing in the run above needed a payment, a token, or a secret.

Run it on your pipeline

• Copy the pattern: the template is public at gitlab.com/rambozambodotdev/zambo, aer-1/ci/gitlab-ci-receipt.yml, header marked PROVEN with the run named.
• See one receipt first: the live demo mints the same kind of receipt for one call, no signup.
• Check a receipt by hand: the verifier walkthrough runs the checks against a real public receipt, hashes included.
• Keep a whole day of runs: a Day Pass ($0.99) raises the free limits and seals closed runs.