Run a production-readiness game day for an AI feature

• Use a realistic staging or isolated environment with synthetic or approved test data.
• Define steady-state expectations and abort conditions before injecting faults.
• Cover user experience, quality, safety, privacy, cost, and operations rather than uptime alone.
• Assign an incident commander and control owners; observers should record evidence without steering silently.
• Exercise rollback and degraded operation, not only detection.
• Turn every failed expectation into an owner, due date, and retest requirement.

1. Publish the feature contract, SLOs, quality and safety gates, data policy, dependencies, runbooks, and decision authority.
2. Establish a clean baseline across representative evaluation slices, latency, errors, tokens, cost, freshness, and tool outcomes.
3. Inject one bounded failure at a time, observe alerts and operator decisions, and protect real external systems from unintended actions.
4. Require the team to identify the affected stage, contain impact, communicate status, and invoke rollback or degraded mode.
5. Verify recovery through user-visible checks, evaluation suites, reconciliation, deletion, and recurrence monitoring.
6. Write an after-action record separating detection, diagnosis, containment, recovery, and prevention; block launch on unresolved critical gaps.

game_day:
  steady_state:
    grounded_answer_rate: ">= 0.85 overall and >= slice gates"
    unsupported_high_risk_claim_rate: "<= 0.005"
    p95_latency_seconds: "<= 8"
    retrieval_freshness_minutes: "<= 30"
    duplicate_side_effects: 0
  experiments:
    - id: provider-throttle
      inject: bounded_429_responses
      expect: [deadline_respected, approved_fallback_or_degraded_mode, alert]
    - id: stale-retrieval
      inject: pause_one_connector
      expect: [freshness_alert, stale_source_disclosed_or_disabled]
    - id: indirect-injection
      inject: malicious_retrieved_chunk
      expect: [no_cross_tenant_data, no_unauthorized_tool, security_event]
    - id: ambiguous-tool-result
      inject: timeout_after_acceptance
      expect: [stable_idempotency_key, reconciliation, no_duplicate]
  abort_when:
    - any_real_customer_data_exposed
    - any_uncontained_external_side_effect
  launch_gate: all_critical_expectations_pass_and_retested

The exercise is bounded by the number of failure hypotheses and recovery paths. The valuable output is not test volume but verified ownership and evidence for the highest-risk system behaviors.

• All infrastructure health checks pass while answer quality or corpus freshness has failed.
• A fallback restores latency but does not meet structured-output or regional policy.
• A security control blocks the action but exposes sensitive content in traces.
• Rollback changes the model but leaves an incompatible retrieval index or prompt version.
• The technical system recovers while ambiguous external actions remain unreconciled.

• Keep services healthy while degrading one evaluation slice and require a quality alert.
• Offer an incompatible fallback and require policy-aware degraded operation instead.
• Plant sensitive text in an injected chunk and inspect telemetry for leakage.
• Recover request traffic but leave a pending ambiguous side effect and reject incident closure.
• Ask for concrete launch blockers, owners, and retest evidence rather than a generic readiness checklist.

• A load test alone does not exercise probabilistic quality, data, tool, and safety failures.
• Injecting faults without predefined expectations turns the exercise into improvisation.
• Detecting an incident without practicing containment and recovery creates false confidence.
• Passing aggregate metrics while a critical slice fails is not launch readiness.
• Closing the game day with undocumented observations guarantees the same gaps return at launch.