At 08:08 UTC our watchdog reported 21 contracts of INJ sitting with no protective order on them, and named the system that owned them — one that had been deleted.
At the same hour the exchange showed a long position of 24 contracts and a reduce-only sell order for exactly 24. The side was covered in full. Nothing was unprotected, and the 21 was not a position at all.
It was a remainder: exchange position minus the part our own books could explain at that instant. Two takes had filled seconds earlier, our books caught up at 08:07:05, and in the window between those two events the difference landed on a dead address.
That was one of three false alarms that morning. Each had a different defect. All three were the same question asked badly.
Why a false alarm is expensive
An alert channel that cries about something you cannot act on gets muted — and the one that gets lost afterwards is the real one. We have already paid for this: a demo venue once failed one class of endpoint, and twenty-odd identical "position may be unmanaged" alerts went out about a simulated account in a single hour.
So for a monitoring system, the false-positive rate is not cosmetic. It is the thing that determines whether the true positive is ever read.
What we measured
Our alert journal (it exists since 18 September 2026 — before that the only record was the owner's chat) over the morning of 19 September, 00:41–08:08 UTC.
The useful property here is that each alert prints the facts it acted on, so falseness is checkable after the fact — you do not need to trust anybody's memory:
- •the side's age at alert time versus the delay threshold;
- •whether a protective order had been cancelled seconds earlier;
- •whether the side was already fully covered by a reduce-only order.
Three alerts that morning were demonstrably false by these criteria. In all three the position was being managed, and our position-reconciliation instrument, asked about the same systems, answered "nothing found".
The three defects
1. Freshness measured by our own fill, not by the exchange
06:38 UTC, INJ, 4 contracts. The exchange had opened the side at 06:36:06 — an age of 114 seconds against a 180-second grace threshold. The alert should not have fired.
It fired because "how old is this position" was answered from our own fill record, and that record was written at 06:38:07 — two minutes after the exchange acted. In the window between "the venue opened it" and "we wrote it down", the source we asked has nothing to say.
The take-profit filled at 06:40:05. The position was being managed the entire time.
2. No allowance for "the engine itself removed the stop and is closing right now"
07:53 UTC, ARB, 18.2 contracts. The take was cancelled at 07:52:57.429 and the market sell executed at 07:53:02.735. A window of 5.3 seconds — and it is the most ordinary event there is: the routine close of a cycle, which necessarily means a moment with no resting protection.
The fix needed a third source of freshness: the age of the last cancellation of a *protective* order. Note how narrow that predicate has to be. "Age of the last change to the books" would never expire on a system that ticks every 30 seconds — the guard would be permanently suppressed, which is the same as not existing.
3. Subtraction of two different things, with the remainder given an owner
The opening example. For a system that is no longer polled, the leftover was computed as exchange position − what our books explain.
These are not two measurements of the same quantity. One is the venue's truth at this millisecond; the other is our record of it, which lags. Subtract them during a lag and you get a number that describes neither.
The defect, though, is not the subtraction. It is what happened to the result: the unexplained remainder was assigned an owner — a deleted system whose books have nothing to do with those contracts.
And here the product contradicted itself inside one message. The alert text says, in so many words, that ownership is not established — *"the system name here is only the address of the door"*. Then it names the system anyway, and offers the door that closes a position.
Printing the leftover as "unexplained" would have been honest uncertainty. Naming an owner turned uncertainty into a claim.
The same number also truncated the coverage calculation — coverage had our estimate of somebody else's share subtracted from it — so a side that was covered in full looked uncovered. The fix checks full coverage as soon as the orders are known, before coverage is reduced by that estimate. A partial cover is still a finding, because a partially covered position genuinely is one.
There is a detail in *where* that check had to go, and it is more interesting than the fix itself. To judge coverage you must ask the venue for its orders — and that question is deliberately asked last, once per instrument, only after everything cheaper has already agreed that something looks wrong. Move the check earlier and the watchdog would query every system on every account on every pass.
So the order of checks here is dictated by the price of the question, not by the logic of the rule. The fix had to fit into that order rather than rearrange it to suit itself. Monitoring code is full of this: the cheapest questions run first, which means the most authoritative answer usually arrives last — and a guard that needs the authoritative answer has to live where it becomes available, not where it would read most naturally.
The generalisation worth keeping
This breaks any reconciliation where one side of a subtraction comes from the venue, the other from your own records, and the remainder is attributed to a third party.
Two questions catch it:
- Are the minuend and the subtrahend the same kind of number, measured at the same instant by the same authority?
- Who owns the remainder if the honest answer is "nobody"? If your system has no way to print "unexplained", it will name somebody.
The second question is the one that generalises furthest. A monitoring system is under constant pressure to be actionable — an alert with a name and a button is more useful than an alert that says "something does not add up". That pressure is exactly what turns an honest unknown into a confident wrong answer.
What the numbers say so far, and what they do not
Seven alerts of this class in 40 hours. Three of them — all from the morning after the journal existed — are demonstrably false by the criteria above. The other four, from the day before, do not look false by the freshness test, but we cannot check them against the other two criteria, because the evidence those need was not being recorded yet.
So: three demonstrably false out of seven, over a period during which the class was still being fixed.
That is not a before/after result, and we are not going to present it as one. A proper measurement has to be a ratio — false alarms as a share of all alarms of the class, each with a checkable criterion — because false positives here cluster around *events* (a cycle turning over, takes filling in a cascade), and event frequency depends on how many systems are trading. Count them per day and you measure fleet activity, not the fix.
All three defects are now closed. The ratio will be measured after the fix has stood through enough watchdog cycles to have a denominator worth dividing by.
Limits of this measurement
- •One fleet, one morning, a journal two days old. Small numbers, and we say so rather than scaling them up.
- •The fourth criterion did not exist yet. For the alerts of the previous day we can test freshness but not coverage — absence of evidence, not evidence of absence.
- •"Demonstrably false" is our own criterion. It is checkable by anyone from the text of the alert, which is why we chose it; it is still our choice.
- •This is not investment advice, and none of the above is a recommendation to trade.
If you run monitoring over your own bots
Three questions, in order of how much they cost when the answer is wrong:
- Which source answers "how old is this position" — the venue, or your own record of it? Your record lags by however long your write path takes, and that lag is exactly when a freshly opened position looks abandoned.
- Does your guard know about the moments when your own software removes protection on purpose? Closing a cycle means a window without a resting order. If the guard does not know that window exists, it will report every normal close as an emergency.
- What does your system print when it cannot explain something? If the answer is "it attributes it to the nearest plausible owner", you do not have a monitoring system. You have a system that manufactures defendants.