Skip to main content
Training creates a model artifact from pinned data and a recorded recipe. Deployment prepares that artifact for its supported inference runtime. Evaluation measures task behaviour. Activation selects a verified chat deployment for an application alias. Ask this in the project conversation after creating the relevant tutorial or workflow results. These states are related, but none substitutes for the others. Successful training automatically starts the matching chat or decision deployment. An unsuccessful deployment does not invalidate the fact that training finished, and a retry does not require repeating training. A capability’s benchmark model is independent of its active serving model. Changing the benchmark default changes future comparisons; it does not reroute application traffic. Activation preserves the previous selection until the new deployment verifies. Workers can later scale down, so being active does not guarantee a permanently warm worker. A direct request to a pinned deployment does not prove the application uses the alias. Native decision artifacts include a decision head and probability contract. They deploy through that runtime, not the chat-completions contract. Costs also have distinct boundaries. A forecast is an estimate with assumptions and missing components; a worker receipt records measured usage; a ledger charge records metered spend. None should be presented as a complete provider invoice unless the evidence actually covers it.