The reconciliation trap
A global industrial manufacturer was operating a five-DC replenishment network across multiple regions.
For six weeks, demand volatility had been rising. OTIF had moved from a stable 96% to the 91–92% range. Expedite spend was already 28–35% above baseline and still trending in the wrong direction.
The planners were not blind.
They could see the system was under pressure. What they could not agree on was which signal should trigger action.
Demand consumption data was running 24 to 48 hours behind actual pull. Supplier confirmations were arriving on schedule but increasingly out of sync with in-transit visibility. Departures were late, yet the supplier status feeds had not yet flagged the risk. Inventory timestamps across the five DCs were updated on different cycles, so the same SKU could appear covered in one view and exposed in another, depending on which system was queried and at what time.
The data was not useless. That was the problem.
It was close enough to suggest risk but not trusted enough to trigger a decision.
Nobody wanted to rebalance inventory too early on a signal that might still resolve itself. Nobody wanted to authorize expedited freight without confidence that the underlying numbers would hold. The default response was to wait for the reconciliation cycle.
Wait for the gaps to close.
Wait for the systems to agree.
Wait for the data to clean itself up.
By the time the data was agreed upon, the backlog had already moved downstream. Three more DCs were short. Expedite spend had locked in another 12% increase. OTIF had deteriorated to the point that the commercial team escalated it to the COO. The post-mortem called it a data quality issue. It was not. By ordinary standards, the data was adequate.
The gap was that nobody had defined what adequate meant for that decision.
In the absence of a governing threshold, the operating model defaulted to a different standard:
Adequate for reconciliation,
Adequate for reporting,
Adequate for audit.
That is a different standard. It has different costs. And it has no decision clock attached. This is the trap many AI initiatives in operations keep walking into.
The statement:
"We need clean data before we can use AI."
is often an articulate way of saying something more structural:
We have not defined the decision that the data is supposed to govern.
Why perfect data became the default
The reflex toward purity did not appear by accident.
Three decades of business intelligence have trained operating leaders to treat clean data as a precondition. Reports had to be reconciled. Dashboards had to tie out. Executive reviews needed a single version of the truth. Audit committees expected numbers to be explainable after the fact.
That discipline mattered. It still matters.
But it was largely built for reporting rhythms. Monthly closes. Quarterly reviews. Annual plans. Executive scorecards. Those rhythms allowed time for reconciliation. Operations rarely have that luxury.
AI inherited the reporting reflex and intensified it.
Every conversation about AI in operations eventually reaches the same gate:
"Do we have the data quality to support it?"
The implicit answer is almost always:
"Not yet."
That framing has a structural flaw.
Operational decisions have never waited for perfect data. Forecast confidence is imperfect. Lead-time variance is real. Supplier reliability is probabilistic. Transportation updates lag physical movement. Inventory snapshots are never as current as the warehouse reality they try to represent.
The question was never whether the data was perfect.
The question was whether it was reliable enough to act on within the window the decision required.
What has changed is not the nature of operational uncertainty. What has changed is the number of systems through which that uncertainty now appears.
ERP.
WMS.
TMS.
OMS.
Planning platforms.
Supplier portals.
Customer feeds.
Carrier updates.
Analytics models.
Each system updates at a different rhythm. Each system was designed for a different purpose. Each system creates a different version of operational reality for a period of time.
That disagreement is not always a defect. Often, it is simply latency. But every visible disagreement now looks like a data quality problem. And every apparent defect triggers the same reflex:
"Wait until it reconciles."
The reconciliation reflex is expensive.
It treats every discrepancy as something to fix before deciding, rather than as something to govern within the decision.
Most operations measure two criteria and leave the other four undefined.
The six criteria of decision-grade data
Decision-grade data has six criteria. Each connects data quality to a specific operating behavior:
What is measured,
Who owns it?
When it triggers action,
And how the decision learns over time.
The first two are familiar.
The other four are where most operating models break.
1. Freshness
The data must be new enough for the decision window, not just the reporting window. I've seen teams delay a rebalancing decision for almost a day, waiting for systems to reconcile.
The decision window was six hours.
The problem wasn't the data.
The problem was the absence of a freshness threshold.
Freshness is not a universal standard. It is a function of the decision. Same data. Different decision. Different freshness requirements.
2. Completeness threshold
Completeness is not 100%. Completeness is the minimum coverage at which the decision becomes safe enough to take. Most operations measure completeness as a data-quality metric. The real question is:
94% of what?
If the missing 6% contains low-risk SKUs, the data may be decision-grade.
If it contains constrained components or strategic customers, it may not.
Completeness only becomes useful when tied to decision exposure.
3. Source reliability
Source reliability is not about whether a system is online.
It is about whether the source owns the operational reality that the data claims to describe. The question is simple:
Does this source own the reality it represents?
If not, the data may still be useful.
It should not automatically be treated as decision-grade.
4. Variance signal
The data must distinguish normal variation from operational exceptions.
Without a variance signal, every deviation looks similar. Teams either react to everything or create firefighting. Or react to nothing until the exception becomes unavoidable. The variance signal answers one critical question:
Is this noise, drift, or exception?
5. Decision linkage
This is where many operations confuse visibility with governance.
The dashboard shows inventory drift.
The signal exists.
The trend is visible.
Nobody owns the call.
Nobody owns the threshold.
Nobody owns the cadence.
Nothing happens.
Visibility says:
The signal is available.

Governance says:
Under these conditions, this signal triggers this owner to make this decision within this time window.
Most operations have rich dashboards and thin decision linkage. The data is governed for reporting. It remains ungoverned for action.
That is how AI becomes decorative.
It makes the signal more sophisticated without changing the decision behavior attached to it.
6. Audit trail
The audit trail is the history of decisions taken under similar conditions and the outcomes those decisions produced.
It is often the rarest criterion. And the most valuable. Without an audit trail, every decision is argued from scratch.
The same debates return.
The same trade-offs are relitigated.
The same owners hesitate.
The result is organizational amnesia.
An audit trail turns decision history into calibration. Over time, thresholds become less political and more empirical. Owners become more accountable. Escalations become less subjective.
This is where decision-grade data becomes more than a data concept.
It becomes a learning mechanism.
Why data quality projects often miss the real defect
The two criteria most operations measure, freshness and completeness, are largely technical. The four criteria they often leave undefined are source reliability, variance signal, decision linkage, and audit trail, which are governance criteria. That is why many data-quality programs do not fix the problem they were created to solve. They improve the data layer without changing the decision layer.
A clean dashboard can still lead to an ambiguous decision.
A reconciled report can still arrive too late.
A complete dataset can still have no owner.
A technically accurate signal can still produce no action.
The defect is not always in the data.
Often, the defect lies in the governance layer that the data is supposed to feed into.
Revisiting the manufacturer
Apply the six criteria to the manufacturer at the start of this article. The data wasn't fundamentally wrong. The operating model had no definition of ready enough. The team had freshness. Some completeness. But weak source reliability. No variance signal. Thin decision linkage. No audit trail. The disagreement between systems became a reason to wait.
Not an input into action. That is why the team acted late. Not because the data was unusable. Because the data was almost usable. And nobody had defined the threshold that converted usable into actionable.
Decision-grade is a governance threshold.
Decision-grade is not a level of data purity.
It is a threshold defined by the decision.
The operating model determines:
the decision window, the owner, the threshold, the confidence boundary, and the cadence by which the decision is reviewed.
Most organizations invest in ETL refinement.
Master data cleanup. Single-source-of-truth architectures. Those investments matter. But they do not automatically produce decision-grade data. Data quality and decision quality are different problems.
The cheapest way to move data from available to decision-grade is often not additional cleansing.
It is governance.
Define the decision.
Name the owner.
Set the threshold.
Clarify the confidence boundary.
Instrument the audit trail.
An immaculate data layer feeding an ungoverned operating model produces immaculate dashboards and slow decisions.
Why AI makes this urgent
AI does not eliminate uncertainty.
It accelerates the arrival of signals inside uncertainty.
That changes the operating requirement. Organizations can no longer rely on slow reconciliation cycles to make action feel safe.
They need explicit standards for acting before all data is agreed upon. This is where many AI initiatives stall. Not because the data is unusable. Because the data is almost usable, and nobody has defined what makes it usable enough.
AI can predict.
Rank.
Recommend.
Alert.
But it cannot create decision governance where none exists.
Installing decision-grade thinking
Most of this can start without a new system, a new budget, or a new team.
It starts with a conversation about one decision.
Four moves carry most of the weight.
Map the critical decisions, not the datasets.
Define the threshold per decision, not per system.
Assign an operational owner, not only a technical owner.
Instrument the audit trail.
These are not technology moves.
They are governance moves.
They require discipline, decision rights, and managerial courage.
That is why many companies would rather buy software.
What AI actually exposes
AI does not create operational excellence.
It reveals whether the operating model already has the discipline to turn signals into governed action.
Perfect data is often the most sophisticated alibi for not deciding.
It sounds responsible.
It sounds disciplined.
It sounds defensible.
And sometimes it is necessary.
But in many operating environments, the pursuit of perfect data becomes a way to avoid defining the standard for action under uncertainty.
Decision-grade data is a harder standard because it forces the operating model to commit.
This decision.
This owner.
This threshold.
This cadence.
This confidence boundary.
Once those are defined, the data either supports the decision or it does not. The argument moves from data purity to decision governance, where the real leverage has been all along.
Most AI initiatives in operations do not stall on bad data.
They stall on data that was almost ready.
And "almost ready" is not a data problem unless the organization has never defined "ready enough".
Reply to this email: Which of the six criteria is your operation missing most today?
I read every reply and often use them to shape future editions.
Paulo Segala · Supply Chain & Operations · Nearly 20 years turning dashboards into decisions.
→ Connect on LinkedIn
Found this useful? Forward it to one person who owns a decision without a playbook.
