A mixed estate on one platform

An operator with many buildings rarely has one security posture. The plant with the regulated line is isolated and will stay that way. The distribution center two regions over is connected to the company's warehouse system and document store, both of which it runs itself. A third site is somewhere in between, isolated today and considering a single route next year. These are reasonable differences, and they are not going to be flattened for the convenience of a software platform.

Substrate does not ask them to be. Posture is a per-site setting. Each building declares the routes it wants, which may be none, and the platform underneath is the same everywhere.

One platform, several postures

Every site in the estate runs the same Substrate. The seven services, the one API, the open-weight models, the signed image, the records: all identical. What differs is the Local Bridge configuration. The isolated plant has declared no routes. The distribution center has declared a read route to its document store and a results route to its warehouse system. The third site has declared nothing yet and can add a route when it decides to.

Because the difference is configuration rather than product, nothing has to be bought, installed, or migrated to change posture. A site that connects adds a route. A site that withdraws from a connection removes it. The applications running on the appliance do not notice.

What applications see

An application built against the Substrate API does not know what posture it is running on. It calls Inference, Retrieval, or Memory on the facility network and gets an answer within its latency budget. Whether the appliance behind the API has zero routes or three is invisible to it.

This is what makes a mixed estate practical. An integrator builds a damage-reading application for one distribution center and deploys the same application to the isolated plant. The only difference is where the documents for Retrieval come from: read over a declared route at one site, loaded onto the appliance at the other. The application code does not change. Neither does the model, the trace format, or the way results are recorded.

For a robot vendor shipping Czar Chassis, the same property holds. The vendor's fleet software calls the same API at every site the customer runs, regardless of how each site has chosen to connect.

What each site keeps to itself

Nothing is pooled across buildings. Each site has its own Czar or Czar Grid, its own Evaluation records, its own Watchman history, its own Memory, and its own adapters. There is no path between appliances in different buildings, and no central service that aggregates what they do.

This matters for the isolated plant most of all. Its isolation does not depend on the behavior of the connected sites. The distribution center's routes reach only the distribution center's systems. The plant is isolated regardless of what any other building in the estate declares, and that remains true as the estate grows.

It also matters for ownership. The adapters trained on one plant's floor captures are that plant's. If the customer wants to carry one to another site, they can, as a signed artifact moved under their own control. The platform does not move it for them, and it does not assume they want it moved.

How updates work across the estate

Signed updates are the same bundle for every site. Connected sites download it from the portal; isolated sites receive it on media. Each appliance verifies the signature before loading, and each can roll back to the previous signed release on its own. The provenance record at each site notes what was loaded and when.

The practical result is that an estate can run on one release across all its buildings, with each site advancing on its own schedule and by its own delivery method. The operations team does not maintain two update processes for two kinds of site. They maintain one bundle and two ways of carrying it.

Running the estate

An estate team ends up with a short description of each site: which release it runs, which routes it has declared, which adapters it holds. Everything else is the same. The mixed estate is not a special configuration of Substrate; it is what happens when several sites each make their own connection decision on a platform that treats a connection as a decision. The platform overview at /platform describes the services that stay constant across them.