Cyntrisec
A verifier should be able to answer at least four questions about a specific inference: what model identity was claimed, what request was processed, what response was returned, and what trusted environment produced the result.
AIR receipts are designed around that idea.
The center of the receipt
At the center of the receipt are cryptographic hashes. The request is hashed. The response is hashed. The model identity is represented by a model hash. The attestation evidence is linked through an attestation document hash and measurement claims. Then the whole receipt is signed so the bundle can be verified later.
Why binding matters
Because isolated facts are weak. A log line that says "model X ran" is not very meaningful if it is not cryptographically bound to the specific request and specific response. Likewise, a model hash by itself is not enough if it is not connected to the particular execution event.
The value comes from binding.
When the request hash and response hash are in the signed receipt, the verifier can check that the receipt refers to the exact input and output pair being reviewed. When the model hash is included, the verifier can check which model identity was claimed for that run. When the attestation linkage is included, the verifier can see that the receipt is connected to an attested execution context rather than being a detached application log.
Model identity nuance
There is still an important nuance around model identity. A single model_hash can mean different things depending on how it was produced. If it represents only the raw weights file, that is useful but incomplete. If it is derived from a signed manifest that also binds tokenizer and config, that gives a stronger identity story. That is why a receipt should expose the model hash scheme, not just the hash value.
Layered verification
From a verifier's perspective, the structure is useful because it supports layered checks.
At a basic level, the verifier can validate structure and signature.
At a stronger level, it can validate whether the request hash matches the request under review, whether the response hash matches the response under review, and whether the model hash matches an expected model or allowlist.
At the strongest level, it can also validate attestation-linked claims, expected measurements, freshness windows, and policy constraints.
Portability
This makes the receipt portable. A buyer, auditor, partner, or regulator does not need to trust the service operator's internal dashboards. They can inspect the receipt directly, apply local policy, and determine whether the evidence is acceptable.
That portability is important. AI governance becomes much easier when the proof artifact can travel with the output.
The short version is:
- request hash binds the input
- response hash binds the output
- model hash binds the model identity claim
- attestation linkage binds the run to a trusted execution context
- the signature binds the whole receipt together
That is what turns an inference event into something that can be verified later instead of merely described later.