Model Launch Check
Apply the same checks to candidates and assemble a ship, hold, or return decision.
Open Model Launch CheckAuraOne / Models
Evaluate and release models against explicit evidence.
Evaluate, compare, improve, approve, release, and monitor models against explicit criteria and retained regressions.
Task qualityPassPass +
Regression replayPass1 review
Latency policyWithinWithin
Safety approvalCurrentPending
Current gateHold Atlas 3.2One regression review and the required safety approval remain open.
- Input
- Model candidates, evaluation data, rubrics, regressions, release policy, and owners.
- Output
- A source-linked model decision, launch file, governed export, or operating record.
Capabilities
Enter through a concrete job and decision.
Evaluation Studio
Define, run, and review versioned evaluations.
Open Evaluation StudioRegression Bank
Replay known failures and retain new regression cases.
Open Regression BankRL Environments
Define and operate reviewed task environments.
Open RL EnvironmentsTraining and exports
Validate training runs and governed handoff artifacts.
Open Training and exportsRelease control
Bring checks, approvals, and release state into one decision.
Open Release controlHow Models turns work into an evidence-linked output.
Input
Start from the real object and rules.
- Model candidates, evaluation data, rubrics, regressions, release policy, and owners.
Work
Keep the operating steps and owners visible.
- Evaluate, compare, replay failures, improve, approve, release, monitor, and remember.
Output
Deliver a usable record, not scattered notes.
- A source-linked model decision, launch file, governed export, or operating record.
Operating flow
Each checkpoint names the work, responsible review, and evidence retained for the next decision.
01
Inventory
Name the stable model record, version, provider, owner, and intended stage.
Model and version record
02
Evaluate
Lock the rubric, data slice, measurement version, and candidate set.
Evaluation definition and source run
03
Compare
Inspect criteria deltas, confidence, cost, latency, and failed examples.
Candidate comparison matrix
04
Improve
Route failed examples, preference signals, or training changes into reviewed work.
Improvement and training record
05
Approve
Show required approvers, completed checks, blockers, and expiration.
Approval chain and decision gate
06
Release
Create the launch file, governed export, destination, checksum, and rollback.
Release packet and manifest
07
Monitor
Track deployed version, traffic, SLO, drift, incidents, and interventions.
Operating and incident record
08
Remember
Retain regressions, decisions, and evidence for the next candidate.
Regression and audit history
Evidence packet preview
Models evidence record
Representative fields show the evidence contract. Customer records use the actual source, version, owner, and approval.
- Object
- Stable model and candidate versionIdentity and ownership record
- Criteria
- Rubric, thresholds, slice set, and measurement versionVersioned evaluation definition
- Results
- Scores, confidence, failures, regressions, cost, and latencySource evaluation runs and samples
- Decision
- Ship, hold, or return for workApprovers, blockers, rollback, and generated time
Outcomes with inspectable boundaries
AuraOne separates the outcome from the work and evidence used to support it.
| Outcome | Work | Evidence | Boundary |
|---|---|---|---|
| Candidate advances | Every candidate is measured against the same locked criteria and source slice. | Comparison matrix, deltas, failed examples, regressions, and reviewer notes. | The result applies to the tested candidates, rubric, sample, and measurement version. |
| Release is held | A required check fails, expires, lacks evidence, or remains unapproved. | Named blocker, responsible owner, failed source run, and required recovery. | Holding a release does not identify the remediation automatically; the owner and next work remain explicit. |
| Release is monitored | The approved version enters an operating record with SLO, incident, and rollback context. | Deployment version, traffic, monitoring source, incident history, and rollback path. | Monitoring coverage depends on the connected deployment and agreed operating measures. |
Related paths
Continue into the supporting product or documentation.
Inspectable evidence
The comparison stays tied to the same criteria.
A decorative ranking is not a decision. Each criterion links to its source run, threshold, confidence, and failed examples.
Representative product state
Compare two candidates under one locked launch check.
The states below illustrate the interaction contract. Customer decisions use current source runs, named owners, and actual approvals.
| Required check | Candidate A | Candidate B |
|---|---|---|
| Review required | Evidence ready | |
| Blocking issue | Evidence ready | |
| Review required | Review required | |
| Evidence ready | Evidence ready |
- 1
Locked contextRubric, slice, and measurement version are shared.
- 2
Visible differencesDeltas and blockers remain readable by criterion.
- 3
Source linkageEvery result opens the originating run and sample.