Graph-Native Supply Chain Risk — A Neo4j Perspective

BOM Subtree — The depth argument

One assembly fans out to 6 sub-assemblies, dozens of components, and 8 cathode materials. One MATCH clause. And this is only 4 of 8 levels.

A traditional Bill of Materials is a tree that stops at L3 or L4 — it lists parts and sub-parts but does not trace material chemistry. "Cathode Active Material (NMC 811)" is one line in a BOM. In the PMG graph, it is a node connected to eight chemical inputs, each of which traces back through industrial synthesis routes to specific ores in specific geographies.

That is the difference between knowing "you use NMC 811" and knowing "your NMC 811 depends on Lithium Hydroxide Monohydrate with a 210-day TTR, sourced through a processing chain with 90%+ concentration in two countries."

Expand

Battery Pack (L1) → 6 SubAssemblies (L2) → Components (L3) → 8 Cathode Active Materials (L4). Every green L4 node has a full L5–L8 subtree beneath it, not shown here.

The query that produced this visualisation traverses four levels through three heterogeneous relationship types in one MATCH clause:

// Full BOM fan-out — Battery Pack to L4 materials
MATCH (a:Assembly)-[:CONTAINS_SUBASSEMBLY]->(l2:SubAssembly)
WHERE a.name CONTAINS 'Battery Pack'
WITH a, l2
MATCH (l2)-[:CONTAINS_COMPONENT]->(l3:Component)
WHERE l3.name CONTAINS 'Cathode Active Material'
WITH a, l2, l3
MATCH (l3)-[:COMP_USES_MATERIAL]->(l4:ComponentMaterial)
RETURN a.name        AS assembly,
       l2.name       AS sub_assembly,
       l3.name       AS component,
       l3.estimated_ttr_days AS component_ttr_days,
       l4.name       AS material,
       l4.estimated_ttr_days AS material_ttr_days
ORDER BY l4.name

The eight L4 nodes surfaced by this query — Nickel Sulfate, Cobalt Sulfate, Lithium Hydroxide Monohydrate, Manganese Sulfate, and four others — each carry their own estimated_ttr_days. Lithium Hydroxide Monohydrate sits at 210d. Nickel Sulfate at 60d. These are not declared by the T1 supplier. They are computed from the material graph, tracing the actual synthesis and sourcing chain beneath each node.

When China announces export controls on lithium, a procurement team needs to know which of these eight cathode materials depends on Chinese processing. This query — or a variant of it with a concentration_country filter — tells them in milliseconds. Not after a cross-system join across a procurement platform, a materials database, and a BOM tool. In one traversal, on the live graph.

Diamond Convergence — The hidden single point of failure

19 independent assemblies. One ore. The convergence is invisible at L3, L4, even L5. The graph detects it automatically at L8.

In a flat supplier model, the Battery Pack has a nickel supplier. The Traction Motor has a different nickel supplier. The Braking System has a third. Three independent supply chains. Three independent risk assessments. Traditional risk tools treat them exactly this way — and they are structurally correct to do so, given the data they have.

The problem is that all three paths ultimately trace through the same raw material: Nickel Laterite Ore at L8. If that ore supply is disrupted — a mine closure, an export restriction, a geopolitical event — all 19 assemblies in the vehicle programme are affected simultaneously. The convergence is invisible at every level above L8. It is only detectable from the bottom of the graph, looking upward.

Expand

Four of 19 shortest paths shown. Each path enters through a different nickel compound at L4–L5, converging at L8. diamond_assembly_count = 19. estimated_ttr_days = 120.

This is what the PMG graph calls a diamond node: a material or supplier node where multiple independent assembly paths converge. The property is_diamond_node = true is not declared anywhere — it is computed by traversal and written back to the node. diamond_assembly_count = 19 quantifies the blast radius. The query that detects it:

// Find all assemblies that depend on Nickel Laterite Ore
MATCH (ore:RawMaterial)
WHERE ore.name = 'Nickel Laterite Ore'
  AND ore.is_diamond_node = true
MATCH path = shortestPath(
  (a:Assembly)-[:CONTAINS_SUBASSEMBLY|CONTAINS_COMPONENT|
    COMP_USES_MATERIAL|COMP_MAT_TRANSFORMS_TO_SEMI|
    SEMI_TRANSFORMS_TO_PRIMARY|PRIMARY_TRANSFORMS_TO_PRECURSOR|
    PRECURSOR_TRANSFORMS_TO_RAW*1..8]->(ore)
)
WHERE a.level = 1
RETURN path,
       ore.diamond_assembly_count  AS assemblies_affected,
       ore.estimated_ttr_days      AS recovery_days,
       a.name                      AS assembly_name
ORDER BY a.name

That query returned 19 rows in under 200ms. The *1..8 variable-length path pattern traversed all paths between length 1 and 8 through any combination of the listed relationship types — without knowing the path lengths in advance, without conditional logic for different depth assemblies. Native graph operation. The equivalent in SQL is not merely complex. It requires pre-computing all possible paths at load time in a denormalised lookup table, and rebuilding that table entirely whenever a BOM changes.

The four paths shown in the image — Battery Pack via Nickel Sulfate, Traction Motor via Nickel coating, Braking System via Nickel-Copper-Nickel Plating, HVAC Compressor via corrosion protection — pass through entirely different intermediate nodes at L4 through L6. The convergence is not visible at any of those levels. It only surfaces when you traverse to L8 and ask the graph: how many assemblies depend on this node?

Our live graph contains 4,554+ diamond nodes — materials that feed multiple independent assemblies. The highest diamond_assembly_count in the graph is 19, for Nickel Laterite Ore. These nodes were detected automatically at graph load time by the same traversal pattern shown above. No analyst marked them. No spreadsheet maintained the list. The graph computed it.

TTR Depth — Where your risk actually lives

DENSO Corporation supplies your Battery Pack. Six levels below DENSO, the graph shows a 270-day TTR that DENSO's declared lead time cannot capture.

The Ford-MIT study (Simchi-Levi et al., 2015) introduced TTR — Time-to-Recover — as the right metric for supply chain risk, and proved that PI (Performance Impact) and TTR together identify hidden risk concentrations that spend-based monitoring misses. That framework was built on T1-observable data, because T1 was the data that existed. The authors were explicit about this ceiling in the paper itself.

PMG extends that methodology downward. TTR is not declared by a supplier — it is computed from the material graph. The constraining TTR for any disruption scenario is the maximum across the full dependency path, and that maximum is almost always deep in the chain, not at the T1 supplier.

Expand

Vertical L1→L8 Lithium chain. Suppliers attached at four different depths via typed SUPPLIES_* relationships. TTR escalates from 210d at L4 to 270d at L8.

The TTR values across the Lithium chain in the live graph:

DENSO Corporation quotes a lead time based on their own inventory, manufacturing capacity, and T1 procurement relationships. That estimate is operationally honest. What it cannot include is the physics of the material chain beneath them. Six levels below DENSO, Lithium Ore (Spodumene) carries a 270-day TTR — the time to qualify an alternative source, restart processing, rebuild inventory through every transformation stage back up to L1.

The query that builds this chain and overlays the supplier network:

// Full Lithium chain — L1 Assembly to L8 Raw Material
MATCH (a:Assembly)-[:CONTAINS_SUBASSEMBLY]->(l2:SubAssembly)
      -[:CONTAINS_COMPONENT]->(l3:Component)
      -[:COMP_USES_MATERIAL]->(l4:ComponentMaterial)
      -[:COMP_MAT_TRANSFORMS_TO_SEMI]->(l5:SemiFinishedMaterial)
      -[:SEMI_TRANSFORMS_TO_PRIMARY]->(l6:PrimaryMaterial)
      -[:PRIMARY_TRANSFORMS_TO_PRECURSOR]->(l7:PrecursorMaterial)
      -[:PRECURSOR_TRANSFORMS_TO_RAW]->(l8:RawMaterial)
WHERE a.name CONTAINS 'Battery Pack'
  AND l4.name CONTAINS 'Lithium Hydroxide'
RETURN a.name AS assembly,
       l3.name AS component,       l3.estimated_ttr_days AS l3_ttr,
       l4.name AS material,        l4.estimated_ttr_days AS l4_ttr,
       l5.name AS semi_finished,   l5.estimated_ttr_days AS l5_ttr,
       l6.name AS primary,         l6.estimated_ttr_days AS l6_ttr,
       l7.name AS precursor,       l7.estimated_ttr_days AS l7_ttr,
       l8.name AS raw_material,    l8.estimated_ttr_days AS l8_ttr

The supplier overlay is structurally important. In the PMG graph, suppliers attach to materials at every depth via typed SUPPLIES_* relationships. SupplierLocation -[:SUPPLIES_RAW_MATERIAL]-> RawMaterial is not the same edge as SupplierLocation -[:SUPPLIES_L1]-> Assembly. Each relationship type represents a different commercial and operational relationship with its own risk properties. This means you can ask: which suppliers are exposed at L6 or deeper, where substitution takes more than 180 days? — and get the answer in one traversal, without a cross-system join.