Catalog & BOM standards by industry¶
The hardest part of this system is catalog and BOM modeling — everything else is swappable around it. The graph model this project uses is deliberately industry-agnostic:
- products — the atomic, purchasable/traceable items (SKUs);
- systems — engineered assemblies made of products (the thing you actually quote / build / manufacture);
- procedures — the instructions that turn products into a working system;
- edges — typed relationships carrying quantities:
part_of_system(BOM),requires,compatible_with,applied_by_procedure.
What changes between industries is which external standards fill those slots: the product identifier scheme, the classification taxonomy, the meaning and structure of the "BOM", the data-exchange format, and the regulations that force certain relationships to exist and be auditable. This page is an orientation to those standards so you can map a new domain onto the schema.
Orientation, not legal advice
Standards and regulations evolve and vary by region. Treat this as a map of the landscape, and verify the current version and applicability of any standard with its issuing body before building against it.
The common backbone¶
A handful of standards recur across every industry below.
| Concern | Standards you'll meet everywhere |
|---|---|
| Trade item identity | GS1 GTIN (Global Trade Item Number, the number behind a barcode), GLN (locations), SSCC (logistic units) |
| Classification / taxonomy | UNSPSC (procurement), eCl@ss (industrial, property-rich), GS1 GPC, ETIM (technical products w/ features) |
| Product-data exchange | GS1 GDSN (data pools), ISO 8000 (master-data quality), ISO 10303 / STEP (engineering product data, PLM) |
| BOM archetypes | EBOM (engineering), MBOM (manufacturing), service/spare BOM, sales/configurable BOM |
\"BOM\" is an overloaded word
In manufacturing a BOM is a parts-and-quantities tree. In software an SBOM is a Software Bill of Materials (component/licence inventory, e.g. SPDX / CycloneDX) — a different thing. In construction the closest concept is a Bill of Quantities. Always pin down which one a stakeholder means.
The pattern to look for in any industry: a stable identifier, a classification with attributes, a quantified decomposition (the BOM), and a regulatory trace that dictates what must link to what.
Construction / building products¶
The project's home domain (the plasterboard example).
| Concern | Standard(s) |
|---|---|
| Identity | Manufacturer article numbers; increasingly GS1 GTIN |
| Classification | Uniclass 2015 (UK), OmniClass & MasterFormat/UniFormat (North America), CoClass (SE), CCI, ETIM (MEP/electrical) |
| Product data | BIM / IFC (ISO 16739), COBie handover data, Product Data Templates (PDTs), EPDs (EN 15804) |
| "BOM" | Bill of Quantities (BoQ) / quantity takeoff; measured per NRM (RICS); systems → materials with per-area/-length quantities |
| Regulatory drivers | EU Construction Products Regulation (CPR) → CE marking + Declaration of Performance (DoP); harmonised EN standards; fire/acoustic/thermal classes |
Why it maps cleanly here: Uniclass even splits Systems (Ss) from
Products (Pr) — exactly this schema's system vs product. A construction
"system" (e.g. a W112 partition) carries performance classes (fire EI60,
acoustic Rw), and its BoQ is per-unit-area quantities — which is precisely what
system_product_edge.quantity_per_unit models.
| This schema | Construction concept |
|---|---|
product |
building product (Uniclass Pr, GTIN, w/ DoP) |
system |
building system / assembly (Uniclass Ss, performance-classed) |
procedure |
installation method / application guide |
system_product_edge (qty) |
bill of quantities line (per m²/m) |
requires |
compliance/compatibility requirement (e.g. board → matching screw & fire class) |
applied_by_procedure |
installation sequence |
Pharmaceuticals¶
Here the "catalog" is medicinal products and the "BOM" is a formulation / recipe, and traceability is legally mandated down to the batch.
| Concern | Standard(s) |
|---|---|
| Identity | GS1 GTIN on packs; NDC (US National Drug Code); GLN for sites |
| Substance & product identity | ISO IDMP suite — 11615 (medicinal product), 11616 (pharmaceutical product), 11238 (substances/SMS), 11239 (dose forms/routes), 11240 (units) |
| Classification | WHO ATC/DDD, RxNorm (US), SNOMED CT |
| "BOM" | Formulation / recipe: quantities/ratios of API(s) + excipients; batch/lot genealogy; process modelled with ISA-88 (batch control); Master Batch Record |
| Data exchange | GS1 EPCIS (traceability events); HL7 SPL (US labeling); eCTD (submissions, not catalog) |
| Regulatory drivers | GMP; serialization: EU FMD (Delegated Reg 2016/161) + EMVS, US DSCSA — unique identifier in a 2D Data Matrix, verified through the supply chain |
What's different: quantities are exact ratios under tolerance, not
"~10% waste"; and every unit must trace to a batch/lot, so the graph gains a
lot/batch dimension the construction model doesn't need. requires edges encode
regulated composition (an API requires its excipient system), not convenience.
| This schema | Pharma concept |
|---|---|
product |
substance / packaged drug (GTIN + IDMP substance ID) |
system |
finished medicinal product / formulation |
procedure |
Master Batch Record steps (ISA-88 recipe) |
system_product_edge (qty) |
formulation line (mg/unit, %w/w) |
requires |
mandated composition / substance relationship |
| (add) lot/batch node | batch genealogy for serialization/recall |
Medical devices¶
Component-level traceability again, but driven by UDI and design-record regulation rather than batch recipes.
| Concern | Standard(s) |
|---|---|
| Identity | UDI = DI (device identifier) + PI (production identifier: lot, serial, expiry); Basic UDI-DI (EU); issuing agencies GS1 / HIBCC / ICCBBA |
| Databases | GUDID (US FDA), EUDAMED (EU) |
| Classification / nomenclature | GMDN (Global Medical Device Nomenclature), EMDN (European) |
| "BOM" | Device EBOM/MBOM with component & material traceability; UDI applied at each packaging level |
| Quality records | Device Master Record (DMR), Device History Record (DHR), Design History File (DHF) |
| Regulatory drivers | ISO 13485 (QMS), US 21 CFR 820 / QMSR, EU MDR 2017/745 & IVDR; risk ISO 14971; biocompatibility ISO 10993; electrical IEC 60601 |
What's different: the BOM is inseparable from the quality system — the DMR is the authoritative product definition, and each component may carry its own compliance evidence (biocompatibility, sterilization). Traceability is by UDI + production identifier, and packaging levels form a hierarchy.
| This schema | Medical-device concept |
|---|---|
product |
component / material (with UDI-DI where applicable) |
system |
finished device (Basic UDI-DI, GMDN/EMDN class) |
procedure |
manufacturing process / Instructions For Use (IFU) |
system_product_edge (qty) |
device BOM line + traceability requirement |
requires |
mandatory component / compliance dependency |
applied_by_procedure |
DMR-referenced process step |
Telecommunications¶
The odd one out: the "catalog" is products, services, and resources, and the "BOM" is really a decomposition from what the customer buys down to the network that delivers it.
| Concern | Standard(s) |
|---|---|
| Catalog model | TM Forum SID (Shared Information/Data model); Product / Service / Resource split; Product Offering vs Product Specification |
| APIs / exchange | TM Forum Open APIs — TMF620 (Product Catalog), TMF633 (Service Catalog), TMF634 (Resource Catalog); eTOM processes |
| Service definitions | MEF (Carrier Ethernet, LSO, MEF 3.0) & MEF LSO APIs for connectivity products |
| Decomposition | CFS/RFS — Customer-Facing Service maps to Resource-Facing Service maps to physical/logical resources |
| Identity | Product-offering IDs; GS1 GTIN for CPE hardware; network inventory identifiers |
| "BOM" | Product bundle → service components → resources; hardware still uses classic EBOM/MBOM |
What's different: a telco "BOM" is layered and often configurable — a
product offering decomposes into services, services into resources, with
commercial vs. technical catalogs kept separate. The requires/part_of
edges model a service decomposition tree, not a physical parts list (except
for CPE hardware, which is classic manufacturing BOM).
| This schema | Telecom concept |
|---|---|
product |
resource / CPE hardware / atomic service component |
system |
product offering / bundle (a Customer-Facing Service) |
procedure |
service activation / provisioning workflow |
system_product_edge (qty) |
bundle/service decomposition (CFS → components) |
requires |
CFS → RFS → resource dependency |
compatible_with |
interoperability between network elements |
Side by side¶
| Construction | Pharma | Medical devices | Telecom | |
|---|---|---|---|---|
| Identifier | GTIN / article no. | GTIN + NDC + IDMP | UDI (DI+PI) | offering ID / GTIN |
| Classification | Uniclass / OmniClass / ETIM | ATC / IDMP | GMDN / EMDN | TM Forum SID |
| "BOM" means | bill of quantities | formulation / recipe | device BOM + traceability | product→service→resource decomposition |
| Quantities | per area/length (+waste) | exact ratios (tolerance) | exact + traceable | configurable/logical |
| Trace unit | batch/DoP | lot/batch (serialized) | UDI + lot/serial | service instance |
| Key regulation | CPR / CE / DoP | GMP + FMD/DSCSA | ISO 13485 / MDR / FDA | (commercial + MEF/TMF) |
| Exchange | IFC / COBie / GDSN | EPCIS / SPL | GUDID / EUDAMED | TMF Open APIs |
Adapting this pipeline to your industry¶
A checklist for pointing the catalog schema at a new domain:
- Pick the identifier your products are keyed by (GTIN, UDI, NDC, offering
ID) → it becomes
product.sku(and any secondary IDs go inattributes). - Adopt a classification with attributes (eCl@ss, ETIM, Uniclass, GMDN) →
populate
product.categoryand theattributesjsonb; the extraction enums (extraction/schema.py) should be drawn from this vocabulary. - Decide what a "system" is — the thing you quote/build (assembly,
formulation, device, product offering) →
system, with its performance / regulatory classes inattributesfor the rules engine to match on. - Model the BOM edges with the right quantity semantics — waste factors for
construction, exact ratios for pharma, traceable components for devices,
decomposition for telecom →
system_product_edge.quantity_per_unit+unit. - Encode mandated relationships as
requiresedges (composition rules, compliance dependencies) — these are deterministic data, never inferred by the model. - Add a trace dimension if regulated — batch/lot for pharma, UDI production identifier for devices — as an extra node/table beyond this starter schema.
- Put the compliance logic in the rules table (
rules/rules.yaml), so a domain expert extends it without touching prompts — the same way the construction fire/moisture rules work today.
The invariant across all four industries stays the same as this system's core principle: vector search finds the entry point; the graph delivers the relationships — and the relationships are whatever your industry's standards say must be true, resolved deterministically, never guessed.