Approve or reject a production candidate
There is no one-command production certification. Release approval is a review of immutable,
persisted evidence for one active revision, one candidate revision, and one exact environment. A
healthy runtime alone is not approval.
Candidate creation/provisioning can create billable resources; validation sends the approved fixture
to active and candidate runtimes; semantic evaluation may process sensitive customer examples in
your evaluator; promotion changes production traffic; rejection and rollback can delete
candidate/failed capacity. Before any mutation, approve maximum spend, data handling, provider
ownership, immutable model/runtime/container identity, staging-only load, and the retained rollback
revision. Unknown identity, inventory, price, privacy, or qualification is a stop condition.
1. Read-only preflight
Also capture the selected provider’s canonical read-only baseline from
release evidence in CI. The plan, integration catalog, and model
record must agree on provider adapter, compute mode, runtime/version, immutable model commit,
container digest, accelerator/topology, region, and replica bounds. Local qualification does not
replace exact real-environment evidence.
2. Stage one candidate
Use one stable idempotency key. Do not create another candidate after an uncertain response:
Record ACTIVE_REVISION_ID and CANDIDATE_REVISION_ID from that inspection. Reattach to the same
durable operation on disconnect. If provider identity is uncertain, reconcile persisted identity
against read-only inventory before retrying.
3. Require independent evidence
The release reviewer must collect all applicable rows:
Use the exact procedures in protocol rollout,
semantic quality,
autoscaling qualification,
and provider outage recovery. If a row is required by policy and not
measurable in the exact environment, the result is WAIT/INCONCLUSIVE, not PASS.
Configure bounded validation and deterministic policy, then collect the persisted result:
The Guard snapshot must name the same active/candidate pair and explicit policy. It cannot infer
semantic quality, provider billing, active-stream completion, autoscaling recovery, or inventory
cleanup from readiness.
4. Decide
Promote only when the current decision is ACCEPT, every required external checklist row passes,
and the rollback revision is retained:
Keep the bounded automatic observation window. Run a non-duplicated production smoke request,
inspect its request ID, and retain the stream to terminal [DONE]. If the monitor rejects, verify
that the prior revision and router generation are restored before cleanup.
If Guard is REJECT, record the evidence before removing only the candidate:
If a regression appears after promotion and automatic rollback has not restored service:
Never delete the whole deployment to recover a release.
5. Close the evidence bundle
Capture canonical provider inventory again and compare it with the baseline. Promotion may retain
the explicitly documented rollback capacity only for its bounded monitor; rejection/cleanup must
not leave candidate-only resources. Sign an Inference Passport only after all required evidence is
complete. A passport attests to the bundle—it cannot convert a missing row into approval.
Reviewer outcome
- APPROVE: Guard
ACCEPT, every applicable checklist row passes, rollback is ready, identities match.
- REJECT: a measured readiness, protocol, quality, performance, recovery, or policy regression exists.
- WAIT: evidence is missing, stale, incomparable, unavailable, or the provider outcome is uncertain.
Record the outcome, reviewer, timestamp, exact revision IDs, and evidence paths. No LLM decides
promotion.