The report is a chat message. The quirks are the spec.
Below the level where anyone buys software, a great deal of business runs on a person typing the day's takings into a chat group at half past eleven at night. Getting that into a ledger is a two-hour job and a two-year maintenance problem, because the quirks are not errors — they are the format. One outlet types a seven-digit date every single night. One posts the previous day's figures the next morning. And two of them use the same notation for genuinely different things. Switch a quirk off and watch the ledger go wrong without complaining.
Honest-AI note. No model on this page: the messages are read by a real parser, and switching a handler off really removes it. Every figure, outlet and operator is fictional. The one finding that no parser can produce is the last panel — a night nobody posted. There is no wrong row to detect; only a step in the operator's own running total that our rows cannot explain, which is the same second-axis idea as Edition 018.
The operator's quirks
The ledger, as built
The check that needs no parsing at all
The +B that is not one thing
Plain-language key (stated date, month-to-date step, second component, silent loss)
- Stated date
- The date the operator wrote in the message, as opposed to when the message arrived. Only the first one is about the money.
- Month-to-date step
- The difference between two consecutive running totals. It must equal the takings in between — which makes a missing night visible without reading anything.
- Second component
- The
+Bin "A + B = C". Same notation at two outlets, different businesses behind it. - Silent loss
- A night that never enters the ledger and never raises anything, because nothing was wrong — something was simply absent.