1. Introduction

A vehicle seat has to satisfy packaging, comfort, safety, feature, regional-market, and manufacturing requirements at once. Within one family, trim style, surface material, stitching, piping, hard- plastic color, comfort hardware, electronics, market content, and plant build strategy interact instead of varying independently, so a single family yields many buildable variants of which only a small subset is valid for a given vehicle line, model year, and plant. The theoretical end-product count is too large to hold as separate bills of material (BOMs), which is why mass-customization environments keep a generic superset structure [1], [5], and why variety is itself a cost driver [2]. Seat engineering has grown more quantitative over three decades [3], [4], but product- structure management has not kept pace.

In production programs observed by the author at a Tier 1 seating supplier, assigning color to a part means moving between interior callout documents, engineering-change tabs, and PLM to establish which material applies where, then recording the answer in a form PLM will accept. A second workflow consolidates several customer color definitions from the color-and-trim report (CTR) into one internal trim-color code and rebuilds the result as a plant-facing spreadsheet, because the plant cannot read the engineering representation. Both depend on a few trim engineers who know each customer's conventions. The architecture proposed here holds one authoritative 150% engineering structure per seat family as a graph, with deterministic rules carrying documented constraints and machine learning recovering constraints never written down.

A. Contributions

The primitives used here are established: generic or 150% superset structures, predicate-based derivation, and ontology-linked configuration. No novelty is claimed for them. Three contributions are claimed. First, a seat-domain ontology in which SurfaceZone, ColorCode, MaterialFamily, and TrimStyle are constraining entities rather than part attributes, which makes color and trim logic computable. Second, treatment of document-sourced configuration semantics as a problem class of its own: configurator and product- line traditions assume configuration knowledge is authored inside the enterprise, whereas in seating much of it arrives from customers as documents that are late and repeatedly revised. What is claimed is the handling of extracted content as governing logic, carrying a confidence value and a provenance path. Third, a bitemporal view of that knowledge, with a resolution algorithm that keeps deterministic validation separate from learned assessment.

B. Scope and Assumptions

Failure modes were identified from direct engineering and information-technology experience with production seating programs at a Tier 1 supplier, covering color-part configuration, EBOM-to- MBOM transformation, configurator variant-rule behavior, and change-impact analysis. Program, customer, supplier, and system identities are withheld, and no proprietary data or part numbers are included. No deployment results are reported. Five assumptions bound the work. A1: one authoritative 150% structure can be maintained per seat family. A2: enough released configurations exist to train a plausibility model. A3: source systems emit change events or can be polled. A4: CTR documents can be parsed to a recorded confidence level. A5: engineers retain release authority.

A2 is the weakest. A front-seat family may hold several thousand theoretically buildable variants but only a few hundred released over program life, and the feature vector described in Section 5 is high-dimensional against that sample, so an autoencoder would memorize it rather than learn the manifold. Early deployment should use distance-based and rule-consistency detection and defer reconstruction models until a multi-program training set exists; the governance posture in Table 4 does not depend on the detector.

2. Background and Related Work

Five streams of published work bear on seat BOM and configuration management, and each leaves a different gap. High-variety BOM structure supplies the generic bill of material, a product-family model held once as a parameterized superset from which specific bills are generated [5], later extended to routing so that engineering, ordering, and operations planning share one representation [6]; carmaker practice shows how constraints reduce a large alternative space to a buildable subset [1], [2]. This is the foundation of the 150% BOM used here, but it addresses neither color and trim semantics nor many-to-one customer-color mapping. Configuration research establishes how predicates derive a specific product from a generic model [7]-[10], and product-line engineering treats the same problem through feature models [11], [12].

Enterprise- and plant-level work connects configuration to BOMs and downstream plans [13], supplies the commonality-versus-variety framing [14], recovers generic BOM structure from what was built [15], derives engineering and manufacturing views from one source [16], formalizes transformation for production planning [18], and retargets an EBOM to a maintenance BOM [17]. Graph-based lifecycle integration connects design, manufacturing, and quality artifacts through persistent identifiers [19], [21], where what is promoted to an addressable entity determines what can later be reasoned about [20], [24]; knowledge graphs have been applied to configuration [22], [23], and a graph BOM model couples product development with production planning [25]. No published work known to the author applies these primitives to a commodity in which trim and color drive variety.

A. Capability Gap Versus Deployment Gap

In the reference environment, saved variant rules can express a 100% BOM derived from a released 150% BOM, but when the 150% structure is revised there is no reliable way to identify every saved rule affected. That is an observation about one deployment, not evidence against the technology class. The narrower claim made here is that three capabilities were not available together: color and trim semantics as first-class constraints, configuration knowledge extracted from external documents with recorded confidence, and bitemporal state separating when a change applied from when the enterprise learned about it.

3. Problem Definition

A seat variant combines several option spaces, each with its own structure and constraints. Table 1 multiplies the main dimensions of a representative front-seat family before left/right position, model year, or plant destination are considered.

Table 1. Representative option dimensions for a front-seat family

Customer-visible choices are weak predictors of the engineering content beneath them. One internal trim-color code may stand for several customer color values across six seat areas, and whether two zones share a code depends on piping, stitching, and whether the theme is single- or multi-tone. The real problem is the constrained mapping from commercial language and supplier documents to engineering parts, and from there to plant-consumable content. Table 2 lists the recurring failure modes observed and the architectural response to each.

Table 2. Current-state failure modes and their architectural response

These are data-engineering problems, and stricter process discipline alone has not produced durable improvement. The data model has to reconcile conflicting identifiers and states, analytics have to catch invalid combinations before material reaches the plant, and changes have to propagate through variant space at bounded cost. Saved variant rules do not propagate.

4. Proposed Architecture

A. Design Principles and Layering

The architecture keeps one authoritative 150% seat structure per product family and represents entities, constraints, and events directly as a graph, following the generic BOM and configuration literature [1], [5], [7], [13] and graph-based digital-thread work [19], [21], [25]. Layer L1 in Figure 1 ingests structured sources such as PLM part masters, released EBOMs, and saved variant rules, together with the semi-structured sources carrying most of the color logic. Layer L2 assigns each record a persistent graph identifier and a provenance tuple holding source system, source object identifier, source revision, ingestion timestamp, confidence, and validation flags. Versioning is bitemporal [27]-[29]: valid time records when content applies, transaction time when the platform learned it. External documents often arrive after the change they describe, so valid time alone cannot answer what the platform believed on a given date.

Figure 1. Six-layer reference architecture. Sources are ingested and resolved to persistent identities, held in the seat-domain ontology of Table 3, reasoned over by rules and AI together, and materialized as engineering and manufacturing output

B. Ontology and Graph Schema

A seat BOM ontology has to carry more than parent-child assembly. PartUsage is modeled as a node rather than an edge property because seat variants need instance-level attributes: quantity, side, stitch pattern, color treatment, effectivity, and plant- specific substitution. Making PartUsage addressable keeps variant filtering manageable, following the principle that only entities made explicit can later be reasoned over [20], [24]. Table 3 gives the canonical schema from which Figure 1 is drawn. PartUsage is the pivot at which structural, configuration-semantic, and operational relations meet, and the lifecycle edges force re- resolution when a change event commits.

Table 3. Canonical node and edge specification of the seat configuration graph

Consider a trim-cover assembly whose substrate is shared across several visible color variants while the foam adhesive changes in one region and the sewing thread in another. In the graph the trim-color code, regional package, substrate material, and thread choice are separate nodes joined by typed constraints, and a valid 100% BOM is the subgraph produced by a feature assignment and an effectivity window. In a hierarchy the same dependencies have to be duplicated across every affected branch or moved into spreadsheets, where nothing validates them.

5. AI and Analytics Methods

Letting a model generate configurations directly is not defensible for a product structure carrying safety and quality obligations. Deterministic rules stay authoritative for mandatory inclusions, exclusions, and cardinality, and AI supports them. Table 4 identifies the analytics applied above the structural responses of Table 2, the failure modes they address, and the authority each is allowed.

Table 4. Analytics methods, target failure modes, and governance posture

A. Hybrid Derivation and Constraint Propagation

Let F be the selected features and options, C the hard constraints, P the part usages in the 150% BOM, t the effectivity instant, and plant the target location. Deterministic evaluation produces the candidate set

(1)

Equation 1 filters P and cannot introduce part usages outside that set, but seat configuration often depends on implications running the other way: a premium perforated substrate in one zone may require a thread family and a side-shield color mapping that no predicate over F names. Those relationships are the semantic edges of Table 3. With I the active implication set, each implication written q implies p, the resolved set is the least fixpoint

(2)

so B* holds B*0 plus every part usage reachable through active implications, and B* is what gets scored and materialized. Equation 2 is monotone and the closure step does not check C, so if q implies p and q is in B*0, then p enters B* even where the predicate would have excluded it for exclusivity, cardinality, or effectivity. The risk is not incompleteness but that B* may violate the constraints that defined B*0.

The architecture therefore re-validates B* against C after closure and treats any post-closure violation as a hard stop rather than a low score. Let V = violations(B*, C). If V is non-empty the configuration is not materialized under any plausibility score; it returns as a review package carrying the implication paths responsible. A hard-constraint violation and a low plausibility score are different findings: one breaches authored logic whatever the history contains, the other is a statistical judgment calibrated against what has been built. Algorithm 1 keeps the two separate, and assumption A5 depends on it.

The AI layer then scores B* for plausibility and completeness against released configurations, manufacturing output, and source- document implications. Let σ(B*) be that score on [0,1], where 1 means indistinguishable from accepted practice; where the detector produces a reconstruction error or outlier distance e, σ is a fixed monotone decreasing normalization of e. Below threshold τ the system raises an explainable alert instead of emitting an unchecked BOM. τ is governed by review capacity rather than model tuning. Graph reasoning adds transitive impact analysis, propagating a color-code change to trim-cover part usages, plant MBOM rows, and supplier package references, and cross-domain conflict detection, which catches inconsistencies no single system sees.

B. Anomaly Detection and Variant Rationalization

Anomaly detection is applied here to product-structure and configuration data rather than to machine telemetry; the literature reviewed above showed no prior work applying outlier detection directly to released BOM or configuration structures, which is recorded as a gap rather than an exhaustive claim. Let xv be a feature vector for variant v built from selected features, resolved part families, commodity-level count distributions, color-zone signatures, and plant assignment. A distance-based or one-class detector trained on accepted variants flags configurations outside the accepted region, with specific alert classes: missing mandatory usages, duplicated mutually exclusive parts, impossible color-zone pairings, and cost jumps absent from neighboring variants. Training variants came from the manual process this architecture is meant to replace, a circularity that restricting training to never-corrected configurations reduces but does not remove.

Portfolio complexity is a separate question from single-variant validation. The optimization layer treats variant rationalization as a constrained choice over retained feature bundles and unique parts. Let yi = 1 when bundle i is retained and zj = 1 when part j is retained; let cj be the unit cost attributable to part j, bi the change burden of bundle i, and vi its verification load. The objective is

(3)

subject to constraints that give it meaning, with M the market segments to serve, I(m) the bundles covering segment m, U(i) the parts consumed by bundle i, X the incompatible bundle pairs, wi the customer value of bundle i, and W the minimum portfolio value accepted by product planning:

(4)

Coverage prevents the trivial solution, since all coefficients are non-negative; the linking constraint keeps a part whenever a retained bundle uses it. The formulation is NP-hard in general, so it belongs in offline decision support rather than inside Algorithm 1. Where coverage and incompatibility conflict, returning the minimal infeasible subsystem to product planning exposes the binding segment instead of quietly relaxing W.

6. Deriving 100% BOMs from the 150% Structure

Figure 2 shows the seven-stage resolution workflow, and Algorithm 1 states it.

Figure 2. Seven-stage resolution workflow. B* is scored before anything is materialized

Algorithm 1. ResolveVariant

Algorithm 1 extends the saved-variant-rule mechanism of the reference configurator with post-closure re-validation, lifecycle- aware scoring, explainable validation, and synchronized engineering and manufacturing output. Stage S4 dominates cost. The fixpoint in Equation 2 uses a worklist that marks each part usage on first entry, so each element of B* expands at most once and each outgoing implication edge is examined at most once. With d the maximum out-degree over semantic edges,

(5)

A naive path enumeration would be O(|B*0| · dᵏ) for traversal depth k because it revisits elements already reached. Marking removes depth from the bound: the traversal is linear in the reachable implication subgraph, so the size of the reachable set, not the depth needed to reach it, decides whether S4 is inexpensive. A pilot should instrument the distribution of |B*| relative to |B*0| and report k separately.

A. Producing the Manufacturing Graph

Producing the manufacturing graph is more than a flattening step. Plants need top-level assemblies, process phantoms, packaging, labels, line-side sequence kits, color-consumable rows, and supplier mappings that do not exist in the engineering structure [16]-[18]. The operator T applies plant templates, phantom- assembly rules, procurement views, routing links, and color interpretation to the resolved engineering subgraph. Where no engineering-side color part exists, current practice substitutes a customer part number in a spreadsheet and the decision becomes hard to trace; here it is a governed node with provenance. Recipes are versioned templates linked to plants, so an engineering revision recomputes only the affected MBOM fragments.

Figure 3. EBOM-to-MBOM transformation. T is parameterized by versioned, plant-linked recipe templates, which makes every structural difference between the program view and the plant view explicit and attributable

7. Application Scenario

Take the front-seat family of Table 1, built across 3 plant destinations. Trim covers, headrests, side shields, armrests, and cushions each carry color and material semantics the base PLM structure does not fully capture. Table 5 compares current and proposed handling of two representative tasks. In the proposed architecture, customer CTR rows, trim engineering outputs, PLM parts, and plant MBOM templates are all graph nodes; surface zones are named explicitly; and each customer color entry maps first to a semantic color entity and then to a governed internal color-code node.

Table 5. Baseline versus proposed handling of representative seat configuration tasks

8. Discussion

None of the following has been measured. Anomalies and validation failures would surface before material reaches the plant, which is where BOM defects are usually caught today. Cycle time is the most visible candidate for improvement: a color program that currently takes weeks to process manually would resolve against the graph in a single pass. One graph-derived structure also replaces numerous parallel spreadsheets and saved-variant artifacts. Table 6 defines the pilot metrics: a paired comparison on one seat family of N variant releases under current practice against N releases after cutover, evaluated by a two-sided paired test at the 5% level.

Table 6. Evaluation framework for a future deployment study

A. Limitations and Implementation Risks

The architecture is conceptual, so its benefit claims are architectural arguments rather than measured outcomes, and the pilot of Table 6 is what would settle them. Training data volume is small relative to the feature space, which is why rule- consistency detection comes first. Critical color and trim semantics still arrive in semi-structured external documents, so ingestion must be staged with confidence flags, a human-in-the- loop resolution queue, and reported parse confidence. Induced rules that go unreviewed merely relocate the ambiguity, so they need a promotion workflow of candidate, engineer validation, then controlled logic. Closure size grows with the reachable implication subgraph, so a depth cap is enforced at query time. Alignment across PLM, manufacturing, trim engineering, release, and the plants requires a canonical identity layer.

9. Conclusions

Seating is a demanding and underexamined domain for configuration and BOM research. Product structures have to connect customer- facing variety with hidden engineering and manufacturing dependencies, and failures concentrate in trim, color, and plant- specific realization. In the programs observed, color-structured BOM extraction, propagation of affected variants after a 150% revision, and automated EBOM-to-MBOM transformation all remain unresolved.

The proposed architecture combines a graph-native ontology, one authoritative 150% seat structure, deterministic reasoning, AI- supported review, anomaly detection, and event-driven synchronization to derive explainable 100% engineering and manufacturing BOMs. Promoting PartUsage, SurfaceZone, and ColorCode to first-class nodes makes seat color and trim logic computable. Bitemporal versioning is standard [27]-[29] but becomes necessary when configuration semantics arrive through late external documents, because valid time alone cannot show what the enterprise believed when a release decision was made. AI should advise and explain rather than decide. The next step is an instrumented pilot on one seat family evaluated against Table 6.

ACKNOWLEDGEMENTS

The author thanks colleagues in seat engineering, trim engineering, manufacturing engineering, and product lifecycle management whose day-to-day practice framed the problem addressed here.