Get startedOperate · Release and runtime
Deploy and operate models
Release models to devices, providers, managed APIs, or outcome-based workloads.
Source reviewed 2026-09-16. Availability depends on your installation, permissions, and compatible runtimes. A supported path is not a guarantee of model quality or production readiness.
Outcome
Operate a versioned visual system with health, traffic, spend, feedback, and rollback context.
Start here
What you need to know first
Check the inputs below before starting. If you are new, begin with the first-project guide. A dataset holds media and labels; a model produces results; a deployment makes a selected model version callable. Creating one does not create the others.
Bring these inputs
- — An eligible model or workflow release
- — Runtime target, routing, scaling, and observability policy
Expected output and limits
- — A routable deployment or outcome workload
- — Telemetry, spend, feedback, and rollback state
Core workflow
Choose the production outcome
Deploy an endpoint or launch completed work such as annotation and multi-stage inference.
Select an eligible release
Bind a model or workflow version with the required evaluation and conformity evidence.
Choose the runtime
Target managed compute, a connected provider, or a registered edge device.
Monitor and improve
Observe health and usage, capture failures, and route evidence into the next workflow version. Administrators can inspect grouped application errors with fingerprints, affected resources, and recovery actions; changed and resolved incidents remain distinguishable.
What this surface supports
Managed endpoints
Edge deployment
Outcome workloads
Monitoring and feedback
Grouped error and recovery evidence
Expert section
Contracts, signals, and failure modes
Use this section when you are defining acceptance criteria, automating the surface, or reviewing whether its output is safe to promote downstream.
Quality and operating signals
- — Availability and error rate
- — P50/P95 latency
- — Throughput and cost
- — Quality drift and conformity
Common failure modes
- — Artifact/runtime mismatch
- — Capacity exhaustion
- — Silent input drift
- — No rollback or feedback route
Expert release checklist
□ Inputs and dependencies are pinned to immutable versions.
□ Acceptance metrics include critical classes and operating slices.
□ Failure, retry, cost, and rollback behavior are understood.
□ The resulting artifact has an owner and a downstream review path.
Engineering safeguards
- — Every traffic or provider-compute path requires a passing exact-version model test
- — Runtime and artifact remain linked
- — Rollback context is retained
- — Production alert delivery still requires an operator-owned destination and scheduler