Engineering Bill of Materials (EBOM)

There is no formal bill of materials. The assembler knows what parts go into the product because they have built it a hundred times. When a new person asks 'what parts do I need for Product X?' the answer is 'watch Maria build one and take notes.' If someone orders the wrong parts, the assembler catches it on the floor, not from a document.

AI cannot perform any BOM analysis, component risk assessment, or cost rollup because no product structure exists in any system.

Parts lists exist in spreadsheets maintained by individual engineers. Each engineer has their own format — some include revision levels, others do not. Some list sub-assemblies as separate tabs, others flatten everything into one list. When you need the BOM for Product X, you find the engineer who designed it and ask for their spreadsheet. Half the time, the spreadsheet does not match what manufacturing actually builds.

AI could parse individual spreadsheets but cannot reconcile conflicting BOMs or build a reliable product structure because formats, completeness, and accuracy vary per engineer.

A standard EBOM template is used consistently. Every product has a BOM in the same format in a shared location — part number, description, quantity, material spec, revision level. Engineers maintain BOMs in a shared system (structured spreadsheet or basic PDM). Finding the current BOM for any product is straightforward. But make-versus-buy decisions, effectivity dates, and alternate components are tracked separately or not at all.

AI can generate BOM comparisons, cost rollups, and component usage reports. Cannot perform supply risk analysis or change impact assessment because component relationships, alternates, and effectivity logic are not captured in the BOM structure.

EBOMs live in PLM with complete product structure — assemblies, sub-assemblies, components, and raw materials are all defined with revision control and effectivity dates. Each line item links to its material specification, approved suppliers, and make-versus-buy status. Engineers can query 'show me every product that uses Component X at Revision C or later' and get a reliable answer. BOM change history is complete and traceable.

AI can perform where-used analysis, change impact assessment, component obsolescence planning, and multi-level cost rollups. Can predict BOM impacts of engineering changes before they are approved. Cannot yet auto-generate BOMs from design intent.

EBOMs are schema-driven entities with formal relationships to every aspect of the product lifecycle. The EBOM auto-derives from the CAD assembly. MBOM and SBOM variants maintain explicit transformation rules from the EBOM. Every component has formal entity definitions — specifications, test requirements, supply sources, manufacturing process requirements — all queryable via API. An AI agent can ask 'what is the complete procurement and manufacturing impact of substituting Material A for Material B in Product X?' and get a structured, comprehensive answer.

AI can perform autonomous BOM optimization, alternative material evaluation, and cross-product component standardization. Full lifecycle cost modeling from design through service is possible from BOM relationships alone.

The EBOM is a living, self-maintaining product structure that continuously evolves with the design. CAD assembly changes instantly propagate through EBOM, MBOM, and SBOM variants. Component specifications, supplier qualifications, and manufacturing requirements update in real-time as the design evolves. There is no static 'BOM document' — only a continuous product structure stream that always reflects the current design state.

Fully autonomous product structure management. AI maintains all BOM variants, propagates changes, resolves conflicts, and optimizes component selections in real-time. The BOM is a living entity, not a static document.

Ceiling of the CMC framework for this dimension.