Sixteen BOM Views on One CI Graph

TL;DR

Every real engineering programme needs sixteen different bills of materials. The engineering team needs an eBOM. The manufacturing team needs an mBOM. The hardware team needs an HBOM. The software team needs an SBOM. The firmware team needs an FBOM. The operations team needs an OBOM. The test and qualification team needs a tBOM. The deployment team needs a dBOM per site. The in-service team needs a cBOM and an rBOM. The disposal team needs a deBOM. The programme office needs a vBOM for variants, an aBOM for alternates and substitutes, an xBOM for export control, an iBOM for inherited content and gaps, and a pBOM for long-lead procurement.

Legacy enterprise stacks store these as sixteen separate trees in sixteen separate tools, reconcile them by hand across years-long programmes, and never quite close the loop. The engineering BOM lives in the PLM. The manufacturing BOM lives in the ERP. The software BOM lives in the SCM. The as-built BOM lives in the MES. The spares BOM lives in the CMMS. The deployment BOM lives in a spreadsheet the deployment lead emails around. The export-control BOM lives in the compliance team’s SharePoint. The “real” BOM lives in nobody’s head and everybody’s margins.

Clarity takes the opposite position, and a single phrase from the architecture documentation captures it:

“BOM is a query, not a tree.”

There is one configuration-item graph. The sixteen BOM views are queries — eleven stored types that live in per-layer BOM files across L6 through L12, plus five filter / aggregation modes that render at read time without storing anything. Same nodes. Same edges. Different filter predicates. No duplication. No reconciliation. Six structural properties make this possible, and together they are the Clarity USP for bill-of-materials governance.

1. CI as node, BOM Item as edge. A configuration item is a part master. It has no parent. Every structural relationship is an edge — a BOM Item — carrying quantity, unit, effectivity, view type, structuring intent, and its own @source provenance. The graph is a graph, not a tree.
2. Five relationship types, not one. used-in, alternate-for, substitute-for, replaces, variant-of. The aBOM (alternates), vBOM (variants), and the history of supersessions all fall out of traversing these edges rather than forking the graph.
3. Per-layer BOM sidecar files. Every layer L6–L12 has its own L{N}-bom.json file, independent of the corresponding Lx.json. BOMs are never embedded in Lx layers; Lx layers reference their BOMs by file path. L8 and L10 are first-class BOM files (qualified-configuration and operating-configuration), not overlays. Standalone BOMs (long-lead procurement, supplier libraries, pre-Lx imports) live at bom/standalone-{bomId}.json with no layer home required.
4. Orthogonal structuring intent. The same parent-child CI pair can be structured for assembly, analysis, function, simulation, or procurement — independently of the BOM view type. The same CI graph can be traversed as an assembly tree, a FEA zone tree, a functional decomposition, a CAE model, or a procurement package.
5. Harmonised supplier namespaces and standard parts. Standard parts (NSN, JEDEC, MIL-SPEC) collapse to a single global ciId across every tenant and every supplier. Supplier-specific CIs live under scoped namespaces. Duplicate-suspect matching runs as one of six automated harmonisation quality checks. The ICD is the authority source with a weight of 0.95 — the same weight as a formal engineering change notice.
6. Evidence back-propagation across layers. Eight typed back-propagation paths carry the implementation-plane reality — build deviations, V&V results, site overrides, telemetry, in-service mods, disposal manifests — back into the design plane via typed @source entries on the originating BOM Items. The loop closes because the BOM is the graph, and the graph closes the loop.

If you only read one sentence: a bill of materials is a traversal filter over a typed, versioned, provenance-carrying configuration-item graph — not a stored tree that has to be forked, synchronised, and reconciled across sixteen different tools forever.

The bargain on offer

Walk into any complex engineering programme on a Monday morning and ask the simple question — “which parts are in the product, who uses that list for what, and where is the authoritative version?” — and the room will give you sixteen answers, all inconsistent, all defensive, all fully believed by the person giving them.

The engineering team will point you at an eBOM exported from the MCAD tool and curated in the PLM. It is the as-designed tree, and it does not include manufacturing consumables, it does not include the harness tBOM, it barely touches the electrical design, and it assumes every supplier part will behave exactly as the supplier said it would.

The manufacturing team will point you at an mBOM inside the ERP. It does include the consumables, it does include the process steps, and it was forked from an earlier eBOM revision four months ago. Since the fork, engineering has closed six change records that have never propagated to the manufacturing side. The manufacturing team knows this, and has built a spreadsheet that tracks the deltas out of band. The spreadsheet is owned by one person who is on annual leave.

The contract manufacturer will point you at their internal ERP, which pulled a BOM from an XML export two weeks ago, which the contract manufacturer then modified to add their own supplier substitutes, which they have flagged as “deviations pending customer approval” in their own system. The customer’s change-management system has no record of the deviations. The first time anybody will find out is when the built units come back with a non-conformance report, and even then the non-conformance report will be a PDF attached to an email.

The deployment team will point you at a kit list — a partial BOM — for each site. The kit lists are site-specific variants, each one a spreadsheet, each one a little different from the others, none of them connected to the engineering BOM by anything more reliable than the part numbers that happen to appear in both.

The in-service team will point you at the spares catalogue in the CMMS. It has part numbers. It does not have the revisions. It does not know which build version each deployed unit is running. When a part fails in the field, the repair technician calls the programme office and asks which spare to send, and the programme office guesses based on the date of the last deployment.

The export-control team will point you at a flag field on a subset of parts, maintained in a separate spreadsheet, never quite aligned with the compliance list the legal team uses for licensing decisions.

Somewhere in the middle of all of this, there is a single physical product. It has a serial number. It has real parts. It has real software. It has a real build history. Nobody can answer the Monday-morning question about it in less than a day, and when they do answer it, they do so by reconstructing the narrative from seven different tools and three spreadsheets and one phone call to the person on leave.

This whitepaper explains how Clarity approaches the problem differently. It has three sections:

• Section 1 — why legacy PLM / ERP / MES / MRO stacks produce sixteen forked trees instead of one queryable graph, illustrated by thirty years of direct experience running and auditing BOM-governance work across complex engineering programmes in automotive, aerospace, defence, nuclear, medical devices, heavy industry, energy, rail, shipbuilding, and advanced manufacturing.
• Section 2 — how Clarity’s CI graph works: nodes, edges, relationship types, the lx-bom.json sidecar architecture, per-layer BOM ownership L6–L12, the 11 stored types, the 5 filter / aggregation modes, L8 qualified-configuration and L10 operating-configuration as first-class BOMs, multi-discipline support, structuring intent, supplier harmonisation, acquisition modes, and the eight back-propagation paths that carry reality back to the design plane.
• Section 3 — what that architecture unlocks in practice: the eBOM remains the single source of truth because the mBOM is a view rather than a fork, change management cannot be bypassed, contract-manufacturer handoff becomes a filtered query, as-built traceability is structural, spares forecasting is data-driven, export control is a filter, and none of it can be retrofitted into a legacy stack.

Section 1 — Why programmes end up with sixteen forked trees

The observations in this section are drawn from thirty years of direct experience running, governing, auditing, and in several cases rescuing BOM-governance work across complex engineering programmes — starting in automotive vehicle-dynamics and manufacturing programmes in the late 1990s, moving through defence naval and land systems in the early-to-mid 2000s, through long-lifecycle aerospace PLM programmes supporting eighteen concurrent defence programmes, and through enterprise cloud-adoption and PLM-integration work across multiple industries in the decade since. The patterns described below have been observed, in essentially the same shape, in every industry and every tool stack the authors have worked inside over three decades. The patterns are universal.

1.1 What a BOM is supposed to be — and what it actually is

A bill of materials is, in theory, a simple thing. It is a list of parts and assemblies that make up a product, with quantities, references to the parent assembly, and enough identifying information that someone building, maintaining, or auditing the product can reconstruct exactly what the product is made of.

In practice, no single BOM can answer every question an engineering programme needs to answer. A maintenance technician needs different information from a procurement buyer; a compliance officer needs different information from a deployment engineer; a failure investigator needs different information from a spares forecaster. Over the last forty years, the industry evolved a taxonomy of BOM types to address these different use cases — the engineering BOM, the manufacturing BOM, the hardware BOM, the software BOM, the as-built BOM, the as-deployed BOM, the maintenance BOM, and a dozen more.

The industry’s mistake was not the taxonomy. The taxonomy is useful. The mistake was storing each type as a separate tree in a separate tool, with ad-hoc reconciliation between them. Once the trees are separate, the reconciliation is a full-time job, and nobody has enough time to do it properly, and the programme drifts further from reality with every change.

1.2 Five structural gaps that every legacy stack produces

Every complex engineering programme large enough to need serious BOM governance ends up exhibiting the same five structural gaps — in automotive, aerospace, defence, nuclear, medical devices, heavy industry, energy, rail, shipbuilding, and advanced manufacturing. The industry labels differ, the tool stacks differ, the regulatory overlays differ, but the structural pattern is always the same. The gaps are not bugs in individual products. They are emergent properties of the “separate trees in separate tools” approach, and they appear wherever that approach is taken.

The mechanical / electrical coupling gap

Mechanical design lives in an MCAD tool. Electrical design lives in an ECAD tool. The two are connected by harnesses, connectors, mounting points, thermal envelopes, routing constraints, and a lot of implicit assumptions about what the other discipline is doing. The MCAD tool does not understand the ECAD data, and the ECAD tool does not understand the MCAD data, and the PLM that is supposed to manage both understands neither of them natively.

The workaround, in every programme the authors have seen, is a manual process: the mechanical engineer exports a harness specification, the electrical engineer imports it into the ECAD tool, the harness is designed, a cable BOM comes back, the mechanical engineer manually reconciles the cable BOM against the MCAD model, and the reconciliation lives in a spreadsheet that nobody else can see. When the mechanical design changes, the process runs again, usually late, usually incomplete, usually with discrepancies that surface only during prototype build.

The organisations the authors have observed have recognised this as a strategic problem and are actively trying to fix it. They cannot fix it inside their existing tools, because their existing tools were never architected around a shared semantic model of the product.

The eBOM → mBOM fork

The engineering BOM is what the engineers designed. The manufacturing BOM is what manufacturing uses to build it. In theory the mBOM is derived from the eBOM. In practice, in every legacy PLM-to-ERP deployment the authors have seen, the mBOM is forked from the eBOM at a specific point in time, and the fork then drifts.

The drift accumulates for specific, legitimate reasons. Manufacturing needs to add consumables (loctite, grease, thread-locker, cleaning agents) that the engineering design does not track. Manufacturing needs to reorder the assembly steps to match the shop-floor flow. Manufacturing needs to substitute suppliers where the designer’s preferred part is on long lead time. Manufacturing needs to add test and inspection steps that have nothing to do with the engineering intent.

Each of these is a reasonable modification. What is not reasonable is that after the fork, neither the eBOM nor the mBOM is the truth — the eBOM lacks the manufacturing reality, and the mBOM is increasingly stale relative to the current engineering revision. Change management is supposed to propagate changes across the fork, but in practice change management is either bypassed (because it is slow and bureaucratic) or partial (because nobody maintains the mappings between eBOM and mBOM items well enough for the propagation to work).

Every serious engineering-and-manufacturing organisation the authors have worked inside over the last three decades has eventually reached the same conclusion, in essentially the same language: the eBOM must remain the source of truth for engineering, and the mBOM must be a derived view, not a forked tree. The conclusion was correct in 1998. It is still correct in 2026. It has never been implementable in any legacy tool stack the authors have encountered.

The change-management bypass

Every serious programme has a documented change-management process. Problem report (PR), engineering change request (ECR), engineering change notice (ECN), quality change notice (QCN), deviation, waiver. The process exists. It is written down. It is trained on. It is mandated in the procedures.

In every programme the authors have observed, the change-management process is routinely bypassed. Not because the engineers are ignoring it. Because the tool that implements it is slow, requires too many clicks, gets in the way of the work, and produces artefacts that nobody downstream actually reads. The engineers raise a ticket, or send an email, or tell the manufacturing team in the daily stand-up, and the work proceeds. The formal change record is created retroactively, if at all, and the formal record does not match what actually happened.

The single clearest symptom of this dysfunction is the overuse of waivers. A waiver is supposed to be an exception — a one-off, time-limited, explicitly-approved departure from the released baseline, granted when a full change record would be too slow or too heavyweight for a genuinely exceptional circumstance. In a healthy programme waivers are rare, scoped to a specific serial number or batch, and closed out promptly. In the programmes the authors have actually observed — across every industry, for three decades — waivers are the primary vehicle for routine change. Engineering issues a waiver because the ECN would take three months. Manufacturing requests a waiver because the mBOM has drifted from the eBOM and nobody wants to reconcile it. The contract manufacturer ships a waiver because their supplier substituted a part. The quality team accepts a waiver because rejecting it would block the line. Month after month, the waiver backlog grows, nothing is ever closed out, and the “baseline” of the programme is an accumulation of overlapping waivers that no single person can reconstruct.

Waivers are not overused because engineers are lazy. They are overused because the legacy tool stack makes every alternative harder. An ECR requires forking the eBOM to the mBOM (which the tools cannot do cleanly), routing through multi-stage approval (which the workflow engine cannot scale), updating the contract-manufacturer’s copy of the BOM (which the integration cannot handle), and reconciling the change across PLM, ERP, MES, and CMMS (which nobody is resourced to do). A waiver requires one signature on a PDF. The economic incentive is so lopsided that waivers become the default, and the “exception” path becomes the normal path. The programme’s configuration state quietly decouples from the released baseline, and the decoupling is invisible until a safety investigator, an auditor, or a regulator asks for the current as-built configuration and discovers that nobody can produce it.

The consequence is that the PLM’s change-management module contains a partial, idealised, after-the-fact narrative of what changed. The real history lives in waivers, tickets, emails, stand-up notes, and the memory of the people who were there. When a regulator asks “which changes were approved on which date with what evidence, and which of them are still open?”, the answer is reconstructed by hand from sources that were never designed to be audit-admissible.

The fix is never “better workflow in the existing tool”. The fix is making the change-management process so lightweight, so structural, and so tied to the underlying data that there is no incentive to bypass it. The legacy tools cannot deliver that fix because their change-management is a bolt-on on top of a forked-tree BOM, and the bolt-on has to do exponential reconciliation work to keep up. Clarity’s answer, described in Section 2, is to make the BOM a graph and the change a mutation of the graph — at which point the cost of “doing the change properly” collapses to zero.

The contract-manufacturer visibility gap

Every complex engineering programme of any meaningful scale relies on at least one contract manufacturer, tier-1 supplier, or partner build yard. That external organisation has its own ERP, its own quality system, its own deviation and waiver process, its own supplier substitution rules, and its own ECO workflow. The customer’s PLM has none of that. The customer’s PLM has an eBOM, a change record, and a set of drawings.

The handoff from the customer to the contract manufacturer is the single most fragile boundary in the entire lifecycle. The customer’s eBOM is exported — usually to Excel or XML — and re-imported into the contract manufacturer’s ERP. The contract manufacturer then modifies the imported BOM for their own supplier chain, their own work instructions, and their own deviations. The customer has no visibility into the modified BOM. The contract manufacturer has no visibility into the customer’s pending engineering changes. When the customer ships an ECN mid-build, the contract manufacturer may or may not receive it, may or may not apply it, may or may not update their own BOM accordingly.

Contract manufacturers the authors have worked with directly, across three decades of customer-to-external-manufacturer engagements, consistently report the same seven recurring issues at this boundary: deviations and waivers not followed up with timely ECOs, incorrect BOM items driving supply-chain issues, lack of revision control on spreadsheet-based BOMs, drawings not aligned with BOM changes, lack of traceability on lower-level revisions, limited visibility of inventory and WIP impact, and no systematic documentation of supplier requests for engineering approvals. These issues have appeared, under different names, in every customer-to-external-manufacturer handoff the authors have worked on — naval shipbuilding, automotive tier-1 supply, aerospace sub-assembly, medical device contract manufacture, nuclear component fabrication, and every other industry where a design organisation hands off to a build organisation. Every one of them is a direct consequence of the handoff being a bulk export of a forked tree rather than shared access to a single queryable graph. The external manufacturers did not ask for a new tool. They asked for a common substrate.

The as-built and as-deployed traceability gap

Ask any programme how many of its deployed units are running exactly the configuration that was released at L5 decision time. Nobody knows. Ask how many have been modified in the field, by whom, with what evidence, and under what change authority. Nobody knows. Ask which serial number was built to which revision of which eBOM, with which supplier substitutions, against which ECN effectivity. Nobody knows.

Legacy systems do not know because they do not store this information in any linked form. The MES stores the as-built for a while, then archives it. The CMMS stores a spares catalogue but not a configuration snapshot. The deployment tracker stores which serial numbers went where, but not which revisions. Nothing connects them. As-built traceability is, in almost every programme, a reconstructive activity performed by hand when a failure investigation demands it.

This gap is the reason predictive maintenance does not work at scale on any fielded engineering platform, the reason field upgrades are fragile, the reason recalls are expensive, and the reason root-cause analyses take months. The data exists. The data is not connected. The data is not queryable. And no amount of AI or dashboarding layered on top of the disconnected data will ever make it so.

1.3 The “one spreadsheet to rule them all” anti-pattern

Underneath every one of the five gaps in §1.2 is a single recurring organisational pattern: the real BOM is a spreadsheet. Not the PLM export. Not the ERP report. Not the MES dump. A spreadsheet, maintained by one person, that reconciles the inconsistencies across the official tools by hand, and that the programme quietly trusts more than it trusts any of the systems of record.

The spreadsheet is rational. The official tools are broken, the reconciliation between them is manual, and the programme needs to ship. The spreadsheet is also disastrous. It has no schema, no version history, no access control, no provenance, no audit trail, no backup strategy, and it usually lives on the laptop of a person who is one job change away from taking the entire programme’s institutional BOM knowledge with them.

Every serious engineering programme has a version of this spreadsheet, in every industry the authors have worked in. It is the clearest evidence that the legacy toolchain has failed at its most basic job — being the single source of truth for the product — and it is the most under-discussed risk in the industry. No vendor sells a fix for it, because no vendor can fix it: the spreadsheet exists because the vendors’ tools are forked trees, and the fix is a shared graph, which no legacy vendor is architected to provide.

1.4 What the industry actually concluded — and why they cannot implement it

Every serious BOM-governance review of the last thirty years — across every industry the authors have worked inside, covering the four recurring digital threads of single BOM, release to manufacturing, spares management and forecasting, and bidirectional change management — has reached the same set of conclusions, independently, in essentially the same language. The conclusions are worth listing because they are universally correct and, in every tool stack the authors have ever audited, universally uninstallable:

1. Centralise and standardise the change-management processes (PR, ECR, ECN, QCN, deviation) so the organisation uses one unified flow rather than per-team variants.
2. Define the mBOM process and ensure the eBOM remains the source of truth for engineering.
3. Improve the integration between the PLM and the product development process to ensure traceability and configuration management.
4. Provide training on leveraging PLM effectively for key stakeholder roles.
5. Establish a centralised, documented repository of PDP requirements accessible to the entire organisation.
6. Implement more rigorous change control to prevent bypassing critical PDP steps.
7. Develop a short-term solution for the interim before the formal PLM/PDP system is in place.
8. Align PLM and PDP processes organisationally for consistency.
9. Define clear roles, responsibilities and accountability for PLM across the product lifecycle.
10. Establish a standardised PLM and PDP framework that can scale and adapt to different product-development models.

Every one of those conclusions is correct. Every one of them is what a rational engineering organisation should be pursuing. And every one of them hits the same architectural wall: the existing tools are forked trees, and forked trees cannot be centralised, standardised, or unified without moving the data off the forked trees and onto a substrate that supports a single graph.

Thirty years of reviews, audits, and recoveries across multiple industries did not fail to identify the problem. They failed to have a substrate to fix it on. That substrate is what Section 2 describes.

Section 2 — Sixteen BOM views on one CI graph

Clarity’s BOM architecture starts from an inversion of the legacy model. Instead of storing each BOM type as a separate tree in a separate tool, Clarity stores a single configuration-item graph and renders every BOM as a query over it. The graph is typed. The edges are typed. The relationships are typed. The provenance is structural. The BOM is not a stored artefact — it is a traversal.

This section describes how that works: the node/edge model, the relationship taxonomy, the per-layer sidecar pattern, the eleven stored types, the five filter modes, L8 and L10 as first-class structural BOMs, multi-discipline support, structuring intent, supplier harmonisation, acquisition modes, and the eight typed back-propagation paths.

2.1 The CI graph model — nodes, edges, no tree

A configuration item (CI) in Clarity is a node in the graph. It represents a part master. It has a stable identity, a part number, a revision, a name, an acquisition mode, a design-authority provenance record, an export-control classification, and a set of intrinsic properties. It has no parentCiId. Structural relationships are not stored on the CI.

A BOM Item is an edge in the graph. It represents a parent-child usage relationship between two CIs, and it carries everything that makes that usage specific: the quantity, the unit, the effectivity window, the BOM view type, the structuring intent, the relationship type, and its own @source provenance record.

The JSON shape of a BOM Item, simplified:

{
  "bomItemId": "uuid",
  "parentCiId": "uuid-parent",
  "childCiId": "uuid-child",
  "quantity": 2.5,
  "unit": "kg",
  "relationshipType": "used-in",
  "effectivity": {
    "dateFrom": "2026-04-01",
    "serialFrom": "S/N-0001",
    "variantApplicability": ["Tropical"]
  },
  "bomViewType": "eBOM",
  "structuringIntent": "assembly",
  "@source": {
    "lineage": "human",
    "author": "...",
    "timestamp": "...",
    "changes": [ /* ... */ ]
  }
}

The consequence of CIs having no parentCiId is that the same CI can appear under many parents, in many views, in many effectivity windows, in many variants, with many different structuring intents — all as separate BOM Items referencing the same underlying CI node. A fastener that appears in five hundred assemblies is one CI node with five hundred used-in BOM Item edges pointing at it. A supplier substitution is not a fork of the CI — it is an alternate-for edge between two CIs. A supersession is a replaces edge with an effective date. A variant-specific part is a variant-of edge with a variantApplicability filter on the BOM Item effectivity.

The five canonical relationship types are:

• used-in — the standard parent-child containment relationship
• alternate-for — form-fit-function equivalent, approved substitution
• substitute-for — conditional use with known trade-offs
• replaces — supersession, usually tied to an ECN effective date
• variant-of — configuration-specific applicability (e.g. the tropical-climate variant uses a different cooling fan)

These five types are enough. Between them they cover every BOM structural relationship the authors have seen in forty years of real programmes.

2.2 The lx-bom.json sidecar pattern

Every layer of the Lx model from L6 through L12 has its own first-class BOM file. The file is called L{N}-bom.json and it lives alongside — not inside — the corresponding L{N}.json layer file in the tenant’s S3 bucket:

projects/{tenantId}/{portfolioId}/{productId}/L6/L6.json
projects/{tenantId}/{portfolioId}/{productId}/L6/L6-bom.json
projects/{tenantId}/{portfolioId}/{productId}/L7/L7.json
projects/{tenantId}/{portfolioId}/{productId}/L7/L7-bom.json
...
projects/{tenantId}/{portfolioId}/{productId}/L12/L12.json
projects/{tenantId}/{portfolioId}/{productId}/L12/L12-bom.json

Four invariants govern this sidecar pattern:

1. A BOM file is never embedded inside an Lx layer file. The Lx layer references its BOMs via a bomRefs[] array of file paths. An L6 layer that wants to reference multiple BOMs (one per acquisition mode, for example) does so by listing their paths — not by embedding their content.
2. BOMs may exist independently of any Lx layer. Long-lead procurement BOMs, pre-Lx supplier imports, library BOMs, and inherited-content gap trackers all live at projects/{tenantId}/{portfolioId}/{productId}/bom/standalone-{bomId}.json with no layer home required. A standalone BOM is fully first-class: it has its own version history, its own @source, and its own cycle-prevention check.
3. Cycle prevention is writer-side. Every BOM write runs a depth-first cycle check before commit. A BOM Item that would create a cycle is rejected at write time, not read time. The graph is guaranteed acyclic by construction.
4. @source carries the full provenance model on every write. That includes the fifteen-field provenance record, plus the two additional fields introduced by the acquisition-mode model: designAuthorityProvenance (who owns the design authority for the CI, under what data-rights agreement) and exportControl (ITAR / EAR / NOFOR classification with agreement references and releasability markings).

The pipeline underneath is completely decoupled from the Lx.json aggregation pipeline. The generate_lx_json Lambda builds Lx layer aggregates. The aggregate-bom Lambda builds BOM aggregates. Writing a BOM does not trigger generate_lx_json. Writing an Lx layer does not trigger aggregate-bom. The two pipelines share the quiesce pattern (see the companion Event-Driven by Kernel whitepaper) and honour the same burst-write debouncing, but they are otherwise fully independent.

2.3 The eleven stored types across L6–L12

Eleven of the sixteen BOM view types are stored — they live as native content in per-layer BOM files. The distribution across the implementation plane is deliberate and derived from the semantics of each lifecycle layer.

The full-name mapping of the eleven stored types, taken from the canonical definition:

• eBOM — Engineering BOM (the as-designed intent at L6)
• HBOM — Hardware BOM (L6 discipline partition for mechanical, electrical, electronic, PCB, optical, fluids, harness, RF, and structural hardware)
• SBOM — Software BOM (L6 discipline partition; aligned with SPDX and CycloneDX cybersecurity SBOM standards)
• FBOM — Firmware BOM (L6 discipline partition)
• OBOM — Operational / Support BOM (L6 as-acquired / as-inherited long-lead and support spine)
• mBOM — Manufacturing BOM (L7 as-built shop-floor structure)
• tBOM — Test / Qualification BOM (L7 / L8 qualified-configuration view)
• dBOM — Deployment BOM (L9 per-site deployment content)
• cBOM — Calibration / Configuration BOM (L11 in-service configuration state)
• rBOM — Repair / Overhaul BOM (L11 sparing and overhaul content)
• deBOM — Decommissioning BOM (L12 disposal and retirement manifests)

Every one of these is a set of BOM Items (edges) in its layer’s BOM file, carrying the bomViewType field that classifies which view it belongs to. The same CI node can appear in an eBOM Item, an HBOM Item, an mBOM Item, a tBOM Item, a dBOM Item, and so on — as five separate edges, all referencing the same underlying part master, each with its own effectivity and provenance.

2.4 The five filter / aggregation modes

The remaining five view types are not stored. They are query modes that render at read time against whichever BOM file or set of BOM files the user is currently scoped to. They do not duplicate data. They do not have their own files. They are filter predicates over the stored graph.

• vBOM — Variant BOM. Filters BOM Items by relationshipType: "variant-of" and by effectivity.variantApplicability. Renders the specific BOM that applies to one variant (e.g. tropical, cold-climate, high-altitude, export-restricted) without forking the base tree.
• aBOM — Alternate / Substitute BOM. Filters BOM Items by relationshipType: "alternate-for" and "substitute-for". Renders the approved alternate set for a given CI, with the trade-off rationale and the effectivity of each alternate.
• xBOM — Export-Controlled BOM. Filters CIs by @source.exportControl classification. Renders an ITAR / EAR / NOFOR view, filtered by jurisdiction and releasability markings, ready for a licensing decision or a cross-border release.
• iBOM — Inherited / Gap BOM. Filters CIs by acquisitionMode: "as-inherited". Renders the content that has been reconstructed from audit, teardown, or reverse-engineering, along with the remaining gaps — a live “what we still don’t know about this system” view.
• pBOM — Procurement / As-Ordered BOM. Aggregates BOM Items by CI rather than by traversal, resolving the supernode problem for high-reuse items (fasteners, bulk materials, consumables) by summing quantities across all parent assemblies. The result is a purchasing list, not a structural tree.

None of these five modes requires its own file. None of them requires its own write pipeline. None of them can drift from the underlying graph, because they are the underlying graph, filtered. When the underlying graph changes, every view changes simultaneously and automatically.

2.5 L8 qualified-configuration and L10 operating-configuration — first-class BOMs, not overlays

Two of the layers in the distribution above deserve specific attention, because they are the layers that legacy tools get most wrong.

L8 (As-Validated) is the qualified-configuration BOM. Each BOM Item at L8 represents a CI configuration that has been put through V&V. Not a link to the item that was built at L7 — a new item, with its own structure, its own grouping (often by test rig or qualification article), its own version history, and its own traceability back to the L7 item it validated. The L8 file links per-item to L7 via linkedBomItemId + linkedBomLayer, never by mutating the L7 file.

L10 (As-Operated) is the operating-configuration BOM. Each BOM Item at L10 represents a CI configuration as observed in deployment over a time window. An L10 item may span multiple L9 deployments (an operating-configuration observed across a fleet of sites), or it may be a time-sliced view of a single deployment. The L10 file links per-item to L9 via the same linkedBomItemId + linkedBomLayer mechanism.

Both L8 and L10 are first-class BOM files, not overlays on L7 or L9 respectively. The structural reason is write isolation: an L8 V&V run should never mutate the L7 as-built file, and an L10 telemetry summary should never mutate the L9 as-deployed file. The as-built at L7 is the as-built. The as-deployed at L9 is the as-deployed. What happened to them during qualification and during operation gets its own file, its own version history, and its own reorganisation authority (the L8 team can group items by test rig; the L10 team can group items by fleet), without the base layer having to agree.

Consumers that want “all validation results for this L7 BOM Item” follow the reverse index from bom-index.json, built automatically by the aggregate-bom Lambda. They do not have to load the L7 file and the L8 file in lockstep. The index handles it.

2.6 Multi-discipline by construction

A real engineering product — whether a vehicle, an aircraft, a ship, a reactor, a medical device, a production line, or a robotics platform — is multi-discipline. Mechanical. Electrical. Electronic. PCB. Optical. Fluids. Harness. RF. Structural. Plus software, firmware, and the operational consumables that make the whole thing work. A legacy PLM stack typically handles two or three of these disciplines natively and delegates the rest to discipline-specific tools that the PLM knows nothing about.

Clarity’s approach is that discipline is a classification on the CI, not a separate tree. The bomViewType field on each BOM Item classifies which discipline the item belongs to at the point of use — HBOM for hardware, SBOM for software, FBOM for firmware, OBOM for operational and support. Within HBOM, the same CI graph carries mechanical, electrical, electronic, PCB, optical, fluids, harness, RF, and structural content, distinguished at query time by the attributes on the CI (material, type, category, assembly class) rather than by the file it lives in.

A multi-discipline CI — a sub-assembly that is hardware and firmware and operational — appears in the graph as one CI node with BOM Items classified across the relevant disciplines. Rendering the HBOM view returns the hardware BOM Items. Rendering the SBOM view returns the software ones. Rendering the FBOM view returns the firmware. All from the same graph. No duplication. No reconciliation. A cross-discipline change record automatically propagates to every view because the change is a mutation of the shared graph, not a synchronised update across three separate trees.

The electrical / mechanical coupling problem that plagues legacy stacks — the one where MCAD and ECAD cannot agree on a harness — is not a separate problem in Clarity’s architecture. It is a structural feature: the harness CIs and the attachment-point CIs are all in the same graph, and a harness BOM Item is an edge between a mechanical mounting CI and an electrical connector CI, with structuring intent assembly (for the manufacturing view) and function (for the electrical signal chain view) and analysis (for the thermal and EMI analysis view). One set of CIs. Multiple traversals. No sync job.

2.7 Structuring intent — orthogonal to BOM view type

The sixteen BOM view types answer the question “what domain does this BOM Item belong to?”. A second, orthogonal field — structuringIntent — answers the question “why was the parent-child relationship structured the way it was?”.

The five canonical structuring intents are:

• assembly — children are physically installed into the parent; the hierarchy mirrors the physical build sequence
• analysis — children belong to the same analysis domain (FEA zone, thermal node, signal chain, FMEA failure domain); the hierarchy mirrors how the analysis was decomposed
• function — the hierarchy mirrors the functional decomposition from the L4 / L5 systems architecture; each level answers “which function does this sub-assembly realise?”
• simulation — the hierarchy is a CAE model structure; children may be idealised or proxy representations; CAE model IDs and idealisation types live in sourceFields
• procurement — the hierarchy mirrors procurement lot groupings; the parent is a procurement package, not a physical assembly

Structuring intent is orthogonal to BOM view type. The same parent-child CI pair can exist as multiple BOM Items with different intents: an assembly eBOM Item (for manufacturing), an analysis eBOM Item (for FEA), a function eBOM Item (for the systems trade study), and a simulation eBOM Item (for the CAE run). Four BOM Items, two CI nodes, one graph, zero duplication.

This also removes the need for a seventeenth BOM view type. The simBOM — the simulation BOM — is not a separate type. It is an eBOM with structuring intent simulation. The CIs in a simBOM are the same engineering parts as the eBOM; what changes is the structural arrangement and the presence of idealised representations. Storing it as a separate tree would imply a different CI population, which is wrong. Storing it as a structuring intent on the same graph is correct, and the graph carries the idealisation metadata on the CI’s sourceFields.

2.8 Supplier namespace harmonisation and the BOM truth vector

Real programmes import BOMs from suppliers. Many suppliers. Many formats. Many levels of completeness. Many potential duplicates with the integrator’s own content. Clarity handles this with a two-tier CI identity scheme:

• Standard parts (NSN, JEDEC, MIL-SPEC, and other registered standard-part catalogues) are identified by UUIDv5("clarity-standard/{standardNumber}"). This makes the ciId globally stable across every tenant and every supplier. A MIL-SPEC fastener with the same standard number is the same CI everywhere in the world, always.
• Programme-specific parts are scoped: integrator parts use UUIDv5("{tenantId}/{partNumber}"), and supplier parts use UUIDv5("{tenantId}/{supplierCode}/{partNumber}"). This prevents supplier namespace collisions without requiring central coordination.

Standard-part collapsing is automatic. Programme-specific duplicates are handled by six automated harmonisation quality checks that run on every import:

1. Interface completeness — CIs at the boundary between an integrator BOM and a supplier BOM must match by attachment point; gaps or surplus CIs produce a gap or surplus verdict.
2. Quantity consistency — the integrator’s expected quantity and the supplier’s supplied quantity must agree; disagreement produces quantity-mismatch.
3. Structural intent compatibility — an integrator assembly meeting a supplier analysis at the boundary produces an intent-mismatch warning.
4. Effectivity coherence — the supplier’s effectivity window must fit inside the integrator’s; out-of-window supplies produce effectivity-misaligned.
5. Revision currency — the supplier BOM’s referenced revisions must match the current ICD; a mismatch produces revision-mismatch.
6. Probable duplicate CI — the same physical part under different part numbers produces probable-duplicate.

Promotion of a supplier BOM into an integrator L6 is blocked on the critical verdicts (gap, quantity-mismatch, effectivity-misaligned) unless overridden with an explicit rationale.

Sitting above the six checks is the BOM truth vector — a weighted model of which sources the platform trusts to settle a disagreement. The canonical authority weights are:

The ICD carries the same weight as a formal engineering change notice, which reflects how engineering organisations actually work: the ICD is the contract. When a supplier says one thing and the ICD says another, the ICD wins — structurally, not by convention.

2.9 Acquisition modes — as-designed, as-acquired, as-inherited

Real programmes rarely design every part from scratch. They design some parts (as-designed), they acquire other parts from OEMs or licensed manufacturers (as-acquired), and they inherit some parts from predecessor programmes, legacy platforms, or acquired assets (as-inherited). These three modes are not edge cases. They are the norm.

Clarity models acquisition mode as a per-CI field, not a per-product one. A single product will typically have CIs in all three modes, and the acquisitionMode field on each CI drives the design-authority, completeness, and data-rights rules that govern how that CI is handled.

Two @source fields support this model across all layers (not just L6):

• designAuthorityProvenance — who owns the design authority, what authority level (original / contracted / delegated), what data rights, what jurisdiction, what contract reference, what confidence level
• exportControl — what regime (ITAR / EAR / NOFOR / other), what classification, what jurisdiction, what agreement reference, what releasability markings, what owner, what expiry date

These two fields are carried on every write, at every layer, from L0 through L12. They are not a bolt-on compliance module; they are a structural property of every field in the system. The xBOM filter mode described in §2.4 is simply a query over these fields — there is no separate compliance database.

2.10 “BOM is a query, not a tree” — the canonical principle

The architectural documentation backing Clarity’s BOM model contains a single phrase that summarises the entire approach:

“BOM is a query, not a tree.”

The phrase appears in the canonical data-management trade-off matrix of the platform’s BOM management architecture decision record. The full context is that the sixteen BOM views are traversal filters on one L6 CI graph: the eBOM is all used-in edges; the HBOM is used-in where the CI is hardware; the aBOM is alternate-for plus substitute-for edges; the xBOM is the @source export-control filter. All sixteen views. One graph. No stored duplication.

The implication is not just storage efficiency. The implication is that every question the BOM has ever been asked to answer reduces to a graph traversal with a filter predicate. Change management becomes a graph mutation. Variant rendering becomes a filter. Where-used becomes a reverse traversal. Cost rollup becomes an accumulating traversal joined with the procurement overlay. Spares forecasting becomes an operational-configuration traversal at L10. Compliance filtering becomes an @source predicate. None of these requires a separate tool, a separate database, a separate data model, or a separate reconciliation process.

2.11 The eight back-propagation paths — how reality reaches the design plane

The final structural property that closes the BOM loop is that every implementation-plane layer back-propagates its reality into the design plane through typed @source paths. Eight paths are defined, each with a specific source layer, trigger, mechanism, and target.

Every one of these paths is structural. Every one is typed. Every one carries provenance. Every one runs automatically through the event-driven kernel described in the companion whitepaper — immutable writes, EventBridge debounce, quiesce pattern, invariant enforcement. The BOM is not a static artefact that drifts from reality. It is a living graph that absorbs reality and propagates it to the decisions that depended on the old reality being true.

Section 3 — What this unlocks in practice

Sections 1 and 2 described the legacy problem and the Clarity architecture. Section 3 walks through the specific operational properties that fall out of the architecture — the things that become trivially possible in Clarity that are structurally impossible in any legacy forked-tree stack. Each of these is a direct answer to one or more of the recurring patterns documented in Section 1 — patterns the authors have watched organisations struggle with for three decades.

3.1 The eBOM remains the single source of truth — because the mBOM is not a fork

The industry’s long-standing conclusion — “the eBOM must remain the source of truth for engineering; the mBOM must not be a forked tree” — is structurally enforced in Clarity’s architecture. The mBOM is not a separate tree. It is a set of BOM Items at L7, classified by bomViewType: mBOM, referencing the same CI nodes that the L6 eBOM references. When the L6 eBOM changes, the CIs change. When the CIs change, every mBOM Item that references those CIs automatically reflects the change.

Manufacturing-specific content that does not belong in the eBOM (consumables, process steps, shop-floor groupings, supplier substitutes) is added as additional BOM Items at L7 with the appropriate structuring intent (assembly) and relationship types. The manufacturing team’s edits never touch the L6 file. The engineering team’s edits never touch the L7 file. The two layers coexist without forking because they share the underlying CI graph.

A change that originates at L6 propagates to the L7 view automatically. A deviation that originates at L7 back-propagates to L4 through path #1 of the back-propagation table — as a generic L4 change candidate that L4 classifies. Neither team can silently drift from the other, because there is no silent drift to have: the CIs are shared, the edges are typed, and the deviations are structural events, not emails.

3.2 Change management becomes impossible to bypass, because there is nothing to bypass

The “workflow bypass” pattern described in §1.2 exists because legacy change-management tools are heavyweight wrappers on top of a forked-tree BOM. The wrapper is slow because it has to reconcile the fork at every step. The reconciliation is slow because the tools cannot see each other. The engineers bypass the wrapper because the wrapper is the slow thing, and the underlying data move faster without it.

In Clarity there is no wrapper. A change to a BOM Item is a mutation of the graph — a new version of the BOM Item with a new @source record carrying the change lineage. There is no separate ECN document that has to be manually linked to the BOM Item; the link is structural. There is no manual propagation from the eBOM to the mBOM; the mBOM is a view over the same CIs. There is no lag between raising the change and seeing it in the downstream layers; the layers consume the BOM references at read time.

Because the cost of doing the change through the platform is zero — or rather, because the platform is the change — there is no incentive to bypass it. The bypass pattern disappears, not because the discipline improved, but because the architectural cost that created the bypass incentive has gone.

3.3 Contract-manufacturer handoff becomes a shared filtered view

The contract-manufacturer visibility gap of §1.2 arises because the legacy handoff is a bulk export of a forked tree. Clarity replaces it with a shared filtered view of the same graph. The contract manufacturer reads the relevant CIs and BOM Items from Clarity directly, with appropriate tenant / role-based filtering, and every modification they make — deviations, supplier substitutes, work-instruction additions — is written back as new BOM Items with supplierCode in the @source record and the harmonisation quality checks running automatically on every write.

The seven recurring issues listed in §1.2 at the contract-manufacturer boundary are resolved structurally, not procedurally:

• Deviations not followed up with timely ECOs → every deviation is a BOM Item with a @source.changes entry of type deviation, which emits an L4 change candidate through back-propagation path #1; nothing can be a deviation without an L4 record.
• Incorrect BOM items drive supply-chain issues → the harmonisation checks catch revision and effectivity mismatches at write time, not at build time.
• Lack of revision control on Excel BOMs → there are no Excel BOMs; there are only versioned JSON BOM files with immutable history.
• Drawings not aligned with BOM changes → drawings are CIs in the library, linked to BOM Items by @source.evidence references; a BOM change that invalidates a drawing surfaces as a structural event.
• Lack of traceability on lower-level revisions → linkedBomItemId + linkedBomLayer cross-file traceability makes lower-level revision traversal a one-query operation.
• Limited visibility to inventory and WIP impact → the pBOM filter mode aggregates by CI, giving the procurement view directly from the graph without a separate purchasing database.
• No systematic documentation of supplier requests for engineering approvals → supplier requests are first-class BOM Items with their own @source lineage; nothing is off-record.

None of these require a new feature, a new module, or a new integration. They fall out of the architecture.

3.4 As-built and as-deployed traceability is structural, not reconstructive

The as-built gap of §1.2 is closed by L7, L9, and L10 being first-class BOM files with per-item cross-file traceability. Every serial-numbered unit at L7 has a BOM Item record identifying which CIs it was built from, at which revisions, with which supplier substitutions, against which L6 baseline. Every deployed unit at L9 has a BOM Item record identifying which L6 CIs were selected for the site-specific variant, with which effectivity. Every operating unit at L10 has an operating-configuration record summarising what the unit has actually looked like in service, over which time window.

When a failure occurs in the field, the investigation is a traversal: start at the failed unit’s L10 operating configuration, traverse to the L9 as-deployed variant, back to the L7 as-built serial, back to the L6 as-designed intent, back to the L5 decision that approved the design, back to the L3 analysis that supported the decision, back to the L2 option set that was analysed, back to the L0 intent that shaped the option set. Every hop is a JSON reference with provenance. The investigation takes minutes rather than months, and the evidence is admissible without reconstruction.

3.5 Spares forecasting becomes data-driven, not guessed

The spares forecasting problem of §1.2 is the problem of not knowing what is actually in the field. Clarity closes this by making the L11 sBOM and rBOM consume real data from L10 operating configurations. The operational telemetry back-propagates via path #5 into L3 scenario models, which drive the spares forecast through the same Measure-of-Effectiveness framework the platform uses for every other kind of L3 analysis.

The rBOM is not a static parts list. It is a BOM view over the CIs that are currently deployed, filtered by the @source.operational entries that indicate which CIs have been showing signs of wear, which have been replaced recently, and which are approaching end-of-life per the L10 telemetry summaries. The forecast is computed from the live graph, updated continuously through the event-driven pipeline, and visible to the supply-chain team as a first-class view — not a quarterly spreadsheet that is out of date the day it is published.

3.6 Compliance filtering is a query, not a database

The xBOM filter mode of §2.4 is the compliance team’s view of the product. They do not need a separate compliance database. They run the xBOM query filtered by the regime and jurisdiction they care about (ITAR / EAR / NOFOR with their releasability markings), and the platform renders the specific CIs that are in scope, with their full design-authority provenance and export-control metadata.

When an export-control decision is made — a licence granted, a releasability marking changed, a jurisdiction added or removed — the decision is a single update to the @source.exportControl field on the affected CIs, and the xBOM view automatically reflects it everywhere. Downstream consumers (the licensing team, the legal team, the programme office, the cross-border exchange diode described in a separate whitepaper) see the same view at the same time. The compliance team does not have to keep a parallel database in sync with the engineering team’s work, because the compliance data is the engineering team’s work, with a different filter.

3.7 Cross-product CI reuse and supernode management

Every serious programme has high-reuse CIs — fasteners, bulk materials, standard parts that appear in hundreds of assemblies across dozens of products. Legacy stacks treat these as traversal bottlenecks because the parts list has to be rebuilt every time someone asks for it. Clarity pre-computes the aggregation in bom-index.json, a tenant-scope index maintained by the aggregate-bom Lambda.

The index is updated on every BOM write event. It contains where-used pointers (which products reference which CIs), supernode flags (CIs with high reuse degree), and cross-product reuse tracking. A question like “which products use this specific fastener, and if I change its specification, what is the blast radius?” becomes a one-lookup answer against the index, not a multi-hour traversal across seven different databases.

The pBOM filter mode takes advantage of this by aggregating by CI rather than by traversal. The procurement team’s view is the index, joined with the procurement overlay that carries make/buy/inherit and lead-time data. The supernode problem — the same fastener appearing five hundred times in a BOM query and blowing up the performance — is resolved structurally by aggregating at the index level, not at the traversal level.

3.8 Why legacy PLM / ERP stacks cannot be retrofitted

The structural properties described in §3.1 through §3.7 depend on decisions that were made at the kernel of the architecture, not at the feature level. The CI as node with no parentCiId. The BOM Item as edge. The lx-bom.json sidecar pattern. The immutable JSON write model. The typed @source provenance on every field. The event-driven aggregation via the aggregate-bom Lambda. The quiesce pattern for burst writes. The structuring intent orthogonal to BOM view type. The per-layer first-class L8 and L10 files. The linkedBomItemId cross-file traceability. None of these are features. They are the shape of the system.

A legacy PLM cannot adopt the “CI as node with no parent” model without invalidating every customisation built on the assumption that a part has a single parent. A legacy ERP cannot adopt the sidecar pattern without abandoning its transactional update-in-place storage model. A legacy MES cannot adopt first-class L8 / L10 without rebuilding its data model. A legacy change-management tool cannot make the workflow bypass disappear without eliminating the wrapper, which is the product the vendor sells. The retrofit is architecturally impossible — not because the vendors are incompetent, but because the retrofit would require rebuilding from zero and abandoning the revenue stream that funds the existing engineering.

A legacy PLM with a “digital thread module” bought by acquisition is still a legacy PLM. An ERP with a “single source of truth” marketing label is still an ERP storing a forked mBOM in tables with in-place updates. A bolt-on dashboard cannot render sixteen BOM views from one graph because the one graph does not exist in the bolt-on’s data model. The sixteen trees are still sixteen trees, under a new coat of paint.

Conclusion — one graph, sixteen views, every question answerable

A bill of materials is not a document. It is not a file. It is not a report. It is not a module in an ERP or a table in a PLM. A bill of materials is a query over a typed, versioned, provenance-carrying configuration-item graph. When the graph is the authoritative store, every BOM view falls out of it automatically — eleven as per-layer stored types across L6 through L12, five as filter / aggregation modes rendered at read time, sixteen in total, zero duplicated, zero forked, zero synchronised by hand.

Every legacy problem described in Section 1 — the mechanical / electrical coupling gap, the eBOM → mBOM fork, the change-management bypass, the contract-manufacturer visibility gap, the as-built traceability gap, the spreadsheet-of-record anti-pattern — is a symptom of the same architectural mistake: treating each BOM as a separate tree in a separate tool. The mistake is recoverable only by moving the data off the separate trees and onto a substrate that supports a single graph with typed edges, orthogonal structuring intents, supplier-namespace harmonisation, acquisition-mode awareness, and back-propagation from the implementation plane to the design plane. No legacy vendor offers that substrate, because offering it would require rebuilding their entire product.

Clarity is the rebuild. One configuration-item graph. Sixteen BOM views as queries over it. Eleven stored types across L6–L12 with typed cross-layer linkage via linkedBomItemId. Five filter modes that render at query time without duplication. Five relationship types (used-in, alternate-for, substitute-for, replaces, variant-of) that cover every structural relationship a real programme needs. Five structuring intents (assembly, analysis, function, simulation, procurement) orthogonal to the view types. Six automated harmonisation quality checks on every supplier import. Three acquisition modes (as-designed, as-acquired, as-inherited) per CI, not per product. Two new @source fields (designAuthorityProvenance, exportControl) carried on every write across all thirteen Lx layers. Eight back-propagation paths that carry implementation-plane reality back into the design plane. One canonical principle: BOM is a query, not a tree.

That is what Sixteen BOM Views on One CI Graph means. It is not a storage optimisation. It is not a marketing slogan. It is the only architectural shape on which a real complex engineering programme can run its full design-to-deployment lifecycle without building sixteen forked trees and then spending the next decade reconciling them. It is the one the next twenty years of engineering work is going to need.