Skip to content
Trusteed Evidence

Prepare useful evidence before the dispute arrives.

Find out which facts exist, which are missing and what a recipient can verify. Start with current individual receipts and move forward only when there is a real consumer.

Guided pilots with visible state: what is current, what is conditional and what remains planned.

Trusteed Evidence

Before promising a dispute evidence pack, find out what proof exists and who is going to receive it.

When an agentic operation is questioned, the intent, the decision, the order and the outcome usually live in different systems: the agent, your store, the payment provider and fulfilment. Reconstructing that by hand, under deadline pressure, is where defensible disputes are lost.

01

Detect the gaps

The declared intent, the decision taken, the order created and the final outcome do not always match in time or in the system that stores them.

Make what is missing visible before the conflict, not during.
02

Reuse the current corpus

TrustReceipt v1.0 keeps signed individual records. Production issuance is confirmed live — the open question is coverage: the MCP-standalone checkout path does not enqueue a receipt by default, so not every transaction generates one yet.

A verifiable technical base, not a promise of a full lifecycle.
03

Design with the recipient

An evidence export only gains value when the payment provider or dispute team that will receive it defines the format and actually consumes it.

Avoid building evidence nobody reads.
From operation to receipt

How a delegated action becomes a verifiable fact.

Each receipt signs what existed at the moment of the operation, not a narrative reconstructed afterwards.

01
The surface records the actionCheckout, confirmation or outcome within its scope
by surface
02
Available context is fixedIdentity, applied policy and decision, with their hashes
canonical
03
The record is signedJWS · Ed25519, verifiable without depending on Trusteed
code complete
04
The recipient verifies itWith the public verifier and the key's JWKS
in pilot
What each party gains

A signed receipt serves whoever asks for it, not only whoever issues it.

Evidence readiness is only worth something if it reduces somebody's concrete work at dispute time.

01available
FOR THE MERCHANT

Answer a dispute without rebuilding it by hand.

The individual receipt already has input, output and decision signed; there is no need to trace logs across systems.

  • Proof verifiable outside Trusteed
  • Missing proof, visible before a payment provider asks for it
  • Fewer support hours per case
02in pilot
FOR THE PAYMENT PROVIDER OR DISPUTE TEAM

They get a format they define, not a generic one.

The export is co-designed with whoever will consume it, so it arrives in the format their process already expects.

  • Structured evidence, not a log dump
  • Verifiable signature without depending on Trusteed
  • Less back and forth per case
03planned
FOR THE AGENT OR ITS OPERATOR

They can evidence what they did and under what conditions.

An operator who can prove what it authorised and what it got back argues its own liability better.

  • A trace of the decision it received
  • Proof of what it was allowed to do
  • Fewer data-less disputes on both sides
What is available and what is conditional

Separating current proof from the vision protects credibility.

A v1.0 corpus and a verifier exist, and production issuance is confirmed live — the caveat is coverage, not existence: not every checkout path enqueues a receipt yet. State Witness, the Lifecycle Evidence Graph and the dispute export remain behind flags or pilot requirements.

Verify an individual receipt
What is available and what is conditional
input/output
canonical hashes
signature
JWS · Ed25519
lifecycle graph
planned
planned

A dispute export is designed with the recipient's format.

code completev1.0Issuance and verification; probe pending
dormantv1.1Hardening behind a flag
Without Evidence versus with Evidence

The difference is not having logs. It is being able to verify them without depending on someone finding them in time.

Without evidence readiness, every dispute starts with a manual search across systems. With Evidence, the relevant fact is already signed before the question arrives.

Without Evidence
  • The dispute arrives and someone rebuilds by hand what happened, cross-referencing logs from the agent, the store and the payment provider.
With Evidence
  • The signed receipt already exists. Verifying it takes minutes, not a full investigation.
Before designing the pilot

What people evaluating Evidence usually ask.

Does a TrustReceipt guarantee winning a dispute?

No. It strengthens traceability and evidence readiness. Evidentiary weight depends on the case, the recipient, the process and the jurisdiction.

Do I need a specific payment provider to start?

Individual receipts work today without depending on a recipient. The dispute-oriented export does need a payment provider or platform that defines and consumes the format.

Does Evidence record the whole lifecycle of the operation?

Not today. It generates individual receipts on supported surfaces. A causal graph connecting events is planned, not a current capability.

What if an event has no authoritative source?

It is shown as a gap, not filled in with an assumption. Evidence prefers a visible hole to an invented datum.

A next step, not a broad promise

Assess your evidence readiness

We start with the facts and the recipient. An export only enters the pilot when there is a payment provider or platform willing to define and consume its format.

Trusteed Evidence — prepare useful evidence before the dispute