1.6 KiB
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.