Proof
How you know it works
The landing page shows an animation. An animation proves nothing. This page is the evidence underneath it, with the gaps named as plainly as the passing tests — because a page of evidence that hides what it has not tested is not evidence.
- Tests passing
- 293
- Test files
- 18
- Full runs on real infrastructure
- 2
- Payments settled
- 0
01 — The suite
293 tests, and where they sit
Run npm test in the repository and this is the output. The heaviest file is the policy engine, which is correct — it is the part where being wrong costs money.
| File | Tests | What it covers |
|---|---|---|
| policy/evaluate | 33 | Rule order, inclusive limits, null versus zero, every decision path |
| approvals/routes | 25 | The approve and deny endpoints, replay, expiry, wrong tokens |
| db/repo | 24 | Every query, idempotency, the daily spend calculation |
| actions/service | 24 | Request to decision to execution, and every terminal path |
| audit/log | 23 | Event vocabulary, redaction, the size cap, ordering |
| routes/actions | 20 | The HTTP surface, auth, validation, error bodies |
| sdk/client | 20 | All three methods, timeouts, polling, error shapes |
| approvals/token | 17 | Minting, hashing, single use, expiry |
| env | 15 | The boot refusals, including half-configured SMTP |
| routes/audit | 14 | Reading a trail back, pagination, scoping to a project |
| demo/agent | 13 | A real LLM agent driving the tool, end to end |
| docs/generated | 13 | That the published schema matches the runtime behaviour |
| notify/email | 12 | Message construction, the approval link, escaping |
| shared/actions | 11 | The wire schema, strict mode, integer cents |
| notify/smtp | 10 | Transport construction and credential verification |
| policy/seedPolicy | 8 | The policy the seed script writes |
| adapters/ledger | 6 | That it records and does not settle |
| auth/apiKey | 5 | Generation, hashing, constant-time comparison |
02 — The real run
Twice, against real infrastructure
A suite that only ever talks to fakes proves the fakes agree with themselves. The whole loop has been run twice against the real thing.
Real Gmail SMTP. A real email arriving on a real phone. A human reading the amount, the recipient and the rule that was crossed, then tapping approve. The agent, which had been blocked in waitForAction, picking up and reporting the result. A complete audit trail afterwards showing every step in order, including the ninety-five seconds where nothing happened because a person was deciding.
That gap in the timestamps is the only part of this that cannot be faked, and it is the whole claim the product makes: action.executing comes after approval.granted, never before.
03 — Hard cases
The tests worth naming
Most of the 293 are ordinary. These four are the ones that catch the mistakes a future change would actually make.
No terminal status without its event
One test walks every action in the database and fails if any of them sits in a terminal status with no terminal event beside it. It exists to catch a transition somebody adds later and forgets to record — the failure mode that leaves an audit log quietly incomplete.
Redaction, checked in the stored bytes
Not that the function returns the right thing — that the row on disk contains the harmless field and does not contain the secret. Testing the function would pass even if the write path skipped it.
Deny always beats approve
The policy suite pins the rule ordering, so a refactor cannot reorder the checks and make a payment past the hard ceiling arrive as something a human is allowed to approve.
A token cannot be spent twice
Replay, expiry and unknown tokens all have their own cases, because a double-clicked approve button and a browser re-submitting a POST both reach the server twice in normal use.
04 — Unproven
What none of this shows
Read this section as carefully as the one with the numbers in it.
-
No money has moved
Zero payments have settled, ever. The ledger adapter records and returns settled: false. Every test and both real runs stop exactly where a payment processor would begin, so nothing here is evidence about what happens when one is attached.
-
No load or concurrency testing
The database is SQLite with a single writer, and nobody has driven it with concurrent traffic to find out where that breaks. The suite runs sequentially against a fresh database.
-
No external security review
Tokens are hashed, compared in constant time, and single use, and that reasoning is written down — but nobody outside this project has tried to break it.
-
No production users
Nobody is running Adeia in front of real money. Two demos and a test suite are not the same thing as a system that has survived being used.