Skip to content

Read a receipt

A receipt is the durable record of one Themis run.

It should let another person answer these questions:

  • What release did Themis check?
  • What exact dataset did it use?
  • Which cases ran?
  • Did the candidate match the oracle?
  • What DataHub signals were present or missing?
  • Which runtime traces link to the run?
  • Why did policy return the decision?

Read the receipt in order

1. Identity

Confirm the release ID, run time, policy version, and dataset identity.

If the dataset identity is different from the expected manifest, stop. Do not compare the result with a receipt from another snapshot.

2. Decision

Read the decision and the policy reason. Do not infer a decision from the number of green cards.

3. Replay and oracle

Check the selected case count and passed case count. Check the candidate result against the independent oracle. A SQL query can execute successfully and still fail the expected behavior.

4. DataHub evidence

Read schema, ownership, lineage, quality, lifecycle, and context evidence. available: false or a missing signal is useful information. It means the receipt does not prove that fact.

5. OpenTelemetry evidence

Trace IDs and span IDs must come from the OpenTelemetry SDK. They let an operator inspect runtime work in a trace backend. They do not prove business correctness by themselves.

6. Write-back

Read the write-back state. ACK is not the same as verified read-after-write. The receipt must say what the API actually returned.

Redaction rules

Receipts may contain IDs, hashes, bounded timings, and policy reasons. They must not contain:

  • provider API keys;
  • bearer tokens;
  • raw passwords;
  • private request headers;
  • unrestricted raw result rows;
  • a claim that a provider ran when it did not run.

The receipt is an audit artifact. Keep it small enough to inspect and safe enough to share.