What a provenance record contains

Ask most operators where the compute in their rack came from and the honest answer is a purchase order and a shipping label. The box arrived from a distributor who got it from a reseller who got it from a manufacturer, and somewhere along the way the software was loaded by someone. If a question is asked later, the answer is a reassurance from whoever is on the phone.

A Czar node arrives with a provenance record instead. This article describes what is in it, why those entries and not others, and how the record is used once the node is in the building.

Three entries

The record covers three things for every node: its integration, its sealing, and its software load.

Integration is the account of how the node was put together as a unit. Sealing is the account of the moment the enclosure was closed and the state it was closed in. Software load is the account of the sealed, signed, read-only image placed on the node before it shipped.

Three entries is a short list, and the shortness is deliberate. Each entry corresponds to a point at which the node could have become something other than what the site expected, and each gives the site a fixed fact to compare against later. A longer record would be more impressive and less useful.

Why the origin question needs a record

The question an operator wants to answer is simple to state: is the node in my rack the node that was built, and is it running what it was loaded with. Without a record, the question cannot be answered at all. It can only be asked of a vendor, who answers from their own records, which the site cannot see.

A provenance record moves the answer into the building. The site holds the account of integration, sealing, and software load, and the node itself is built so that the account can be checked against it. Checking is what attestation does: before joining a Grid or accepting a task, the node reports what it is running, and the Grid compares the report to the software load on the record. A match admits the node. A mismatch refuses it. Attestation before a node joins a Grid describes that step.

The record is therefore not a document filed on delivery and forgotten. It is the reference the Grid consults every time a node asks to serve.

Reading the record as an auditor

An auditor's interest in a facility pool usually comes down to a chain of questions. What is this equipment. Who built it. Has it been altered. What software runs on it. Did the site check. Each of these has an answer in the record or in the attestations that reference it.

What is it: the integration entry. Has it been altered: the sealing entry, together with the enclosure seal it describes. What runs on it: the software load entry, together with the most recent attestation. Did the site check: the attestation log, which shows the node matching the record before each task.

None of this is a compliance claim, and the record does not pretend to be one. It is a plain account that an auditor can read and compare against the rack. That turns out to be more useful to an auditor than a certificate, because a certificate says someone else was satisfied and a record lets the auditor be satisfied themselves.

What the record is not

A provenance record is not an inventory of parts, and it is not a statement about geography. It does not list what is inside the enclosure, because the site's interest is in whether the node is the one that was built and sealed, not in a bill of materials. It makes no claims about places, because the record is an account of events: integration, sealing, load.

Keeping the record to what was recorded is what makes it trustworthy. An entry that said more than was observed would be a reassurance in a different font. What a sealed enclosure means explains the sealing entry in more depth.

The record across a Grid

A Czar Grid is several nodes, and each has its own record. When a facility adds a node to grow the pool or replaces one, the new node brings its record and attests against it. The Grid's view of itself is the set of records of the nodes that have attested and been admitted.

That gives the site, for the whole pool, the same answer it has for a single node: here is what each one is, here is the state it was sealed in, here is what it runs, and here is the proof it was checked. For a building that trusts the pool with perception and decisions for every robot on the floor, that is the minimum worth having and the record is how it is had. See Czar for the node and The audit question a site can answer for the conversation the record is built for.