Skip to content

// Free resource

Is your LLM feature ready for production?

Seven categories, 20+ checkpoints. Score your feature in a few minutes — the same bar we hold our own work to: reliability is measured, not assumed.

// Score

Score your feature

Not yet

This would be a risky thing to put in front of users.

0 / 22 checkpoints

Readiness score 0 percent — Not yet. 0 of 22 checkpoints complete.

// The criteria

What each check means

The model is one part of a production-ready feature. These are the seven pillars of the system around it — score each below.

  • 01Evaluation· 4
  • 02Grounding & accuracy· 3
  • 03Guardrails· 3
  • 04Observability· 3
  • 05Cost control· 3
  • 06Security· 3
  • 07Ownership· 3

Evaluation

  • A labelled evaluation set exists for the feature

    Why: Without a fixed eval set you can't tell a real improvement from a lucky prompt. How: Point to the dataset + the metric it scores.

  • Evals run automatically on every prompt/model change

    Why: Manual spot-checks miss the regressions that matter; a gate catches them before ship. How: Show the eval step in CI and a change it has blocked.

  • Regressions are tracked over time, not just pass/fail

    Why: A slow quality drift is invisible without a trend. How: Show a score history per release.

  • A human reviews a sample of real outputs regularly

    Why: Automated metrics miss failure modes you didn't think to measure. How: Show the review cadence + what it has caught.

Grounding & accuracy

  • Answers are grounded in retrieved sources, not free generation

    Why: Ungrounded output is confident and wrong exactly when it matters. How: Show that each answer maps to a retrieved passage.

  • Every claim is traceable to its source

    Why: Users (and auditors) need to verify, not trust. How: Show citations rendered with the answer.

  • The system refuses when it has no supporting source

    Why: A plausible guess is worse than an honest 'I don't know'. How: Trigger a no-source query and confirm it declines.

Guardrails

  • Inputs and outputs are validated against a schema

    Why: Unvalidated model output corrupts everything downstream of it. How: Show the schema + what happens on a validation failure.

  • There's a safe fallback when a call fails or times out

    Why: A single slow provider call shouldn't take the feature down. How: Kill a dependency and confirm graceful degradation.

  • Abuse and rate limits are in place

    Why: An open LLM endpoint is a cost + safety liability. How: Show per-user limits + abuse handling.

Observability

  • Every request is traceable end-to-end

    Why: A wrong answer you can't trace is a wrong answer you can't fix. How: Open a trace from input to final output.

  • Latency, error rate, and quality are monitored per stage

    Why: Aggregate health hides which stage is actually failing. How: Show the per-stage dashboard.

  • Alerts fire on quality/latency/cost regressions

    Why: You want to hear it from a page, not a customer. How: Show a configured alert + a time it fired.

Cost control

  • There's a spend budget with hard limits

    Why: LLM cost scales with traffic and can surprise you overnight. How: Show the budget + what happens at the cap.

  • Caching cuts repeat calls

    Why: Paying twice for the same answer is avoidable waste. How: Show the cache hit rate.

  • The model is right-sized for the task

    Why: The biggest model is rarely the best cost/quality trade. How: Show the model choice justified by an eval.

Security

  • Prompt-injection is defended against

    Why: Untrusted input can hijack a naive agent's instructions. How: Show the mitigation + a blocked injection attempt.

  • Secrets and PII never leak into prompts or logs

    Why: Prompts and traces are a new place for data to escape. How: Show redaction in prompts + logs.

  • Model output is sanitized before it's rendered or executed

    Why: Treating model output as trusted HTML/SQL is an injection vector. How: Show output sanitization at the boundary.

Ownership

  • There's a runbook for when it misbehaves

    Why: The on-call engineer shouldn't be reverse-engineering it at 2am. How: Show the runbook + escalation path.

  • You can roll back a bad prompt/model instantly

    Why: A bad change should be a one-click revert, not a redeploy. How: Show the rollback mechanism.

  • The system is documented for the team that owns it

    Why: A system only its author understands is a liability. How: Show the handover docs.

// FAQ

Questions

Not the model — the system around it: evals that gate every change, answers grounded in real sources, guardrails and safe fallbacks, observability, cost controls, security, and a clear owner. This checklist scores all seven.

It's the share of checkpoints you can honestly tick across the seven categories — 80%+ is production-ready, 50–79% means close the gaps before you scale, and below 50% is risky to ship.

Engineering and product teams putting an LLM feature in front of real users — to pressure-test it before launch, or to audit one that's already live.

// Let's build

Scored low — or want a second opinion?

We run this same audit on real systems. If you want an outside read on where your AI feature stands, let's talk.