Reference architecture

LLM Evaluation Control Plane

An evaluation architecture connecting capability claims, versioned datasets, deterministic checks, validated graders, release gates, and production outcomes.

18 minVerified 2026-07-214 primary sources
A governed production AI reference architecture with observable, secured service boundaries.

Architecture

An evaluation architecture connecting capability claims, versioned datasets, deterministic checks, validated graders, release gates, and production outcomes.

Intent and policy
Validated request
Controlled execution
Independent verification
Telemetry and response
Conceptual teaching model synthesized from:Evaluation Best PracticesDemystifying Evals for AI AgentsArtificial Intelligence Risk Management FrameworkOpenTelemetry Generative AI Semantic Conventions

The architecture separates intent, policy, state, execution, evidence, and response. Each boundary has one accountable owner and an observable contract. Probabilistic components may propose or classify; deterministic software owns permissions, budgets, state transitions, and release conditions.

Architecture claim
Representative test
Production signal
Decision gate
Review or rollback
Conceptual teaching model synthesized from:Evaluation Best PracticesDemystifying Evals for AI AgentsArtificial Intelligence Risk Management FrameworkOpenTelemetry Generative AI Semantic Conventions

Decisions

| Decision | Required evidence | Review trigger | |---|---|---| | Turn every evaluation into a test of a named product or risk claim. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Prefer deterministic state checks before subjective grading. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Version datasets, prompts, models, tools, policies, and graders. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Use segmented release gates and preserve disagreements. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change |

Alternatives and trade-offs

A centralized control plane simplifies policy and evidence collection but can become a latency and availability dependency. Distributed enforcement reduces central bottlenecks but requires consistent identity, versions, and audit semantics. Prefer the smallest boundary that can enforce the invariant and prove the outcome.

Failure modes

  • One average score hides severe cohorts.
  • The grader changes without a new baseline.
  • Synthetic examples replace representative tasks.
  • Offline quality has no connection to production outcomes.

Operational checklist

  • [ ] Claims map to metrics and representative cases.
  • [ ] Critical failures have severity gates rather than averages.
  • [ ] Judge calibration and disagreement are measured.
  • [ ] Paired evaluations compare release candidates.
  • [ ] Production drift reopens the evaluation decision.

Connected practice

Sources

  • openai-evals
  • anthropic-agent-evals
  • nist-ai-rmf
  • otel-genai