Public Verification Receipts — v1.0
An Atinamos public verification receipt is a machine-readable record of one timestamped observation of one machine-service invocation.
You can pay to be tested. You cannot pay to be trusted.
The receipt records evidence. It does not certify a provider as permanently trusted or untrusted.
Read the receipt as an execution history
seller offer
→ payment contract
→ authorization
→ authorised request
→ settlement
→ fulfilment
→ output validation
Each stage matters independently.
- HTTP 402 means a payment requirement was observed. It does not mean money moved.
- A payment authorization means the required authorization could be created. It does not mean settlement occurred.
- Settlement means value moved. It does not prove useful work was delivered.
- HTTP 200 means a response arrived. It does not prove the thing purchased was valid.
- A valid observation is evidence from that run, not a permanent reputation score.
Identity and scope
evidence_version
Identifies the public receipt format. The current value is atinamos.public-verification-receipt.v1.
observation_id
Stable identifier for this specific published observation.
observed_at
Timestamp for the observation. Evidence ages, so a buyer can apply its own freshness policy.
provider and service
Identify the provider and the specific service tested. Evidence is primarily service/route-specific rather than a provider-wide reputation statement.
Request evidence
The request object records the endpoint, HTTP method and a public summary of the controlled test input.
The exact invocation matters. A result for one method, route or input does not imply that every invocation behaves the same way.
Payment evidence
The payment object separates stages that are often incorrectly collapsed into “paid”.
initial_http_status
Status observed before payment. In x402 observations this is commonly HTTP 402.
authorization_created
Whether the verifier successfully constructed the payment authorization.
authorized_request_sent
Whether the authorised request was actually submitted.
settlement_observed
This is deliberately a three-state value:
true— settlement evidence was observed;false— evidence supports that settlement did not occur in the observation;null— settlement state was not established.
Unknown must remain unknown. null must not be converted into a failure or a success.
transaction
Where applicable, this contains a public transaction identifier supporting observed settlement. It may legitimately be null.
paid_http_status
HTTP result from the authorised paid path. A status of 200 is not, by itself, proof of valid fulfilment.
Contract anomalies
contract_anomalies records machine-contract irregularities observed during the run, for example malformed fields.
An anomaly is evidence of what was observed. It does not automatically prove what caused a later failure.
Evidence hashes
Where useful, receipts may include SHA-256 hashes of retained evidence such as a payment challenge or a narrowly normalized representation.
These hashes help preserve integrity and comparison without requiring publication of every private execution detail.
Fulfilment and output validation
fulfilment.observed
Whether the service returned or completed work in the tested invocation.
fulfilment.output_valid
Whether the returned useful output passed the published objective checks.
This distinction is central to Atinamos. A seller may return HTTP 200 and a JSON body while the primary thing the buyer paid for still fails validation.
seller_final_status
Service-reported terminal status where one exists. It may be null when not available or applicable.
Assertions
The assertions array contains the public objective checks applied to the returned result and whether each passed.
An empty array does not mean validation passed. It can mean output validation was never reached.
Atinamos publishes enough to explain the tested claim while keeping future challenge-selection logic and anti-gaming mechanics private.
Response hash
response_hash_sha256 is an integrity reference for the retained canonical response representation.
It can be null if no suitable response was obtained.
A response hash proves that a particular retained representation can be identified; it does not prove that representation was correct.
Classification
The classification field describes the observed execution state.
Current public examples include:
settled_fulfilment_valid— settlement observed, fulfilment observed and tested output assertions passed;pre_settlement_paid_path_failure— the authorised paid path failed before observed settlement and successful fulfilment;settled_fulfilment_contract_invalid— settlement and fulfilment were observed, but the purchased output failed the tested output contract.
A classification describes the run. It is not a provider-wide trust score.
Limitations
Every public receipt contains explicit limitations defining what the observation does not prove.
These are part of the evidence record, not a disclaimer added afterwards.
true, false, null and absent are different
Buyer software should preserve these distinctions:
true— evidence supports that the state occurred;false— evidence supports that the state did not occur or the check failed;null— the state was not established;- absent optional field — that dimension was not published or applicable.
A buyer should never turn “Atinamos does not know” into negative evidence.
What is deliberately not in a public receipt
Public receipts are sanitised. They do not require publication of wallet secrets, authentication material, private infrastructure, raw payment authorization headers, verifier implementation, future test selection or anti-gaming logic.
The goal is reproducible interpretation of the evidence, not disclosure of the private verifier.
How a buyer can use a receipt
A buyer agent can combine the receipt with its own procurement policy. Depending on risk and value, it might accept recent positive evidence, require a fresh test, lower a spend cap, avoid a recently failed execution path, or combine Atinamos evidence with marketplace and identity information.
The buyer decides. Atinamos reports the evidence.
Technical specification
The canonical public schema is available directly from Atinamos Verification:
The complete public technical specification and source schema are maintained in the Atinamos Agent Verification Research repository:
The public repository also contains three real receipt examples covering successful validation, pre-settlement failure and settled but contract-invalid fulfilment.