Deployments

Deployments bind a task version to a model and execution strategy.

Supported strategies today:

  • prompt
  • rag
  • lora

Endpoints

POST /v1/deployments

Create a deployment with a frozen config snapshot.

Key request fields:

  • task_id
  • task_version_id
  • model_id
  • optional strategy
  • optional adapter_id for lora
  • optional evaluation_id to link the release to the matching comparison

PUT /v1/deployments/:id/activate

Mark a deployment active for its task.

PUT /v1/deployments/:id/deactivate

Deactivate a deployment.

GET /v1/deployments

List deployments, optionally filtered by task_id.

Notes

  • LoRA deployments validate that the adapter belongs to the same task and base model.
  • Activation is per-task, so activating one deployment deactivates the previously active deployment for that task.

The task version pins instructions, answer rules, and skill versions. Validation and routing settings are snapshotted. Sources and retrieval settings are snapshotted with the release. Later source edits do not change that snapshot. A comparison link establishes what was tested, not a guarantee of correctness.

Release tests

Supply evaluation_candidate_id with evaluation_id to select an exact passing release-test candidate, including when two candidates use the same model. Tasks with config.release_policy.mode: "required" require a qualifying candidate when creating, activating, or serving a release. Read the adoption and rollback rules.