Reactive Value Chain Resilience
What follows an alert is usually the same playbook used for the last disruption, and the one before that: build inventory, dual-source, regionalize. ECC's reactive layer runs a live optimisation solve — against your real capacity and constraints — while the disruption is still unfolding, and turns the result into a full set of ranked options grounded in 1,000+ documented disruption cases, rather than an answer to the one question someone thought to ask. Few platforms run this kind of solve live, during an active disruption — and fewer still as a deployed product rather than a research prototype.
ECC moves through six stages — detect, enrich, match, solve, execute, learn — fusing real-time intelligence with your operational graph and this knowledge base. A Resilience Copilot travels with your team through every stage, present from the same signal your team sees, through to the plan your team locks.
How It Works
When a disruption signal crosses the threshold for your operations, ECC moves through this sequence — not as five separate tools, but as one flow, with the Resilience Copilot present at every stage.
01 — Detect
ECC's reactive layer is fed by a partner intelligence network that monitors global risk events continuously, at a scale most internal teams cannot replicate on their own: 10M+ companies monitored, 1.9M+ articles processed daily across 600+ risk categories, covering 234 commodities and 26,000+ locations worldwide — with visibility extending beyond Tier-5 supplier networks, the depth where most disruptions actually originate. When a signal crosses the threshold for your operational footprint, it doesn't join a dashboard queue. It triggers the flow below.
02 — Enrich
The Operations Graph — a partial digital twin of your operational network — runs a ripple-effect analysis outward from the disrupted entity: which materials, assemblies, plants, and orders sit downstream. That traversal is translated directly into the two numbers your leadership will ask for first — material impact (which assemblies, how exposed) and financial impact (cost and revenue exposure, scoped to this event). Not an estimate from a spreadsheet. A computed exposure, from the graph, before the war room has finished convening.
03 — Match
This is where CACM — Constraint-Aware Context Matching — runs against the Resilience Intelligence Fabric: a research-backed graph of 1,000+ documented disruption cases and 150+ mitigation measures across 20+ disruption domains, drawn from 25 years of supply chain disruption research. CACM does not retrieve a generic playbook. It matches your specific scenario to the evidence of what has worked in comparable situations before — and surfaces the full set of strategic options, checked against your real constraints, rather than answering a single question someone thought to ask. The output is a ranked set of options, each tied to its supporting evidence — the raw material for the next stage.
04 — Solve
The ranked options from Match become the inputs to a cuOpt-enabled solver, which solves the underlying capacity problem — supply capacity and production capacity — together, as a single optimisation. This is also where temporal co-optimisation happens: rather than treating the disruption onset, the gap it leaves, and the return to normal supply as three separate decisions made by three different teams at three different times, ECC solves the entire disrupted-to-recovered window as one multi-period problem. The output is a set of plans across that trade-off space — cost, risk, and time-to-recover — not a single recommendation.
One extension is on the roadmap, not in the live platform today: continuously re-solving as the situation changes during the disruption — a supplier capacity update, a new constraint, a shift in the event itself. Today, ECC solves once per disruption signal, against the most current data available at that point. Re-solving across the life of a disruption is a natural extension of this same architecture.
05 — Execute
ECC's flow is intentionally human-in-the-loop. Every plan from Solve — including the full reasoning behind it — is handed to your team to review, adjust, and lock. This is not a gap waiting to be automated away. Research on disruption response consistently finds that trust in algorithmic recommendations falls exactly when the stakes are highest — and the more experienced the decision-maker, the more they want to override the system during a real crisis. Keeping the decision point explicit, and making every recommendation explainable enough to defend in that decision, is how ECC is designed to be used during the disruptions that matter most. A Resilience Thinking Agent that can carry an approved action into the relevant system, within defined guardrails, is the natural next step for execution — the human decision point stays, by design, either way.
06 — Learn
The plan that gets locked — and, over time, the outcome of executing it — feeds back into the Resilience Intelligence Fabric. The knowledge base doesn't just store the case. It refines the constraint envelopes and evidence that CACM matches against next time. The platform doesn't reset between disruptions. It compounds.
Throughout Every Stage
Not a separate chatbot bolted onto the platform. A conversational layer present at every stage of the flow above — from the same signal that triggers Detect, through to the plan your team locks in Execute.
The Copilot's context starts where yours does — at the disruption signal itself. It has access to the same partner intelligence data your team sees in Detect, including the explainability behind each alert: why this was flagged, what evidence supports it, what has changed. Explainability isn't a feature added to the output afterwards — it's part of the data the Copilot works with from the first signal onward.
Beyond explaining what happened, the Copilot answers what-if and trade-off questions directly against the set of plans Solve produced — "what changes if this supplier's lead time shifts by two weeks," "why was this option ranked below that one." Answering those questions against live optimisation output, not a static write-up, took a substantial engineering investment — and it's what makes the Copilot useful in the room where the plan actually gets decided.
The decision stays with your team — the Copilot's job is to make it faster and better-informed, not to make it for you. It removes the time spent reconstructing context, so the conversation in the war room starts at "do we agree with this plan," not "what are we even looking at."
The Mechanism Behind Solve
Classical disruption response treats each period as a separate decision — handle the onset, fill the gap, then plan the return to normal, usually by three different teams at three different times. The solver inside Stage 04 — Solve treats the entire disrupted-to-recovered window as one integrated multi-period problem, solved simultaneously.
Period 1 — Disruption Onset
ECC immediately initiates rerouting to accelerate the primary supplier's recovery — using TTR modelled from material physics, not supplier declaration. This shortens the recovery arc rather than simply waiting for it to pass.
Period 2 — Vacuum Window
Alternate suppliers are temporally scheduled — each with different qualification status, lead times, cost profiles, and compliance posture. This is where the conflicting objectives surface directly: the cheapest alternate is rarely the fastest to qualify, and the fastest is rarely the lowest-risk. ECC's solver works cost, risk, and time-to-recover simultaneously — not collapsed into one number, but as the trade-off space the plan is chosen from. Not a single sourcing decision. A schedule, optimised across all three.
Period 3 — Phase-Back Transition
The handoff is planned from the start. As primary capacity returns, ECC ramps down alternate supply, ramps up primary, and manages inventory through the transition — minimising total recovery cost. All three periods solved simultaneously, not sequentially.
The Science Behind the Flow
The six-stage flow above runs because of a specific architectural decision made at the foundation: two graphs, not one. Understanding why they are separate — and what connects them — explains what makes the Decide and Solve stages qualitatively different from anything a generic SCRM platform or a GenAI assistant can produce.
Graph 1
BOM structures, plants, inventory, supplier tiers, lead times, constraints, orders — the customer's operational network as it actually exists at the moment of a disruption. Answers: what is impacted, and what is feasible right now?
Graph 2
1,000+ documented disruption cases across 20+ domains, 150+ mitigation measures (100+ ICA, 50+ PCA), constraint envelopes, evidence pointers — all structured as a queryable graph. Answers: what has worked before, in situations like this?
Connecting layer
The Resilience Intelligence Fabric normalises the disruption signal into a structured scenario, retrieves and ranks relevant evidence from the Research KG, validates every candidate action against the Operations Graph — and packages the output for the solver. CACM is the matching engine inside RIF: not a similarity search, but a constraint-aware synthesis that produces actions that are both evidence-backed and feasible for this customer, at this moment.
What the knowledge base covers
ICA — Immediate Corrective Actions
The options that restore production and deliveries quickly — ranked by cost, lead time, and feasibility. This is what the flow surfaces in the hours after a signal arrives.
PCA — Permanent Corrective Actions
Structural changes that prevent the same disruption from happening again. Mined from patterns across incidents — where the organisation was exposed, and which levers remove that exposure permanently.
The scientific foundation
ECC's response architecture was built around four properties that the system must have to be useful under crisis conditions. In 2025, Simchi-Levi, Dai, Menache, and Wu published a framework in Operations Research (SSRN 5511218) that independently formalised the same four properties — Insight, Interpretability, Interactivity, and Improvisation — as the requirements for any system combining GenAI with mathematical optimisation in operational contexts. The convergence validates the architecture, not the other way around.
Generating the full set of response options — not answering the one question someone thought to ask. The autonomous option generation gap is where ECC operates.
Every recommendation comes with its reasoning traced to the specific constraint or evidence record that produced it. Planners can defend it in a boardroom.
What-if and trade-off questions answered directly against the live plan set — not a static write-up — through the Resilience Copilot that runs alongside the entire flow.
Re-solving as the situation changes. Today ECC solves once per signal against current data; continuous re-solving across the life of a disruption is the natural next extension of the same architecture.
Research Library
Two research papers — available for download with a work email. The first documents the market gap in prescriptive optimisation; the second explains the architecture that closes it.
Research Paper 01
Evidence from McKinsey, Gartner, and academic literature on the $47M/year blind spot in SCRM, why planning tools fail during live disruptions, why GenAI alone is insufficient, and why the respond-and-recover phases have no incumbent covering them with formal optimisation.
Research Paper 02
A deep-dive into the two-graph architecture (Operations Graph + Research Knowledge Graph), the RIF connecting layer, and the CACM matching algorithm — with the ICA/PCA framework and the knowledge-base breadth that makes constraint-aware option generation possible.
Pilot Programme
ECC is accepting a limited number of pilot partners from automotive OEMs and Tier-1 suppliers. Pilots run on your infrastructure — your Azure environment, your data. Nothing leaves your perimeter.
We review applications within 5 business days. Pilot eligibility criteria: automotive OEM or Tier-1 supplier, minimum 500 active supplier relationships.