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

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

1. Purpose

An OpenChainGraph (OCG) artifact (SPEC.md §3) is already a self-contained, hash-anchored decision record. This predicate re-expresses that artifact as the predicate of an in-toto Statement v1, so that generic in-toto/SLSA tooling - verifiers, transparency-log ingesters, policy engines built against the in-toto ecosystem - can consume an OCG receipt without bespoke parsing. It does not replace the OCG artifact as the source of truth; it is a lossless re-expression layered on top, the same posture OCG already takes toward its other export profiles (VC, SD-JWT, PROV-DM - SPEC.md §13).

2. Statement envelope

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

• subject[0].name - "<mandate_type>/<tool_id>" from the OCG envelope (SPEC.md §3), e.g. "payment_mandate/ap2-fee-route-optimizer".
• subject[0].digest.sha256 - the OCG artifact's execution_hash (SPEC.md §4), stripped of its sha256: prefix (in-toto's digest map is algorithm-keyed; the prefix is redundant inside it and MUST NOT be duplicated).
• predicate - the mapping in section 3 below.

3. Predicate field mapping (OCG envelope → predicate)

All fields are verbatim or renamed passthroughs of the source OCG artifact - the predicate mints no new claims and performs no re-derivation beyond stripping the sha256: prefix for the subject digest. This keeps the mapping mechanical and auditable: a reviewer can diff predicate fields against the source artifact field-by-field.

4. What this attestation asserts, and does not (honest-caveat doctrine)

Mirroring SPEC.md's own layered-honesty model (§4 vs §17 vs §18):

Asserts (always, from executionHash alone)

• The recorded outputPayload is exactly what was produced from the recorded policyParameters under some deterministic function - anyone can recompute executionHash and get the same value (SPEC.md §4 re-verifiability). Tampering with either input or output after the fact is detectable.

Asserts (only if the field is present)

• kernelIdentity present → the publisher claims a specific kernel source digest produced this output. This is an advisory published claim, not a cryptographic proof of execution (SPEC.md §17.2) - a dishonest server could still have run different code.
• computeProof present → a zkVM proof exists that the named kernel, not merely a kernel, produced this output - verifiable without re-execution and without trusting the publisher (SPEC.md §18).
• auditSignature present → the artifact is bound to a specific signing key (did:key or did:web); the run is now linkable to that key (de-anonymizing - SPEC.md §16.2).
• anchorBindings present → executionHash (or a Merkle root committing it, §20.1) was included in an independent transparency log or timestamp service by the recorded time.

Never asserts

• That the policyParameters (inputs) are true, complete, or non-malicious - the predicate attests to computation integrity, not input veracity.
• That the emitting party is authorized, licensed, or compliant with any external regime - mandateType and complianceFlags are decision metadata, not regulatory certification.
• Real-world identity of the signer - a did:key proves control of a key, not a legal identity, unless the deployer separately anchors to did:web over a domain they control (SPEC.md §16.4).
• That the kernel is bug-free - computeProof proves the named code ran and produced this output; it says nothing about whether that code is correct.

5. Non-goals for this draft

• No runtime code, no verifier implementation, no CLI. This is a spec/proposal artifact only.
• No submission to the in-toto community, in-toto/attestation, or any public registry - a separate, explicitly-flagged decision.
• No claim that any AINumbers node currently emits this predicate in production - it is a proposed export shape, not a shipped feature.

Rationale - why in-toto, specifically

Status: draft reasoning accompanying the predicate spec above. Positioning notes, not a spec.

1. EU AI Act Art. 12 audit-logging tailwind. Enforcement lands 2 Aug 2026. Art. 12 requires high-risk AI systems to keep logs that make outcomes traceable and auditable throughout the lifecycle. Regulators and auditors evaluating logging adequacy increasingly reach for existing supply-chain-attestation tooling (in-toto/SLSA) rather than bespoke formats, because that tooling already has verifiers, policy engines, and transparency-log integrations built. Expressing an OCG receipt as an in-toto Statement lets a deployer point at that ecosystem instead of writing a one-off Art. 12 log-format justification.
2. Verifier reuse, not verifier invention. in-toto/SLSA has an existing, maintained verification toolchain (in-toto-golang, slsa-verifier, cosign attestation support, GitHub's own attestation APIs). A predicate is the only thing OCG has to define - subject digest binding, envelope signing (DSSE), and transport are already solved problems in that ecosystem. This is far cheaper than building or promoting a bespoke OCG-only verifier and asking third parties to adopt it.
3. Low-cost, additive move. The mapping in section 3 above is a mechanical, verbatim passthrough of fields OCG already emits (SPEC.md §3/§4/§16/§17/§18/§20). No new hashing, no new signing scheme, no schema change to the canonical artifact. The predicate is a view, the same posture OCG already takes with its VC (§13.11), SD-JWT (§13.12), and PROV-DM export profiles - all hash-excluded, all re-derivable from the canonical artifact, none authoritative over it.
4. First-mover positioning, not lock-in. Publishing a draft predicate (never mind submitting it) costs nothing and de-risks nothing away - if the in-toto community's own attestation-bundle work moves in a different direction before this is ever proposed externally, the draft is simply discarded. It exists to have a concrete artifact ready if OCG pursues external interop, not as a commitment.

Positioning vs. SLSA provenance

SLSA provenance (https://slsa.dev/provenance/v1) attests to a build: which source, which builder, which build steps produced a software artifact. An OCG receipt attests to a decision: which inputs, which deterministic function (kernel), produced which financial/compliance output. These are complementary, not competing - a shipped AINumbers kernel already has (or could have) its own SLSA build provenance covering "this kernel source came from this commit, built by this CI job," entirely separate from the OCG execution receipt covering "this specific run, with these inputs, produced this output." The kernelIdentity/kernelDigest field in this predicate (SPEC.md §17) is the natural handshake point: a verifier who trusts a kernel's SLSA build provenance can then trust that the same digest, referenced in an OCG receipt's kernelIdentity, ran to produce a given decision.

Positioning vs. IETF SCITT / RFC 9942

SPEC.md already treats SCITT/RFC 9942 as an aligned-but-distinct concern (§20, and its scitt-receipt-rfc9942 anchor-binding type), choosing OCG's compiled-mandate record hash as the SCITT "statement" and its §20 anchor as the SCITT-style "receipt" specifically so a future SCITT registration is a re-labelling, not a re-model. SCITT defines a transparency-service protocol (registration, receipts, append-only logs via SCRAPI) - OCG implementations are explicitly not SCITT Transparency Services (§20, normative). This in-toto predicate is a different, narrower thing: a statement shape, not a transparency-service protocol. The two compose rather than compete: an OCG artifact expressed as this in-toto predicate could still be the payload registered with a SCITT-conformant transparency service later, exactly the way any in-toto/SLSA attestation can be. Adopting the in-toto predicate now does not foreclose a SCITT registration later - it's an orthogonal axis (statement format vs. transparency-log protocol), and the existing §20 anchor-binding machinery already covers the "was this included in a log by time T" question regardless of which statement format sits inside it.

What this rationale does not argue

• It does not argue in-toto is the only viable interop layer - W3C VC and SD-JWT exports already exist for that (SPEC.md §13.11/§13.12) and serve different consumer ecosystems (verifiable credentials / wallets vs. supply-chain tooling).
• It does not argue for external submission - that remains a separate, explicitly-flagged decision, contingent on whether OCG pursues external ecosystem interop as a strategic move.