> ## Documentation Index > Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt > Use this file to discover all available pages before exploring further. # BOM Explosion & Where-Used > Walk the BOM graph in both directions: explode assemblies into their components, and trace where any component is consumed. ## Overview There are two directions for walking the [BOM](/product/bom) graph: * **BOM explosion** (forward) — starting from an assembly, expand it into every component, sub-component, and raw material it consumes, all the way down to the leaves. * **Where-used** (reverse) — starting from a component, trace every parent assembly that consumes it, optionally all the way up to the finished goods that ultimately depend on it. Both operate on the same directed acyclic graph of BOMs. Explosion answers *"what goes into this?"*; where-used answers *"what depends on this?"* and *"if I change this, what moves?"*. ## Where to Reach Them ### On the BOMs page The BOMs page supports both directions interactively: * Open any BOM to expand its component tree down to the leaves, with the per-edge quantity at each level. * From any BOM, run **where-used** to see every parent assembly that consumes it. This is the everyday surface — click through when you're browsing. ### Through Dexter For questions posed in natural language, or when you want the answer pulled into a chat, ask [Dexter](/product/ai-assistant): * *"What goes into `widget-assembly`?"* * *"Show me the BOM tree for the standard bracket."* * *"Where is `steel-plate` used?"* * *"If I change the steel-plate BOM, what's affected?"* Dexter activates the **BOM Explosion** workflow and runs one of two scripts against your factory's BOMs: * `explode ` — forward explosion of a BOM * `where_used [--recursive]` — reverse explosion of a BOM The resulting tree or list appears in the chat, and Dexter can follow up with impact analysis, exports, or downstream questions in the same turn. ## Inputs Both tools take a **BOM slug** — the identifier of a specific BOM node in the graph, not an entity name. The slug matters because one entity can have many BOMs. A bracket entity with a standard variant and a heavy-duty variant lives as two BOMs, each with its own component tree: `bracket-standard` and `bracket-heavy-duty`. To explode the standard bracket, you pass `bracket-standard`. There is no separate "variant" input — variant selection *is* which BOM slug you name. If you know the entity but not the slug, look it up on the BOMs page first, or ask Dexter to resolve the entity and variant to a slug. `where_used` takes one flag: * `--recursive` — walk the full ancestor chain up to the top-level SKUs. Without it, `where_used` returns only the **direct parents** — the BOMs that list the target as an immediate component. Neither tool takes a production quantity. Outputs show per-edge quantities as authored; if you need totals for a specific production volume, multiply the leaf quantities by the number of finished units yourself, or ask Dexter to do it. ## Outputs ### `explode` — component tree An indented tree rooted at the target BOM, drawn with monospaced box-drawing characters (`├──`, `└──`, `│`) — text tree art, not a table with columns. The root line is ` explosion:` and carries no quantity or depth of its own. Each node below it shows its BOM slug, the quantity consumed by its parent (`×N`), and its depth from the root. Depth 1 is a direct component; depth 2 is a component of a component; and so on down to the leaves. ```text theme={null} $ explode widget-assembly widget-assembly explosion: ├── steel-plate (×2, depth 1) ├── plastic-housing (×1, depth 1) │ └── abs-pellets (×3, depth 2) └── circuit-board (×1, depth 1) ├── copper-sheet (×2, depth 2) └── solder-paste (×1, depth 2) ``` The quantities on each edge are **per one unit of the immediate parent**, as authored on that parent BOM. To compute the total quantity of a leaf material required for one unit of the root, multiply the per-edge quantities along the path from root to leaf. When the same leaf appears under multiple parents (a shared component), sum those path-products to get the leaf's total roll-up. ### `where_used` — parent list A flat list of every BOM that consumes the target, with the quantity consumed per parent. Direct parents only (default): ```text theme={null} $ where_used steel-plate steel-plate is used in: - widget-assembly (×2) - bracket-assembly (×4) ``` Recursive — every ancestor up to the SKUs: ```text theme={null} $ where_used steel-plate --recursive steel-plate is used in (recursive): - widget-assembly (×2, depth 1) - bracket-assembly (×4, depth 1) - finished-product (×2, depth 2) ``` The recursive header line changes to ` is used in (recursive):` — the `(recursive)` marker tells you which mode produced the list. The output stays a flat list either way; ancestors beyond the direct parents are simply additional rows, not a nested tree. `depth 1` is a direct parent; deeper entries are further ancestors. The `×N` on a recursive entry is the quantity consumed at that specific level, not the roll-up from the leaf. ## Step-by-Step ### Exploding a BOM 1. Identify the BOM you want to explode. If you know the entity but not which variant, open the entity on the BOMs page first and pick the variant that matches the configuration you care about. 2. On the BOMs page, click the BOM to expand its tree — or ask Dexter *"explode ``"* or the equivalent in plain English. 3. Read the tree top-down. Direct components are depth 1; leaves have no further children and are your raw-material demand. 4. If you need totals for a specific production quantity, multiply per the path rule above — or ask Dexter to compute rolled-up leaf quantities for N units. ### Finding where a BOM is used 1. Identify the BOM you're changing or investigating. 2. On the BOMs page, run **where-used** on it — or ask Dexter *"where is `` used?"*. 3. Start with the direct-parents view for a quick impact scan; use the recursive view to see every finished good downstream of the change. 4. Before editing a widely-consumed BOM, review each direct parent — changes propagate to every parent that consumes it, and to every scenario run against a [planning model](/product/planning-models) whose BOM list includes them. Make where-used a habit before editing any shared component. Direct-only output will miss indirect impact — add `--recursive` when you need every affected finished good. ## Limits and Caveats * **Slug in, slug out.** Both tools address BOMs by slug; entity names and variant descriptions are not accepted as inputs. * **No quantity multiplier.** Neither tool takes "how many finished units" as an argument. Multiply per-edge quantities yourself, or hand the roll-up to Dexter. * **No variant resolution against a demand line.** The tools do not take a variant condition and pick the matching BOM — they walk the specific BOM you name. Variant resolution happens on [planning inputs](/product/demand-and-supply) via subset matching, not here. * **Shared components appear multiple times in an explosion.** A leaf consumed by two branches shows up under both — the tree shows every path a component sits on, not a de-duplicated set. Sum across appearances for a single roll-up figure. * **Cycles are impossible.** A material can't be part of its own BOM — cyclical dependencies are rejected on write, so traversal always terminates. Explosion reflects BOMs **as authored** — it doesn't know about a planning model's BOM list, on-hand inventory, or supply orders. For *"how much do I actually need to produce to fulfill this demand?"* run a [planning scenario](/product/planning-runs); the optimizer accounts for inventory, supply, and resource constraints. BOM edits are visible immediately: both tools read the current BOM graph, so a change lands in the next explosion or where-used call. Planning runs, by contrast, take effect on the next run — see [Planning Runs](/product/planning-runs).