• Most supply-chain systems only see the suppliers you pay directly. Disasters rarely respect that boundary.

• DOMINO models the whole chain as a graph in FalkorDB and follows a disruption hop by hop, down to the customer orders that will actually ship late.

• It measures real capacity with max-flow, rejects "backup" suppliers that share the same failure, and tests five recovery plans inside GRAPH.COPY sandboxes.

• An AI agent (Claude, over MCP) picks the tools. It never writes a query and never places an order on its own. A human approves; the database enforces the rest.

• Across 40 simulated disruptions, the graph-aware plans left 71 orders late versus 130 for the same planner limited to a tier-1 view.

Links: Live demo · Code · Video

Contents

1. The incident nobody's dashboard caught

2. Why this is a graph problem

3. Exposed is not late

4. How much can we really get? Ask max-flow

5. The backup that wasn't

6. Rehearsing the fix on a copy of the world

7. The agent proposes, a human decides

8. Memory that outlives a reset

9. Does the graph actually help? The numbers

10. Five things FalkorDB taught me

11. Running it

12. What's still missing

1. The incident nobody's dashboard caught

Here is the scenario DOMINO is built around. The companies are fictional; the geography and the failure mode are very real.

Day 0. Monsoon flooding hits Ayutthaya, Thailand. Industrial estates close. Recovery is expected in three to five weeks.

Kestrel Devices, a laptop maker, checks its supplier list. Nobody it buys from is in Thailand. The tier-1 dashboard shows zero affected suppliers.

Day 0, a few seconds later. DOMINO declares an incident on VoltCell Energy, a battery-cell factory in Ayutthaya, and follows the graph upstream to downstream. VoltCell sells cells to two of Kestrel's battery-pack suppliers, BatteryMax in Penang and PowerCell Packs in Hai Phong. 38 customer orders depend on that chain.

Day 11. The Penang plant runs out of 6-cell battery packs.

Day 26. The Bac Ninh plant runs out of 4-cell packs.

Day 28. VoltCell is back. Too late for 13 orders, carrying $536,370 in late-delivery penalties.

What this tells us: the risk was never in the supplier list. It was two hops away, in a factory the company had no contract with. Any tool that stops at tier 1 is structurally blind to it.

2. Why this is a graph problem

A supply chain is a network, but most systems store it as rows of "who do I buy from". That's one hop. The flood was further out.

In DOMINO the whole chain is a single FalkorDB graph:

• Sites that make parts, and which site FEEDS which.

• Which sites SUPPLY which plants, with weekly capacity on the edge.

• What each product REQUIRES, what each plant STOCKS and BUILDS.

• Customers, the orders they PLACED, and where those orders are FULFILLED_AT.

Once it's a graph, "who does this flood hurt?" is a path query:

MATCH path = (hit:Site)-[:FEEDS*0..4]->(t1:Site)-[:SUPPLIES]->(pl:Plant)

and from the plant on to products and orders. The path is not just the answer; it's the evidence. When DOMINO says an order is at risk, it can show the exact chain from the flooded factory to that order. In the war room UI those paths are labelled E1, E2, E3 and the agent has to cite them.

3. Exposed is not late

This distinction is where a lot of risk tooling loses people's trust.

38 orders are exposed: they depend on VoltCell somewhere upstream. But exposure isn't damage. A plant with enough stock rides out a 28-day outage. An order due after the factory reopens is fine.

So DOMINO projects the shortage day by day, per plant and per part: stock on hand, what is still arriving, when each order needs its parts. Only the orders that actually run dry count as projected late. That's 13, not 38.

If an agent cried wolf about all 38, planners would learn to ignore it within a week.

4. How much can we really get? Ask max-flow

The obvious next question: if we shift volume to the suppliers that still work, how much can we get?

The naive answer adds up tier-1 capacity. For 6-cell packs at Penang that's 980 a week.

That number is wrong, because tier-1 suppliers need inputs, and inputs come from upstream sites with their own limits, some of them under water. DOMINO builds a small flow network from the graph, splits each site into an in-node and an out-node so site capacity counts too, and runs FalkorDB's algo.maxFlow on it.

The real figure is 650 a week.

The min cut of the same network tells you where the bottleneck is. That's far more useful than a list of edges that happen to be saturated, which is what you get if you eyeball utilisation.

5. The backup that wasn't

When DOMINO looks for alternatives, it checks each candidate's upstream paths too.

AmpereOne in Johor Bahru looks like a great backup for 4-cell packs: approved, with spare capacity on paper. But it buys its cells from the same flooded VoltCell factory. Its clean capacity is zero, and DOMINO rejects it, with the evidence path attached.

The rule matters in both directions. Exposure alone is not a reason to reject: PowerCell Packs also touches VoltCell, but it still has healthy capacity, so it stays on the table with a warning. A source is rejected only when nothing clean is left.

The naive tier-1 plan in the demo does pick AmpereOne. It looks cheaper on paper, and it fails two of DOMINO's post-execution checks.

6. Rehearsing the fix on a copy of the world

Before anyone approves anything, DOMINO tests five strategies:

Each one runs inside a copy of the live graph made with GRAPH.COPY. The plan executes for real in the copy, the same projection engine scores it, and the copy is dropped.

This is my favourite part of the design. There is no separate simulator that can drift out of sync with production logic. "What happens if we buy from these three suppliers?" becomes "do it in a sandbox and look", using the exact code that will later run against the real world.

The same trick powers the demo's Reset the world button: a pristine graph is copied over the live one.

7. The agent proposes, a human decides

The AI is deliberately on a short leash.

• It chooses, it doesn't compute. The model (Claude, over MCP) picks from 16 fixed, parameterised tools: resolve the places in an alert, trace exposure, project shortages, compute capacity, find alternatives, simulate, submit a plan. Every number comes from a deterministic engine.

• It never writes Cypher. Every query is a checked-in file. Every ID the model passes is resolved against the graph first; anything unknown comes back as unknown_entity.

• It can only propose. submit_plan_for_approval pauses the run. A person approves or rejects in the war room UI. If they reject with feedback ("keep it under $120K"), the agent has to re-plan; resubmitting the same plan is refused.

• The database enforces the approval. It is bound to the plan's hash and to a world version stored in the graph. If anything changed since the simulation, the approval fails and the agent must simulate again.

• One atomic write. On approval, a single query marks the decision executed and creates the purchase orders, the allocations and an audit record. A unique constraint on PurchaseOrder.id makes duplicate orders impossible. Then nine verification queries check budget, capacity, material balance and receipt counts.

• The report gets audited too. If the agent cites an ID, an evidence path or a number that no tool returned during that run, the report is rejected and has to be fixed.

In the Monsoon case the approved plan buys battery packs from three other suppliers for $142,475 and protects 12 of the 13 late orders.

Note the wording: protected (projected). The purchase orders exist; the parts haven't arrived. I made the UI say exactly that, because "fulfilled" would be a lie.

8. Memory that outlives a reset

Every completed run writes lessons into a separate memory graph, linked to the sites and parts they're about. Resetting the world doesn't touch it.

Next time something hits Ayutthaya, the agent's recall_history call returns the earlier lesson with the date it was learned, for example that VoltCell is a hidden shared upstream of three tier-1 suppliers, and the agent has to check it against the current run.

It's honest to say what memory does not do yet: it informs the agent and the report, but it doesn't change the allocator's maths.

9. Does the graph actually help? The numbers

It's easy to say "graphs are better". I wanted a number.

The setup: 20 generated worlds, each hit by two disruptions, so 40 cases and 4,766 orders. Every method runs on its own copy of the graph and is scored by the same projection.

The interesting comparison is B1 against B2. They use the same allocator and the same budget. The only difference is that B2 can see upstream.

• B1's plans break. It picked a source with zero clean capacity in 20 of the 40 cases, failed 40 verifier checks, and 88 of the orders it marked "protected" were still late.

• B2 never loses. Fewer late orders in 19 cases, a tie in 21, worse in 0.

• The gain is specific. In the factory-fire scenario every method ties at zero late orders, because there the backup supplier is genuinely independent. The graph pays off exactly when a backup shares an upstream site, which is the failure mode it was built for.

To avoid grading my own homework, a separate checker recomputes everything from a raw export of the graph with NetworkX. It imports no DOMINO code. It agrees on every exposed order (998/998), every late order (386/386) and every capacity (85/85).

10. Five things FalkorDB taught me

A few lessons I'd pass on to anyone building on FalkorDB:

1. Alias every relationship you count or sum. With two parallel edges between the same nodes, a pattern that doesn't name the relationship returned one row in my tests; naming it returned two. Unnamed edges in an aggregate give you wrong totals without any error.

2. A MATCH that misses is silent. In a batched UNWIND loader, a row whose endpoint doesn't exist is simply dropped. Return a count and compare it with the batch size.

3. algo.maxFlow only returns edges that carry flow. If the max flow is zero, you get no rows at all. Treat "empty" as zero, not as a failure.

4. GRAPH.COPY carries indexes and constraints across, so a sandbox is ready to query the moment it exists.

5. Use GRAPH.RO_QUERY for every read. "This tool can't change anything" becomes a database guarantee instead of a code-review promise.

11. Running it

Everything runs in one container: FalkorDB listening only inside it, the FastAPI backend, the MCP server and the React war room. A full agent run peaks at about 160 MB of memory.

The war room has four modes:

• Replay plays back a recorded Claude Code run, step by step, without touching the graph.

• Demo runs a scripted agent through the real tools, the approval pause and the verification.

• Claude Code lets you drive DOMINO from your own terminal over MCP. It's one command:

claude mcp add --transport http --scope user domino https://domino-jiie.onrender.com/mcp/ --header "Authorization: Bearer YOUR_KEY"

Then /mcp__domino__monsoon inside Claude Code hands it the alert together with the agent's playbook, which the server itself provides. The war room shows each tool call as it happens, including the Cypher behind it.

• Claude API runs the agent inside the backend when an Anthropic key is configured.

One deployment war story: my uptime monitor reported the site down for an hour while it was serving traffic perfectly. The monitor checked with HEAD requests, and the health endpoint only answered GET, so every check returned 404. One line fixed it. It's a good reminder that "down" is whatever your probe says it is.

12. What's still missing

DOMINO is a hackathon build, so here are the limits, stated plainly:

• The data is synthetic. Real use means loading a bill of materials, approved-vendor lists, sub-tier supplier maps and open orders into the same schema.

• The allocator is greedy, not optimal.

• Everyone shares one live world. Per-user worlds are a GRAPH.COPY away but not built yet.

• "Not in the graph" never means "safe". When an alert names a place DOMINO doesn't model, like a port strike in Antwerp, it says exactly that instead of reporting no impact.

Next on the list: single-point-of-failure scans (knock out each site in turn and re-run max-flow), route search over the logistics network with FalkorDB's path algorithms, and an import path for real data.

If you work in supply chain and the Ayutthaya scenario feels familiar, I'd like to hear how you get tier-2 visibility today. My guess is: spreadsheets, and a lot of phone calls.