Skip to content
ELEMENT 31

Adapter

An adapter is the artifact Substrate's Adaptation service produces when an open model is fine-tuned on a site's own data. It is trained on the appliance, stays on the appliance, and belongs to the customer.

· 2 min read

IN SHORT

An adapter is the trained artifact produced when Substrate's Adaptation service fine-tunes an open-weight model on a site's own data. It modifies how a base model behaves for that site's floor, items, or documents. Adapters are trained entirely on the appliance, served alongside the base model by Inference, and owned by the customer. They stay on site unless the customer chooses to carry one elsewhere.

An adapter is the trained artifact that Substrate's Adaptation service produces when it fine-tunes an open-weight model on a site's own data. It adjusts a base model's behavior for a particular floor, set of items, or body of documents, and it is served alongside that base model by Inference.

Why it matters

Open-weight models arrive knowing the world in general. A facility needs them to know its world in particular: the labels its suppliers print, the damage its forklifts cause, the way its operators describe a fault. The gap between general and particular is what an adapter closes, and the data that closes it is precisely the data a site would never send anywhere.

Adapters are how that data earns its keep without leaving. A site's captures become a model that understands its floor, trained in the rack where the captures already live. The result belongs to the site, and it compounds: each round of adaptation builds on what the floor has already taught the pool.

How it works here

Adaptation runs entirely on the appliance. The site selects the data, the base model, and what the adaptation is for. Training happens on the Czar or across the Czar Grid, and the output is an adapter stored on the appliance. No external service is involved, and nothing about the training data or the adapter is reported upstream.

Inference then serves the adapter together with its base model. Callers address the adapted model through the same API and declare the same latency budgets. Evaluation records which adapter answered each call, so the site can compare the floor's behavior before and after a new adapter is put into service and roll back to the previous one if needed.

The customer owns every adapter trained on their data. It stays on the site where it was trained unless the customer carries it to another appliance in their estate, as a signed artifact under their own control. Element 31 has no access to it.

  • Inference service: the service that serves adapters alongside base models.
  • Substrate: the platform Adaptation belongs to.
  • Latency budget: the deadline adapted models are served within.
  • Watchman: the integrity service that verifies the image an adapter runs on.

Questions this raises

What data does an adapter get trained on?
Whatever the site chooses to use: floor captures from its cameras, items it handles, documents it keeps, or corrections its operators have made. The data stays on the appliance throughout training.
Does Element 31 see the adapter or the data behind it?
No. Adaptation runs entirely on the appliance, which has no path out. Element 31 does not receive adapters, does not aggregate them across sites, and does not use one customer's adaptation to inform another's.
Can an adapter be moved to another site in our estate?
Yes, if the customer decides to. An adapter is the customer's artifact and can be carried to another appliance as a signed file under the customer's own control. The platform does not move it automatically.

KEEP READING

Related.