Provenance below the software

Every integrity argument above the hardware rests on an assumption about the hardware. Attestation proves which firmware ran and which image executed, with evidence rooted in a measurement the software cannot forge — but the root of trust it chains to is a component someone sourced, soldered to a board someone assembled, in a facility someone selected. The proof is only ever as good as the object it is anchored in.

That assumption is usually inherited rather than examined. An integrator buys a module. The module vendor buys a controller. Below that is a package, a die, a firmware blob supplied as an opaque binary, and a logistics path nobody in the chain has looked at closely, because at every level the answer was that the layer beneath is somebody else's problem. The result is a security posture that is rigorous at the top and vague at the bottom, which is a strange shape for an argument whose whole purpose is to establish a foundation.

For machines that work near people, the vagueness matters differently than it does in a rack.

What attestation assumes

Attestation answers one question well: what changed after the unit was provisioned. Boot stages measure each other, the accumulated measurements are compared against known-good values, and a node that does not match is refused work. Powerful, and bounded. It says nothing about whether the unit was trustworthy the first time it was measured, and nothing about who decided what counted as good.

The chain has a first link, and the first link is a physical object. If a board was substituted before provisioning, or a component was not the part the bill of materials named, attestation will faithfully measure the compromised thing, record it, and defend it thereafter as the baseline. Provenance is the discipline that makes the baseline worth measuring against. It is how an operator knows what the unit was on the day the chain started.

The stakes here are the ones that separate embodied systems from servers. A compromise in a datacenter is informational, however serious. A compromise in a machine with mass, speed, and reach is a safety event, and it does not announce itself as one. That difference sets the standard that phrases like "we buy from reputable suppliers" have to clear, and they do not clear it.

What has to be answerable

What is in the unit. At the component level, not the assembly level. A parts list that reads as one compute module and one carrier board is an inventory, not a provenance record. The question is what is inside those, with particular attention to anything that holds writable firmware, because a component that can be reprogrammed and whose origin is undocumented is an unexamined trust assumption sitting underneath a carefully examined software stack.

Where the components came from, and through whom. Sourcing is a path, not an origin. A part can be entirely authentic and still have travelled through a broker who cannot say where it was stored, by whom, or for how long. The record that matters is the chain of intermediaries — and the useful version of that record names the segments where it thins out rather than smoothing them into a single reassuring line.

Who integrated it, and under what physical controls. Integration and final assembly are the moments a collection of parts becomes a specific unit with a specific identity, and they are the last moments anyone has unrestricted access to its interior. The controls around them are part of the story: who could reach the boards, what was verified before the enclosure was closed, how the space itself is governed. A well-sourced set of components assembled in an uncontrolled area is not a controlled unit.

Identity and custody

Two further questions decide whether any of the above survives contact with a working fleet.

The first is what the unit's identity was at the moment it was provisioned, and what that identity is bound to. An identity that exists as a serial number in a database is an assertion about the unit. An identity rooted in hardware, created under known conditions and not extractable afterward, is a property of it. The distinction shows up the first time two units claim to be the same node: one of those situations is resolved by evidence, the other by argument.

The second is chain of custody between assembly and installation. A server travels a short, contractual path from factory to cage, mostly under one party's control. A unit bound for a yard, a substation, or a forward site travels a much longer one — freight, staging, integration into a chassis someone else built, storage in places nobody selected for their access control, and handling by people whose names appear on no document. That window is when the unit is least observed and most reachable. A provenance story that ends at the loading dock ends early, which is also why verification at installation, rather than trust carried forward from the factory, belongs in the design.

Where the unit is built

Integration and final assembly in the United States is a design requirement in E31 Network's case rather than a line of marketing. The reason is procedural. In the environments this system is aimed at — defense, critical infrastructure, regulated industry — provenance questions arrive in writing, from accreditors and contracting officers, and they are answered in writing by someone who has to be right. A supply chain assembled for cost and reconstructed later under questioning does not survive that exchange.

Designing against those questions changes decisions while they are still cheap. Which components are acceptable because their origin can be documented. Which suppliers are workable because they will attest to their own inputs rather than referring you onward. Which savings are unavailable because taking them would place a link of the chain somewhere unanswerable. Each of those is a modest constraint during design and an expensive retrofit once hardware exists in the field, which is the practical argument for treating provenance as an engineering input rather than a document produced at the end.

The same chain, applied to weights

Provenance below the software now has a counterpart above it. Behavior lives in weights: a model determines how a machine approaches a person, how hard it grips, when it commits to a path. The questions asked of a component apply directly. Who trained this model. On what data. Against what evaluation. Who approved it for this site, as opposed to approving it in general.

A model with an unknown training set is the software equivalent of a component with an undocumented origin, except that it has a shorter and more direct route to the machine's behavior. The mechanics of distributing and admitting models are their own subject, covered elsewhere in these notes. The point here is one of scope: a provenance record that covers the hardware thoroughly and stops at the operating system omits the part of the system most likely to change during its service life and most immediately responsible for what the machine does. The chain should be continuous from the component to the weights, at the same standard of evidence at both ends.

What provenance cannot claim

No vendor can see to the bottom of a silicon supply chain. Wafer lots, mask sets, packaging subcontractors, and firmware that arrives inside purchased components as an opaque binary — visibility runs out well short of the bottom, for everyone, and a claim to the contrary should be read as marketing rather than engineering.

So provenance reduces risk instead of eliminating it. What it actually accomplishes is narrower and still worth a great deal: it shrinks the set of places a compromise could have been introduced, makes substitution harder to perform and easier to detect, and shortens the list of parties who have to be trusted for the rest of the architecture to mean anything. It also assumes its own limits, which is why sealing, a single defined workload, and attestation still matter on hardware whose origins are well understood. Layers exist because the layer below can be wrong.

None of this is a certification claim. The architecture is being designed so that an accreditation process would have something specific to examine; no accreditation is held today, and none is implied here.

The claim worth making is modest and testable. Not that the hardware is beyond suspicion, but that the questions have documented answers, that the answers are specific about where documentation ends, and that the whole record was assembled while the design was still open rather than discovered during procurement. Provenance approached as paperwork becomes a scramble to reconstruct decisions made for other reasons. Approached as a requirement, it shapes component selection, assembly, identity provisioning, and the record kept at every step — and the paperwork becomes a printout of choices already made deliberately. That is the version E31 Network is being built toward: not a supply chain that can be defended afterward, but one designed to be answerable while there is still time to change it.