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.