After six articles of argument there is a suspicion I have earned, and it goes like this: every failed programme of the last twenty years also had an architecture document, and the diagrams were always beautiful. An architecture that exists only as chapters and radar charts is safe from the one test that matters. Fair enough. So this article reports a different kind of progress. The federation layer the book specifies now exists as running code: the seven primitives as typed, validated objects, the book's worked example as seed data, and an append-only event log underneath. It is not a product, and it is not trying to become one. It is the runnable form of the book's argument.
What counts as working
Software claims need a definition of done, so I gave this one the hardest definition I could think of: four demonstrations, each one the mechanical form of a failure this series has already described. Not features, not screens. Four questions the industry has been unable to answer, answered by a running system.
The first demo is the trace
That walk is the query the digital thread has promised for twenty years. The first article argued why it never arrives: the objects the trace needs to pass through do not exist in the data model, so every hop dies in a document, a meeting, or a retired expert's memory. Give the objects existence and the trace is not an achievement. It is one function call.
The second demo is the aging
If you have taken the self-training on the book's site, you have already executed this demonstration once, by hand: the whole exercise walks you through discovering that exact stale judgment yourself. The layer does the same walk without you, at the moment the event arrives, for every judgment it holds. The third article argued that the most valuable engineering data ages silently in people's heads and files. This is what it looks like when the aging is a mechanism instead of an accident.
The third demo is the fleet answer
This is the question the previous two articles called the defining question of the serialised tier, the one the machinery company in both of them could not answer. The superseded as-delivered states stay in history, because supersession is not deletion, so no unit is counted twice and the audit trail survives. And nothing clever happens here. Per-unit configuration states simply exist as data, which is the entire reason the recall scope, the warranty exposure, and the retrofit quote stop being reconstruction projects.
The fourth demo is the defensible answer
The question is the one a programme manager would actually ask, and the two answers come from the same product data. The second article called this the context problem: a model with retrieved documents produces fluency, and a model with managed objects produces accountability. Every clause in the second answer is a field the layer can show you, down to the event that invalidated the judgment. That is the whole difference, and no amount of prompt engineering closes it from the document side.
Under a thousand lines
Here is the part I find most instructive. The layer that passes all four demonstrations is under a thousand lines of ordinary Python plus a set of JSON schemas. There is no clever algorithm in it. The primitives are small typed objects, the store is an append-only log with projections, the invalidation engine is a handful of rules watching events against conditions, and the agent interface is a thin server exposing five query tools. Authority never moves: the layer holds federation references that point into the source systems, and it masters nothing that a source system masters, which is the same property the fourth article argued separates a destination from another migration.
If this substrate were technically hard, its twenty-year absence would be an engineering story. Fewer than a thousand lines say it is not technically hard. The hard part was never the code. The hard part is the institutional machinery the previous two articles kept circling: deciding that judgment is data, giving interfaces owners on both sides, agreeing whose event means what, and running the cadence that keeps the objects honest. That work does not compress into a repository, which is exactly why vendors do not ship it and programmes do not fund it. The code was only ever the cheap part, and now there is a concrete number on how cheap.
What it is not
Calibration, because the claim only holds if it is not inflated. This is a reference implementation at demonstration scale. One worked example. Mock source systems, whose only job is to prove authority stays outside the layer. No authentication, no multi-tenancy, no vendor connectors, no dashboards. It does not have a name yet, and I am in no hurry to give it one, because names are for products and this is an existence proof. What it proves is narrow and, I think, sufficient: the objects the book specifies can be typed, stored, traced, aged, and queried by an agent, on a laptop, today.
One consequence for the reader
The schemas and the specification are available as a companion pack for readers of the book, through the book's site. But the more portable consequence fits in four questions, and you can bring them to your next vendor meeting without any code at all. When the intelligence layer is presented, ask: can it trace a failure back through contract, evidence, decision, and judgment as typed objects? Does recorded evidence age when configurations change, mechanically? Can it tell you, now, which delivered units carry a given component? And when its AI answers, is the answer defensible down to named objects, or plausible down to retrieved documents? Four demonstrations, twenty minutes. You will learn more from where the demo stalls than from the roadmap slide.
One more thing
The layer implements the architecture that Beyond the BOM: A Federation Architecture for Complex Engineering Data specifies across 395 pages, now on Amazon: the seven primitives, the federation pattern that carries them, and the operating model the code deliberately does not contain, because that part runs on people. 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, mapped which pieces of it your product needs, and handed you the tape measure. This one is the existence proof: the substrate runs, and it was never the expensive part. What remains expensive is the decision to want it.