AI Feature Launch Checklist

Chapter 2 of 8 · 4 checks · 2 min

Evals passed

A launch decision needs numbers, not impressions. These checks confirm the feature was measured against an agreed bar, including how it fails.

Show
  1. Meet a written ship rule on a representative eval setMust

    Why it matters and how to check

    Agree before the final eval which thresholds must pass to launch, such as accuracy, format validity, refusal rate and latency, so the result cannot be argued after the fact. The eval set should include realistic inputs, edge cases and hostile inputs, not only tidy examples.

    To verify, attach the eval run to the launch ticket with the model, prompt version and dataset version, and show each threshold next to its result. Any threshold that was lowered for launch needs a note saying who approved it and why.

  2. Run prompt injection, data leakage and harmful content tests before launchMust

    Why it matters and how to check

    OpenAI's safety guide recommends adversarial testing with both typical inputs and deliberate attempts to break the app, including prompt injection such as "ignore the previous instructions". OWASP lists prompt injection among the top risks for LLM applications. Test that the feature does not reveal its hidden instructions, other users' data or internal tools, and does not produce content your policy forbids.

    To verify, keep a red-team set of at least a few dozen attack prompts relevant to the feature and record the pass rate. Every successful attack found before launch should be fixed or accepted in writing, and added to the regression set.

  3. Dogfood with a small group of real users and read the transcriptsShould

    Why it matters and how to check

    Eval sets reflect what the team expected. A week with internal users or a small beta group shows what people actually ask. Read a sample of real transcripts, not only the scores, and turn every surprise into an eval case.

    To verify, record how many sessions were read, the main issues found, and which became eval cases or fixes. The launch ticket should link this summary.

  4. Document the known failure modes and share them with supportShould

    Why it matters and how to check

    Every AI feature has inputs it handles badly. OpenAI's safety guide stresses understanding and communicating limitations: models can hallucinate, produce offensive content and show bias. Support staff who know the known weak spots can answer users quickly and recognise new problems.

    To verify, check that a short "known limitations" note exists, that support has read it, and that it lists what users should do instead in each case.