Does Substrate replace our MLOps stack?

It depends on what the stack does. If the stack is how a research team trains models, tracks experiments, and manages a development workflow, Substrate does not replace it. If the stack is how a facility serves models to robots and applications, traces what they did, adapts them to the floor, and proves the platform is intact, then yes, Substrate is that stack, and it was built for a building rather than for a lab.

Most organizations have some of both, often tangled together. The useful move is to separate them: what happens upstream, in development, and what happens at the site, in production. Substrate owns the second and leaves the first alone.

What Substrate covers

Serving. Inference presents one stable, hardware-independent API on the facility network and serves open-weight models to callers within their declared latency budgets. On a Czar Grid it routes and batches across every node. This replaces whatever a site would otherwise build or buy to get models in front of the floor.

Tracing. Evaluation records every AI operation: caller, model, adapter, route, timing, outcome. This is the piece most MLOps stacks promise and few deliver at the point of use. On Substrate it is not an add-on; every call is traced by construction, and the record stays on the appliance.

Adaptation. The service fine-tunes open models on the site's own data, entirely on the appliance, and the resulting adapters are owned by the customer. For sites whose most valuable training data is footage of their own floor, this is the only adaptation path that keeps the data where it is.

Integrity and connectivity. Watchman verifies the signed image and the enclosure continuously. Local Bridge governs every connection to on-premise systems. Signed updates and rollback handle the release lifecycle. These are platform-operations concerns that a facility-grade stack has to answer and a research stack usually does not.

What Substrate does not cover

Model development. Substrate serves open-weight models; it does not provide the tooling a team uses to design and train them from scratch. A data science team keeps its training infrastructure, its experiment tracker, and its development workflow. What they produce, if it is open-weight, moves to the appliance as a signed artifact the customer brings in.

Cross-site aggregation. Each appliance keeps its own records and its own adapters. Substrate does not pool them across an estate or report them to a central service, because nothing leaves the building. An organization that wants an estate-wide view assembles it from records each site chooses to share.

Public-cloud serving. Substrate runs in the Czar appliance, in the customer's rack. It is not a hosted service and has no cloud component.

How the two fit together

The pattern that works is a handoff. Upstream, a team develops open models with its own tools and treats the output as an artifact. At the site, the customer loads the artifact onto the appliance, where Inference serves it, Adaptation specializes it on local data, and Evaluation traces what it does. Results and traces stay on site. If the upstream team wants to learn from them, the site decides what to share and how.

For sites without a research team at all, which is most facilities, Substrate is the whole stack. They bring in open models, adapt them on the floor's data, serve them to robots and applications, and read the record. The platform overview at /platform describes each of the seven services that make that possible.