PLATFORM DESIGN

Follow a payment
through the system.

An agent can request an action. The transaction service decides whether it is allowed, and an evaluator can inspect the saved result through a separate interface.

This map describes the target deployment. The current interactive sandbox runs its matching logic in your browser.

Explore a flow

Platform design

A scoped request reaches the transaction service. Verified receipt evidence is matched and committed to Neon.

Choose a component to inspect its role. Arrows show the selected data path, not live traffic.

SELECTED FLOW

Create a scoped request.
Check the actor and transaction terms.
Verify and normalize the synthetic receipt.
Commit one allocation and its event.
Read the resulting state.

The platform separates the browser, agent gateway, private transaction service, database transport, Neon Postgres, and restricted evaluator controls. JavaScript enables flow selection and component details; the full component and trust-boundary descriptions remain below.

AUTHORITY BOUNDARIES

Keep financial authority outside the model.

Agent

Uses fixed business tools. It cannot mint receipts, reset runs, approve itself, issue SQL, or read signing keys.

Transaction service

Checks ownership, exact terms, policy, budgets, and idempotency. Only this service commits financial state.

Evaluator

Inspects the committed result through a separate read path. An agent’s reply is a claim to check, not the source of truth.

One transaction record.
Separate ways to check it.

Cloudflare hosts the services. Neon holds the durable records. Hyperdrive query caching stays disabled so reads after a write reflect the committed state.

Incoming-payment matching remains separate from outgoing transfer execution. Local token rails, paid research purchases, and claims-payment packs use explicit adapters and their own acceptance checks.

Read the product overview