Train adapters

The rollout

A version answers your app's calls only after a rollout: first copies of calls, then a share of them, then all it can take. This page explains each step, what moves a version on, and how you move it yourself. It is for anyone who decides which model answers a task's calls.

The steps

The console and the management API name the steps differently. Both are listed here.

Step	Console	API	What the version answers
Candidate	`Not live yet`	`candidate`	Nothing.
Silent test	`Silent test {p}%`	`shadow`	Copies of the task's calls, after your provider has answered them. Your app never sees its replies.
Partial rollout	`Partial rollout {p}%`	`canary`	A share of the task's conversations. Your provider, or the live version, answers the rest.
Live	`Live`	`promoted`	Every call of the task it can take that the partial rollout doesn't.
Retired	`Retired`	`retired`	Nothing. A newer version replaced it, or someone retired it. Roll back can bring it back.
Taken offline	`Taken offline`	`demoted`	Nothing, until someone moves it to a silent test again.

A task has at most one version in a silent test and one in a partial rollout at a time. A newer version waits until the one ahead of it finishes its rollout. A partial rollout splits calls by conversation, so one conversation stays with one version.

Which calls a version can take, and what happens to the others, is on Calls an adapter answers.

What moves a version on

On app.mubit.ai, Mubit moves each version through the steps itself:

Candidate to silent test. Once the version has its exam result, and no other version of the task is in its rollout.
Silent test to partial rollout. After at least 50 of the version's replies are compared with your provider model's, from at least 10 conversations. A silent test sends the version copies of up to 100 calls a day by default.
Partial rollout to live. After the version answers at least 100 calls in its partial rollout. A partial rollout takes 10% of the task's conversations by default.

When a version goes live, the version live before it retires.

On app.mubit.ai today these steps wait on those counts only. Mubit also measures how often the version's replies hold up against your provider model's, and records the result on the version, but a low result doesn't hold the version back. See How the exam acts today.

The adapter's page shows where each version is, and the line at the top says what answers the task now, such as v2 live or v3 partial rollout 10% · your provider model answers the rest.

When quality drops

Mubit keeps checking a version while it answers calls: it asks your provider model a sample of the same calls and compares the replies. See Costs and data.

Mubit has two tests on those comparisons, one for a pass rate below the floor and one for a version that falls behind your provider model. On app.mubit.ai today, when a test fires, Mubit records it on the version and does not take the version offline or roll back. To stop a version, take it offline or roll back yourself.

Move a version yourself

In the console

An admin of your organization opens the adapter's page. Each version under History has the moves its step allows:

Button	What it does
`Start silent test…`	The version answers copies of a share of the task's calls.
`Start partial rollout…`	The version answers a share of the task's calls.
`Make live…`	The version answers every call the partial rollout doesn't take. The live version retires.
`Retire…`	The version stops answering and stays listed.
`Take offline…`	The version stops answering now. It can go back to a silent test, or be retired.
`Change share…`	The same step, with a new share, from 1 to 100%.

Each move asks for a reason, kept in the adapter's history. Mubit checks the move first, and when it refuses it, the page says why.

The adapter's menu has three more:

Item	What it does
`Roll back…`	The live version retires, and the version live before it goes live again once Mubit has checked it.
`Switch off…`	No version answers the task's calls until you switch it on. Every version is kept. `Switch on…` brings them back.
`Emergency stop…`	Every version stops answering at once, until a version goes live again. You type the task's name to confirm.

Members who aren't admins see the adapter and its history, without the buttons.

From code

A management key with the admin role can start a silent test or a partial rollout, make a version live, and roll back. List a task's versions first to get their IDs.

Python

from mubit import Mubit
 
client = Mubit()
 
version = client.tasks.versions("<task id>").data[0]
client.versions.rollout(version["id"], canary_percent=10)   # a partial rollout on 10%
client.versions.promote(version["id"], reason="checked in Requests")
client.versions.rollback(version["id"])                     # the live version only

Operation	What it does
`GET /api/v1/tasks/{task_id}/versions`	The task's versions, newest first.
`GET /api/v1/versions/{version_id}`	One version, with its step and its test result.
`PATCH /api/v1/versions/{version_id}/rollout`	`shadow_percent` above 0 starts a silent test at that share; `canary_percent` above 0 starts a partial rollout. Name one, from 0 to 100. Both at 0 ends a silent test or a partial rollout.
`POST /api/v1/versions/{version_id}/promote`	Makes the version live, with an optional `reason`.
`POST /api/v1/versions/{version_id}/rollback`	Retires the live version and brings back the one before it. Name the live version: another one gets `409`. The answer names the version that is live again.

A move the version's step doesn't allow, or one Mubit's checks refuse, gets 409 with the reason. Taking a version offline, switching an adapter off and the emergency stop are in the console only today: the management API answers 501 for them.

ℹ️Note

The CLI asks before a rollback. In a script, pass --yes.