Architecture, graph-native data model, variant configuration algorithms, and performance validation across eight AI engines for multi-view BOM management, 150% super-BOM resolution, CAD-to-BOM synchronization, eBOM–mBOM transformation, service BOM intelligence, as-built serialized traceability, cost roll-up analytics, and cross-view reconciliation — because the BOM is the single most critical data structure in all of manufacturing, and nearly half of companies still manage it in spreadsheets.
The fundamental problem with BOM management is structural: each department needs a different view of the same product, and each view historically lives in a different system. Engineering’s eBOM reflects functional decomposition from CAD — organized by system, subsystem, and assembly in the hierarchy that makes sense for design analysis. Manufacturing’s mBOM reflects assembly sequences and workstation assignments — reorganized by production flow, with phantom assemblies for kitting, process materials (adhesives, lubricants, solder paste) that don’t appear in the eBOM, and packaging materials added. Service’s sBOM reflects field-replaceable units and repair kits — a completely different decomposition optimized for technician workflow. The as-built aBOM records what was actually installed in each serialized unit at each manufacturing station. Lattice manages all four as interconnected perspectives on a single product graph. A component is one node with four view-specific relationship contexts: its position in the functional hierarchy (eBOM), its installation sequence on the manufacturing line (mBOM), its field-replaceability classification (sBOM), and its actual installed serial/lot number per unit (aBOM). Cross-view reconciliation runs continuously, detecting discrepancies the moment they appear rather than discovering them months later during an audit.
The multi-view BOM data model uses a graph architecture with four primary node types: Item (the canonical component definition — part number, description, material specification, weight, cost, supplier AVL), ViewPosition (the context-specific placement of that item within a particular BOM view — its parent assembly, quantity, reference designator, and find number in the eBOM; its workstation assignment, operation sequence, and tooling requirement in the mBOM; its replaceability classification and kit membership in the sBOM; its actual serial/lot number and installation timestamp in the aBOM), Relationship (typed edges connecting items: contains, substitutes-for, supersedes, requires, conflicts-with), and Configuration (the set of rules that determine which items are included for a specific product variant, market, or customer order). This architecture eliminates the fundamental data integrity problem of traditional multi-view BOM management: when engineering changes a component, the change propagates through the graph relationships to every affected view automatically. There is no synchronization delay, no manual reconciliation step, and no possibility of drift — because there is only one component node, shared across all four views.
The reconciliation engine monitors all four BOM views for discrepancies in real time using a set of invariant rules: (1) every component in the mBOM must trace to a component in the eBOM (no manufacturing-only items without engineering awareness); (2) every field-replaceable unit in the sBOM must correspond to an mBOM assembly boundary (a part that is field-replaceable must be a discrete unit in the manufacturing view); (3) every as-built record in the aBOM must reference a valid mBOM revision at the time of manufacture (no building against obsolete BOMs); (4) component quantities must reconcile across views (if the eBOM specifies 4 fasteners, the mBOM must account for all 4 plus any process-required extras). When a reconciliation violation is detected, the engine generates a discrepancy record with the affected views, the specific items and relationships in conflict, the root cause classification (missing eBOM release, unauthorized mBOM substitution, sBOM not updated after ECO, or aBOM scanner error), and a recommended resolution. Discrepancy records are linked to the knowledge graph and visible to all affected stakeholders in real time. Unresolved discrepancies are escalated according to severity and age thresholds.
Engine 02 manages configurable product families using 150% super-BOMs — master BOMs containing every possible component across every variant, with constraint-based rules that resolve to buildable 100% configurations for specific customer orders. A product family with 8 option categories and 5 choices per category produces 390,625 valid configurations. With 12 categories and variable choice counts, the combinatorial space can reach into the billions. Traditional configuration approaches use nested IF-THEN spreadsheet logic that becomes unmaintainable beyond a few hundred rules. Lattice uses a constraint-satisfaction algorithm that evaluates the complete rule set simultaneously, resolving configurations in milliseconds regardless of complexity. Rules enforce three constraint types: technical compatibility (this motor requires this controller, this power supply is incompatible with this voltage range), regulatory compliance (this market requires this safety certification, this refrigerant is banned in this jurisdiction), and commercial logic (this option package includes these features at a bundled price, this upgrade replaces this standard item). Engine 03 extracts BOM structures natively from CATIA, NX, Creo, SolidWorks, Inventor, Fusion 360, and STEP/JT neutral formats, maintaining assembly relationships, metadata, and revision linkage without requiring manual BOM creation from CAD outputs.
The configuration engine uses a three-phase resolution pipeline: (1) Option Selection — the customer or sales engineer selects options from the product configurator, each selection activating include/exclude rules across the 150% super-BOM; (2) Constraint Propagation — each selection triggers forward-chaining constraint evaluation that automatically resolves dependent choices (selecting a 480V motor automatically selects the matching VFD, the appropriate overload relay, and the compliant cable gauge), detects conflicts (selecting both a high-temperature coating and a low-cost standard finish), and presents remaining valid choices for unresolved options; (3) BOM Resolution — once all options are determined, the engine resolves the 150% super-BOM into a buildable 100% configured BOM with exact part numbers, quantities, and assembly instructions. The resolved BOM is versioned and linked to the sales order in the knowledge graph, ensuring that what was sold matches what is built. Invalid configurations are architecturally impossible — the constraint engine blocks selection of incompatible options before they reach manufacturing, eliminating the 40% of order-entry errors that configuration spreadsheets cause in engineer-to-order manufacturers.
The CAD-to-BOM synchronization engine maintains live bidirectional linkage between the CAD assembly structure and the Lattice eBOM. When an engineer adds a component in CATIA, the corresponding BOM item is created in Lattice with metadata extracted from the CAD model: part number, description, material, weight, geometric envelope, and assembly relationships. When an engineer removes or replaces a component, the BOM updates immediately. Critically, the synchronization preserves the semantic meaning of CAD relationships that simple file-export approaches lose: a bolt that fastens two assemblies together belongs to both assemblies functionally but must be assigned to one workstation in the mBOM — Lattice tracks both the functional relationship (eBOM context) and the manufacturing assignment (mBOM context) for the same component. Multi-CAD environments (e.g., mechanical in NX, electrical in CATIA, plastic housings in SolidWorks) are unified into a single eBOM that merges the assembly structures from all CAD systems, resolving naming conflicts and establishing cross-domain assembly relationships that no single CAD system can express.
Engine 04 addresses the most error-prone handoff in product development: the transformation from engineering’s functional BOM to manufacturing’s assembly-sequence BOM. A component that engineering groups with its functional subsystem may need to be installed earlier in the manufacturing sequence due to access constraints. Phantom assemblies must be introduced for kitting. Process materials (adhesives, solder paste, lubricants) that do not appear in the eBOM must be added. Lattice provides guided restructuring with full traceability: every mBOM item traces to its eBOM origin, every structural change is documented with justification, and bidirectional change propagation ensures that ECOs flowing through Cascade update both views automatically. Engine 05 auto-derives the sBOM from the mBOM by classifying components by field-replaceability: customer-replaceable units (CRUs), field-replaceable units (FRUs), and non-replaceable items that require factory return. Supersession chains track part number evolution across design revisions, ensuring service technicians always receive the current-revision replacement. Engine 06 captures the as-built configuration at each manufacturing station through barcode scanning, creating a serialized record of exactly what was installed in each unit — enabling Echo’s root cause traceability and Cascade’s effectivity management.
The transformation engine provides a visual workspace where manufacturing engineers restructure the eBOM hierarchy into the mBOM assembly sequence. Drag-and-drop operations move components between assembly groups, with the engine tracking every structural change and maintaining the traceability link between the eBOM origin and the mBOM position. The engine enforces structural integrity rules: every eBOM leaf component must appear in the mBOM (nothing can be lost in translation), no mBOM item can lack an eBOM origin unless it is explicitly classified as a process material or packaging material, and quantity totals must reconcile between views. Phantom assemblies — virtual groupings that exist in the mBOM for manufacturing convenience but do not represent physical assemblies — are first-class objects with explicit classification so they are not confused with real assemblies in procurement or inventory. When an ECO processed through Cascade modifies the eBOM, the transformation engine automatically identifies the affected mBOM positions and presents the manufacturing engineer with the required updates, pre-populated with the proposed changes and requiring only approval rather than manual re-derivation.
Engine 06 captures the actual configuration of each manufactured unit at each assembly station through barcode or RFID scanning of component serial numbers and lot codes. The as-built record documents not just what was designed (eBOM) or what was planned (mBOM), but what was physically installed in unit SN-48720 at Station 14 at 14:23:07 on 2024-11-15 by operator badge #2847. Deviations between the planned mBOM configuration and the as-built reality are detected in real time at the station: a different component revision, a substitute part from an alternate supplier, or a missing item. Deviations are classified by severity (critical, major, minor) and routed through the appropriate disposition workflow — use-as-is, rework, or reject. The as-built registry becomes the foundation for Echo’s field intelligence: when a field failure is reported on unit SN-48720, Echo traverses the aBOM to identify the exact component revision, supplier lot, and manufacturing station — enabling root cause traceability that is impossible without unit-level as-built records. A defense contractor deployment achieved 100% as-built traceability with DCMA audit time dropping from 3 days to 4 hours.
Engine 07 computes cost roll-ups across all four BOM views simultaneously, revealing cost perspectives that single-view systems cannot provide: the eBOM cost (design cost based on target pricing from the AVL), the mBOM cost (actual manufacturing cost including process materials, scrap factors, and labor), the sBOM cost (aftermarket service cost including markup, kit assembly labor, and warranty reserve), and the aBOM cost (actual cost per unit including any deviations from the planned configuration). Should-cost analysis compares the current BOM cost against parametric cost models and industry benchmarks, identifying components where the current supplier price exceeds the should-cost estimate by more than a defined threshold. Engine 08 provides the definitive 4-way BOM diff: comparing eBOM, mBOM, sBOM, and aBOM to detect discrepancies across any combination of views. Regulatory compliance gap detection screens every BOM item against RoHS restricted substance lists, REACH SVHC candidate lists, TSCA inventories, California Proposition 65, and conflict mineral regulations (3TG). Substance declarations aggregate upward through multi-level BOM roll-ups: if any leaf component contains a restricted substance, the flag propagates to every parent assembly and finished product.
The cost roll-up engine computes four simultaneous cost perspectives from the same product graph: (1) eBOM design cost — the sum of target component costs from the approved vendor list (AVL), providing the baseline cost estimate that engineering uses during design trade-off decisions; (2) mBOM manufacturing cost — the actual production cost including component costs at negotiated purchase prices, process material costs (adhesives, solder, lubricants), labor costs per workstation based on cycle times from the routing, scrap and yield loss factors applied to each component based on historical manufacturing data, and overhead allocation; (3) sBOM service cost — the aftermarket cost structure including component cost with service markup, repair kit assembly labor, field technician labor for replacement, warranty reserve allocation per field-replaceable unit, and logistics cost for reverse logistics and core return; (4) aBOM actual cost — the realized cost for each manufactured unit, capturing deviations from the planned mBOM such as approved substitute components at different prices, yield losses at specific stations, and rework labor. The delta between mBOM planned cost and aBOM actual cost is the manufacturing cost variance — a metric that drives continuous improvement.
The regulatory compliance screening engine operates at the leaf level of the BOM and rolls upward: each purchased component carries material declaration data (IPC 1752A format) from its supplier, listing the substances and concentrations present in the component. Lattice screens each component against every applicable restricted substance regulation simultaneously — EU RoHS (10 restricted substances), REACH SVHC candidate list (updated semi-annually by ECHA), TSCA chemical inventory, California Proposition 65, and conflict mineral regulations (tin, tungsten, tantalum, gold). When a component contains a restricted substance, the flag propagates upward through every parent assembly, sub-assembly, and finished product that contains it — because regulatory compliance is assessed at the product level, not the component level. Product-level compliance declarations are generated per target market and regulation: one BOM, multiple compliance declarations. When ECHA adds a new substance to the REACH SVHC candidate list, Lattice automatically re-screens every BOM and flags all newly affected products within seconds — rather than the weeks-long manual review that characterizes traditional compliance processes.