There is a fair objection to the architecture, and it goes roughly like this: we make moulded enclosures, or garden equipment, or industrial fasteners. We have a BOM, a drawing vault, and a change process that works. Are you seriously telling us we need to add managed interface contracts, configuration histories, and formally recorded judgment objects?
For that question the answer is obviously no. And the fact that the answer is no does not weaken the architecture. It is the thing that makes the architecture credible. A framework that prescribes everything to everyone is not a framework; it is a sales speech. All seven primitives describe the full extent of what complex engineering data may require. What your organisation actually needs is in many cases a different question, with a different set of primitives as an answer.
Five drivers, multiple ambition levels
The need for each primitive is not set by revenue, headcount, or how modern your tools are. It is set by five drivers, all properties of the product itself: how long the product lives, how many boundaries the work crosses (disciplines, teams, suppliers), how much deployed units diverge from each other over their life, what your regulatory requirements are, and how costly it is to lose tacit knowledge.
Score low on all five and the informal ways of keeping engineering knowledge (a person, a document, plain revision control) are not a liability. They are the correct answer. A product that has no configuration variants, lives three years, involves one discipline, and answers to no regulator does not need its verification evidence bound to configuration states, because there is only one state that matters. Formalising an object has a cost, a permanent one, in discipline and maintenance. The formalisation is only worth it when something fails.
Score high on all five and these informal ways will fail constantly, and the failures compound: the retired expert, the interface nobody owned, the test report that silently stopped describing the product in the field. That end of the spectrum is where the book lives, and where the previous articles have been arguing.
Most organisations are somewhere between, and that is where the interesting question sits: which primitives, at which depth.
Typical scenarios
Run these drivers across real product types and these scenarios fall out.
The simple product (furniture, moulded goods, simple assemblies): single discipline, short life, one team. Here a collaborative BOM workspace with revision control and attributed capture is sufficient, and I mean that without irony. System structure exists implicitly in the BOM and that is fine. Verification is a test report in a folder. Decisions live in memory, and the memory is adequate because the people who made them are still in the room when the next product starts. The architecture has no value here.
The mechatronic product (connected consumer devices and their relatives): the moment software and a third-party supplier enter the picture, the first primitive becomes load-bearing, and it is always the same one. Interface. The contract between your hardware and your supplier's module, between your firmware and your cloud service, now has an owner on each side, versions on each side, and a failure mode (the mismatch) that no BOM tree can even represent. Verification follows immediately, because compliance marks (EMC, safety, radio) create evidence that must trace to what was actually tested. Configuration history arrives in lightweight form because a fleet in the field runs divergent firmware. But note what is not yet needed: formally managed judgment, spatial allocation, a real federation layer. The expert is still the line, and the toolchain is still small enough.
The industrial product (machinery, equipment, serviced fleets): serialisation changes the arithmetic. Each delivered unit now has its own life, its own maintenance history, its own divergence from the design baseline, and the as-maintained configuration becomes something the organisation must know rather than reconstruct. This is also, not coincidentally, the tier where the retirement problem from the third article arrives, because product life now exceeds job lifecycles. The judgment that accepted a marginal case fifteen years ago is still deployed in the field after the person who rendered it has left. At this tier most of the primitives need to be managed objects in the working domain.
The regulated system (aerospace, marine, energy, automotive platforms): certification, decades of deployment, system-of-systems scope. Everything the book specifies, at full depth, with the role architecture and operating cadence to run it. This is the scenario the seven primitives were drawn from, and nothing less holds it.
They arrive in a predictable order
Lay these scenarios side by side and a pattern appears that is more useful than the scenarios themselves: the primitives arrive in a consistent order as the drivers kick in. Interface first, when the first boundary crosses a company or discipline line. Verification lineage second, when regulation starts watching. Configuration history third, when units become serialised and serviced. Judgment fourth, when product life outgrows the memory of the people. Space and the full federation layer arrive last, with system-of-systems scope.
The order matters because it means you can see the next one coming. If your product just gained a software stack and a supplier module, you do not need to guess which primitive to invest in next. It is interface, and verification is close behind. The map is not a maturity ladder that everyone should climb to the top. It is a weather forecast keyed to your product's actual drivers.
Depth is a cost decision
There is a second axis you need to be aware of. Even a primitive you need does not always need to exist at full institutional depth. There is a real difference between lightweight (the object is named, findable, and attributed, and staleness is caught by people remembering), managed (the object has an identifier, an owner, validity conditions, and mechanically surfaced staleness within the domain where the work happens), and full (estate-wide references, population-level queries, audit-grade history, challenge and supersession as routine practice).
The distinction that matters most in practice is managed versus full, and it is not a schema distinction. Managed answers the question "can our engineering work rely on this object?" and its unit of trust is the team. Full answers the question "can the enterprise, its partners, and its regulators rely on it for decades?" and its unit of trust is the institution. The step between them is not more data model. It is institutional machinery: roles, cadences, authority. Buying that machinery when your drivers do not demand it is how organisations end up with governance nobody attends. The right depth is the lowest one the drivers allow.
The failure that actually matters
Here is the point of the whole map. The interesting failure is not a simple-product company running happily without primitives. That company is correct, and no architect should bother it.
The interesting failure is the company whose drivers moved one or two scenarios while its data model stayed behind. The consumer product that quietly acquired connectivity, a software team, and three external supplier parties, still coordinating interfaces by email because the data model dates from when the product was plastic and springs. The machinery company that started selling service contracts on a serialised fleet, still unable to answer which delivered units contain the substituted component, because its model still assumes the design baseline is the product. Nothing announces the transition. Revenue looks fine. The tools still work. The drivers moved, the model did not, and the gap fills up with heroics.
That, compressed into one sentence, is the story of the last thirty years of industrial engineering data: products crossed scenario boundaries decade by decade, while the data model underneath them stayed at the tier where the company was founded.
One consequence for the organisation reading this
Do not score yourself against the maximal architecture. Score yourself against your drivers. The diagnostic from the book is now available as an interactive page on the book's site, and it now asks about your scenario before it interprets your scores: a gap the map says you do not need is reported as a non-issue, and a gap your drivers say is load-bearing is reported as the place the heroics are currently living. An honest instrument has to be able to say "this is fine" as often as it says "this is the gap", or it is not an instrument, it is marketing.
And if you run it and everything comes back green at the simple-product tier, then you have my formal permission, for whatever it is worth, to close this series and go build products. The architecture will be here when the drivers arrive.
One more thing
The scenario map in this article is an application of Beyond the BOM: A Federation Architecture for Complex Engineering Data, now on Amazon, which develops all seven primitives at the depth the regulated system demands. The earlier articles argued that the digital thread, the AI copilot, the knowledge-retention programme, and the replacement fantasy all fail on the same missing substrate. This one is the dosage guide: which pieces of that substrate your product's drivers actually call for, and which they do not. A prescription that ignores the patient's problem is not architecture.