Sovereign by property, not by market

The word sovereign has drifted into a sales category. It names a kind of buyer, a government agency or a regulated firm, and a kind of product tier sold to that buyer at a different price with a different contract. Everyone else gets the ordinary version, which is assumed to send data somewhere.

Element 31 does not use the word that way. A pool is sovereign because of what the node and the Grid do, and every Czar does those things. The market the building belongs to is not part of the definition.

The properties, named

There are five of them, and they are short enough to list on a whiteboard.

The enclosure is sealed. The software image is sealed, signed, and read-only. Each node attests what it is running before it joins a Grid or accepts a task. Integration, sealing, and software load are recorded for every node, so the site holds a provenance record rather than an assurance. And nothing leaves the building: camera feeds, captures, task records, adapted weights, and the record of every decision stay on the operator's hardware inside the operator's network.

None of these depends on who the operator is. A pick floor in a fulfillment center and a floor in a secure plant receive nodes with the same enclosure, the same image discipline, the same attestation step, and the same record. The difference between those sites is a posture decision, which the next section covers, not a different machine.

Why a market label is the wrong test

A label tells a buyer about the seller's intentions. A property tells the buyer about the equipment. When a buyer is asked to accept that a system is sovereign because it is sold to the sovereign segment, the buyer is accepting a claim about a sales channel and reading into it a claim about data paths.

The two come apart quickly. A product sold to secure buyers can still phone home for telemetry, and a product sold to warehouses can keep everything on site. The channel is not evidence. The only evidence is the behavior of the node, and behavior is something a site can inspect: what routes exist, what the node attests, what the record contains.

Defining sovereignty by property also removes a quiet penalty. Under the market definition, an ordinary building that wants its floor data kept inside has to buy its way into a tier that was priced for someone else's threat model. Under the property definition there is no tier. The building subscribes to a configured Grid and chooses its posture.

Posture is the only variable

What does differ between sites is posture, and it is chosen per site on the same appliance. A Czar can run air-gapped, with no path out and updates arriving as signed bundles carried in on media. Or it can run connected only to the systems the site already secures: the robot vendors' fleet software, the warehouse system, the PLCs, and nothing the site did not declare. Mixed estates run both.

Posture is a decision about connections. It is not a decision about which properties the node has. An air-gapped Czar and a connected Czar both attest before joining, both carry a provenance record, both keep the floor's data on the operator's hardware. The connected one has declared routes; the air-gapped one has none. See Air-gapped, or connected only to what the site secures for how the two postures behave day to day.

A warehouse qualifies the same way a lab does

Consider the inventory of what a robot floor produces. Camera feeds show the layout, the goods, the people, and the pace of the work. Captures from the fleet become the material for adapting models to that specific floor. Task records show what was tried, who approved it, and how it went. Adapted weights encode what the floor taught the pool.

A fulfillment operator has every reason to keep that inventory inside, and the reasons are commercial rather than classified. Layout and pace are competitive facts. Adapted weights are the operator's own work product. The record of decisions is the operator's defense when a question is asked after an incident. None of this needs a government buyer to be worth protecting.

Under the property definition, the operator does not have to make a case for being special. The node already does what a secure site would ask of it. The operator's only job is the posture decision and the declaration of routes.

What the property test asks of a buyer

Evaluating a pool by property is more work than reading a label, but not much more. A buyer asks what the node attests before it joins a Grid, and gets an answer that is the same for every node. A buyer asks for the provenance record on a node and reads where it was integrated, when it was sealed, and what software was loaded. A buyer asks which routes the site has declared and expects the answer to be a list the site wrote, with everything else denied.

Each question has an artifact behind it. That is the difference between property and market: a property leaves something the site can read. For the detail of each artifact, start with What a provenance record contains and The audit question a site can answer. For how the appliance itself is built and sold, see Czar and How to buy.