Atinamos Verification Methodology

Atinamos reports what it observed and the conditions under which it observed it.

You can pay to be tested. You cannot pay to be trusted.

A seller may fund independent testing, but payment cannot buy a positive outcome, suppress a failure or erase historical evidence.

Evidence, not verdicts

Atinamos does not assign a universal trusted/untrusted label. A verification record describes an observation. The buyer decides how much weight to give that evidence according to its own budget, risk tolerance, freshness requirement and cost of failure.

For example, if Atinamos observes that a paid service settled successfully but its primary output failed the tested contract, the registry reports that fact. One buyer may reject the service, another may request a fresh test, and another may accept the risk.

Observation levels

We keep separate evidence for:

1. advertised/discovered — a registry, marketplace or seller claimed the service exists;
2. reachable — the relevant host or route was contacted;
3. payment contract observed — a live payment requirement was captured and parsed;
4. payment authorization created — the buyer/verifier successfully constructed the required authorization;
5. authorised request sent — the paid-path request was actually submitted;
6. payment settlement observed — transfer/settlement evidence was observed where available;
7. execution/fulfilment observed — the seller returned or completed work;
8. output validated — assertions were applied to the returned result;
9. repeat operation — the same service was observed independently over time.

These levels are not collapsed into a single claim.

Example classifications

Current public evidence uses narrow classifications such as:

• settled_fulfilment_valid — settlement observed, fulfilment returned and tested 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 returned output failed the tested output contract/assertions.

A classification describes the run. It is not a provider-wide reputation score.

Service route versus test invocation

Evidence is attached to a service route while retaining the exact tested invocation. Query parameters or request bodies may contain the controlled test input and are preserved in the evidence record.

This allows a buyer considering the same route with a different input to discover relevant prior evidence without implying that Atinamos tested every possible input.

Every empirical finding should state

• exact question tested;
• sample size;
• observation/test dates;
• service and endpoint where relevant;
• method and test input;
• payment amount and rail where relevant;
• evidence source;
• directly observed result;
• inference, if any;
• limitations;
• last updated date.

Unknown services

If there is no Atinamos evidence for a service, the public result should say: Atinamos holds no evidence. It must not imply unsafe, fraudulent or untrustworthy.

Failures

Failed observations are retained. A later pass does not delete a previous failure. Where possible, failure classes distinguish seller/service behaviour from verifier/system errors. Internal verifier defects must not be reported as seller failures.

A response is not automatically classified as valid fulfilment because money settled or because the endpoint returned HTTP 200. Where the advertised output is objectively testable, the verifier should test the relevant assertions independently.

Development records versus public evidence

Development tests can validate the verifier itself but should not automatically become public evidence about a seller. Deliberately changing an Atinamos endpoint to produce a failure can prove contract-change detection; it is not independent evidence that the production seller is unreliable.

Service-level scope

Evidence should attach primarily to an exact service rather than to a vague provider-wide reputation. One provider may operate services with different contracts and very different histories.

Recency and provenance

Evidence timestamps indicate when an observation happened. Each observation should also identify whether it came from Atinamos direct testing, an external marketplace or registry, a payment/facilitator record, an independent third-party evidence system or seller-supplied metadata.

Machine-readable registry

Published evidence is exposed for buyer software through the trust lookup API:

GET /v1/trust?endpoint=<service-url>

The API returns evidence summaries and timestamped observations. It is deliberately designed so that procurement policy remains outside the registry.

Public corrections

If a published finding is later shown to be incorrect, the page should be corrected with a dated note rather than silently rewritten where the correction materially changes the conclusion.