Adapting models on Czar Forge

A team with a few dozen engineers and a codebase that has grown for years has a vocabulary of its own. There are internal libraries that wrap the public ones, a house convention for errors and retries, service names that mean something only to the people who named them, and a way of writing tests that newcomers learn by reading. A general open-weight model knows none of this. It reads the public world's code fluently and this team's code as a stranger would. Adaptation on a Czar Forge tunes the model on the team's own repositories, conventions, and datasets, on the appliance, and the result never leaves the building.

Why a general model does not read this team's code

A model trained on public code has learned the common shape of software. That is useful, and it is also the problem. When an agent proposes a change to this team's service, the proposal reaches for the public idiom: the well-known client library rather than the team's wrapper around it, the usual error pattern rather than the house one, a test that looks right and runs against nothing the team has. Reviewers spend their time correcting the accent instead of judging the change.

The repository index narrows the gap. Retrieval can hand the model the team's wrapper and the house convention at the moment it is drafting, and that helps with any single change. What retrieval cannot do is change what the model considers normal. A model that has only been shown the team's code reads it; a model that has been tuned on it writes it. For a team that wants proposals which read as if its own engineers wrote them, the second is what matters.

What Adaptation does on the appliance

Adaptation is the Substrate service that tunes an open-weight model on the team's own material, on the appliance. The team chooses the sources: the repositories themselves, the design notes and runbooks that explain them, the datasets a data or machine-learning team already curates, and the record of past changes with the reviews that accepted or rejected them. Adaptation builds a training set from those sources on the Forge and produces an adapter, a tuned layer that sits on the base model and carries what the team's material taught it.

The base model does not change, and the team can hold more than one adapter: one for the backend services, one for the data pipelines, one for the style a particular product team insists on. A machine-learning team can also use Adaptation for its own models, tuning a general model on the team's domain data for an internal application rather than for code. The mechanism is the same, and so is where it runs.

The adapter stays inside

Everything that goes into the adapter is the team's own: its source, its conventions, its decisions. An adapter is, in a real sense, a compressed account of how the team works. On a Czar Forge it is produced on the appliance, stored on the appliance, and served from the appliance by Inference to the agents and to the team's own applications. It is not uploaded to tune a vendor's model, and it does not sit in a vendor's account under a vendor's terms.

This is also what makes the adapter the team's to keep. Agency Studio records which adapter produced which proposal, and Watchman verifies that the adapter running is the one the team promoted. If the team retires an adapter, it is removed from the team's own record, not requested back from somewhere else.

Evaluation before the tuned model is promoted

A tuned model is not better because it was tuned. It may have learned the team's conventions and lost some general competence, or learned an old convention the team is trying to retire. Before an adapter serves anything, Evaluation scores it on the appliance against the team's own test sets: changes the team has already resolved, review outcomes it already knows, questions whose correct answers live in the index. The tuned model is compared with the base model and with the adapter it would replace, on the same sets, and the scores are written to the record.

Agents on a Czar Forge prepare and propose; a named engineer merges, promotes, or releases. Nothing reaches production, a customer, or the outside without that person, and every step is on the record the team holds. For an adapter, that means a named engineer reads the evaluation and promotes it, or does not, and that decision is on the record beside the scores. A model is never promoted on a feeling, and never by the process that produced it.

Keeping the adapter current

A codebase moves, and an adapter tuned on conventions the team has since changed begins to drift. A platform team can schedule Adaptation to re-tune on a cadence it chooses, each run followed by the same evaluation and the same named promotion. The work runs on the Forge, inside the perimeter, on the team's own schedule, and the subscription does not change because the team tunes more often.

For an unusually long fine-tune, the Compute network is being built so that a team could send the job out as a sealed overnight batch and receive the result as a signed bundle, to be evaluated and promoted on the Forge like any other adapter. That is optional and designed for the occasional large run; a team's routine adaptation stays on the appliance.

A team's code is one of the most detailed records it has of how it thinks. Adaptation on a Czar Forge turns that record into a model that writes the way the team writes, and keeps the result where the record has always been.