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.