The AI Feature Ship Gate

An AI prototype can look excellent in a product review and still be unfit to ship. The demo usually contains a cooperative prompt, a familiar task, and an output someone already checked. Production supplies the typo, the missing context, the sensitive detail, and the user who interprets fluent language as a factual guarantee.

“Looks good” is a useful reaction. It is a poor launch criterion.

The operating position is direct: evals are executable product requirements. A feature should cross a ship gate only when it meets explicit thresholds on representative, edge, adversarial, and regression cases, with graders matched to the consequence of failure and rollback rules defined before release.

A product requirement that cannot fail is incomplete

Traditional requirements often describe the happy path: the user provides an input, the system produces a result, and the user continues. For a variable AI system, that leaves the most important decisions unresolved.

How often must the behavior succeed? Which failures are tolerable? Which single failure blocks a release? Does the bar change for a novice user, a sensitive input, or an irreversible action?

OpenAI's November 2025 eval primer makes a useful connection: contextual evals turn fuzzy goals into specific expectations for a particular workflow. It recommends defining what great looks like, testing under real-world conditions, and using error analysis to expand the test set. The same source is clear that evals complement production monitoring, user feedback, and A/B tests. They do not replace them.

Vendor guidance is not enough to set a release bar. NIST's AI Test, Evaluation, Validation, and Verification program frames evaluation as reliable measurement of AI technologies and their use, supported by tasks, metrics, testbeds, and methods that also expose limitations. NIST does not prescribe this article's five-lock gate. It supports the narrower principle that a trustworthy launch needs an explicit measurement method and known limits, not a persuasive demo.

The product manager's job is to turn those expectations into release policy. An eval suite without a ship decision is a research report. A launch decision without an eval suite is a judgment call that cannot be reproduced.

Test the outcome, not the sentence

Fluency makes weak evaluation especially dangerous. A response can sound polished while failing the user's task.

Anthropic's guide to evaluating AI agents separates a transcript from an outcome. A booking agent may say that a flight was booked, while the verifiable outcome is whether the reservation exists. The guide also recommends multiple trials because model behavior varies, balanced cases where a behavior should and should not occur, reference solutions, and a combination of code-based, model-based, and human graders.

The principle applies beyond agents. In this synthetic career-writing scenario, the output is a draft achievement statement. The outcome is a statement that preserves the user's facts, improves clarity, avoids invented impact, and is usable after an acceptable amount of review. Grading only tone or grammar would miss the failure that matters most: adding a claim the user never made. The example demonstrates the release method and does not report Bragora's current implementation or performance.

The ship gate has five locks

The following scorecard is a proposed artifact. The thresholds are illustrative and must be calibrated against task consequence, human judgment, and actual baseline performance.

Lock 1: The task contract

Write the behavior in observable terms before assembling examples.

• Input: a user-authored work note and optional context.
• Expected outcome: a concise achievement statement that preserves supplied facts.
• Forbidden behavior: invented numbers, employers, responsibilities, or outcomes.
• Allowed fallback: ask for missing evidence or return a clearly labeled draft with gaps.
• Decision owner: the named product and domain owners who can change the bar.

If two reviewers read the requirement and disagree about whether an output passed, the contract is not ready.

Lock 2: The case bank

Build cases by failure surface, not by convenience.

• Golden cases: common, well-specified inputs with expert-approved reference characteristics.
• Edge cases: incomplete notes, acronyms, multiple achievements, conflicting context, or unusually long inputs.
• Adversarial cases: instructions to invent impact, expose private data, or ignore the product's constraints.
• Regression cases: every critical production failure and previously fixed defect that must stay fixed.
• Negative cases: inputs where enrichment should not occur or the system should ask a question.

The current OpenAI evaluation best-practices guide likewise recommends typical, edge, and adversarial test data and human calibration of automated scoring. Its specific Evals platform is scheduled for deprecation in late 2026, so the durable lesson is the evaluation design, not the vendor API.

Lock 3: The grader stack

Use the cheapest reliable grader for each assertion.

• Deterministic checks: required format, prohibited strings, length bounds, schema validity, and tool-call arguments.
• Reference checks: preservation of supplied facts and expected task state.
• Model graders: bounded judgments such as clarity or whether unsupported claims appear, calibrated against human labels.
• Human review: ambiguous outputs, high-consequence slices, grader disagreements, and periodic quality audits.

A model should not be the sole judge of a failure that can materially harm a user. Model graders also carry biases, including preferences for longer answers, and need routine calibration.

Lock 4: Slice-specific thresholds

Do not hide a critical failure inside one average score. A proposed release policy might require:

• acceptable correction time, tail latency, and cost per qualifying outcome.

These numbers are synthetic. A medical, financial, employment, or irreversible workflow may require a stricter bar, narrower scope, or mandatory human approval. A low-consequence creative tool may accept more variation.

A threshold also needs a meaningful denominator. Adoption Is Not an AI Value Metric explains why release evidence should connect attempts to qualifying user outcomes rather than reward activity alone.

Lock 5: Release and rollback

Define the operating response while the team is calm.

• Launch to a bounded cohort with monitoring by task slice.
• Preserve the tested model, prompt, tools, data, and configuration as one release unit.
• Trigger rollback when a critical failure appears or a protected slice falls below its floor.
• Route new failures into the regression bank.
• Review whether the grader or the product failed before optimizing the score.

This final point matters. A system can learn to satisfy a narrow grader without becoming more useful. Reading traces, outputs, and failures is part of maintaining the measurement instrument.

A gate should slow the wrong launch

The strongest counterargument is speed. A young team may have twenty examples, no evaluation platform, and customers waiting. Building a comprehensive harness can become quality theater that delays learning.

A small gate is often enough. Start with the highest-consequence behavior, a compact expert-reviewed case bank, a manual scoring sheet, and one explicit rollback condition. Automate after the team understands the errors. The gate should be proportional to risk and maturity.

There is a clean boundary: for a deterministic, low-consequence feature where ordinary tests fully specify the behavior, an AI-specific gate adds little. A generative interface with variable outputs does not meet that condition.

Leave a decision record

Before approving an AI feature, write a one-page launch record. It should contain:

If a teammate cannot reproduce the decision from that record, the gate is incomplete. An eval does not remove product judgment. It records that judgment in a form the team can test, challenge, and improve.