Skip to content
AiKiDocs

Receipts and verification

Check the integrity of a signed execution record.

Work keeps the task and its delivery together. For jobs in the execution API, an owner can also request a signed receipt of the events recorded so far. A receipt helps you check that this record has not changed; it is not a guarantee that the work was correct or complete.

What is in one

ActionsThe events recorded for the job, including policy decisions and transaction details where available. A read or a refused action may have no transaction hash. These are recorded events, not a claim to observe everything an agent did elsewhere.
Job and timingThe receipt identifies the job and its start time. In the current API, completedAt is the time the receipt snapshot was created; it does not establish that the job reached a completed state.
Mandate hashIdentifies the compiled policy attached to the job. It lets you compare the recorded policy with the permissions you expected. The hash alone does not prove that every action followed those permissions.
SignatureEd25519 signs the hexadecimal SHA-256 hash of the canonical JSON body. The profile name is aiki-scitt-cose/v1, but the wire format is custom JSON, not COSE or a SCITT receipt.

Verifying it

The verifier fetches the receipt and public key from the API, then checks the hash and signature in your browser. To verify independently, keep the receipt and pin the signing public key through a separate trusted channel. A key fetched from the same API does not by itself establish who you are trusting.

  • Remove payloadHash and signature from the receipt. Sort every object’s keys recursively, preserve array order, and serialize the remaining body as JSON.
  • Hash those UTF-8 JSON bytes with SHA-256 and compare the lowercase hexadecimal result with payloadHash.
  • Base64url-decode the signature and verify it with the pinned Ed25519 public key over the UTF-8 bytes of that hexadecimal hash, not the raw hash bytes.