Prompt Eval vs Production Monitoring: Use Both Honestly
Pre-ship eval and production monitoring answer different questions. Golden cases catch known failure modes; traces catch the unknown.
Version fields exist so you can compare notes when models or prompts change underneath the same feature flag.
Do not paste secrets into prompts. Treat eval inputs like production data with short retention.
CI plugins and SSO are not assumed unless this build ships them — marketing copy must match code.
Refuse pass-rate guarantees. Models drift; tools that claim never-fail evals are selling theater.
Pre-ship eval answers "did we break what we knew?"
An eval set is a curated list of inputs with expected behavior. It encodes the failure modes you have already seen: a malformed JSON, a refused safety case, an injection attempt. Running it before a ship confirms those specific cases still pass.
Eval is deterministic and fast. It is also blind to anything not in the set. A green eval means "the known cases held," not "the feature is correct."
Production monitoring answers "what are we missing?"
Monitoring reads live traffic — latency, error rates, output scores, user reports. It catches the case nobody wrote down: a new phrasing that tips the model into a loop, a downstream API that changed its schema, a region where the model underperforms.
Monitoring is noisy and retrospective. It tells you something broke after users felt it. That is why it pairs with, rather than replaces, eval.
Use version fields or lose the comparison
Record the model version, prompt version, and eval version on every run. When outputs shift between Tuesday and Thursday, those three fields tell you whether the model changed, your prompt changed, or the eval changed.
Without versioning, a regression looks like "the model got worse" and the fix becomes a guess. With it, the regression points to a specific commit.
Handle eval data like production data
Eval inputs often contain the same sensitive content as real requests — names, code, customer text. Do not paste secrets into prompts to build a test case, and store eval artifacts with the same retention rules you apply to production logs.
Short retention also keeps the eval set honest. Old cases rot; a year-old "expected output" may describe a product that no longer exists.
The 2026 threat model changed the eval surface
The OWASP GenAI LLM Top 10 kept Prompt Injection at LLM01 and elevated Excessive Agency to LLM03 as agents that call tools spread. That means eval sets now need agent-permission cases — what the model can do, not just what it can say — and a human checkpoint before any high-impact action. A pre-ship eval that only checks output text under-tests the risk that actually rose fastest.
Reading the two together
| Situation | What it means |
|---|---|
| Eval green, monitoring red | Unknown failure in live traffic; write a new case |
| Eval red, monitoring quiet | Known case broke; block the ship |
| Both green, users unhappy | Success metric missing from both systems |
What to claim, and what not to
Claim that known failure modes are covered by an eval set with a version history. Claim that live traffic is observed. Do not claim a pass rate proves the model is safe, and do not claim monitoring catches everything — it catches what you instrument.
CI plugins and SSO are real only if this build ships them. Marketing copy that lists features the code does not contain is the fastest way to lose the trust eval and monitoring exist to build.
A version-field example
An eval run records three versions: model=gpt-4o-2024-08-06, prompt=v3, eval=v2. Two weeks later the same input returns different output. Comparing the run records shows the prompt moved to v4 — the regression tracks to that commit, not to the model. Without the fields, the team blames "the model" and re-rolls a prompt that was fine.
Further reading
- OWASP GenAI LLM Top 10 — LLM01 Prompt Injection and the 2026 list.
- schema.org/FAQPage: the structured-data type this page publishes for its FAQ.
FAQ
Does HOLD block deploys automatically?
No. It is decision-support for humans.
Is OWASP coverage complete?
It highlights common risks; it is not a full assurance program.
Honesty note: educational decision-support only. No guarantee of rankings, compliance, or ship safety.