# Capability Deployments

## M9 shared-GPU admission

OCR, visual embedding and ASR deployments use the existing lease/residency scheduler. Manifest resource classes explain expected pressure, but an exact measured `CapabilityResourceEnvelope`, external GPU observation and fixed reserve determine admission. Heavy work fails with `INSUFFICIENT_SCHEDULABLE_VRAM`; ModelForge never evicts unmanaged Ollama, Tdarr or Plex workloads.

A CapabilityDeployment is the immutable production binding between CapabilityContract,
DeploymentCandidate, production approval, exact ArtifactSet, RuntimeProfile, ComputeNode,
accelerator, EmbeddingSpace and measured ResourceEnvelope. Lifecycle states are stable, draining,
deprecated and archived; LAB_READY remains a separate non-production candidate state.

Promotion rejects missing or stale runtime evidence, non-verified artifacts, non-production nodes,
incomplete supply-chain review and mismatched deployment facts. The active M5 deployment is
`420f11de-4906-4751-bfd4-923849fc7d9d`, pinned to candidate
`c6824408-84d1-45bf-b431-a3893e57fd52` and worker image
`sha256:e707953d1cc6fe3e66e4571ea1381f37e5a88bc71a31dac896b98bccf56dbac0`.

## M12 lifecycle overlay

Lifecycle subjects reference deployments rather than replacing them. A partial unique database
index prevents two `production=true, status=stable` rows for one capability contract. Promotion
execution additionally uses subject-version compare-and-swap and idempotency keys. Platform-stable
does not grant a project production binding; that change requires its own project policy and fit
evidence.