Know whether it actually happened.

When your app or AI agent calls a payment, booking, or provisioning API, a timeout doesn’t mean it failed, and a 200 doesn’t mean it worked. Truth Engine checks the real outcome before you retry, refund, or tell a customer anything.

Proven today: GitHub repository creation · Supabase record creation.

YOUR APPor AI agent
ACTIONrefund · order · booking
↓
TRUTH ENGINEexecute · verify · reconcile
↓
THIRD-PARTY APIreal external action
SATISFIED
NOT_SATISFIED
UNKNOWN

Your API response isn’t the truth.

01A 200 isn’t proof.

You tell the customer it shipped. It didn’t.

02A timeout isn’t a failure.

You retry. The customer is charged twice.

03Unknown isn’t permission.

Your agent guesses. Finance cleans up.

WITHOUT TRUTH ENGINETimeout → blind retry → possible duplicate → support ticket
WITH TRUTH ENGINETimeout → UNKNOWN → evidence check → justified outcome

How it works.

Truth Engine sits between your app or AI agent and the third-party API for actions you need to verify.

APP / AI AGENT
TRUTH ENGINE
THIRD-PARTY API
1

Send the action. Route a refund, order, booking, or agent action through Truth Engine.

2

It records and verifies. If the response is lost, it checks the provider through the allowed evidence path.

3

You get a proven outcome. Plus the evidence that justifies it.

POST /v1/protected-actions

{
  "action": "refund.create",
  "provider": "payments",
  "params": { "order": "A-1042", "amount": 400 }
}

outcome: "SATISFIED"
evidence: "provider record"
Illustrative request shape. Exact evaluation schema is issued with approved access.

Three outcomes. Each tells you what to do next.

SATISFIED

It happened.
Confirm the result to the customer or calling system.

NOT_SATISFIED

Proven not to have happened.
Retry only if execution authority permits it.

UNKNOWN

Not provable yet.
Don’t retry blindly. Reconcile, wait, or escalate.

“AI may decide what to do. It doesn’t decide what happened.”

Built for your role.

DEVELOPERSStop rebuilding the hard part.

Use one protected-action API instead of custom retry and reconciliation logic for each integration.

Read the API →
PRODUCT MANAGERSFewer “did it go through?” failures.

Reduce duplicate actions, support tickets, and ambiguous customer states.

See the use cases →
RISK + COMPLIANCEEvidence behind the outcome.

See why an action is SATISFIED, NOT_SATISFIED, or still UNKNOWN—including agent actions.

Visit Trust →

Where it fits, honestly.

PROVEN TODAY

GitHub repository creation·Supabase record creation

DESIGNED FOR

Refunds·orders·bookings·provisioning·access changes·agent actions

Why not just idempotency keys or a workflow engine?They solve related problems. Compare where execution truth lives.
Compare approaches →

Early access is open. We want you to break it.

Get scoped evaluation access, run your hardest failure case, and tell us what you find. Engineers who find gaps shape the roadmap.