What the signed image guarantees
Substrate runs from a sealed, signed, read-only software image. That one property is what lets a node prove what it is running, lets Watchman detect a change, and lets a site roll back with confidence.
· 4 min read
IN SHORT
The signed image guarantees that the software running on a Czar node is a release Element 31 sealed and signed, unchanged since. Because the image is read-only, nothing on the node can alter it; because it is signed, a node can prove which release it runs; and because releases are discrete, the site can roll back to the previous one. Models and site data live outside the image.
Every claim Substrate makes about integrity rests on one fact: the software it runs is a sealed, signed, read-only image. A node either runs exactly a release that Element 31 produced, or it does not run at all. This article explains what that fact means, what follows from it, and what it does not cover.
Three properties
Sealed means the image was assembled and closed before it shipped. Its contents are fixed. Nothing is added or compiled on the node after the fact.
Signed means the image carries a cryptographic signature over its contents, so that any party with the verification key can confirm both that the image came from Element 31 and that it has not changed since it was signed. A single altered byte fails the check.
Read-only means the running node cannot modify the image in place. Software on the node cannot patch itself, and an operator cannot edit it. The image a node boots is the image it runs until a new signed release is applied.
Together these make the image a known artifact. Any question of the form "what software is this node running" has a definite answer that can be checked rather than trusted.
What follows from it
Attestation follows. Before a node joins a Czar Grid or accepts work, it attests what it is running. The attestation is meaningful because the image is signed and read-only: the node can present a verifiable statement about its software, and the statement cannot be faked by a node running something else. The attestation article covers this step.
Watchman follows. Continuous verification is only possible if there is a known-good state to verify against. Watchman compares the running image to its signature continuously and writes any deviation to an append-only record. Without a sealed, signed image, Watchman would have nothing to compare.
Rollback follows. Releases are discrete, signed artifacts. The previous release is as verifiable as the current one, so a site that needs to step back can apply the prior signed image and know exactly what it is returning to.
The provenance record follows. For every node, the record of its integration, sealing, and software load names the signed image. That is a record with a definite subject rather than a description of a machine that may have changed since.
What the image is not
The image is the platform. It is not the site's content. Models, adapters trained on site, policies, document libraries, memories, and traces all live outside the image and belong to the site. The site changes them freely, and changing them does not touch the image or its signature.
This separation is deliberate. The site needs its own content to be fluid: a new adapter this week, a revised procedure manual next week, a new policy for a new vendor's robots. The site needs the platform beneath that content to be fixed and verifiable. Keeping the two apart gives both.
How the image changes
The only way the software on a node changes is a new signed release, delivered as a bundle. On connected sites the customer downloads the bundle from the portal; on air-gapped sites it is carried in by media. Either way the node verifies the bundle's signature before applying it, and the previous release remains available for rollback.
The site decides when to apply a release. Nothing is pushed. A node running an older signed release is still running a verified image, and it is the site's call when to move forward.
What this rules out
A signed, read-only image rules out a class of problems that are otherwise hard to exclude. Software drifting between nodes in a Grid, because each node runs the identical signed release. An operator's well-meant local fix becoming an undocumented difference, because there is nowhere to make one. A compromised node quietly running altered software, because the alteration fails verification and the node is excluded. An auditor's question about what version was running on a given date, because the attestation and provenance record say.
It does not rule out everything. A model can be wrong. A policy can be too permissive. A site's data can contain errors that an adapter learns. Those are the site's content, outside the image, and the Evaluation record is the tool for them. The image guarantees the platform; the site governs what runs on it.
The step at which a node proves its image is in attestation before a node takes work. Continuous verification afterward is in what Watchman watches. Returning to a prior release is in rolling back to the previous signed release. The security overview is at /security.
Questions this raises
- Can the site customize the software on the appliance?
- The platform image itself is not modified on site; that is what makes it verifiable. Everything the site shapes, including models, adapters, policies, document libraries, and memory, lives outside the image and is the site's to change.
- What stops someone with physical access from altering the image?
- The image is read-only and its signature is verified at boot and continuously by Watchman, so an altered image fails verification and the node does not take work. The enclosure's tamper indicators are also monitored, and deviations are written to an append-only record.
- How does the site know which release a node is running?
- The node attests it before joining a Grid or accepting work, and the attestation names the signed release. The same information is in the node's provenance record and in every Evaluation trace the node writes.
KEEP READING