Skip to main content
Version: MVP

Receipts

5 min readCore conceptUpdated 2026-05-19

What you'll learn

  • What a capability receipt is, and what kinds of actions produce one.
  • The fields every receipt carries and how they bind to operator + credential identity.
  • How redaction keeps secrets out of the receipt store.
  • How to query receipts by task, policy envelope, or handoff.

Capability receipt

A concise, durable accountability record for an action that mattered. Every receipt names who acted, what they used, what they touched, why it happened, and how it ended — bound to both an operator identity and a credential identity.

Receipts are not full transcripts. They're the short, queryable record the next agent, the next operator, and the next auditor can ground their decisions on.

The contract​

craik.capability_receipt is one of the few public contracts Craik guarantees across versions. Its shape:

Field
Type
Purpose
id
id
Stable id, prefixed rcpt_. Used to join across tasks, handoffs, and policy.
actor
operator_uri
OIDC operator identity that initiated the action.
credential
credential_uri
Credential profile or pool member used. Bound at runtime.
task_id
id
The task this action belongs to. First-class field.
capability
capability_name
Which capability grant authorized the action — e.g., provider.call, fs.write.
target
uri
What the action affected. A file path, provider endpoint, memory scope, etc.
reason
text
The short, human-readable justification.
policy_envelope_id
id (in metadata)
The policy that gated the action. Carried in result.metadata.policy_envelope_id.
handoff_ids
id[] (in metadata)
Handoffs that reference this receipt. Carried in result.metadata.handoff_ids.
fail_open
bool
true if the run took a fail-open path; receipts are still written so the choice is auditable.
result
result
Redacted summary — ok / error, redacted payload references, and metadata. Never raw secrets.
sealed_at
timestamp
Wall-clock time the receipt was sealed and persisted.

What produces a receipt​

Today's MVP writes receipts when the runtime is the direct actor: provider calls, credential use, memory writes, policy decisions, and certain runtime side-effect wrappers. Tool execution that lives outside the runtime (an arbitrary shell command the agent runs) does not yet auto-emit a receipt — that work is on the roadmap as side-effect wrappers extend.

If you need every shell command to be receipted today, route it through the side-effect wrappers documented in Side-effect wrappers.

Redaction is non-negotiable​

Receipts may not contain raw secrets or credentials. Local persistence validates every stored receipt through the central redaction guard and rejects payloads that still appear to contain unredacted secret material.

In practice that means receipt authors should:

  • Use redacted summaries (status: ok, tokens: 1842) instead of raw request/response payloads.
  • Pass file paths and content hashes in metadata, not file content.
  • Reference credentials by profile URI, never by the secret itself.
  • Strip credential-bearing URLs in metadata (?token=…) before sealing.

See Redaction for the full ruleset and how to extend the guard for new redaction patterns.

Query receipts​

List all receipts
craik receipts list
Filter by linkage
craik receipts list --task-id task_docs_reconcile
craik receipts list --policy-id policy_docs_reconcile
craik receipts list --handoff-id handoff_docs_reconcile
Inspect one receipt as JSON
craik receipts show rcpt_pytest

Both list and show print JSON payloads matching the craik.capability_receipt schema. Pipe to jq for ergonomic filtering.

An example receipt​

rcpt_4f1c · provider call
{
  "id": "rcpt_4f1c",
  "actor": "oidc://acme.okta.com#alice",
  "credential": "pool:openai-prod#k_77a",
  "task_id": "task_review_docs",
  "capability": "provider.call",
  "target": "anthropic.messages",
  "reason": "Compile migration plan for task_review_docs",
  "fail_open": false,
  "result": {
    "status": "ok",
    "model": "claude-opus-4-7",
    "tokens": 1842,
    "metadata": {
      "policy_envelope_id": "policy_review_docs",
      "handoff_ids": ["handoff_review_docs"],
      "evidence_refs": ["adr/0042", "pr/1188"]
    }
  },
  "sealed_at": "2026-05-19T14:08:21Z"
}

Current scope​

The receipt store and query commands are implemented end-to-end. Automatic receipt-producing wrappers for shell commands, file writes, GitHub writes, case-file builds, and handoffs are in progress — see Roadmap for the current state.

What's next​

Read nextHandoffsHow a run ends and how the next agent picks up.ReadGovernancePolicy envelopes, capability grants, and the gates that decide which receipts even get a chance to be written.ReferenceRedactionThe redaction guard, its patterns, and how to extend it.