One API for seven services

A platform that does seven things could expose seven interfaces. Substrate exposes one. Every capability of the appliance, from serving a model to verifying its own integrity, is reached through a single API on the facility network, with one way to authenticate, one way to declare a budget, and one record of what happened.

This article introduces the seven services behind that API and explains why putting them on one surface is a design choice rather than a convenience.

The seven services

Inference serves models. A caller names a task, sends its input, and declares a latency budget; the pool returns an answer from an open-weight model loaded on the appliance. This is the service robots and most applications call.

Retrieval answers questions over the site's own documents and returns citations. It indexes manuals, procedures, records, and whatever else the site points it at, and grounds a language model's answer in those sources so the reader can check it.

Memory gives agents a persistent semantic store, so that an agent working across many sessions stays coherent about what it has seen and decided. It is the service that lets the agent layer on the appliance behave like a colleague rather than a stranger each morning.

Adaptation fine-tunes open models on the site's data, producing adapters that stay on the appliance and belong to the customer.

Evaluation writes a trace of every operation the platform performs and holds the audit record. It is the service an engineer reads during bring-up and an auditor reads afterward.

Watchman continuously verifies that the signed software image is what it should be and that the enclosure's tamper indicators are intact. Any deviation is written to an append-only record.

Local Bridge provides policy-governed connectivity to systems the site already secures, over routes the site explicitly declares. No default path to the public internet exists; Local Bridge is how a connection becomes a decision.

Why one surface

The first reason is for the caller. A warehouse application that needs a model answer and a retrieval citation authenticates once, uses one connection, and declares budgets the same way for both. A robot vendor integrating with the pool learns one interface. An integrator bringing up a floor configures one set of identities and policies.

The second reason is for the record. Because every call crosses the same surface, the Evaluation service sees every call. There is no side door through which an operation could happen untraced. When an auditor asks what the platform did for a given caller on a given afternoon, the answer is in one place.

The third reason is for posture. A site deciding whether anything can leave the building has one surface to reason about. Six of the seven services never touch anything outside the appliance. The seventh, Local Bridge, touches only what the site has declared. There is no second API with its own egress to review.

Stability across hardware

The API does not describe the hardware beneath it. A caller asks for a task, not for an accelerator or a node. This is what lets the site change what is in the rack, add a node to a Grid, replace a failed node, or roll back a release without touching a single caller. It is also what lets a vendor ship an integration once and have it work on a single Czar, a Grid, or a Czar Chassis under their own name.

The stability extends to the services themselves. An application written against Retrieval today will not need rewriting because the site adopted a different embedding model next season. The model behind the service changes; the service does not.

Identity and policy on one surface

Every caller on the API has an identity, and the site's policy decides which services and which models each identity may use. A robot's identity may be permitted Inference for perception models and nothing else. A maintenance assistant may be permitted Retrieval over the maintenance library and Memory for its own sessions. An operator's console may be permitted to read Evaluation.

Because this is one surface, it is one policy. The site does not reconcile permissions across several systems to understand who can do what. The policy and the traces that show it being applied are both on the appliance.

What this looks like from the floor

A machine or an application on the facility network sees an endpoint. It authenticates, declares what it needs and how long it can wait, and receives an answer, a citation, a memory, or a refusal. It does not know how many nodes are behind the endpoint, which model answered, or whether the site is air-gapped or connected. Those are the site's decisions, made once, and the API presents the same face regardless.

The most-called service is described in calling Inference from the facility network. Grounded answers are covered in Retrieval with citations over the site's documents. Agent coherence is the subject of Memory that keeps an agent coherent. The record behind all of them is in tracing every operation with Evaluation. The platform overview is at /platform.