The Receipt

Technical reference · April 2026

TL;DR

What it isA content-addressed, tamper-evident record of a single verification or execution event, written to the context graph on every push.

Two typesVerification receipts record what was evaluated and what the determination was. Execution receipts record what built, tested, or deployed.

The bridgeFile nodes appear in both receipt types: the bridge between what was verified and what shipped, and the basis of every provenance query.

Tamper-evidentEach receipt’s identity is its SHA-256 hash. It cannot be revised. The receipt you query today is the receipt written at the moment the event occurred.

The Two Receipt Types

Every event in the pipeline produces a receipt

When a requirement is evaluated against code, a verification receipt is produced: a structured record of what was evaluated, what the determination was, and which files were involved. When a build, test, or deploy runs, an execution receipt is produced: a record of what ran, what it consumed, and what it produced. Both are written to the context graph on every push.

Verification Receipt

A requirement was evaluated against code

Produced on every spec-to-code evaluation. Records the requirement, the seam query, the determination, and the files evaluated.

determination · conforms / does-not-conform

spec_file + spec_section

requirement_text

query · the seam query executed

inputs[] · code files evaluated

Execution Receipt

A build, test, or deploy ran and was observed

Produced on every pipeline execution event. Records what ran, what was consumed, and what was produced.

type · build / test / deploy

inputs[] · path + content hash

outputs[] · path + content hash

parent_ids[] · execution chain

exit_code + command_line

Content Addressing

The receipt cannot be revised after the fact

Each receipt’s identity is its SHA-256 hash, derived from the canonical form of its fields. Any modification to a hashed field produces a different receipt with a different id. The graph holds the original. There is no amendment path.

Hashed fields are locked into the receipt’s identity at write time. Non-hashed fields such as start_time and duration_ms are preserved alongside the receipt as metadata but do not affect its identity. A receipt written with a given determination will always carry that determination when queried, regardless of what happened in subsequent pushes.

Verification Receipt

What is recorded on every requirement evaluation

Canonical form · verification receipt

{
  "schema_version":              "1.0.0",
  "type":                        "verify-code-generation",
  "commit":                      "a3f8c1d",
  "repo":                        "idora",
  "determination":              "does-not-conform",
  "spec_section":               "§auth.rotation",
  "spec_file":                  "specs/gates/AUTH_SPEC.md",
  "lines":                       [142, 158],
  "requirement_text":           "token rotation every 24h · no static keys in production",
  "implementation_description": "no rotation logic found · static keys present",
  "query":                       "Does auth.service.ts conform to §auth.rotation? Verify rotation interval and key hygiene.",
  "inputs": [
    {{ "path": "src/services/auth.service.ts" }},
    {{ "path": "tests/auth.test.ts" }}
  ]
}
// Metadata sidecar · not part of receipt identity
{{ "start_time": "2026-03-27T14:30:00Z", "duration_ms": 45000 }}

Field	In hash	Notes
schema_version	yes	Always `1.0.0`
type	yes	`verify-code-generation` or `verify-test`
commit	yes	Explicit SHA at the time of evaluation
determination	yes	`conforms` · `does-not-conform` · `indeterminate`. Indeterminate is not an unknown. It carries a structured reason: missing specification, missing code, missing test, ambiguous specification, or runtime dependency. Each reason points to a specific resolution path.
spec_file	yes	Path to the governing spec. Becomes a File node in the graph.
spec_section	yes	Section identifier. Linked to the governing Seam node in the graph. A MAPS_TO edge connects the Seam to each evaluated file and accumulates a verification count on every subsequent receipt. This is the compounding mechanism. See The Compounding Moat.
lines	yes	Start and end line numbers of the spec lines this seam covers. Supplements `spec_section` and `query` as the three-field seam targeting contract.
requirement_text	yes	The exact requirement evaluated
implementation_description	yes	Structured finding: what the code does or fails to do relative to the requirement, as evaluated at this commit
query	yes	The seam verification query as executed: sections, conditions, governance references, and concrete values in one string. Used for audit and for warm routing on subsequent pushes.
inputs[]	yes	Code files evaluated. Path only. Each becomes a File node with CONSUMED, EVALUATED, and MAPS_TO edges.
start_time · duration_ms	no	Metadata sidecar only

Execution Receipt

What is recorded on every build, test, and deploy

Canonical form · execution receipt

{
  "schema_version": "1.0.0",
  "type":           "build",
  "commit":         "a3f8c1d",
  "repo":           "idora",
  "exit_code":      0,
  "command_line":   "dotnet build src/Idora.Pipeline.csproj -c Release",
  "inputs": [
    {{ "path": "src/services/auth.service.ts", "hash": "a1b2c3d4..." }},
    {{ "path": "src/services/payments.ts",      "hash": "f6e5d4c3..." }}
  ],
  "outputs": [
    {{ "path": "bin/Release/api-server.so", "hash": "9f8e7d6c..." }}
  ],
  "parent_ids": []
}
// Metadata sidecar · not part of receipt identity
{{ "start_time": "2026-03-27T15:00:00Z", "duration_ms": 150000 }}

Field	In hash	Notes
type	yes	`build` · `test` · `deploy`
commit	yes	Explicit SHA at the time of execution
exit_code	yes	Nullable. Process may not terminate normally.
command_line	yes	Full command as executed
inputs[]	yes	`{path, hash}` pairs. Each creates a File node (path identity) and an Artifact node (content hash).
outputs[]	yes	`{path, hash}` pairs. Each creates an Artifact node with a PRODUCED edge. No File nodes from outputs.
parent_ids[]	yes	Receipt IDs from earlier in the same session. Creates PARENT_OF edges establishing the build to test to deploy chain.
start_time · duration_ms	no	Metadata sidecar only

The File Bridge

Two receipt types. One shared node. One provenance claim.

Verification receipts evaluate files. Execution receipts consume files. The same File node appears in both streams at the same commit. This shared identity is what makes the provenance claim queryable in a single graph traversal.

Provenance · single commit · auth.service.ts

Verification stream

verification§auth.rotation · does-not-conform
key rotation test missing

verification§auth.rotation · conforms
next push after fix

→EVALUATED

File node

auth.service.ts

CONSUMED→

Execution stream

build · sha:b8f2e1exit 0 · 7 inputs consumed

deploy · sha:f1d9e2api-server.so · sha:9f8e7d

→The same file that was verified against §auth.rotation was consumed by the build at the same commit. One hop in the graph proves it.

→The artifact the build produced is the artifact the deploy shipped. Content hash identity proves the chain is unbroken.

→Both claims are queryable together in a single traversal from any commit SHA.

Receipts accumulate across schema versions. A receipt written as 1.0.0 retains its original schema version when queried. The graph is append-only. Nothing written by a prior push can be altered by a later one. A third receipt type records requirement ingestion, connecting the seam graph to the provenance chain. See Idora Context Graph.

The receipt is the primitive that makes the integrity layer possible. Without tamper-evident, content-addressed records at every step, the provenance claim is a reconstruction. With them, it is a proof.