13.5 / Technical insight
Anatomy of a Cryptographic Receipt for AI Services
A useful cryptographic receipt is a portable, machine-readable record of what was claimed, what evidence was supplied and how the result was derived.
01 / Identity
Bind the record to the correct service and agreement.
The receipt begins with stable identifiers: schema version, agreement reference, service name, provider reference, buyer reference and issuance time. These fields prevent a technically valid measurement from being detached from its original context and reused for a different service.
Display names alone are insufficient because they can change or collide. References should follow a documented format and be normalised before hashing. Where privacy matters, a system can use pseudonymous identifiers or commitments while retaining the underlying mapping in an authorised system of record.
02 / Terms and evidence
Keep expected conditions separate from observations.
Criteria describe what should happen: maximum latency, minimum uptime, maximum evidence age or an expected output hash. Evidence describes what was observed. Separating those objects makes the comparison inspectable and prevents a result from hiding which side of the agreement changed.
Units and precision must be explicit. Milliseconds, basis points and seconds are easier to compare reliably than formatted percentages or natural-language durations. Optional fields need defined absence semantics so two implementations do not construct different payloads from the same apparent record.
- Record observation timestamps and freshness limits.
- Use fixed units and bounded numeric ranges.
- State whether evidence is caller supplied, independently observed or signed by a source.
- Commit large or sensitive outputs by hash instead of publishing them when appropriate.
03 / Checks
Preserve the reasons behind the outcome.
A final PASS or FAIL label is not enough. Each check should name the rule, expected condition, observed value and individual result. The engine version belongs beside those checks because a later software release may apply different validation or canonicalisation rules.
This structure lets an auditor explain whether a failure came from latency, uptime, freshness or an output mismatch. It also supports partial automation: a workflow can route particular failed checks differently without parsing a free-text explanation.
04 / Commitment
Canonicalise first, then calculate the digest.
Hashing arbitrary JSON is unsafe because insignificant formatting and key order can change the byte sequence. The receipt format needs a canonical representation that fixes field order, number handling, optional values and domain separation. The verifier reconstructs those bytes and calculates the digest again.
An optional digital signature can prove that a particular private key signed the digest. It still does not establish the human identity or organisational authority behind that key unless a separate identity process makes that connection. PactVerity's current browser engine reflects this distinction: digest verification is deterministic, while wallet signature verification proves key control only.
05 / Portability
Make the receipt useful outside the issuing interface.
A portable receipt should have a public schema, bounded validation rules and a verifier that rejects alteration. It should remain readable without an account and should not require the issuing dashboard merely to understand its structure. OpenAPI documents and known-answer examples help independent implementers test compatibility.
The PactVerity Receipt API beta exposes creation and verification endpoints for the current assurance-receipt schema. The format describes a deterministic result from supplied inputs; it is not a payment receipt, legal certificate or proof of independent monitoring.
Continue researching