Incremental revenue recovered — engine minus control
—
- Control — held out, never touched
- Baseline — a fixed ladder
- Engine
- Oracle — the ceiling
Control is not a competitor. It is a randomly held-out slice of the same traffic that the engine is forbidden to touch, so the gap between it and Engine is the only number here that nothing else explains. Baseline is what a fixed retry-and-remind ladder gets. Oracle is what perfect play would have got, and it is the denominator — not a target.
What it cost to get there
The numbers a recovery engine is usually not asked for.
Where we lost
Segments where the engine did worse than doing nothing.
| Segment | Engine | Control | Difference | Cases |
|---|
Every case, in every arm
One failed payment becomes four cases — the same debt is run
through the engine, the fixed baseline ladder, the untouched control and the
oracle — so the same order appears up to four times, once per arm. That
repetition is the measurement. Pick a row to see exactly what was known and
what was decided.
| Case | Failure | Method | Amount | Rung | Arm | Status |
|---|
Nothing selected yet. Open the
Cases tab and pick a row — or one of the four highlights there — and the whole
decision record lands here: what was known, which gates ran, what each candidate
action scored, and why this one won.
The live worker
The same three steps the benchmark runs — decide, schedule,
execute — on real cases in real time.
TIME_SCALE divides the
waits so a six-hour ladder is watchable; it never touches the clock, so
every timestamp below is real.| Case | Failure | Amount | Rung | Contacts | Status | Last decision |
|---|
Settled money, and how sure we are it belongs here
Every settlement is matched to a debt on a five-rung ladder.
Levels 1–2 are exact ids. Level 3 matched a phone or email and an amount.
Level 4 matched only an amount — that is a guess, and it is labelled one.
Level 5 is a human's word for money we never saw arrive.
| Level | Matched on | Confidence | Settlements | Amount |
|---|
Abandoned checkouts
The second source of at-risk revenue, and the only one with no
webhook. Nobody reports closing a tab, so this is an absence: an order was
created and the payment never arrived. Watching is not at risk yet — most of it
gets paid within the minute. Only the sweeper, 30 minutes
later, turns silence into a case.
| Order | Amount | Created | State | What happened |
|---|
Break it on purpose
Each button injects a real failure and shows what the system did.
Press one.
What is happening right now
Every webhook, gate verdict, decision, action and rupee,
newest first. Nothing here is written by hand — it is read back out of
the same tables the engine decides from, so if it is on this page it is
in the ledger, and if it is not, it did not happen.
Stop recovery
Freezes deciding and executing, and cancels everything already queued.
Webhooks, settlement matching and the abandonment sweep keep running —
a paused engine that stops listening comes back to a ledger that drifted
while it was off.
Or stop something narrower. A scoped pause leaves the rest
of the ladder moving.
Mode
—
Today
Since local midnight. Money recovered is shown next to what
the actions cost, because a recovery number with no cost beside it is a
number nobody can act on.
Needs a human
Nothing on this list resolves itself. An empty list here is
the normal state, not a missing feature.
Quiet hours
The window in which this merchant may not contact anybody.
A 24/7 gaming merchant and a B2B invoicing merchant do not have the same one.
Changing it here does not weaken the gate and does not edit
config/default.yaml — it builds a config for this merchant, which
is why the effective config version changes when you save.Configuration
A version string says the settings
changed. The table says what they were.
| When | Who | What | Before | After |
|---|