Why AI Evaluation Must Run at Every Lifecycle Stage

Most teams treat AI evaluation as a launch gate: build the feature, run the golden set, get sign-off, ship. That mental model copied from waterfall QA misses where probabilistic systems actually fail. Retrieval drift happens mid-quarter. Model vendors update weights without a semver bump. Prompt edits in one workflow leak context into another through shared templates. Evaluation confined to pre-launch is a snapshot in a medium that never stops moving. Quality has to be measured at every lifecycle stage — design through post-incident — or you will discover gaps only when users do.

Lifecycle-stage evaluation map#

Each stage asks a different question and catches different failure classes:

Skipping a stage creates a blind spot. Design without testable constraints produces golden sets that argue about prose instead of policies. Production without sampling misses corpus drift until tickets spike.

Design: evals start before code#

Evaluation during design is the cheapest time to decide what "good" means. For each job class, document:

• Must-do behaviors — cite specific sources, call required tools, output valid schema
• Must-not behaviors — answer outside scope, invent identifiers, execute unapproved tools
• Edge cases — ambiguous queries, conflicting documents, empty retrieval

These become case specifications before a single prompt is finalized. Product and compliance review boundary cases — not model outputs — and sign the spec. When engineering implements, they implement against labeled expectations, not against demo vibes.

Build: CI evals on every meaningful change#

Treat prompt, retrieval, tool, and orchestration changes like code changes — because they are behavior changes. Run affected golden subsets on every PR. Block merge when schema validity or faithfulness regresses beyond threshold on the touched job class.

Keep CI runs fast: subset by job class and change blast radius. A prompt edit in support triage should not rerun the entire legal summarization suite unless shared components changed. Tag cases with component ownership so runners select intelligently.

interface GoldenCase {
  id: string;
  jobClass: string;
  components: ("retrieval" | "generation" | "tools" | "orchestration")[];
  input: string;
  constraints: Record<string, unknown>;
}

type Component = GoldenCase["components"][number];

function isAffectedByChange(
  evalCase: GoldenCase,
  touched: Set<Component>,
  fallbackJobClass: string,
): boolean {
  if (touched.size === 0) {
    return evalCase.jobClass === fallbackJobClass;
  }
  return (
    (touched.has("retrieval") && evalCase.components.includes("retrieval")) ||
    (touched.has("generation") && evalCase.components.includes("generation")) ||
    (touched.has("tools") && evalCase.components.includes("tools")) ||
    (touched.has("orchestration") && evalCase.components.includes("orchestration"))
  );
}

const supportTriagePromptCase: GoldenCase = {
  id: "support-triage-042",
  jobClass: "support_triage",
  components: ["generation"],
  input: "Refund policy for delayed shipment",
  constraints: { must_refuse_billing_dispute: true },
};

const touched = inferComponents(changedFiles); // e.g. Set(["generation"])
const runOnPr = isAffectedByChange(
  supportTriagePromptCase,
  touched,
  inferJobClass(changedFiles),
);

Full nightly runs catch interaction effects CI subsets miss. PR gates catch obvious regressions before they compound.

Pre-launch: integrated system proof#

Staging evals run the full golden set against production-like configuration: real index snapshots (sanitized), actual model aliases, feature flags set as in launch. Add shadow traffic comparison when migrating models — same inputs, dual execution, diff scores and cost.

Pre-launch is also when you validate eval coverage itself. If a job class has fewer than thirty cases or zero refusal examples, you are not ready regardless of pass rate. Coverage review belongs in the launch checklist alongside load tests.

Production: evaluation never stops#

Production introduces inputs no lab saw: new document types, seasonal phrasing, adversarial users, tool outages mid-trajectory. Offline suites go stale. Online evaluation closes the loop:

• Sample traces daily — escalations, regenerations, random success slice
• Score faithfulness, tool success, schema validity on the sample
• Alert on rate shifts like error budget burn
• Monthly refresh golden sets from mined production cases

Production eval is not a replacement for observability. It consumes traces and produces trended quality metrics. Pair with token and latency dashboards so cost-quality tradeoffs stay visible.

Post-incident: evals as organizational memory#

After an AI incident — wrong answer accepted, policy bypass, cost runaway — the post-incident review should produce eval artifacts, not only a postmortem PDF:

1. Export trace IDs for failing requests
2. Add minimal repro cases to the golden set
3. Verify fix passes new and adjacent cases
4. Schedule replay in thirty days to catch regression

Incidents without new cases repeat. Teams forget why a prompt constraint exists until the same failure embarrasses them again.

Cadence#

Adjust frequency to traffic and risk. High-stakes job classes warrant stricter gates at every stage.

Summary#

AI evaluation is not a pre-launch checkbox. It belongs at design — where requirements become testable — at build — where CI catches regressions — at pre-launch — where the integrated system proves readiness — in production — where drift and novel inputs appear — and post-incident — where failures become permanent guards against recurrence. Lifecycle-spanning evaluation is how probabilistic systems earn the same operational discipline deterministic software takes for granted.