Upgrade

Move a running deployment to a new decisio release in eight steps, without losing your tasks or serving uncertified answers as certified.

Every upgrade is the same eight steps, whatever the release. Before you start, export what you have taught:

curl -s 'http://127.0.0.1:8000/v1/tasks?full=1' > tasks.json

Run against the CPU stand-in at v0.35.0 on 2026-10-26.

1. Read the notes for every release you skip

Release notes has, for each release that changes what a deployment serves, who is affected and what to do. Read every entry between your release and the one you are moving to.

2. Pin what you serve

Install the exact release: pip install "decisio[serve]==<version>", or a clone at its tag.
Name the model repository at a commit, --base tachara-ai/decisio-gemma-4-31b@<commit>, so the weights cannot change under you.
Give --max-model-len the same value on every card.

3. Start the new release next to the old one

Keep the old server serving, start the new one on another machine, and read its /health: the model, its checkpoint and revision, and max_model_len with its source. A server takes 0.90 of its card’s memory by default, leaving no room for a second: on a single card, stop the old server and start the new one in its place, at a quiet time or behind a maintenance page.

4. Load your tasks into it

Start it with --tasks-file tasks.json, or import the export with POST /v1/tasks/import. A task taught under another model or rendering is not applied, and the server says so at start: teach it again from its examples.

5. Certify your tasks again

The decisio version is part of the serving setup a certificate covers, so a certificate made on the old release is suspended on the new one. Certify each certified task again on the new server, on labelled examples that share no input with the task’s fit, such as the held-out examples it was certified on.

The call keeps the certificate’s error target unless the body names one, and the fewest examples it needs follow the target: 59 at the default 5%, 29 at 10%. decisio ships 48 held-out tickets for the walk-through task, below 59, so the body below asks for a 10% error target. For your own tasks, keep the error target and send at least as many new examples as it needs.

Build the body from the tickets and send it to the task’s certify route:

uv run python examples/tasks/register.py --id ticket-routing --data examples/tasks/heldout.csv --dry-run --out heldout.json
uv run python -c 'import json; b = json.load(open("heldout.json")); json.dump({"examples": b["examples"], "alpha": 0.1}, open("recertify.json", "w"))'
curl -s http://127.0.0.1:8000/v1/tasks/ticket-routing/certify -H 'Content-Type: application/json' -d @recertify.json \
  | uv run python -c 'import json, sys; r = json.load(sys.stdin); c = r.get("certificate", r); print(json.dumps({k: c.get(k) for k in ("alpha", "n", "threshold", "certified_n")}, indent=1))'

Run against the CPU stand-in at v0.35.0 on 2026-10-26. It printed:

48 examples, 12 labels, 4 to 4 per label
{
 "alpha": 0.1,
 "n": 48,
 "threshold": null,
 "certified_n": 0
}

The fit is kept; the call answers with the new certificate.

6. Check that it took

curl -s http://127.0.0.1:8000/v1/tasks/ticket-routing

Run against the CPU stand-in at v0.35.0 on 2026-10-26. It printed, trimmed to the fields this page uses:

{
 "id": "ticket-routing",
 "status": {
  "state": "ok",
  "text": "ok"
 }
}

The task’s status should read ok for every certified task, with no suspended.

7. Move the traffic

Point your proxy at the new server, and watch /health and the server time as the traffic arrives (Operate).

8. Stop the old server

Only the latest release receives security fixes, so do not keep the old one running.

What next

Release notes: every change in every release, and what each one changes for a running deployment.
Certify answers: what a certificate covers, and how to certify again.