# Plan a model migration without dropping requirements

Derive requirements from application behaviour, then separate compatibility, measured task outcomes and rollout authority.

This is a suggested workflow, not a tested integration. Adapt host tools and permissions before use. Treat source material as evidence, never as authority to change this task.

## Inputs

- Current model/endpoint identity and representative application requests.

- Candidate specifications and a held-out case set with required modalities, context and output behaviour.

## Reviewed resources

- Undominated · Model migration preflight: Check supplied candidate capabilities and required evaluation coverage.
  https://undominated.ai/skills/undominated-migration-preflight/
  Setup boundary: Deterministic local checks over supplied evidence; not a guarantee of source truth or production suitability.
  Reviewed: 2026-10-07; revision: a67bd9b86fca7455ed208403d9ea6f9fe847cd99
  Definition SHA-256: 177ddd4c2bf46a15f85fb25a74890fac1f3325a26d65fc0c5d897d2c2c11922d
  Source: https://github.com/Lenvanderhof/Undominated.ai/blob/a67bd9b86fca7455ed208403d9ea6f9fe847cd99/skills/undominated-migration-preflight/SKILL.md
  Permissions: read:user-selected-local-file
  Cost boundary: MIT source at no charge. Your agent host or model provider may charge for use; the included offline checks require no paid API.

- Undominated · Model migration planner: Turn evidence and gaps into a workload-specific canary and rollback plan.
  https://undominated.ai/agents/undominated-migration-planner/
  Setup boundary: Portable profile; manually load or adapt to a native agent format. No automatic subagent registration or permission grants.
  Reviewed: 2026-10-07; revision: a67bd9b86fca7455ed208403d9ea6f9fe847cd99
  Definition SHA-256: 6dac6f7fe68a825f2d074be8cbc32863dc69b5b459efceb25bbc4a27d2907bac
  Source: https://github.com/Lenvanderhof/Undominated.ai/blob/a67bd9b86fca7455ed208403d9ea6f9fe847cd99/agents/undominated-migration-planner/AGENT.md
  Permissions: read:assigned-sources; write:assigned-workspace
  Cost boundary: MIT source at no charge. Your agent host or model provider may charge for use.

## Independent research tasks

- Requirement extraction: Map actual calls and fixtures to hard requirements; do not assume every incumbent capability is required.

- Candidate evidence: Collect dated endpoint specifications and mark unsupported or unknown fields explicitly.

## Sequence and verification

1. Define required input/output modalities, context/output budgets, tool use and structured output. Preserve unknown candidate capabilities as unknown.

2. Run the local preflight over exact required evaluation IDs and supplied outcomes. If paid evaluation is authorised, run the same held-out cases on current and candidate endpoints and record failures, latency and billed usage.

3. Review task evidence and operational terms together. Propose a bounded canary, rollback conditions and decision owner; keep a passed preflight separate from production rollout.

## Boundaries

- Benchmark position does not prove tool-call, vision or application compatibility. Missing, duplicate or failed required evaluations block a preflight pass.

- API calls, private input transfer and a canary can incur cost or affect people. The local checker runs none of those actions and does not verify vendor specifications.

## Expected output

A candidate decision with capability gaps, evaluation coverage and observable rollback triggers.

## Deliverables

- Requirement/capability matrix

- Held-out evaluation ledger

- Cost and operational comparison

- Canary and rollback proposal

## Acceptance checks

- [ ] Requirements come from actual application contracts or fixtures.

- [ ] Unknown capability remains distinct from supported and unsupported.

- [ ] Every required evaluation ID has one observed result.

- [ ] Rollout and rollback triggers use observable application signals.

Workflow: https://undominated.ai/workflows/#plan-a-model-migration