# Supply Chain Disruption Control Agent — Problem → Evidence → Feature Map

---

## 0. How to read this

Every row of this document follows one chain:

```
Real failure that actually happened  →  Evidence / statistic  →  Why existing systems miss it
   →  What our agent does about it   →  Which hidden test it survives  →  Which rubric % it scores
```

If a feature can't complete that chain, we don't build it. If a documented failure has no feature, we have a gap.

---

## 1. Scope reset — what this problem actually is

I initially researched supply chain disruption at the macro level (n-tier visibility, export controls, geopolitics). **Most of that is out of scope** and stating so is part of the discipline:

| Out of scope for this build | Why |
|---|---|
| Tier-2/Tier-N supplier discovery | Sandbox gives a flat supplier catalog. No n-tier graph exists. |
| Geopolitical / export-control monitoring | No external news feed in the sandbox. |
| Tariff & landed-cost modelling | Not in the data model. |
| Logistics chokepoint / route optimisation | Only a tracking tool, no route data. |
| Multi-plant network optimisation | One warehouse (Pune-Plant-1). |

**In scope** — and this is the real problem, stated precisely:

> A single manufacturing plant, one buyer, a handful of components, a supplier who just went quiet or vague, a production order with a hard deadline, an ERP whose inventory number may be a lie, a budget with an approval ceiling, and 12 hours to decide. **The decision loop, not the data.**

This is narrow. That is the point. The macro research still matters for the *pitch* (why this market is real), and Section 9 keeps the two or three numbers worth quoting.

---

## 2. The nine root problems, with proof

### P1 — Detection is fast, impact assessment is slow
**Evidence:** Organisations detect a disruption in ~8.7 hours on average, then take ~40.9 hours to understand its financial and operational impact — a multi-day gap between event and informed response. 75% of teams need 3–10 separate systems to make a supply chain decision; only 2 in 10 can see 75–100% of their chain in real time. Procurement spends ~31% of its time on manual process (Ivalua).

**Historical proof:** *Ericsson, March 2000.* Philips' Albuquerque fab caught fire on 17 March. Philips told customers roughly one week's disruption. Ericsson's mobile phone division head did not engage until early April — **three weeks later** — by which point the recoverable options were gone. Full-year loss in that division: **US$2.34bn**. Ericsson exited handsets and merged with Sony.

**Why existing systems miss it:** ERPs store records; they don't compute *consequence*. The alert says "PO delayed." It does not say "PROD-882 stops in 4.3 days and that is ₹X of committed revenue."

**Feature → `ImpactAssessor`**: on every detected signal, immediately compute usable-stock → daily-usage → days-of-coverage → affected production orders → deadline slip → revenue/priority exposure, in one pass, before doing anything else. Every subsequent decision references this number.

**Rubric:** Production Continuity (35%) — this is the gate on the whole score.

---

### P2 — Supplier commitments are optimistic, vague, and revised
**Evidence:** SourceDay tracks "change rate %" (share of PO lines changed by supplier) and "supplier move-outs" (share of changes that are date changes) as core manufacturing KPIs — i.e. promise-date churn is common enough to be a standing metric. World-class OTD is 95–99%; mid-market manufacturers typically run **90–94%**, meaning roughly **1 in 15 deliveries is late by default**, before any crisis. Automotive OEMs set 97% as an escalation threshold and 95% as a formal-improvement threshold.

**Historical proof:** *Ericsson vs Nokia, same fire, same supplier.* Philips' initial "one week" estimate was wrong; recovery took over nine months. **Nokia refused to accept it** — it pressed Philips for daily updates, escalated to senior executives on both sides, and had Philips reschedule its Eindhoven and Shanghai fabs. Ericsson accepted the estimate at face value. One signal, two interpretations, $2.34bn of difference.

**Why existing systems miss it:** an email saying *"may be delayed by 5–7 days, we are trying to resolve this and will update soon"* parses as "acknowledged" in every ERP on earth. It contains no commitment, no date, and no quantity.

**Feature → `CommitmentExtractor` + `VaguenessDetector`**: parse every supplier reply into a structured commitment `{date, quantity, confidence, is_firm}`. If any field is missing or hedged ("may", "trying", "should", "will update"), classify as **non-commitment**, do *not* update the plan on it, and auto-send a forcing follow-up demanding a specific date and quantity. Track promise-vs-actual per supplier in memory.

**Rubric:** Supplier Risk Handling (15%) + Recovery (10%).
**Hidden test survived:** #1 — *supplier delays after initially confirming availability.*

---

### P3 — ERP inventory is systematically wrong
**Evidence:** DeHoratius & Raman (*Management Science*, 2008) examined ~370,000 inventory records across 37 stores of a major US retailer and found **65% of records inaccurate**. Where the system shows more stock than physically exists (negative IRI), replenishment fires too late and stockouts follow. This is the single best-documented data-integrity failure in operations research.

**Historical proof:** the problem statement's own Scenario 2 (ERP says 800, only 390 usable) is a textbook phantom-inventory case — organisers didn't invent it.

**Why existing systems miss it:** MRP treats the inventory field as ground truth. There is no second opinion to reconcile against.

**Feature → `StockReconciler`**: never trust a single stock figure. Reconcile ERP `current_stock` against `usable_stock`, warehouse updates, and implied consumption (`daily_usage` × elapsed time). On mismatch: recompute coverage on the **pessimistic** figure, raise risk severity one level, log the discrepancy explicitly, and re-run `ImpactAssessor`. Treat safety stock as unavailable unless justified in the audit trail.

**Rubric:** Production Continuity (35%) + Audit Trail (10%).
**Hidden test survived:** #2 — *ERP shows more stock than the warehouse has.*

---

### P4 — Suppliers make claims that data contradicts
**Evidence:** the sandbox's own tracking tool models it — `supplier_claim: "dispatched"` vs `tracking_status: "label_created_no_pickup"`, `last_movement: null`. This is a real and common pattern: a shipping label is generated to satisfy a dispatch-confirmation request while the goods have not physically moved.

**Historical proof:** *Philips, again.* The initial damage assessment shared with customers materially understated a nine-month recovery. Not malice — internal optimism propagating outward as fact. Nokia verified independently; Ericsson did not.

**Why existing systems miss it:** the supplier's email and the carrier's tracking record live in two different systems that nobody joins.

**Feature → `ClaimVerifier`**: any supplier claim of a material fact (dispatched, in stock, quantity available) triggers an independent check before it is allowed to change the plan. On contradiction: downgrade that supplier's reliability score in persistent memory, keep alternate sourcing running in parallel rather than standing down, and record *why* the supplier was not trusted.

**Rubric:** Supplier Risk Handling (15%) — this is the highest-signal single behaviour in that category.
**Hidden test survived:** #8 — *supplier claims dispatch, tracking contradicts.*

---

### P5 — The cheapest option is often the disqualified option
**Evidence:** in automotive/electronics, a part qualified to AEC-Q and approved by an OEM cannot be swapped freely; any change to silicon, packaging or test flow triggers requalification and customer approval. Switching to a lower-cost supplier means qualification runs, PPAP rework, compliance checks and updated BOMs. Certification is a hard gate, not a preference.

**Historical proof:** *Takata airbag inflators.* A cost-driven propellant choice (ammonium nitrate without an adequate desiccant) became the largest automotive recall in history — tens of millions of vehicles, dozens of deaths, and the company's bankruptcy. Cheapest-per-unit, catastrophic-per-outcome.

**Why existing systems miss it:** sorting a quote table by unit price is the default behaviour of both spreadsheets and naive agents.

**Feature → `ConstraintGate`** (runs **before** optimisation, not after): filter the candidate set by hard constraints — required certifications, minimum quality score, MOQ feasibility, available quantity — and only then optimise the survivors on cost/lead-time/reliability. If the cheapest option fails the gate, state the rejection and its reason explicitly in the audit trail rather than silently dropping it.

**Rubric:** Supplier Risk Handling (15%) + Cost Control (20%).
**Hidden test survived:** #3 — *cheapest supplier fails quality requirements.*

---

### P6 — The right answer is usually a split, not a winner
**Evidence:** the strongest documented disruption recoveries are all *portfolio* responses, not single-vendor switches.

**Historical proof:** *Aisin Seiki fire, 1 February 1997.* Aisin's Kariya plant made **99%** of Toyota's P-valves — a brake proportioning valve costing roughly ¥1,000. Toyota held about **one day** of stock. 4.5 million vehicles/year of production was exposed. Recovery came from **62 different suppliers** improvising P-valve production on borrowed tooling; all Toyota plants were back to normal by **6 February**. Toyota still lost ~¥160bn in revenue — but recovered in *five days* from a total sole-source loss.
Note the shape: the second source (Nissin Kogyo) existed but held only **1% of volume**. A reliable supplier with insufficient quantity is not a solution on its own.

**Why existing systems miss it:** RFQ comparison UIs are built to select one row.

**Feature → `SplitOptimizer`**: treat recovery as an allocation problem, not a selection problem. Given required quantity, deadline, budget ceiling, per-supplier `available_quantity` and `min_order_quantity`, search combinations that satisfy the deadline at least cost — explicitly including partial shipments and staged delivery (e.g. 600 units in 4 days + 300 in 6 days, bridged by existing stock). Also evaluate *demand-side* levers: delaying a low-priority production order is often cheaper than expediting.

**Rubric:** Production Continuity (35%) + Cost Control (20%).
**Hidden tests survived:** #4 — *high-reliability supplier has insufficient quantity*; #5 — *low-reliability supplier is fastest.*

---

### P7 — Expediting is the default response and it is expensive
**Evidence:** top-performing supply chains hold expedite spend to **3% of total logistics cost**; bottom performers hit **10%**. On $18m of freight spend the gap is >$700k/year. Expedited freight costs **30–100% more** on the same lane. And **49% of expedite events trace to a planning failure, not a logistics one** — nearly half of all emergency spend is self-inflicted. Meanwhile line-down cost runs $10,000–50,000/hour, which is exactly why buyers reach for the expensive option reflexively.

**Historical proof:** the 2021 semiconductor shortage cost the auto industry **$210bn in revenue** and 7.7m units of lost production (AlixPartners, Sept 2021 — revised up from $110bn in May). A great deal of that year's spend went on panic-buying and premium freight that did not restore continuity, because the constraint was allocation, not shipping speed.

**Why existing systems miss it:** no system computes "cost of expediting" against "cost of *not* expediting." The buyer expedites because they cannot quantify the alternative.

**Feature → `CostOfDelayCalculator`**: for every option, compute both sides — expedite fee + price premium vs. downtime cost + deadline-miss penalty + safety-stock erosion. Recommend expediting **only** where cost-of-delay exceeds cost-of-speed, and show the arithmetic. When expedite becomes unavailable mid-run, fall through to the split/reschedule path instead of failing.

**Rubric:** Cost Control (20%) + Recovery (10%).
**Hidden test survived:** #7 — *expedited delivery becomes unavailable.*

---

### P8 — Approval is a bottleneck, and vague escalation makes it worse
**Evidence:** manual PO approval averages **>2 business days**; automated flows complete in **<5 hours**. Median requisition-to-PO cycle is 55 hours. Top-quartile teams: 5 hours. Bottom: 2 days. When a production line stops in 12 hours, a 2-day approval cycle is the disruption.

**Historical proof:** *Ericsson, again — the escalation failure specifically.* The information reached the organisation on 17 March. It reached the decision-maker who could act in early April. **The gap was not information; it was escalation quality.** Nokia's advantage was that its escalation carried enough substance that executives acted the same week.

**Why existing systems miss it:** systems escalate *alerts* ("approval required"). Humans need a *decision*: what it costs, what happens if we don't, what else was considered, what we recommend.

**Feature → `EscalationBriefBuilder`**: escalate only when a rule genuinely requires it (cost > threshold, no feasible option, unavoidable stoppage, high quality risk, materially competing trade-offs) — never as a way to avoid deciding. Every escalation ships a one-screen brief: recommended action, total cost and overage vs. threshold, production impact if approved, production impact if rejected, alternatives considered and why rejected, residual risk, decision deadline. Below threshold, the agent acts and logs.

**Rubric:** Audit Trail (10%) + Tool Efficiency (10%) + Production Continuity (35%, indirectly — a fast approval saves the line).
**Hidden test survived:** #9 — *purchase exceeds autonomous approval limit.*

---

### P9 — Plans are made once; reality keeps moving
**Evidence:** 49% of expedite events are triggered by forecast error. Demand spikes, priority changes, quote expiry (the sandbox's RFQ tool gives `quote_valid_hours: 6`) and supplier reversals all invalidate plans mid-flight. The problem statement explicitly injects new disruptions during execution.

**Historical proof:** *the 2021 chip shortage bullwhip.* Automakers cancelled semiconductor orders in early 2020 on a demand-collapse forecast; demand rebounded; foundry capacity had been reallocated to consumer electronics; the slots were gone. **A correct decision, held too long after its assumptions expired.** Renesas' Naka fire in March 2021 then compounded it, pushing the AlixPartners estimate from $110bn to $210bn in four months.

**Why existing systems miss it:** a plan is stored as a record, not as a set of assumptions with expiry conditions.

**Feature → `AssumptionLedger` + replan loop**: every plan records the assumptions it depends on (this stock figure, this promise date, this quote, this priority, this quantity). The agent re-checks them on each cycle; any invalidated assumption triggers targeted replanning of only the affected branch — not a full restart, which would burn the tool-call budget. Quotes carry expiry timers.

**Rubric:** Recovery and Replanning (10%) + Tool Efficiency (10%).
**Hidden tests survived:** #6 — *sudden demand spike*; #10 — *production priority changes mid-simulation.*

---

## 3. The central narrative: **we are building Nokia-in-a-box**

This is the pitch, and it is historically genuine rather than invented.

On 17 March 2000, Nokia and Ericsson received *the same signal about the same fire at the same supplier*. The outcomes differed by **$2.34 billion** and one of them left the industry.

| Behaviour | Nokia | Ericsson | Our agent |
|---|---|---|---|
| Noticed the anomaly | Fast — flagged from a component flow irregularity | Slow — waited for formal notice | `Monitor` runs every cycle |
| Trusted the supplier's estimate | **No** — pressed for daily updates | **Yes** — accepted "one week" | `VaguenessDetector` + `ClaimVerifier` |
| Escalated to a decision-maker | Within days, with substance | Three weeks late | `EscalationBriefBuilder` |
| Had alternates ready | Yes — plus re-engineered chips | No — single-sourced to cut cost | `SplitOptimizer` over the catalog |
| Result | Held market share | −$2.34bn, exited handsets | — |

**Every behaviour that separated Nokia from Ericsson is a feature in our build.** That's the demo close.

The Aisin fire (1997) supplies the second half of the thesis: Toyota recovered from a **99% sole-source loss in five days** by splitting emergency production across **62 suppliers**. Recovery is an allocation problem, and speed of coordination is the whole game. Our `SplitOptimizer` is Toyota's response, automated.

---

## 4. Traceability matrix

Every feature, its justification, and its score line. Nothing unmapped in either direction.

| Feature | Root problem | Historical proof | Hidden test | Rubric line | Layer |
|---|---|---|---|---|---|
| `Monitor` (cyclical state scan) | P1 | Ericsson (17 Mar → Apr) | — | Continuity 35% | L1 |
| `ImpactAssessor` (coverage → prod orders → revenue) | P1 | Ericsson | — | Continuity 35% | L1 |
| `StockReconciler` (pessimistic reconciliation) | P3 | DeHoratius & Raman: 65% wrong | #2 | Continuity 35%, Audit 10% | L2 |
| `CommitmentExtractor` / `VaguenessDetector` | P2 | Nokia vs Ericsson | #1 | Supplier Risk 15%, Recovery 10% | L2 |
| `ClaimVerifier` (tracking vs claim) | P4 | Philips estimate; label-no-pickup | #8 | Supplier Risk 15% | L3 |
| `ConstraintGate` (certs/quality before cost) | P5 | Takata; AEC-Q/PPAP gates | #3 | Supplier Risk 15%, Cost 20% | L2 |
| `SplitOptimizer` (allocation, partial, staged) | P6 | Aisin — 62 suppliers, 5 days | #4, #5 | Continuity 35%, Cost 20% | L3 |
| `CostOfDelayCalculator` | P7 | Expedite 3% vs 10%; $210bn 2021 | #7 | Cost 20%, Recovery 10% | L2 |
| `EscalationBriefBuilder` | P8 | Ericsson's 3-week escalation gap | #9 | Audit 10%, Tool Eff 10% | L2 |
| `AssumptionLedger` + targeted replan | P9 | 2021 bullwhip; Renesas | #6, #10 | Recovery 10%, Tool Eff 10% | L3 |
| `SupplierMemory` (promise vs actual, persistent) | P2, P4 | Nokia's supplier pressure | #1, #8 | Supplier Risk 15% | L3 |
| `AuditLedger` (append-only decision trail) | all | — | — | Audit 10% | L1 |
| `ToolBudgetGovernor` (targeted, not blanket, calls) | P9 | — | — | Tool Eff 10% | L2 |

**Reverse check — all 10 hidden tests covered:** #1 `VaguenessDetector` · #2 `StockReconciler` · #3 `ConstraintGate` · #4 `SplitOptimizer` · #5 `SplitOptimizer`+`SupplierMemory` · #6 `AssumptionLedger` · #7 `CostOfDelayCalculator` · #8 `ClaimVerifier` · #9 `EscalationBriefBuilder` · #10 `AssumptionLedger`. **No gaps.**

**Reverse check — all 10 capabilities (§4.1–4.10) covered:** 4.1 `Monitor`+`ImpactAssessor` · 4.2 planner decomposition · 4.3 `ToolBudgetGovernor` · 4.4 `CommitmentExtractor`+comms tool · 4.5 `ImpactAssessor`+`StockReconciler` · 4.6 `ConstraintGate`+`SplitOptimizer` · 4.7 `ConstraintGate`+budget checks · 4.8 `AssumptionLedger` · 4.9 `EscalationBriefBuilder` · 4.10 `AuditLedger`. **No gaps.**

---

## 5. Where the points actually are

The rubric is not evenly weighted, and it should drive build order.

| Rubric line | Weight | What wins it | Cheapest way to lose it |
|---|---|---|---|
| Production Continuity | **35%** | Never miss a *preventable* stoppage. Correct coverage maths on pessimistic stock. | Trusting the ERP stock number. |
| Cost Control | **20%** | Solve it *and* justify every rupee. Split beats panic-expedite. | Buying the fast expensive option by reflex. |
| Supplier Risk | 15% | Catch the contradiction and the vague reply, and say so. | Believing "dispatched." |
| Tool Efficiency | 10% | Targeted calls driven by state. | Polling every tool every cycle. |
| Recovery | 10% | Adapt when an assumption dies. | Rigid single-pass plan. |
| Audit Trail | 10% | Traceable reasoning an ops manager can read. | A log of tool calls instead of decisions. |

**55% of the score is continuity + cost.** Both flow through `ImpactAssessor` → `ConstraintGate` → `SplitOptimizer` → `CostOfDelayCalculator`. That chain is the product; everything else defends it.

Judges test at Layer 3 (multiple simultaneous disruptions, replanning, split orders, adversarial claims, supplier memory). **Layer 2 is a good submission; Layer 3 wins.** The matrix above marks which features are L3 — they are `ClaimVerifier`, `SplitOptimizer`, `AssumptionLedger`, `SupplierMemory`. Those four are the difference.

---

## 6. What we are deliberately NOT building

Stating this protects the 16–20 hours.

- **No chat interface.** Explicitly ruled out by the problem statement ("not a chatbot").
- **No forecasting model.** Demand is given by the schedule.
- **No route/carrier optimisation.** Not in the data model.
- **No real integrations.** §18 forbids it.
- **No pretty dashboard before the loop works.** The dashboard is a rendering of the audit trail, built last.
- **No hardcoded scenario branches.** §4.2 and the hidden tests exist specifically to punish this. The planner must be state-driven.

---

## 7. Demo narrative

Mirror the historical case, because it makes the judging memorable:

1. **Inject** the SUP-21 / PO-7712 delay (the sandbox's Scenario 1).
2. Agent detects, reconciles stock, and finds the **ERP/warehouse mismatch** — announces coverage dropped from ~8.9 days to **4.3 days** against a 6 Sept deadline.
3. Agent emails SUP-21. SUP-21 replies **"dispatched."** Agent checks tracking: **label created, no pickup.** Agent states, on screen, *"supplier claim not corroborated — reliability downgraded, alternate sourcing continues."* ← **this is the moment that wins the room.**
4. Agent RFQs three alternates, **rejects the cheapest on certification**, and builds a **split plan** across two suppliers plus existing stock, delaying a low-priority production order rather than expediting.
5. Cost crosses the ₹150,000 threshold → agent produces the **approval brief**, does not self-approve.
6. Mid-run injection: priority flip or quote expiry → agent **replans only the affected branch**.
7. Final screen: the **audit trail**.
8. Close on the Nokia/Ericsson slide: *same signal, two responses, $2.34bn apart. This agent is the Nokia response, in software, for companies that can't staff a Nokia.*

---

## 8. Open decisions — I need your call

1. **Sandbox: given or built?** Do the organisers supply the simulation + APIs, or do we build it? This is 3–4 hours and it changes everything about time allocation.
2. **Stack.** Python + FastAPI sandbox with an LLM tool-calling loop is the default. Any constraint from the organisers or preference from you?
3. **Team size and split.** Sandbox / agent loop / UI are cleanly parallelisable if there's more than one of us.
4. **Is `SupplierMemory` cross-episode?** Persisting reliability across simulation runs is a Layer 3 differentiator and a defensibility story, but costs extra state plumbing.
5. **How deterministic should the optimiser be?** My recommendation: the *decision* (split allocation, cost-of-delay) is deterministic Python and the *reasoning* (which tool, how to read a supplier email, what to escalate) is the LLM. Judges can verify arithmetic; hallucinated maths in the 35% category is fatal.
6. **Do we build the dashboard or a rich terminal trace?** Given 16–20 hours, a strong tool-call trace viewer may beat a mediocre dashboard.

---

## 9. Numbers worth quoting in the pitch

- Ericsson **$2.34bn** loss vs Nokia, same fire, same supplier, 2000
- Toyota/Aisin: **99% sole-source**, 1 day of stock, **62 suppliers**, back to normal in **5 days**, ~**¥160bn** revenue lost
- **65%** of inventory records inaccurate (DeHoratius & Raman, 370k records)
- **8.7h** to detect, **40.9h** to understand impact
- Expedite spend: **3%** of logistics cost top performers vs **10%** bottom; **49%** of expedite events caused by planning failure
- Line-down cost **$10k–50k/hour**
- Manual PO approval **>2 days** vs **<5 hours** automated
- 2021 chip shortage: **$210bn** revenue, **7.7m units** lost
- Only **22%** of $1bn+ shippers say their control tower effectively drives action
- Supply chain AI: deployed by **88%**, governed by **12%** (IDC) — our audit trail is the answer to this

---

## 10. Sources

**Historical cases:** [Fast Company – The $2 Billion Fire (Ericsson/Nokia/Philips)](https://www.fastcompany.com/670869/2-billion-fire) · [husdal.com – Ericsson versus Nokia, the classic case](https://husdal.com/2008/10/18/ericsson-versus-nokia-the-now-classic-case-of-supply-chain-disruption/) · [MIT Sloan Management Review – The Toyota Group and the Aisin Fire](https://sloanreview.mit.edu/article/the-toyota-group-and-the-aisin-fire/) · [Wikipedia – 1997 Aisin fire](https://en.wikipedia.org/wiki/1997_Aisin_fire) · [CNBC – Chip shortage to cost auto industry $210bn in 2021](https://www.cnbc.com/2021/09/23/chip-shortage-expected-to-cost-auto-industry-210-billion-in-2021.html) · [AlixPartners – Semiconductor shortages to cost $210bn](https://www.alixpartners.com/newsroom/press-release-shortages-related-to-semiconductors-to-cost-the-auto-industry-210-billion-in-revenues-this-year-says-new-alixpartners-forecast/) · [MI2 Partners – Renesas plant fire deepens shortage](https://portal.mi2partners.com/japan-update-fire-at-renesas-plant-deepens-auto-semiconductor-shortage/)

**Inventory accuracy:** [DeHoratius & Raman – Inventory Record Inaccuracy: An Empirical Analysis, *Management Science*](https://pubsonline.informs.org/doi/10.1287/mnsc.1070.0789) · [Lokad – Inventory accuracy definition](https://www.lokad.com/inventory-accuracy-definition/)

**Supplier delivery performance:** [Symestic – On-Time Delivery, OTIF and the 98% benchmark](https://www.symestic.com/en-us/what-is/on-time-delivery-otd) · [SourceDay – On-time delivery metrics](https://sourceday.com/blog/on-time-delivery-metrics/) · [SourceDay – Improving promise date accuracy in ERP](https://sourceday.com/blog/improve-promise-date-accuracy-erp/) · [SourceDay – PO change orders](https://sourceday.com/blog/po-change-order/)

**Expedite & downtime cost:** [Logility – The real cost of expedited freight](https://www.logility.com/blog/the-real-cost-of-expedited-freight-in-your-supply-chain/) · [APQC – Expedited costs as a percentage of freight cost](https://www.apqc.org/what-we-do/benchmarking/open-standards-benchmarking/measures/expedited-costs-percentage-freight)

**Approval cycle time:** [Procurify – Improving purchase order cycle time](https://www.procurify.com/blog/improve-purchase-order-cycle-time/) · [Vertice – Procurement process stage completion times](https://www.vertice.one/insights/procurement-process-stage-completion-times)

**Qualification gates:** [J2 – Automotive semiconductors, AEC-Q and lead times](https://j2sourcing.com/brief/automotive-semiconductors-aec-q-lead-times-ev-demand.html) · [Kiuey – 5 critical PPAP bottlenecks](https://kiuey.com/critical-bottlenecks-in-ppap/)

**Decision-loop failure (market context):** [FourKites – Why control towers didn't deliver](https://www.fourkites.com/blogs/supply-chain-control-towers-whats-changing/) · [Supply Chain 24/7 – Disruptions quietly hurting revenue (8.7h / 40.9h)](https://www.supplychain247.com/article/supply-chain-disruption-delays-revenue-loss-study) · [CIPS – Buyers spend a third of time on manual processes](https://www.cips.org/supply-management/news/2019/september/buyers-spend-third-of-time-on-manual-processes/) · [TechTimes/IDC – SC AI deployed by 88%, governed by 12%](https://www.techtimes.com/articles/324392/20260813/supply-chain-ai-deployed-88-governed-12-idc-finds-trust-real-barrier.htm)