A payment being final does not automatically prove that another payment is authorized.

The failure boundary

An AI agent sends a payment. The final response is lost. Later evidence shows the payment committed — but fulfillment is still unknown. Should the agent pay again?

authorized intent→payment attempt→timeout→reconcile→next action?

That single question crosses several independent trust boundaries. Our public-contract research and executable benchmarks forced us to separate them instead of treating “success/failure” as one state.

Four independent questions

1

Evidence authority: what observation is authoritative enough to establish the prior outcome?

2

Payment finality: did the prior monetary action commit, fail, remain pending or remain unknown?

3

Retry authority: even after a final failure, is a new monetary action actually authorized?

4

Fulfillment finality: if money moved, was the paid-for result delivered, compensated or still unresolved?

The gate

We normalize the observed state and run it through a fail-closed Agent Payment Decision Gate:

AUTHORITY
   ↓
PAYMENT FINALITY
   ↓
RETRY AUTHORITY
   ↓
FULFILLMENT FINALITY
   ↓
ALLOW / HOLD / STOP / RECONCILE / COMPENSATE

ALLOW is intentionally hard to reach. It means the evidence currently supports another monetary action within the proven scope. Unknown or contradictory coordinates remain explicit rather than being silently guessed.

What the pilot pressure-tests

  • spending and per-transaction limits;
  • delegated authority, approval thresholds and revocation;
  • timeouts and ambiguous commit;
  • idempotency, duplicate execution and replay;
  • retry identity across attempts;
  • settlement and accounting consistency;
  • API ↔ ledger ↔ webhook ↔ audit disagreement;
  • fulfillment, refund, compensation and repurchase boundaries.

What you receive

01

Causal state map
actor → action → transition → invariant → evidence.

02

Bounded failure scenarios
The smallest reproducible paths that challenge the control.

03

Machine decision
The gate returns a concrete next-action disposition, not a vague risk score.

04

Customer Evidence Pack
Canonical input, recomputed decision, human summary and SHA-256 manifest.

05

Remediation map
The exact missing proof, invariant or recovery rule needed to move forward.

A concrete synthetic example

payment COMMITTED+fulfillment UNKNOWN→RECONCILE→new payment BLOCKED

The included demonstration is deliberately provider-neutral. It proves the decision mechanics without pretending that a synthetic scenario is a production finding.

Pilot intake

Bring one workflow where a wrong retry, release, payout or repurchase could move real money.

We start with the smallest useful boundary. Safely generalized architecture and synthetic or explicitly authorized test environments are enough to begin.

  • Actor: Who or what can initiate the monetary action?
  • Authority: What proves it is currently allowed?
  • Failure: Which timeout, retry or partial-state case worries you?
  • Truth source: Which system is authoritative when signals disagree?
  • Acceptance: What would have to be proven before the next financial action is safe?
Describe the workflow → See the general Verified Workflow pilot →

Do not submit credentials, private keys, personal data, customer-confidential information or identifying production details. We do not need real funds to validate the causal contract.

Scope boundary

This is independent verification of a bounded workflow, not a security certification, legal opinion, wallet service or permission to move production funds. Provider-specific claims require provider-specific evidence. Unknown semantics remain UNRESOLVED rather than being invented.

The product is not “another payment test.” It is evidence for whether the agent is allowed to make the next financial move.