Skip to content

What Watchman watches

Watchman is the Substrate service that keeps verifying after attestation: the signed software image and the enclosure's tamper indicators, continuously, with every deviation written to an append-only record.

· 4 min read

IN SHORT

Watchman continuously verifies two things on every Czar node: that the running software image still matches its signed release, and that the enclosure's tamper indicators are intact. Any deviation is written to an append-only record on the appliance and the node is excluded from work. Attestation proves a node at admission; Watchman keeps proving it afterward.

Attestation proves what a node is running at the moment it joins. It says nothing about the next hour, or the next month. A node could be admitted honestly and altered afterward, by a fault or by a hand. Watchman is the service that closes that gap. It keeps verifying, continuously, for as long as the node is in service.

This article describes what Watchman checks, how it reports, and why its record is built the way it is.

Two things, continuously

Watchman verifies the running software image against its signature on an ongoing basis. The image is sealed and read-only, so it should never change; Watchman confirms that it has not. If a block of the image no longer matches, whether through storage corruption, a failed update, or deliberate alteration, Watchman detects the mismatch.

Watchman also monitors the enclosure's tamper indicators. Czar is a sealed appliance, and the enclosure carries indicators that record whether it has been opened or disturbed. Watchman reads them and treats a change the same way it treats a software deviation: as something that must be recorded and acted on.

The pairing is deliberate. Software integrity without physical integrity leaves an opening; a node with a verified image and an opened case is not a node the site should trust without a look. Watchman reports both from the same place, to the same record.

The append-only record

When Watchman observes a deviation, it writes an entry to a record that can only be appended to. Entries name the node, what was observed, and when. They cannot be edited or removed later, by an operator, by the platform, or by anyone else.

An append-only record is the right shape for this because the value of an integrity log is that it survives the event it describes. A record that could be cleaned up after an incident would be worth little to the person investigating it. Watchman's record is the one that stays as written.

The site controls who may read the record, through the same identity and policy that govern the rest of the API. Reading it is itself traced, so there is a record of who consulted the record.

What happens on a deviation

The node is excluded from the set of machines routing may use. New requests are not placed on it. Work shifts to other nodes in the Grid, and models held only on the excluded node become unavailable until the site loads them elsewhere or restores the node. The Evaluation traces show exactly which callers were affected and how.

Nothing is repaired automatically. A deviation means a person should look, and the platform's job is to make that look well-informed rather than to make the problem disappear. The record shows what Watchman saw. The provenance record shows the node's history. The operator decides whether to roll the node back to the previous signed release, restore it from a verified bundle, or remove it from the Grid for inspection.

A node that has been restored attests again before it resumes work. Watchman then resumes watching it.

From inside the site

Watchman reports to the site, not to Element 31. The record is on the appliance; the monitoring the site's operators watch is on the appliance; alerts go wherever the site's own monitoring sends them over routes the site has declared. Nothing is sent out of the building, and an air-gapped site has exactly the same Watchman as a connected one.

This matters because the alternative, an integrity service that reports home, would itself be a path out of the building, and would make the site's integrity depend on a connection the site may not want. Watchman is built so that the site can verify its own platform from the inside, with no outside party required and no outside party informed.

What Watchman does not do

Watchman verifies the platform image and the enclosure. It does not evaluate models, judge answers, or review policies. A model that gives a wrong answer is not a Watchman event; it is an Evaluation matter, visible in the traces and addressed through adaptation or model choice. A policy that is too permissive is a site configuration matter.

Keeping Watchman narrow is what keeps its record clean. Every entry in it is an integrity deviation, and nothing else. An auditor reading it is reading a list of the moments the platform was not what it should have been, with nothing to filter out.

The admission step Watchman follows is in attestation before a node takes work. The image property Watchman verifies is in what the signed image guarantees. The per-node history that Watchman's entries join is in the provenance record for a node. The security overview is at /security.

Questions this raises

How is Watchman different from attestation?
Attestation is a proof a node makes at a point in time, before it joins a Grid or accepts work. Watchman is the continuous check that follows, confirming the image and the enclosure have not changed since. One covers admission; the other covers the whole time the node is in service.
What happens when Watchman records a deviation?
The deviation is written to the append-only record with what was observed and when, and the node is excluded from the set routing may use. Work shifts to other nodes. A person reviews the record and decides whether the node is restored, rolled back, or replaced.
Can the append-only record be cleared?
No. Entries are added and never removed or altered, which is what makes the record useful to an auditor. The site controls who may read it, and reading it is itself traced.

KEEP READING