GUIDE

Verifying receipts

A Decision Receipt is only useful if you can check that it has not been altered and that the server that issued it actually signed it. This guide shows you how to verify a receipt online with POST /v1/verify, and how to verify its signature independently — offline, without trusting Summit's API.

Online verification

The simplest way to verify a receipt is to send it back to the API. Take the receipt object returned by POST /v1/evaluate, save it as a file, and POST it to /v1/verify. This endpoint requires no authentication — anyone holding a receipt can check it.

REQUEST

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

The response reports an overall verdict and the individual checks that produced it:

RESPONSE

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

The valid field is true only when every check passes. Treat it as a single gate: if it is false, the receipt has failed at least one check and should not be trusted, regardless of how the other fields look. The receipt_id echoes the receipt under test, admissibility reports its recorded status (ACCEPTED, NON_DETERMINISTIC, or REJECTED), and verification_depth is "cryptographic" — meaning the check went all the way to signature validation, not just a structural inspection.

The three verification layers

Verification proceeds in three layers, each stricter than the last. The checks[] array maps onto them.

• Schema presence. The required fields exist and are well-formed. This is what receipt_id_valid, admissibility_present, replay_present, policy_present, evidence_present, and attestation_present assert. A receipt missing any of these is structurally incomplete and cannot be evidence of anything.
• Hash integrity. The receipt's canonical hash is recomputed from its contents and matched against the value recorded in the ledger. This is the hash_integrity check. If a single field were altered after issuance, the recomputed hash would no longer match, and this check would fail.
• Signature verification. The Ed25519 attestation on the receipt is validated against the server's public key. This is the signature_valid check — it confirms the receipt was signed by the issuing server and not forged or re-signed by anyone else.

A receipt that clears all three layers is present, unaltered, and authentically signed. That is the full meaning of verification_depth: "cryptographic".

Offline, independent verification

Sending a receipt back to /v1/verify is convenient, but it asks you to trust the same service that issued the receipt. For a tamper-evident record, that is the wrong trust boundary. The point of an Ed25519 signature is that anyone can verify it with the public key alone — no live API, no trust in Summit required.

Fetch the server's Ed25519 public key, in PEM format, from GET /v1/keys/server:

REQUEST

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

RESPONSE

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEA...
-----END PUBLIC KEY-----

With that key, a third party can validate a receipt's attestations[] signature using any standard Ed25519 library, entirely offline. The receipt carries the signer, the algorithm (Ed25519), the signature, and the signed timestamp; the PEM file supplies the public half of the keypair. Nothing in that chain depends on Summit being reachable, or honest, at verification time.

Why independent verifiability matters

A receipt that only its issuer can verify is just a claim — "trust us, this was fine." It carries no more weight than a log line. What turns a receipt into evidence is that a skeptical third party can confirm it without your cooperation: recompute the hash, check the signature against a published key, and reach the same conclusion you did. Independent verifiability is the property that lets a receipt survive an adversarial reviewer, an audit, or a dispute months after the fact.

This is also why the public key is published rather than held privately. A signature you cannot check is decorative. By exposing the key at /v1/keys/server, the API makes every receipt independently checkable by design — which is the entire point of issuing a signed, hash-chained record in the first place.

For the conceptual grounding behind what a receipt captures and why it is structured this way, see the Decision Receipt concept page.