would-have-alerted audit

what is being predicted

a prediction is one price level, on one coin, on one side. every five minutes the model rebuilds the liquidation map for every coin binance publishes margin brackets for: open interest per venue, split across the leverage brackets, each slice converted to the price it would be force-closed at, then bucketed at 0.25% of mark. buckets under $1m of modeled notional are dropped; the largest three per coin go into the trail with a timestamp, the side, the price and the modeled size — before price does anything. those four numbers are the shipped defaults, each an environment knob rather than a law.

"would have alerted" is literal: these are the levels the alert leg fires on. a level already sitting in the trail unresolved is not written twice, so a magnet that prints for six hours is one prediction, not seventy-two. cluster alerts that actually dispatched to a subscriber's rule are logged in the same table, tagged as alerts rather than model samples; the scorecard counts both and does not split them.

the open interest is real — read from each venue's own endpoint. how it distributes across leverage is an assumption, and a blunt one: equal weight per bracket, doubled on the two highest-leverage brackets because retail crowds the top, longs and shorts split down the middle. it sits in the source as a comment, and it is not tuned to flatter this page.

how a prediction is resolved

twenty-four hours after a prediction is written, the resolver sums every liquidation in our tape for that coin and that side whose print price landed inside the level's bucket, over the 24 hours following the call. reach half the modeled size and it resolves hit; anything else is a miss. no third outcome, no partial credit, no discretion — the half is a constant in the resolver, the window runs from the row's own timestamp, and the row is updated once.

that fixes what can be fixed: the level was recorded before the move, the threshold before the outcome, and the flow is scored against the tape this site publishes elsewhere — not a vendor's aggregate, not the venue's internal ledger. what it cannot fix is that the tape sees less than the market does. every print a feed dropped is size the resolver never counts, and that only pushes one way: true hits land in the miss column, never the reverse. the gaps below are the dated version of that sentence.

the scorecard

predictions logged

403,538

resolved within 24h

376,136

hit rate

0.0% of 376,136 resolved calls

generated 2026-10-07 04:17 utc

hit rate is hits over resolved calls, and it never appears here without the count it was divided by. the table is the twenty most recent resolved calls in time order — the export sorts by timestamp and takes the top of that list, so it is a window, not a selection.

the misses

0 hits · 376,136 misses · 376,136 resolved

misses are the point. a scorecard that publishes only its hits is an advertisement with a table in it. the outcome column carries both, the counts carry both, and rows are ordered by time rather than by outcome, so a bad week has nowhere to hide.

reading them honestly: a miss means the tape did not show half the modeled size at that level inside 24 hours. it cannot tell you which reason applies — the cluster was not a magnet, or the cascade happened and the feed did not record it.

known gaps in the data

the tape is a recording, and recordings have holes. these are the ones we know about.

what this is for

the alarm does one thing: it watches the distance between price and your liquidation and screams before the wick gets there — telegram, push or email, free, no signup.

this page is not a signal service and the hit rate is not an edge. a cluster is where other people's margin runs out, not where price has to go, and a model of it is still a model. read the scorecard as a record of whether the level was called before the move, and size as though the next call is a miss.

arm one on the calculator · the live cluster map