TUTORIAL

Verify a receipt you were given

A vendor, an agent, or another team hands you a Decision Receipt and says the action behind it was checked. This tutorial walks you through confirming that the receipt is genuine and admissible on your own terms — so you trust the math, not the messenger.

By the end you will have run a one-line online check, fetched the issuer's public key for an independent check, and worked through a short checklist of what to actually verify before you rely on a receipt. Everything here uses the live, public Decision Receipt API at https://decrec.summitcognitive.ai.

1. What you have

A Decision Receipt is a JSON object. You may have received it as a file, pasted into a ticket, or attached to a pull request. Whatever the wrapper, the shape is the same — a record of one evaluated action, with its evidence, policy result, replay result, and an Ed25519 attestation:

receipt.json (abridged)

{
  "receipt_id": "dr-...",
  "admissibility": { "status": "ACCEPTED" },
  "subject": { "agent": "claude-code", "repository": "acme-corp/widget-api", "pull_request": 42 },
  "evidence": { "source_count": 2, "source_types": ["ci", "code_review"] },
  "replay": { "deterministic": true, "replay_hash": "sha256:..." },
  "policy": { "status": "PASS", "checks": [] },
  "attestations": [
    { "signer": "decrec-server", "algorithm": "Ed25519", "signature": "base64...", "timestamp": "..." }
  ],
  "chain": { "sequence": 1, "previous_receipt_hash": null }
}

You do not need to understand every field to verify it. For the full breakdown of each section, see the Decision Receipt anatomy. Save what you were given as receipt.json and continue.

2. Quick online check

The fastest way to test a receipt is to ask the issuer to re-verify it. POST /v1/verify takes the full receipt as its request body and requires no API key — anyone can call it.

REQUEST

curl -s https://decrec.summitcognitive.ai/v1/verify \
  -H "Content-Type: application/json" \
  -d @receipt.json | jq .

RESPONSE

{
  "valid": true,
  "receipt_id": "dr-...",
  "admissibility": "ACCEPTED",
  "verification_depth": "cryptographic",
  "checks": [
    { "name": "hash_integrity", "status": "PASS", "detail": "Hash abc123... matches ledger" },
    { "name": "signature_valid", "status": "PASS", "detail": "Ed25519 verified" }
  ]
}

Read the response carefully:

• valid is true only when every check passes. A single failure flips it to false.
• admissibility echoes the receipt's status — you want ACCEPTED.
• verification_depth of "cryptographic" means this was not a shape-only check: the canonical hash was recomputed and the signature was validated.
• checks[] itemizes the work. The two that matter most are hash_integrity (the receipt's contents were not altered and match the issuer's ledger) and signature_valid (the Ed25519 attestation is genuine).

3. Independent, offline check

The point of a signed receipt is that you do not have to take anyone's word for it — including the server's. The attestation is an Ed25519 signature over the receipt, and the matching public key is published.

Fetch the issuer's public key once:

REQUEST

curl -s https://decrec.summitcognitive.ai/v1/keys/server > server-key.pem

The endpoint returns the server's Ed25519 public key as PEM text. Conceptually, independent verification is straightforward: take the receipt's signed content, take the signature from its attestations[] entry, and check the signature against server-key.pem using any standard Ed25519 verifier (for example, an openssl or library-based check). If the signature verifies against that key, the receipt was attested by the holder of the corresponding private key and has not been modified since.

Because the key is published separately from any single receipt, you can pin it, store it, and reuse it. Once you hold the public key, your trust rests on the cryptography — not on the party who handed you the receipt, and not on a live call to their server.

4. What to actually check before trusting

A passing signature tells you the receipt is authentic and unaltered. It does not, by itself, tell you the underlying action met your bar. Before you rely on a receipt, work through this checklist:

• Admissibility is ACCEPTED. Confirm admissibility.status is ACCEPTED — not NON_DETERMINISTIC (the action could not be shown to replay to the same result) or REJECTED. Only ACCEPTED receipts cleared the full bar.
• The policy verdict. Check policy.status is PASS, and read the verdict on the action itself — ALLOWED, ESCALATED, or BLOCKED. An escalated or blocked action may still carry a valid receipt; the receipt records the verdict, it does not override it.
• The evidence meets your bar. Look at evidence.source_count and evidence.source_types. Decide whether the number and kinds of sources (CI, code review, test results, human approval, and so on) are enough for the decision you are about to make. Two sources of one type is a weaker basis than two independent types.
• The signature verifies. The signature_valid check passed in step 2, and — for full independence — your offline check in step 3 confirmed the same against the published key.

If all four hold, you have a receipt that is authentic, admissible, and backed by evidence you have personally judged sufficient.

5. Why this matters

A receipt that only its issuer can verify is just a claim with extra formatting. The reason a Decision Receipt is worth attaching to an action is that anyone can confirm it — independently, offline, against published cryptography — without trusting the party who produced it.

That is the difference between being told an action was checked and being able to prove it yourself. When you receive a receipt from a vendor, an agent, or another team, you are not asking them to be trustworthy; you are checking a signature and a hash against a public key. The trust is in the math.

For the formal meaning of the admissibility states you checked in step 4, see Decision admissibility. To set up your own verification habit end to end, continue with Verifying receipts.