The counterproof: how the system contradicts itself first

Building a monitoring system that asks questions is easy. Building one that asks the right questions is something else. The difference comes down to one habit, rolled out across the testing ground this week: before the system asks a question, it first tries to refute itself. Three examples.

Rhythm is not an error

An amount that returns every quarter — same figure, periods 1, 4, 7 and 10 — looks like forgotten invoicing. It is almost always the opposite: a contract item doing exactly what was agreed. The system now recognises that rhythm and directs the question at the contract instead of at invoicing.

But rhythm detection has a trap of its own, and we went looking for it: one client had the exact same amount booked 94 times. That looks like rhythm. It was 94 separate events at the same rate, on 94 different days. Concluding "contract item" here would have filtered out 94 pieces of real work. The counterproof set the threshold: only above one-and-a-half bookings per period does something count as rhythm.

The records are the truth, not the paperwork

The system first based conclusions on parsed contract documents. In practice those are often empty or incomplete. Worse: from the absence of extra revenue it concluded that no costs were being passed on — the conclusion steering the evidence, instead of the other way round.

So that line of reasoning was measured across the board. Outcome: for 29 clients the work was contractually part of the fixed fee — nothing to pass on, conclusion simply wrong. For 5 it was right: invoicing genuinely missing. For 55 no contract was on record — there the question may be asked, but with that caveat attached. The rule is now inverted: first the contract status from the records themselves, then a conclusion.

Language is measurable too

A question the reader doesn't understand is not a question. So a language check was built that counts technical terms and translates them. The baseline across 57 cards from a single night run was sobering: 427 technical terms, not one clean card. Internal abbreviations, database names, rule codes — the system's language, not the reader's.

After translation: zero terms, 57 out of 57 cards clean. And because this step deserves a counterproof of its own, it was verified that amounts, periods and names survived translation exactly intact.

Why this matters

Every question the system does not ask because the counterproof removed it, is trust earned. Anyone who gets asked three times about something that is simply in the contract stops reading. The human decides — but only about questions worth that decision.