§ Standards — Decision Receipt Specification

A receipt for every machine-generated decision.

A Decision Receipt is a machine-verifiable evidence package proving that a decision was produced under known conditions — with traceable evidence, declared policy, reproducible verification, and auditable provenance. This page summarizes the specification; the full normative text is published openly under CC BY 4.0.

Read the full specification ↗Verify a Receipt ↗

§ 01

The five questions every receipt answers

Machine-generated decisions increasingly influence operations, procurement, compliance, healthcare, defense, and financial services. Most AI systems cannot answer the questions an auditor will ask. A conforming Decision Receipt answers all five.

Question 1

Why?

Why was this decision made — what reasoning and policy context produced it?

Question 2

What evidence?

What evidence supported it, and does each artifact carry an integrity hash?

Question 3

Reproducible?

Can the decision be reproduced from its recorded inputs — deterministically?

Question 4

Policy followed?

Was declared policy evaluated, and are the results logged independently?

Question 5

Accountable?

Who — or what process — is accountable, and is the attestation signed?

§ 02

Receipt structure

Every conforming receipt is an evidence bundle. Three components are mandatory; supply-chain artifacts extend the bundle for higher assurance levels.

Component	File	Purpose
ReportREQUIRED	report.json	What happened, what changed, what was decided
MetricsREQUIRED	metrics.json	Quantitative evaluation results
StampREQUIRED	stamp.json	Integrity hashes and generation metadata
SBOMOPTIONAL	sbom.spdx.json	Software bill of materials
ProvenanceOPTIONAL	provenance.intoto.jsonl	Supply-chain provenance
Policy logOPTIONAL	policy_decisions.jsonl	Policy evaluation results

SUM-RCPT-v1-vendor-risk-assessment.42ADMIT

decision: vendor-risk-assessment.42
evidence: SUM-EVID-v1-…-a41f09c27be3d8e1
sources: 3 artifacts · sha256 verified
policy: policy_decisions.jsonl · 0 violations
replay: deterministic · seed 1337 · pass
stamp: artifact hashes match · valid
signature: ed25519 · trusted generator

fig. 1 — a worked example, rendered from the bundle.

§ 03

Deterministic Evidence IDs

The Evidence ID is the spine of the receipt: a stable, deterministic identifier any party can recompute from the same inputs. Same inputs, same ID — every time, on any machine.

SUM-EVID-v1-{repo}-{pr_or_run}-{workstream}-{artifact_kind}-{sha256_16}

The hash suffix is computed over a canonical JSON input — repository, git commit, run identifier, workstream, artifact kind, policy version, and the hashes of the evaluation dataset and input bundle — serialized with sorted keys, no whitespace, UTF-8.

Determinism rules — the following MUST NOT enter ID computation

wall-clock timestampshostnames or IP addressesrandom UUIDsprocess IDsmutable environment variables

§ 04

Validation

A receipt is valid if and only if every condition below holds. There is no partial credit — a hash mismatch anywhere fails the whole bundle.

01All required files exist: report.json, metrics.json, stamp.json
02Schema versions match expected constants
03Evidence IDs are present and consistent across all three files
04The report references metrics.json for evaluation and regression results
05All required documentation categories are marked as updated
06Metrics are deterministic and passing against declared thresholds
07Stamp artifact hashes match the actual SHA-256 hashes of the files
08No wall-clock data entered the Evidence ID computation

For merge-blocking evidence, metrics MUST be deterministic. Model-graded metrics are advisory unless replay-stamped.

§ 05

Trust model

The specification assumes the agent that produced a decision is not a trustworthy witness to its own conduct. Trust is established structurally.

11.1

Generation trust

Receipts MUST be generated by a trusted process — a CI system — not by the agent that produced the decision. Self-attestation is not valid.

11.2

Verification trust

Any party with access to the inputs can independently verify Evidence ID reproducibility, artifact hash integrity, and metrics threshold compliance — no trust in the issuer required.

11.3

Replay trust

A valid receipt implies the decision can be reproduced from the recorded git commit, the policy version, the evaluation dataset, and the input bundle.

§ 06

Conformance

Implementing the spec does not require Summit software. An implementation conforms if it meets five obligations — all of them testable.

§ 6: Generates valid, deterministic Evidence IDs
§ 5: Produces complete evidence bundles (report, metrics, stamp)
§ 10: Passes all eight validation rules
§ 11: Respects the trust model — no self-attestation
§ 8.1: Enforces determinism for merge-blocking evidence

Security posture is part of conformance: evidence bundles are append-only, timestamps appear only in the stamp, policy decisions are logged independently, cross-tenant evidence isolation is mandatory, and sensitive path access is denied by default.

Implement it. We mean that literally.

The specification is CC BY 4.0 — free to implement, including by competitors. If your vendor claims conformance, the validation rules above tell you exactly what to check.

Full spec on GitHub Certification tiers