Who owns an adapter trained on site

A site that fine-tunes a model on a season of its own captures has made something valuable. It has encoded how its items look, how its floor is laid out, how its operators decide. The question of who owns that encoding is not academic. It determines whether the site's investment in its own data stays its own.

On Substrate the answer is short: the customer owns it. This article spells out what that means in practice and why the platform's design makes it true rather than merely promised.

The adapter is the customer's

The Adaptation service trains on the customer's data, on the customer's appliance, and produces an adapter. That adapter is the customer's property. They can serve it, hold it unused, copy it to another of their sites, or delete it. No approval from Element 31 is involved, and no record of the decision leaves the building.

The adapter is distinct from the open base model it layers on. The base model's license governs the base model, and the platform does not alter those terms. The adapter is the site's own work product, derived from the site's own data, and it carries no new obligation to anyone.

Why it cannot be otherwise

An ownership statement is only as good as the system that enforces it. On many platforms, fine-tuning happens on the provider's infrastructure, and the resulting weights sit in the provider's storage under the provider's terms. The customer owns the result in the sense that they can call it, not in the sense that they hold it.

Substrate's design closes that gap structurally. Adaptation runs on the appliance in the rack. The appliance has no default path to the public internet and never connects to the customer portal. There is no channel by which an adapter could reach Element 31, and no telemetry that would describe it. The customer holds the adapter because the adapter has never been anywhere else.

This is the same property that governs the data the adapter was trained on and the traces the Evaluation service writes while serving it. What leaves the building: nothing. An adapter is included in that nothing.

The robot vendor's position

A common situation deserves a direct answer. A robot vendor's machines call the pool, and the site adapts a perception model so those machines handle the site's items better. The vendor's robots perform better as a result. Does the vendor acquire the adapter.

No. The adapter was trained on the site's data on the site's appliance, and it belongs to the site. The vendor's machines benefit from it the way they benefit from good lighting: it improves their results without becoming theirs. If the site chooses to share an adapter with a vendor, that is the site's decision to make, and the platform neither requires nor prevents it.

The same holds for Czar Chassis deployments, where the appliance is shipped by a vendor under their own name. The vendor's brand is on the enclosure. The data on it, and the adapters trained from that data, remain the end customer's.

Moving an adapter between the customer's sites

A customer with several facilities often wants an adapter trained at one to serve at another. The adapter is a file the customer holds, and it moves the way the customer's posture allows. On connected sites, it can travel over a route the site has declared through Local Bridge. On air-gapped sites, it travels by media, the same way signed updates arrive.

At the destination, the site loads the adapter and it is served behind the same API. The Evaluation traces at the destination record when it was loaded and every request that used it, so the adapter's history is as auditable there as at its origin.

What the record shows

Every adapter has a history on the appliance: when it was trained, which base model it layers on, what data sources the training read, when it was loaded, which nodes held it, and every request it answered. That record is written by the Evaluation service and stays on site.

This matters when ownership is questioned later. A site asked to show that an adapter was trained on its own data, on its own appliance, by its own decision, has the record to hand. An auditor can read it without any party outside the building being involved.

Ownership includes the right to end. A site that retires an adapter deletes it from the appliance, and because the adapter was never copied elsewhere, deletion is complete. The traces that recorded its use remain, subject to the site's retention policy, so the history survives the artifact.

How adapters are produced is in adapting a model on the site's own data. The base models they layer on are described in open-weight models on the appliance. The sealed image that keeps the platform itself unmodified is in what the signed image guarantees.