Move to a new Compute version

Before you start

Write down the four versions you run today:

• the contract release from a recent response
• the workflow.version you pin
• your profile version
• your client version

Read the change entry for the version you are moving to, and note whether it names any of those four.

Run the migration in the sandbox first, against a small input you already know the answer to.

One thing you do not have to prepare: your identities survive a migration. Personal, service and automation identities and their keys stay valid. You do not re-mint a key to move version, and rotation stays a separate deliberate act.

Your sources, destinations and profiles also survive. A profile may need a new version if the new workflow narrows what it accepts, but the profile itself is not replaced.

Migrate the request

The seven TaskSpec objects do not change shape between versions. What changes is what a workflow version accepts inside them.

1. Point workflow.version at the new version.
2. Validate parameters against that version's generated parameters_schema.
3. Check whether your profile still narrows policy, quality, output and limits legally.
4. Correct every mismatch before you submit anything.

An unknown or unsupported field is rejected, never dropped. That is in your favor here: a setting that no longer applies refuses loudly instead of disappearing.

Quote again, always

A quote is signed against one described request. It carries an expiry and non_authorizing = true.

A quote taken against the old version does not price the new one. Get a fresh quote whenever you change the workflow version, the parameters, the profile, the input snapshot, the output declaration or the limits.

If admission answers REPLAN_REQUIRED, the priced request drifted from what you submitted. Quote again and resubmit.

Approve again only when the boundary moves

A quote never authorizes work, so approval stays a separate act on both versions.

Ask for a fresh approval in three cases:

• the new version changes what you may be charged
• it changes the destination a result is written to
• it needs a scope your current approval does not cover

Otherwise your existing approval continues to apply.

Read the result the same way

The bundle layout does not change between versions. result-manifest.json is still written last, and it is still the only complete-bundle marker.

The namespaced result columns keep their names. If a workflow version changes its output schema, that change is on the descriptor and in the change entry. Check both before you alter your parser.

What success looks like

You have a quote against the new version, an admitted job, a SUCCEEDED or PARTIAL status, and a bundle whose result-manifest.json is present.

Compare the manifest's counts with what you submitted, and compare a sample of results with the old version's output on the same input. Then move production traffic while the overlap window is still open.

If something refuses

• REPLAN_REQUIRED — quote again, then resubmit.
• A refusal naming a field path — remove or correct that field and resubmit.
• A refusal naming an approval or a scope — approve it, then resubmit.
• A refusal naming capacity or budget — see what each refusal class means before you retry.

Every non-success carries a safe reason and a next action. Follow the next action on the response before changing anything else.