Client Says the Data Fix Shipped; Agent Proves It Didn't, Then Watches Until It Does
"We fixed it, it'll backfill" is a promise, not a fact. The agent treats it as a hypothesis, and then stands watch.
What was getting in the way.
A client emails on a Friday night: the data feed is corrected, the fix will backfill over the weekend. The usual next step is a human re-checking the numbers every morning, "not yet... not yet... looks different, maybe?", until something changes or everyone forgets. Nobody captures what the broken state looked like before the fix lands, so when new data finally arrives there's no clean before/after to judge it against. And promised fixes that quietly never ship are the most expensive kind: the downstream reports keep running on broken inputs while everyone believes the problem is solved.
Context
Universal: the pattern applies to any promised fix from any vendor, client, or internal team where the proof lives in data: feeds, integrations, exports, tracking, billing files.
How the work runs.
- 01
Treat the claim as a hypothesis, not a status
The agent locates the actual feed in the data warehouse and reads its last-written timestamp. In this case the table had last been written hours before the client's email, so the "corrected" figures everyone might have quoted on Monday were still the broken version.
- 02
Capture the broken baseline while it still exists
Before any fix can land, the agent snapshots the feed's current state, row counts, the key rates and distributions the fix is supposed to change, so the after can be judged against a recorded before, not against memory.
- 03
Document the evidence that the fix is needed
Reading the baseline, the agent finds the feed's profit distribution is structurally implausible: the orders carrying over half of all revenue report near-zero margin while the smallest orders report healthy margins, the signature of missing cost data on large orders. That evidence is written down before the fix arrives, not reconstructed after.
- 04
Arm the watcher instead of assigning a human
An hourly automated check watches the table for re-ingestion. Nothing fires while nothing changes, no daily "any update?" chore, no noise in anyone's channel.
- 05
Report with a verdict, not just an alert
When the table is finally rewritten, the watcher fires once and reports whether the key rate actually moved against the captured baseline, "data landed, and here's whether the fix worked", instead of "something changed, go look."
Evidence from the workflow.
Each system has a role.
intake (the feed the client claims to have fixed)
Data warehouse
record of truth (the broken state, captured before the fix)
Baseline snapshot
signal (fires only on re-ingestion)
Scheduler / hourly watcher
action (one verdict message when the fix actually lands)
Team chat
Why this is Operator.
Owns a workflow end to end, running the process inside the authority you set.
- 01
The watcher is read-only against the warehouse: it never mutates the feed it's watching. The baseline and the implausible-distribution finding are written to the project record before the fix lands, so the eventual verdict is checkable. The agent reports; humans decide what to tell the client.
Impact / Outcomes
The wrong answer that was sitting right there, "the file updated recently, here are the numbers", never gets quoted: the timestamp proved nothing had landed since the client's email.
A daily human re-check loop is replaced by an hourly automated watcher that stays silent until there's something to say.
When the fix lands, the team gets a before/after verdict against a captured baseline instead of a shrug, and the evidence for why the fix was needed is already on record.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.