The anomaly is a question, not a finding
Verification catches numbers that don't match the export. But there's a second class of model output in every AI-drafted ops report: the anomaly flag. "Shipping times spiked mid-week." "Damage rate is trending up." These aren't numbers you can tolerance-check — they're interpretations, and they fail differently.
An anomaly flag from a model is a hypothesis wearing a conclusion's clothes. Sometimes it's real: the 12-day order in your export is genuinely worth a conversation with the carrier. Sometimes it's an artifact: "spiked mid-week" because two orders happened to land on a Wednesday in a five-row sample, which is noise narrated as signal. The model can't tell you which, because telling the difference requires the thing it doesn't have — knowledge of what Wednesday was actually like on your dock.
So anomaly flags get the same treatment as numbers, adapted:
- Every flag gets checked against the export before it survives into the report. Which rows support it? If the "spike" is one order that a forklift sat on while aisle 3 was blocked, the flag dies and the reason gets a sentence instead.
- A checked flag either becomes a finding with rows attached, or it gets cut. No flag passes through on the model's say-so. "Damage rate trending up" with no prior-week data behind it isn't a trend — it's a vibe with a percentage.
The last line of the report
One more discipline, and it's the one that makes the whole document worth sending: the report names the decision it informs. "Avg days-to-ship 6.0, driven by two orders over 9 days — decide whether Thursday gets a second picker." A report that informs no decision is a status ritual; the compressible kind of ops work, per every exposure analysis that's looked. A report that ends in a named decision is the opposite: it's the artifact that makes you the person the decision waits for.
This is also where your field's existing culture does the arguing for you. Operations already runs on traceability — lot numbers, audit trails, ISO paperwork with signatures on it. Numbers-with-receipts isn't a new discipline you're importing from software; it's your discipline, applied to a new supplier. The model is a vendor that delivers reports. You'd never onboard a vendor without incoming inspection. Don't onboard this one that way either.
Two steps left: build the full verifier, then gate the send.