What Does a Customer Need to Provide Before Model Transfer Can Begin?

Most transfers that fail were doomed at intake. The runs did not carry tool results, so nobody could tell which answers were supported. No one was empowered to say what the right answer was, so the training labels were the closed model's opinion. Parity was never defined, so the gate was invented after the candidate was trained. The data rights were assumed, so the project stopped at legal review.

None of those are training problems and none are fixed by a better model. They are supply problems, and the honest thing a product can do is refuse to start until the supply is in place. The checklist below is what to ask for, in the order it is usually hardest to get.

The thing being transferred is not a model. It is an agent: an instruction, a set of tools with their definitions, an output schema, a model with its settings, and any retrieval or routing around it. Every one of those has to be pinned to a version, because a fine-tune trained on runs from one version of the instruction and gated against another measures nothing. Ask for the exact artifacts, not descriptions of them.

A common weak version is a prompt that lives in three places and differs slightly in each. Another is tool definitions that changed last month without anyone recording when. Before intake closes, the team should be able to state the exact contract that produced the runs in the training set and confirm it is the contract the candidate will be evaluated against.

Training examples come from real runs, and a run is only usable if it carries the evidence the model saw: the tool calls it made, the results those calls returned, the documents in context, and the outcome that followed. Without the tool results, no one can tell whether a confident answer was supported or invented, and part 7 explains why that distinction decides what gets admitted to training.

Ask for a sample of runs before intake closes and check three things. Can a run be replayed, meaning every input the model saw is present? Are outcomes recorded, meaning something downstream says whether the answer was right? Are identifiers stable, so the same run can be found again after review? A customer whose observability stack stores only final answers has to fix ingestion first, and that is weeks of their engineering time, not the vendor's.

Someone on the customer side owns the answer to what the agent should have done. Judges and evaluators can propose findings, but they cannot decide intended behavior when the instruction is ambiguous, when two rules conflict, or when a new preference has to be set. That person reviews representative cases, edits proposed targets, and resolves the cases the automated pipeline marks uncertain.

The weak version is a committee or a rotating volunteer. Reviews then wait, decisions contradict each other across batches, and the training set inherits the inconsistency. Ask for one name and a time allocation, and treat the first review batch's turnaround as the leading indicator of whether the project will finish.

Parity has to be defined before any candidate is trained, or the definition will be shaped by the results. The customer states which outcomes count: the primary task result, the safety behaviors that must never regress, the format the downstream system needs, and any latency budget. They state the margin they accept, in the units of the primary outcome. And they name the cases that must never fail, which become the seeded recall check in the gate.

A definition of parity is a business decision the vendor cannot make for them. The vendor can propose defaults and explain their consequences, which part 21 does, but the customer signs. Treat a customer who cannot articulate parity as one who is not ready to switch models, because the switch will be argued about after the fact.

Most service agreements promise that the vendor will not train models on customer data. Converra's own default terms say exactly that. A customer-specific fine-tune is a deliberate exception and needs a written election that scopes it: which data, for which model, used for this customer only, with retention and deletion terms and a statement of who owns the resulting artifact. Part 35 works through ownership; intake only has to confirm the election exists.

Provider terms are the second half. Training data generated by a closed model may be subject to that provider's restrictions on using outputs to develop competing models, and the training provider may have its own warranties about what inputs are allowed. Part 42 covers the specifics. At intake, the question is whether the customer's legal team has looked, not whether the answer is yes.

Two items are less about training and more about whether the result can ship. Traffic facts: requests per day, the shape of the daily curve, the latency budget per request, and what the closed model currently costs. These decide whether a dedicated endpoint makes sense and where break-even sits, which part 27 computes. Guesses at intake become surprises at the economics review.

Deployment path: where the open model will be served, who can approve a production switch, who can roll it back, and how fast. A candidate that passes its gate and then waits a quarter for a platform team to provision an endpoint is a project that has stalled at the finish line. Name the approver and the rollback owner at intake, and confirm the serving path exists or is on someone's plan.

Intake is not one-sided. In exchange for the items above, the customer should expect the machinery: a pipeline that turns reviewed runs into a versioned dataset with protected splits, a frozen gate with a pre-registered rule, a training path on a named provider with a cost cap, an approval step before any traffic moves, and a production measurement afterwards that reports a verdict rather than a dashboard.

They should also expect honesty about what the vendor cannot do. It cannot decide intended behavior. It cannot invent a parity definition. It cannot grant data rights. And it cannot promise the candidate will pass; a failed gate is a valid outcome, and a customer who supplies everything on this list has bought a fair test, not a guaranteed result.

Converra ingests production runs with their tool calls, results, and outcomes through its SDK and API, which is the evidence-carrying form the second checklist item requires. Its fine-tuning workflow curates reviewed runs into versioned datasets with protected splits and per-example admission decisions, records the training job and its gate result against a dataset version, holds the production switch behind an explicit approval, and reports a parity verdict on real traffic. Training itself runs on the customer's provider or infrastructure.

The boundaries match the checklist. Converra does not use customer data to train any model without a written, tenant-exclusive election, because its default terms forbid it. The customer owns the parity definition, the reviewer role, the deployment policy, and the accountability for what ships. No open-weight production verdict for a customer agent has been published yet; the result on any agent's traffic is unobserved until it is measured there.