Every prior page made the system good. This one is about getting it into the customer's production and keeping it healthy there. That's the operational half of the demo-to-production gap, and the phase where a working prototype most often dies. For an AI system, deployment has a twist that trips up even strong infrastructure engineers: the thing you're shipping can get worse without a single line of code changing.
Why this is the job
The FDE ships onto the customer's messy real data, inside their release process, under their uptime expectations. A demo that worked on a clean sample now meets the full distribution of real inputs. Two things make AI deployment its own discipline. First, the behavior-defining artifacts aren't just code: a prompt edit or a model upgrade changes outputs with no diff in your service. Second, "correct" is probabilistic, so your release gate can't be a green unit-test suite; it has to be an eval score against a representative set. An engineer who deploys an LLM app like a stateless web service will ship a silent regression and not know until the customer does.
Before reading on: your service code is untouched for a month, but users say answers have gotten worse. Nothing was "deployed." What changed, and what should have caught it?
Something in the non-code artifacts changed: the model provider updated the model, the corpus was re-indexed, or a prompt was tweaked upstream. What should have caught it is a scheduled eval that runs even when code doesn't, because in an AI system the inputs to behavior extend beyond your repository.
A documented case of silent drift
This page's premise, that a system can regress with no code change, has a real receipt, and reading it correctly is half the lesson. In 2023, researchers measured the same GPT-3.5 and GPT-4 endpoints months apart and found the behavior of the same service had moved (How Is ChatGPT's Behavior Changing over Time?, Chen, Zaharia & Zou, later published in Harvard Data Science Review). The paper's first version reported GPT-4's accuracy at labeling prime numbers falling from 97.6% in March to 2.4% in June, and that figure traveled the internet as proof the model had gotten worse.
The sharper reading came next. Arvind Narayanan and Sayash Kapoor pointed out that every number in that task was actually prime, so a June model that had simply changed its habit, defaulting to "not prime" and no longer writing out the step-by-step working its March answers contained (the study clocked the average answer collapsing from 638.3 characters to 3.9), would score near zero without having lost any arithmetic ability. The behavior had drifted; a capability loss was never shown. The authors then revised the study around a balanced set of primes and composites, where GPT-4 moved from 84.0% to 51.1%: a real regression, and a much smaller one than the headline.
Two things follow for an FDE. A model under a frozen prompt can shift beneath you, which is exactly why the scheduled eval that runs with no code change earns its place in the release gate above. And when that eval does flash red, the prime-number episode is the caution worth remembering: build the set so it can tell a behavior change from a capability loss, because the fix for one is rarely the fix for the other.
The moves
- Version everything that affects output. The prompt, the model identifier, the retrieval index, and the eval set and baseline are all release artifacts. Pin them, log which versions produced which outputs, and you can answer "what changed?" and roll back to a known-good combination.
- Roll out in stages. Pilot with a few real users on real data, then a limited cohort, then full. Each stage surfaces failures the last set didn't, because real usage is broader than any test. The Morgan Stanley engagement gated on evals before firm-wide rollout for exactly this reason.
- Gate the release on the eval. The regression suite is your CI: a change ships only if the eval holds against the committed baseline. This is the mechanism that turns "we improved the prompt" into a claim the baseline can confirm.
- Keep a rollback and watch it after. Deployment isn't the finish line; pair every release with a fast rollback and the observability to catch quality degradation in production, which uptime alone won't show.
The release checklist for a volatile stack
Before each rollout, re-audit the parts that age: confirm the pinned model is still supported and the index still reflects the corpus, then re-run the eval against a recent baseline. Freshness is part of the release gate.
The release manifest
The version story is abstract until you write it down as a file. Below is what a release of the research-library assistant from the observability incident pins: one manifest per release, checked in beside the service. (The manifest that follows is illustrative. The versions, dates, and scores are invented; the shape is what to study.)
# release-manifest.yaml — the versioned artifacts of one release (illustrative) release: 2026-06-14-a service_code: git 4f1a9c2 # the ordinary commit — often unchanged release to release prompt: version: v14 # the prompt template, versioned on its own model: id: frontier-large-2026-05 # provider model identifier; providers deprecate on a schedule retrieval_index: snapshot: idx-2026-05-31 # the embedded corpus, pinned as a snapshot built: 2026-05-31 # the build date that the stale-index incident turned on eval_baseline: suite: research-library-v3 # the fixed question set the release is gated against must_clear: 0.90 # release ships only if the run holds at or above this rollback_to: 2026-05-20-b # the previous known-good manifest, ready to restore
This manifest is the diff a reviewer reads: five behavior-defining lines separated from the service code that often did not change. It is also the rollback target: restoring the release means restoring the prompt, model, and index together. That catches the lie the page opens on: service_code can stay fixed while the model identifier or index snapshot moves underneath it, exactly the shape of the stale-index regression.
A staged rollout, gated at every step
The manifest says what a release is; the rollout says how it earns its way to everyone. Each stage runs the pinned eval suite and compares the score to the baseline the manifest committed to. A pass widens the audience; a regression halts the release and restores the rollback target. Here is a rollout of the research-library assistant's 2026-06-14-a release, model bumped to frontier-large-2026-05, read top to bottom. (The trace is illustrative. The cohorts, scores, and timings are invented.)
release 2026-06-14-a · baseline research-library-v3 @ 0.90 (illustrative)
[pilot] 8 advisors, real questions, 2 days (t=0)
handpicked users on live data — the first contact with reality
[gate] eval research-library-v3 after pilot
score 0.93 vs baseline 0.90 → PASS
widen: pilot cleared, open to the limited cohort
[limited] 120 advisors, one desk, 3 days
a broader slice — questions the pilot never asked
[gate] eval research-library-v3 after limited cohort
score 0.86 vs baseline 0.90 → FAIL (−0.04)
the new model regressed on the fixed suite; below the line
[halt] rollout stops here — full audience never reached
restore rollback_to: 2026-05-20-b
prompt, model, and index revert together to the last known-good manifest
cost of the regression: one desk for part of one day, no widerThe eval score is the gate a probabilistic system uses where a deterministic one would read a green test suite. It runs at every stage because failures cost more as the audience widens: the pilot's 0.93 would have passed, but the limited cohort's 0.86 stopped the release before every advisor inherited the regression.
Bad / Good / Great — "how do you deploy and keep it running?"
Bad — "we deploy the service and monitor uptime." You treated it like a normal web app. Uptime says nothing about whether the answers are still good, and you've versioned none of the artifacts that actually drive behavior. The first silent regression is invisible to you.
Good — "staged rollout, and we test quality before launch." Real deployment hygiene: a pre-launch quality check and a phased release are solid. The gap: a one-time pre-launch test doesn't catch the model or corpus drifting after launch, and there's no versioning story for the non-code artifacts.
Great — "everything that shapes output is a versioned artifact — prompt, model, index, eval baseline — I roll out pilot to limited to full, gate each release on the eval holding against baseline, keep a rollback to a known-good version set, and run the eval on a schedule so a change with no code diff still gets caught. Deployment is a continuous gate rather than a launch event." You made behavior versioned, made the eval the gate, and designed for the silent-regression failure.
What to carry into the interview
When a design reaches "and then we ship it," don't stop at rollout. Say what you'd version (prompt, model, index, baseline, not only code), how you'd stage the rollout on real data, and that your release gate is the eval, run on a schedule, with a rollback behind it. Treating an AI deployment as a continuous, eval-gated process, one that keeps running long after the code first ships, is the operational spine every real engagement runs on.
Related: Evaluations (the release gate), Observability (catch the regression), and Real Deployments (deployment on real, messy data).
Next: Customer Outcomes — Overview — the production toolkit is complete; now the customer craft that decides what you build with it.NextOverview