The verified execution record — proving what an agent actually did

Every job produces a Verified Execution Record (pkg/ver): a per-job account of what actually ran, attested by the daemon that ran it, counter-signed by the Control Plane, and chained to the org's previous record.

It exists because of where the work happens. The daemon runs the Actor–Critic loop in its own process — nothing else observes it — so without the daemon saying what it did, there is no evidence at all. In BYOC the daemon's signing key never leaves your cloud, which means the execution half of every record is attested by something the Control Plane does not hold.

What is in a record

Section	Holds
intent	the task as submitted, its source, who submitted it and when, the idempotency key
governing_spec	the plan's manifest hash and summary, the planner model and its provider, and whether prior-job context was used
subject	repo, ref, base and head commit, the files touched
execution	fleet, execution mode, daemon id and public key, sandbox runtime and network, and one attestation per worker
verification	the guard command, its final outcome, a hash of its output, and how long it took
delivery	the PR URL and when it opened

Each worker attestation carries its Actor and Critic model, the provider they routed to, every step of the loop with its phase and outcome, how many times the Critic rejected an edit, and the tokens and cost it consumed.

What it deliberately does not contain

• No raw output. Detail is stored as a SHA-256 digest, because test output routinely carries secrets. The one exception is the Critic's own prose, which is model-authored review text rather than captured program output — and it is quoted briefly and cut on a rune boundary.
• Nothing invented. A fact the assembler was not given serializes as unknown, never a plausible-looking default. That matters most for execution mode, which is exactly the managed-versus-BYOC distinction that decides whether zero-knowledge holds — a record that guesses is worse than one that admits a gap, because a signature makes every field read as attested fact.

Signing and the chain

A record carries up to two signatures, and both are Ed25519:

• exec_signature — the daemon's attestation over what it executed, made with the same key it generates on boot.
• record_signature — the Control Plane's counter-signature over the whole record.

Signing, hashing and verification all operate on one canonical form: the record with both signature fields cleared, serialized per RFC 8785 (JSON Canonicalization Scheme). Attaching a signature therefore cannot change what was signed or what was chained, and the hash a verifier recomputes always matches the one that went into the chain.

Records are hash-chained per org: each carries the prev_record_hash of its predecessor, read under a row lock inside the same transaction that inserts it, so two concurrent jobs in one org cannot derive the same predecessor. A dropped record is indistinguishable from tampering — which is the property that makes the chain worth having.

:::note An unsigned record is an honest one Signing requires a configured Control Plane key (KIWI_VER_SIGNING_KEY). Without one, records persist with attestation: "unsigned" and the published key set is empty. Kiwi deliberately does not generate a key on the fly: an ephemeral key would differ per replica and make every record unverifiable after a restart, so the signature would assert an authenticity nothing could check. :::

Merge provenance

The approver of a pull request is not known until after the record is signed, and a sealed record is never mutated. So a merge arrives as a new link in the same chain — a kiwi.ver/merge/v1 record capturing who approved the merge, the merge commit, and when — rather than an edit to the original. It goes through the same canonicalization, signing and verification path as the execution record; there is exactly one signing discipline, so a future record kind cannot quietly adopt a second one.

Merge records are appended by a GitHub webhook, which requires a configured secret and fails closed without one.

Reading a record

# The record for a job, with its chain link in a response header.
curl -sD- -H "Authorization: Bearer $KIWI_TOKEN" \
  https://api.runkiwi.dev/api/v1/jobs/<job-id>/record

# The public keys a verifier needs.
curl -s https://api.runkiwi.dev/.well-known/kiwi-signing-keys.json

X-Kiwi-Record-Hash returns the chain link so a caller can check continuity without re-canonicalizing the document. The signing keys are published as a JWKS-shaped key set (OKP / Ed25519 / EdDSA), so verification does not depend on Kiwi being reachable at the time you check.

Lookups are org-scoped: another tenant's job id is indistinguishable from one that does not exist, since a 403 would confirm the record is there.

In the dashboard, the record surfaces in the task drawer as a verified receipt panel showing the record hash. The receipt says what it observes — that the tests confirm the change did not break the suite — rather than claiming the change does what was asked, which no test can attest.