Promotion model
Mistral describes a path from creator-visible assets to workspace promotion and tagged production versions. Domain experts can iterate in Studio; a production-bound label or SDK event can enter the organization’s existing CI/CD.
Required pipeline gates
| Gate | Evidence |
|---|---|
| Resolve | Asset ID, immutable version, owner, label, dependencies |
| Test | Fixed cases, adversarial cases, tool mocks, deterministic checks |
| Evaluate | Versioned dataset, judge or rubric, human review, thresholds |
| Approve | Domain, security, data, safety, and release owners as applicable |
| Promote | Workflow identity, environment, target, artifact, timestamp |
| Verify | Runtime version, traces, errors, metrics, sampled outputs |
| Recover | Rollback candidate, stop path, external-effect repair |
Use workload identity or an approved service account with least privilege. Do not place long-lived Studio credentials in source, logs, or fork-accessible workflow contexts.
GitHub Actions boundary
A GitHub Actions example is an integration pattern, not a requirement to move all prompt source into GitHub. The repository should own pipeline code, tests, policy, and surrounding application dependencies; Studio can own the governed prompt or skill versions. Record the mapping.
Frequently asked questions
Can non-developers promote directly to production?
They can initiate improvement under Mistral’s model, but production promotion should preserve the organization’s tests and approvals.
Should a failed evaluation auto-rollback?
Only when a reviewed rule safely identifies a reversible condition. Consequential or ambiguous failures need human review and external-effect handling.
Where are version and rollback details?
Use the versioning guide.
Official source
Source check: August 5, 2026.