One engineering question, answered twice: once with the documents your organisation has today, once with the primitives the book argues for. You will answer it both times yourself.
About half an hour · no signup, nothing you enter leaves this page · progress is saved in your browser
You joined the programme three weeks ago as an HV systems engineer, on a passenger electric vehicle. Your predecessor has left the company. This morning the programme manager forwards you a message from the homologation team:
Forwarded message · homologation team
VP2 rev F is being released for production. Before we freeze, please confirm: can we rely on the EMC result at the motor terminal? Need an answer today.
You have never heard of the EMC result at the motor terminal. You do what every engineer does: you search the drives and ask around. Forty minutes later you have three artefacts. This is everything the organisation can give you.
Test report excerpt · T-789 · May 2026
Radiated emissions, 30–100 MHz band, measured at motor terminal. Result: 2 dB short of the regulatory margin. Outcome recorded: conditional. (Remaining 14 pages: setup, instrumentation, plots.)
Design review minutes · 22 May 2026
EMC results were reviewed. The margin shortfall at the motor terminal was discussed and considered acceptable given previous platform experience. Action: proceed with current design.Attendees: 11 names, two of whom still work here.
Email thread · 23 May 2026
“…as agreed in Thursday’s review we stay with connector family A. I know the schedule looks tight but that was not the driver here. Let’s document properly later. /J” J left the company in March.
The review that accepted the shortfall: eleven attendees, two still in the organisation.
Your answer to homologation, based on what you have:
And your honest confidence in that answer:
Noted, and no judgment either way: whatever you picked, you picked it the way the whole industry picks it. Keep your answer in mind. You will meet it again at the end.
Step 2 · The same estate, one layer up
Now run the question again
Same organisation. Same PLM, same test lab, same people, same documents underneath. One difference: this organisation operates a thin federation layer above its systems, where seven kinds of engineering context live as managed objects. The documents still exist; the layer holds what the documents cannot: identity, ownership, conditions, and references with authority left where it belongs.
The estate, one layer up: the sources keep authority; the layer adds the objects they never had.
You type the same question into the layer, and instead of a folder of PDFs it gives you a starting object:
system:hvbusin-effect
name
High-voltage bus
scope
Energy distribution between battery pack, inverter, and motor terminal; excludes LV network and charging interface.
owner
HV systems lead
realized_by
plm://demo/ebom/HVB-100authority: source
interfaces
interface:i4-motor-terminalauthority: layer
What you are looking at. The first primitive: a system as a bounded object with scope and an owner, not a hierarchy inferred from the BOM. And the architecture’s quiet rule, visible in the realized_by field: the BOM stays in the PLM, and the layer points at it with authority: source. The layer never masters what a source system masters. It adds the objects the sources never had.
The question concerns EMC at the motor terminal. Where does the trace go next?
The interface. The motor terminal is a boundary between two parties, and in this estate a boundary is an object, not an assumption. Asking around is what you did in Step 1; the point of the layer is that the next hop is recorded, not remembered.
Step 3 · The contract
The boundary is an object
interface:i4-motor-terminalin-effect
name / version
I4 – motor terminal · v3
side A
system:hvbus — supply within voltage/ripple envelope; shielding per contract
side B
plm://demo/system/motorauthority: source — terminal impedance and EMC behaviour per contract
contract
Electrical + EMC contract at the motor terminal: pinout, voltage class, shielding, radiated-emissions allocation 30–100 MHz.
change_control
Neither side changes the contract alone; change via interface owner with both parties’ sign-off.
verifications
verification:t789-revCauthority: layer
A boundary as an object: two parties, one contract, an owner, a version, and change control that binds both sides.
The second primitive: interface as a first-class contract. Two sides, each with obligations. An owner. A version. Change control that binds both parties. In Step 1, nothing could even represent this: the test report mentioned a terminal, the minutes mentioned a margin, and the contract that connects them existed only in the heads of the eleven attendees, nine of whom are gone.
The 2 dB shortfall was measured at this terminal. Whose problem is it?
The contract’s. Emissions at the terminal are a shared allocation: the bus side owes shielding, the motor side owes EMC behaviour, and the split lives in the contract both signed. That is why the trace goes through the interface rather than jumping straight to the test report: the report tells you a number failed; the contract tells you what the number was measuring.
Step 4 · The evidence that knows what it tested
The test report, as a managed object
verification:t789-revCin-effect
subject
interface:i4-motor-terminal
method
test
evidence
mes://demo/test/T-789-revCauthority: source — the 14-page report from Step 1, still in the MES where it belongs
result
conditional · radiated emissions 30–100 MHz: 2 dB short of regulatory margin at motor terminal
configuration_binding
configstate:vp2-rev-eauthority: layer
configstate:vp2-rev-erecorded
kind
as-designed
of
system:hvbus
snapshot
plm://demo/ebom/HVB-100/revEauthority: source
recorded
2 May 2026
Evidence with lineage: the test is bound to the configuration it measured, and rev F is visibly outside it.
Two primitives in one hop.Verification as evidence with lineage: the result, the method, a reference to the raw report in the MES, and the highlighted field the paper world never had: configuration_binding. The test knows what it tested. And configuration history: rev E as a recorded state of the system, a fact about time rather than a folder name.
Homologation asked about rev F. The verification is bound to rev E. What does that binding actually tell you?
It tells you the question is now precise. The evidence describes rev E, not rev F. That does not make it worthless, and it does not make it valid; it makes “does it still hold?” an explicit question that someone with standing must answer. In Step 1 that question could not even be asked, because nothing recorded what the test had tested.
Step 5 · The reasoning that survived
What the email thread lost
The trace shows a decision attached to the interface, recorded two days after the test result:
decision:connector-familyin-effect
statement
Retain connector family A at the motor terminal for the VP2 configuration.
rationale
Family B would recover the 2 dB margin but requires six weeks of additional validation; schedule was explicitly not the driver — the change was judged unnecessary given field evidence on Platform X.
alternatives
Connector family B — rejected: six weeks of validation for margin the field evidence suggests is not required.
conditions
Valid while judgment:emc-2db-accept remains in effect.
configuration_binding
configstate:vp2-rev-e
decided_by
HV systems lead
The road not taken, recorded: the alternative, the reason it was declined, and the coupling to the judgment.
The fifth primitive: decision and rationale. Compare this with the email from Step 1, which is the same event as the organisation actually recorded it. The email had the outcome. It lost the alternative, the reason the alternative was rejected, the explicit statement that schedule was not the driver, and the condition coupling this decision to a judgment. “Let’s document properly later” is where rationale goes to die.
Look at the conditions field. This decision says it is valid only while some judgment remains in effect. What is that?
A reference to the seventh primitive. The decision to keep family A was only sound because someone accepted the 2 dB shortfall, and the decision records that dependency as data. If the acceptance falls, the decision falls with it, mechanically. You are one hop from the object the whole question turns on.
Step 6 · The call
Before you see how it was recorded: make the call yourself
Put yourself in the HV systems lead’s chair in May. The facts in front of you: emissions at the motor terminal are 2 dB short of the internal allocation; vehicle-level compliance is maintained; connector family B would recover the margin at the cost of six weeks of validation; an identical shortfall on Platform X has three years of production behind it with no attributable field failure.
Your call:
The strongest basis for your call:
What conditions do you attach? (pick any, then continue)
judgment:emc-2db-acceptin-effect
assessment
The 2 dB shortfall in radiated emissions at the motor terminal is accepted conditionally for production.
assessor
HV systems lead · standing: 12 years HV integration; reviewed by chief engineer
confidence
High for the tested envelope; conditional on fleet telemetry confirming no field clustering.
basis
reference-case — identical 2 dB shortfall on Platform X: three years of production, no EMC-attributable field failure plm://demo/platform-x/emc-historyauthority: source regulatory — margin is internal allocation; vehicle-level compliance maintained.
conditions
Monthly fleet-telemetry monitoring through the first year of production. Trigger-action plan activates if an EMC-attributable cluster appears.
configuration_binding
configstate:vp2-rev-e
The anatomy of a recorded judgment: six fields that turn an opinion into engineering data.
The seventh primitive: judgment. A professional assessment as a managed object: who rendered it, on what standing, with what confidence, on what basis, under which conditions, against which configuration. Medicine records clinical opinions this way; finance records audit opinions this way; engineering has run on “the team considered it acceptable” for fifty years. Notice too what the record does for the assessor: the foundation available at the time is on file. A recorded judgment is not exposure. It is protection.
Step 7 · Nothing was remembered, everything was caught
Rev F arrives
Four months pass. You are busy with other work; so is everyone. The design evolves, and the PLM releases the change homologation asked you about in Step 1: rev F changes the shielding termination at the motor terminal. Nobody thinks about a judgment recorded in May. Press the button the PLM adapter presses:
{ "type": "configuration.StateRecorded", "subjects": ["system:hvbus"], "payload": { "new_state": "configstate:vp2-rev-f", "note": "Rev F changes shielding termination at the motor terminal." } }
verification:t789-revCin-effect→review-requiredbound to rev E; a new state now exists for its subject
decision:connector-familyin-effect→review-requiredbound to rev E; and its condition rests on the judgment
judgment:emc-2db-acceptin-effect→review-requiredrendered against rev E; the assumption under it just moved
One event, three flips: everything bound to rev E goes to review-required the moment rev F is recorded. Computed, not remembered.
Mechanical aging. One rule did this: every verification, decision, and judgment carries a configuration binding, and when a new state is recorded for the same subject, everything bound to the old state flips to review-required. No one remembered the May acceptance. No one had to. Staleness is computed, not remembered — and if you scroll up, the status chips on the objects you already met have flipped too. The 2020 judgment silently applied to the 2026 configuration, the failure mode from the book’s retirement chapter, cannot happen in this estate.
Step 8 · Plausible versus defensible
The same question, two answers
Two answers to the same question: a cloud of fragments, or a chain of objects.
The document answer
“The margin shortfall was reviewed in May and considered acceptable given previous platform experience, so the result should still be fine for rev F.”
Plausible. Possibly even correct. Built on a report that does not say what it tested, a minute that does not say who accepted what, and an email from someone who left in March. If a regulator, a customer, or your own chief engineer asks “on what basis?”, the answer is an archaeology project.
The layer answer
“No — not without re-rendering. The result was accepted conditionally by the HV systems lead (12 years HV integration, chief-engineer review) on Platform X field history, bound to rev E, conditional on fleet telemetry. Rev F changed the shielding termination at that terminal, so the acceptance is review-required as of today. Re-render against rev F before freeze.”
Defensible. Every clause traceable to a field on a managed object — and the answer knows when it stops being true.
One more consequence. An AI assistant grounded in these objects gives the second answer, with citations to object ids. An AI assistant grounded in the document pile gives a fluent version of the first, because plausible is what retrieval over prose produces. The difference is not the model. It is whether the substrate exists — which is the argument of the whole book, experienced in half an hour instead of argued in hundreds of pages.
Where to take this
Score your own estate
Eight sections, five levels, read against your product’s scenario. The instrument from Chapter 14.
This investigation is built on the worked example that threads Chapters 5–14 of Beyond the BOM, and the objects you traced are real: they are the seed data of the book’s reference implementation, validated against the published schemas.