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.
06 / Implementation reference · Updated 1 October 2026
AI-service receipt JSON format: fields you can inspect.
This reference describes pactverity.assurance-receipt.v1, engine 1.0.0. It is project documentation, not an independently certified standard. Use the machine-readable receipt JSON Schema for nested fields, limits and allowed values. Structural validation alone does not recompute the checks, digest or signature.
| Field | Meaning and validation boundary |
|---|---|
schema | Required literal: pactverity.assurance-receipt.v1. An unknown format must not be silently treated as v1. |
engineVersion | Required literal: 1.0.0. Identifies the rule implementation, not an audit level. |
issuedAt | Required canonical UTC timestamp with milliseconds. Caller-supplied time is not independent timestamp proof. |
agreement | Agreement ID, service name, provider/buyer references and criteria. Limits use milliseconds, basis points and seconds; an optional expected output hash selects the integrity check. |
evidence | Supplied latency, uptime, freshness, observed output hash and observation time. The format does not independently collect these measurements. |
checks | Exactly four ordered entries: latency, uptime, freshness, output_hash. Recorded values and decisions must match a fresh calculation. |
outcome | pass or fail. An output-hash check may be not_evaluated if no expected hash was supplied; any failed check makes the overall outcome fail. |
payloadHash | 64 lowercase hexadecimal characters: SHA-256 of the domain-separated canonical payload. It excludes this field and the signature envelope. |
walletSignature | Optional Ed25519 envelope. A valid signature shows control of a key; require an independently trusted signer to establish the expected issuer. |
How the SHA-256 receipt digest is calculated
- Validate and normalize the supported agreement and evidence fields, then recompute the checks and outcome. Reject a mismatch with recorded results.
- Build the payload from schema, engineVersion, issuedAt, agreement, evidence, checks and outcome. Sort object keys recursively in ECMAScript UTF-16 code-unit order; retain array order and serialize without spaces.
- Prefix the canonical JSON with
PVTY-LAYER/VERIFICATION-RECEIPT/V1and one LF byte. UTF-8 encode, then SHA-256 hash. There is no trailing newline after the JSON. The legacy domain remains unchanged for compatibility; this is not a claim of RFC 8785 compliance.
The exact normalization and signature boundaries are documented in the digest derivation. The signature message uses the separate domain PACTVERITY-RECEIPT-V1, one LF and the normalized payload hash.
Reproduce one known-answer digest
Download the synthetic passing receipt and its exact UTF-8 hash-input bytes. An ordinary SHA-256 tool should return:
55c32f25e10b025ae20ffe0c5148ed89928d59cb9512c48be4345f53248b5fb1This verifies one digest calculation, not truthful measurements or the complete implementation. Do not edit line endings or append a newline to the downloaded input. Compare the distribution files against the published file checksums.
A valid receipt can record a failed service
Consider a synthetic service with a 500 ms latency limit and a measured latency of 900 ms. A correctly constructed receipt records a failed latency check and a fail outcome. Its digest and rules can still verify successfully: it is an intact record of failure, not evidence that the service passed.
The offline verifier checks integrity by default. Add --require-pass when a workflow also requires a passing recorded outcome:
node pactverity-verify-offline.mjs synthetic-pass.json --require-passWith that flag, an otherwise valid receipt recording failure returns exit code 3. The supplied passing fixture returns 0. Neither result proves the inputs were independently measured. Read the offline verifier instructions and signer controls before using it in an evaluation workflow.
Run the passing, failing and deliberately altered cases
All three fixtures use the same terms and fabricated measurements. Download the passing receipt, valid receipt recording failure and deliberately tampered receipt. The latter is intentionally invalid test data, not a real incident.
node pactverity-verify-offline.mjs synthetic-pass.json --require-pass
node pactverity-verify-offline.mjs synthetic-fail.json
node pactverity-verify-offline.mjs synthetic-fail.json --require-pass
node pactverity-verify-offline.mjs synthetic-tampered.jsonExpected exit codes in order: 0, 0, 3, 1. A pass outcome may include an individual output-hash check marked not_evaluated; the pass gate does not require every optional check to run. Also, someone who can replace both an unsigned receipt and its digest can create a new consistent record. Digest agreement alone is not independent provenance.
Version scope and the PVTY token
This page documents existing v1 behaviour; it does not introduce a format or algorithm change. A future incompatible schema or hashing change needs a separately identified format and compatibility tests. Do not change the legacy domain merely to update branding.
PVTY is the project's Solana token, not a requirement for running these public checks. Token staking and settlement roles remain planned, not deployed. For the separate identity, allocation and market-access questions, use the official PVTY token research guide. A functioning receipt verifier does not establish token demand or value.
Continue researching