Walkthrough

Watch a payment get held, and see exactly why.

A procurement agent is about to spend €1,250 with nobody watching. Press the button and read what comes back — not a score, but the rules that fired, in the order they fired.

This page runs the walkthrough locally. It sends no payment and uses no production key.

The payment being attempted

Merchant
supplier-not-on-list
Amount
€1,250.00
Agent
procurement-agent-17
Human present
no
Your per-transaction limit
€500.00

What happens inside

  1. Verify the authorization

    The protocol proof is checked, and the payment identifiers are claimed so the same one cannot be presented twice.

  2. Apply your policy

    Amount, currency, merchant, human presence and the agent's own history, against the limits you configured.

  3. Record the whole input

    Everything the rules read is stored with the decision, so the answer can be produced again later.

What the record carries

Not a summary of the decision — the inputs it was made from, so anyone can run the rules again and get the same answer.

$ python scripts/evidence/verify_decision_evidence.py evidence.json

Transaction:  4471
Recorded:     HOLD, risk 55
Fingerprint:  b6cf7aca0a6a930f59067dae470d6dcc8e11606f...

MATCH — the recorded decision is the decision these inputs produce.

No database, no network, no API key. If our answer and yours differ, the tool says so rather than hiding it.

Performance and integration scope

The policy benchmark measures rule evaluation in isolation. Deployment latency also includes API, database and external-provider calls.

0.15 msThe policy rules themselves, worst case, with an agent carrying a full day of history
6Payment rails implemented, with protocol-specific checks and a shared response format. Qualification and supported modes vary by rail
0Payments moved by TrustedPAI. Your integration acts on the screening decision
Evaluate a pilot → Or read how it works