A launch boundary joins model evaluation to the permissions, review gates, exception paths, monitoring, and recovery behavior around it. A good score is not enough if the operating system cannot respond safely.
Acceptance and evaluation
- State the task, population, allowed inputs, allowed outputs, and excluded uses.
- Define quality thresholds by case type, including cases where abstention or escalation is correct.
- Use representative ordinary cases, edge conditions, conflicting evidence, and harmful failure modes.
- Record the reference answer, reviewer disagreement process, model and prompt version, latency, and cost.
- Test the complete integrated path. Component scores do not establish workflow behavior.
Identity, data, and tool permissions
- Bind every source and action to an authenticated identity and a named permission owner.
- Limit data access and tool use to the bounded workflow and least privilege required.
- Classify prohibited data, retention, output destinations, and cross-boundary transfers.
- Separate read, recommend, draft, approve, and execute permissions.
- Test indirect prompt injection, hostile content, permission confusion, and unintended data disclosure.
Human review that can change the outcome
- Name the reviewer, backup reviewer, and authority to approve, reject, correct, pause, or escalate.
- Show the evidence, provenance, uncertainty, policy context, and prior actions needed for judgment.
- Give the reviewer enough time. A gate that must always be cleared immediately is not meaningful oversight.
- Measure overrides, delayed decisions, unresolved queues, and recurring correction patterns.
Exceptions, fallback, and rollback
Exception path
Define what routes out of the normal path, its priority, required context, destination, operating owner, and service expectation.
Fallback path
Preserve a tested deterministic or human-operated route when the model is unavailable, uncertain, too slow, too expensive, or outside its approved boundary.
Rollback path
Preserve the prior state, action log, dependencies, recovery steps, authority, and verification needed to reverse a consequential change.
Monitoring and operating evidence
- Observe quality, abstention, overrides, exceptions, latency, cost, adoption, and downstream outcomes.
- Set alert thresholds, review cadence, responsible owners, and time to act.
- Detect model, data, prompt, policy, integration, and user-behavior changes.
- Keep an operating record that connects a consequential output to inputs, versions, evidence, approvals, actions, and corrections.
Launch, expand, reshape, or stop
Record the approved population, permissions, acceptance thresholds, known limitations, monitoring owner, support path, fallback, rollback, review date, and stop authority. Expansion requires fresh evidence. A boundary does not become safe merely because the first release stayed quiet.
The launch decision belongs to the bounded system and its operating owners, not to the model score alone.