in-toto Predicate: OCG Execution Receipt (v0.2, DRAFT)

Status: Draft proposal, published at this URL 2026-11-06 so predicateType resolves. v0.2 is additive over the v0.1 predicate: every v0.1 field is carried unchanged and every v0.1 Statement is a valid v0.2 Statement. Not submitted to the in-toto community, the in-toto/attestation repository, or any external registry; no claim that any AINumbers node emits this predicate in production; it is a proposed export shape only.

predicateType: https://ainumbers.co/attestations/ocg-execution-receipt/v0.2

schema.json (JSON Schema draft 2020-12, predicate body) example.json (golden Statement v1, from a real node run) v0.1 (untouched)

Reading these fields against actual regulator clauses: the audit-trail field crosswalk maps the v0.1 receipt fields, row by row, to EU AI Act Article 12, PCI DSS v4.0.1 Requirement 10, and the SOX internal-control and records clauses.

1. Purpose

Compliance platforms and audit tooling key evidence to a control and to a source location: a GRC platform maps each artifact to control ids in a framework (NIST 800-53, SOC 2, ISO 27001, AIUC-1), and an auditor's workpaper points back to the document and page the evidence came from. The v0.1 predicate carries neither. v0.2 adds optional members for exactly that binding, so an OCG receipt can sit inside a control library or a workpaper without a bespoke side table. Everything v0.1 defined is unchanged: v0.2 only adds optional members, which is what makes every v0.1 Statement a valid v0.2 Statement.

2. Statement envelope

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "<mandate_type>/<tool_id>",
      "digest": { "sha256": "<execution hash, hex, no sha256: prefix>" } },
    { "name": "<mandate_type>/<tool_id>.receipt.json",
      "digest": { "sha256": "<receipt document bytes, hex, no sha256: prefix>" } }
  ],
  "predicateType": "https://ainumbers.co/attestations/ocg-execution-receipt/v0.2",
  "predicate": { }
}

subject[0].digest.sha256 is the OCG artifact's execution_hash (SPEC.md §4): SHA-256 over the JCS-canonical {policy_parameters, output_payload} pair. That value is a replay identity over the recorded inputs: hashing the bytes of example.json, or of any other shipped file, yields a different number, so a generic in-toto verifier finds no file it matches. A verifier recomputes it by re-running the kernel with the recorded inputs.
subject[1].digest.sha256 is the byte-level complement: the SHA-256 of the receipt document this Statement is about (the OCG v0.4 receipt object), serialized as compact JSON with recursively sorted object keys, with generated_at pinned. A tool that exports the receipt file can verify this subject by hashing those bytes.
predicate carries the v0.1 field set plus the v0.2 members in section 3.

3. What v0.2 adds over v0.1

All four members are OPTIONAL. The v0.1 members (chaingraphVersion through anchorBindings, table in the v0.1 page) keep their names, sources and meanings unchanged.

Member	Shape	Notes
`controlRefs`	array of `{ "framework": ..., "id": ... }`	`framework` is one of `nist-800-53r5`, `aiuc-1`, `nist-ai-rmf`, `soc2-tsc`, `iso27001-2022`. `id` carries the control identifier only, never a control title or control text (AICPA and ISO copyright). This is the member a GRC platform keys evidence on.
`anchors`	array of `{ "type": ..., "ref": ... }`	`type` is `sigsum` or `eas-base`. A pointer to independent anchoring or transparency-log evidence for this receipt, complementing the v0.1 `anchorBindings` passthrough.
`sourceAnchor`	`{ "documentDigest": ..., "locator": ... }`	`documentDigest` is the SHA-256 of the human-source document, bare lowercase hex. `locator` is a page or region reference, or a spreadsheet cell in `sheet!cell` form. This is the workpaper's "where did this evidence come from" line.
`tickmark`	one of `agreed`, `footed`, `recalculated`, `vouched`, `traced`, `exception`	The audit workpaper action a human reviewer recorded against this receipt. A tickmark describes a person's procedure; it is never, on its own, evidence that a control passed.

The schema.json constrains the members this version mints strictly (closed objects, closed enums) and leaves the v0.1 passthrough members permissive, the same posture v0.1 takes toward the OCG envelope: unknown members are allowed and passed through unvalidated, so the schema cannot reject a legitimate future extension of the source artifact.

4. The golden example and how it was produced

example.json comes straight from a real run of the art-304-aiuc1-evidence-pack-assembler node (its "full-receipt-backed-pack-oscal-golden" fixture vector, the first in chaingraph/kernels/fixtures/art-304-aiuc1-evidence-pack-assembler.fixtures.json), with the hash computed by the estate's shared executionHash() canonicalization code:

Re-running the node's compute() on the vector's policy_parameters replays the fixture's output_payload exactly.
executionHash(policy_parameters, output_payload) returns 6dc36ff96075fde1830bbea4ecbe3bb7896a268e423b68c5354eb72203d18fef, the vector's pinned golden_hash. That value is subject[0].digest.sha256 and predicate.executionHash.
The receipt document digest (subject[1].digest.sha256) is f9ee4dfe6f59eb6aacfcee1d7a3de7ae7da6984523c1b7a1f205d21f06843376, over the buildArtifact() output with generated_at pinned to 2026-11-06T00:00:00.000Z.
predicate.sourceAnchor.documentDigest is 7805c28c612b9daf261960b074b0719eb95986ba35d409e3163aa23c2ccf7c7d, the SHA-256 of the fixture file itself, with the vector named in the locator.
controlRefs carries the vector's AIUC-1 control ids: AIUC-A-01, AIUC-B-01, AIUC-E-01.
tickmark is recalculated, which is literally what produced this file.

Members the golden omits, on purpose: anchors, kernelIdentity, auditSignature and anchorBindings are all absent because that run produced none of them (it is unsigned and unanchored). A v0.2 Statement with those members present is valid; this one carries no such claims.

5. Honest boundary of the v0.2 members

The v0.1 layered-assurance model carries over unchanged: the execution hash alone asserts replayability of outputPayload from policyParameters, and kernelIdentity, computeProof, auditSignature and anchorBindings assert more only when present. The v0.2 members stay inside that boundary: controlRefs records that a publisher cited this receipt against those control ids, a citation that leaves the controls' satisfaction and certification untouched; tickmark records a human workpaper action (agreed, traced, recalculated and so on), which is an annotation about a person's procedure; and sourceAnchor and anchors locate where a document or a log entry lives, leaving what that document says for the reader to check.

6. Scope of this draft

This draft ships a spec and proposal artifact only: no runtime code, no verifier implementation, no CLI, and no submission to the in-toto community, in-toto/attestation, or any public registry, which remains a separate, explicitly-flagged decision. Its change footprint is one folder beside v0.1; the v0.1 predicate, the OCG canonical artifact, and every node are left exactly as they are.