The model was accurate. Across the top 1,500 SKUs of a telecom service supply chain managing 28,000 active parts, it reduced forecast error from 42% to 18%. The signal flagged a stockout risk in a specific cluster of modems and associated components, with five to seven weeks' advance notice. The supply chain today: models that deliver accurate signals to organizations that are not structured to convert them into action; to remove cross-functional input;

The replenishment order went out three weeks late.

Four distribution centers ran out for 12 days. OTIF fell from 96.4% to 91.2%. The total cost of lost sales, emergency freight, and contractual penalties reached US$2.3M.

The model did not fail. The operating model did.

This case is not unusual. It is the dominant pattern in AI implementations in supply chain today: models that deliver accurate signals to organizations that are not structured to convert those signals into decisions. The investment goes into the technology. The gap that absorbs value sits in the governance layer and remains unaddressed.

Every AI-enabled supply chain operation comprises three distinct layers, each with different requirements and failure modes.

Detection is the functional analytics layer where AI performs best and where most investment is concentrated. It surfaces exceptions in near real time: demand anomalies, service risk, supplier delays, and inventory drift. In most modern operations with a reasonable data infrastructure, detection works. AI has made it cheap and reliable. Detection is no longer the competitive constraint.

Decision is where most implementations fail. A signal reaching the decision layer requires four elements to be converted into action: a threshold that defines when action is mandatory, a single named owner with authority to close the decision, a pre-approved playbook of available responses, and a defined time window in which the decision must close. When any of these is absent, the signal enters deliberation. Deliberation is not a decision it is the organizational pattern that replaces decision when accountability has not been assigned.

Execution is where decisions that survive the decision layer often stall. A correct decision to expedite, reallocate, or substitute requires a pre-built execution path: pre-approved spend limits, defined escalation routes, and established supplier protocols. Without these, the decision exists but cannot move. It waits for approvals, negotiations, or capacity that was not pre-committed.

The telecom case failed at the second layer. The threshold was implicit the system flagged a 'high probability of stockout,' not a codified trigger that mandated action within a defined window. The owner was diffuse replenishment decisions were treated as a collective responsibility across planning, procurement, and finance. The playbook was generic. The signal entered a forum. The forum deliberated. The lead time expired.

AI insight without a decision mechanism is not transformation. It is a more expensive version of the same visibility problem.

Among the four governance elements, the threshold is the most consequential and the most frequently missing. It is also the most counterintuitive to design because it requires replacing organizational judgment with pre-committed rules, which creates discomfort.

A functional threshold is not a probability score. 'Stockout risk: high' is a probability flag. It signals a condition but does not mandate a response. Different people will read the same flag and reach different conclusions about whether it is serious enough to act on, who should act, and when.

A functional threshold is a codified rule: if projected inventory coverage falls below 21 days and demand volatility exceeds a defined parameter, a replenishment action is mandatory within 48 hours, and the regional supply planner is the closing authority.

This distinction matters for two reasons. First, it removes the negotiation about whether the signal is serious enough. The threshold eliminates that debate. Second, it assigns mandatory accountability, not a shared concern, but a named person with a defined window. The difference between 'we should look at this' and 'Maria closes this by Thursday' is the difference between deliberation and decision.

For a Fortune 500 operation running IBP with AI-enhanced exception management, threshold design follows three steps:

Step 1 — Identify the decision, not the metric.

The threshold protects a decision, not a KPI. Start with the decision: what action needs to be taken, by whom, and within what window? Build the threshold backward from that.

Step 2 — Codify the trigger condition without interpretation.

The trigger must elicit the same response from every person who reads it. If determining whether the condition is met requires judgment, it is not a threshold. It is a guideline.

Step 3 — Test it against real cases before deploying.

Run the threshold against the last 12 months of exceptions. How many would it have triggered? Were those the right cases? Were there false positives that would have led to unnecessary actions? Adjust until the threshold discriminates correctly.

The second failure pattern is structural and organizational. Most supply chain exceptions are treated as collective decision problems that require input from planning, procurement, finance, and sometimes commercial teams before action can be taken.

This structure exists for good reasons: exceptions often involve trade-offs across functions, and unilateral decisions can optimize locally while creating downstream problems. But collective decision-making processes have a fundamental weakness: they distribute accountability until it disappears.

When five people share ownership of a decision, no one owns it. The signal circulates. Everyone is aware. No one is mandated to close it. The forum meets on Thursday. The lead time expired on Tuesday.

The resolution is not to remove cross-functional input, it is to separate input from authority. Cross-functional teams can inform a decision. Only one person can close it.

Single-threaded ownership does not mean isolated decision-making. It means one person holds the mandate to close after consulting whoever the playbook specifies.

For each decision category in the exception taxonomy, define: who the closing authority is, what their decision SLA is, and who must be consulted before they close. The distinction between 'consulted' and 'authority' is the governance mechanism that prevents both isolation and paralysis.

In the telecom case, the closing authority should have been the regional supply planner. The consultation list: procurement lead for supplier capacity and finance for expedited spend pre-approval. The SLA: 48 hours from the threshold trigger. The playbook: expedite authorization up to US$X is pre-approved, and we can reallocate within the defined inventory parameters.

None of this existed. The decision was a shared concern, the organizational condition that produces 12-day stockouts from 5-week-advance signals.

The third element is the pre-approved playbook, the defined set of responses available to the closing authority when the threshold is triggered.

Most operations have implicit playbooks: experienced planners know that when a stockout risk emerges, the options are to expedite, reallocate, substitute, or shape demand. The problem is that implicit playbooks must be reconstructed each time they are used. The planner must assess what is available, permissible, pre-approved, and what will require additional authorization. Under time pressure, this reconstruction introduces delay and error.

An explicit playbook pre-commits the response set. For each exception category, the playbook defines which actions are available, which constraints apply (budget ceiling, lead-time parameters, supplier agreements), and which actions the owner can execute without additional approval.

The playbook does not remove judgment it removes the need to design the response from scratch under pressure. The owner's judgment applies to selecting the right response from a pre-validated set, not to inventing the set itself.

Playbooks are built from historical exception data, not theoretical scenarios. Extract the most recent 24 months of exceptions from the same category. Which responses were used? Which were effective? Which required additional approvals that delayed execution? Build the playbook from what actually worked, pre-approve the constraints, and retire the responses that consistently stalled.

The playbook is a living document that changes as the operation changes. What does not change is the principle: the owner must be able to act without inventing the response.

The same telecom operation ran a second experiment after the initial stockout. The diagnostic identified response speed as the bottleneck, and the proposed solution was to increase the signal frequency by moving from weekly to daily alert updates to enable faster detection and response.

Within one quarter, logistics costs increased by 18%. OTIF showed no consistent improvement.

Daily alerts triggered reactive decisions. Multiple teams, including regional planning, central planning, and procurement, responded independently to the same signals. Stock was transferred between regions that needed it simultaneously. Expedites were placed for the same SKU from multiple locations. Suppliers received conflicting orders.

The decision architecture had not changed. Only the alert cadence had. Faster signals in a system without thresholds and with single-threaded ownership do not accelerate good decisions, they multiply the volume of ungoverned reactions.

This is the second-order failure of AI investment without governance: organizations that see the signal-to-action gap diagnose it as a speed problem and invest in faster detection. They accelerate input into a system that was already failing to process the volume of signals it was already processing. The result is more noise at higher speeds and a higher cost.

AI does not fail by producing bad signals. It fails by producing more signals than the governance architecture can process into decisions.

For leaders evaluating AI programs in operations, the diagnostic question is not 'Is the model accurate?' Most models, at an adequate scale with reasonable data, produce useful signals. The question is what happens after the signal.

If the signal enters a review forum, it will spark discussion. Discussion builds awareness. Awareness does not produce action.

If the signal hits a threshold and routes to a named owner with a pre-approved playbook and a defined decision window, the signal produces a closed decision. A closed decision produces action.

The four governance elements (threshold, ownership, playbook, and cadence) are not AI features. They are operating model requirements that AI has newly made urgent. They were necessary before AI arrived. AI's contribution is to make their absence both expensive and visible.

Organizations that win the AI cycle in supply chain will not be those that deploy the most sophisticated models. They will be those who used AI's arrival as the catalyst to govern what they should have governed years ago.

The measure of AI in operations is not model accuracy. It is whether the output consistently supports decisions within the right window, without heroics.

If you want the operating-level diagnostics that don't fit a long-form article, that's where I publish them weekly: https://www.linkedin.com/in/psegala/. This newsletter goes deeper into a single argument every other Wednesday. The Tuesday/Thursday posts on LinkedIn are where the smaller, sharper observations land first.
Found this useful? Forward it to one person who owns a decision but has no playbook.