Reference library¶
Coding-evaluation methodology updates — checked 7 September 2026¶
- OpenAI: Separating signal from noise in coding evaluations — July 2026 benchmark-quality audit and changed recommendation; use for task/test validity and independent review, not a blanket replacement-benchmark endorsement.
- Anthropic: Quantifying infrastructure noise in agentic coding evals — resource allocation and enforcement as experimental variables.
- Anthropic: Demystifying evals for AI agents — outcome tests, regression protection and complementary trajectory review. The local coding study implements only a bounded authored-patch exercise.
The primer treats references as part of the evaluation system. A source should tell us more than “where an idea came from.” It should identify the claim it supports, the artifact it changes, how fresh it is, and what would make us revisit it.
Primary-source rule¶
Public claims are re-authored from stable primary evidence wherever possible: official documentation, engineering reports, standards, papers, and source repositories. Research reports and private study notes help us find gaps, but they are not copied into the public primer and do not become evidence by themselves.
For every material claim we record:
- the exact claim and its scope;
- the primary source and date checked;
- the chapter and CX artifact it informs;
- whether the statement is documented fact, experimental result, proposal, or inference;
- the owner and review date when freshness matters.
Claim ledger¶
The maintained claim ledger will use this shape:
| Field | Purpose |
|---|---|
| Claim ID and wording | Prevents a citation from drifting to support a different statement |
| Evidence type | Separates official behavior, empirical evidence, standards, and local design choices |
| Source and checked date | Makes provenance and freshness visible |
| CX artifact | Connects reading to code, data, grader, policy, or experiment |
| Confidence and caveat | Records what the source does not establish |
| Revalidation trigger | Defines when a model, SDK, API, standard, or practice must be checked again |
Seed reference spine¶
This is the starting collection, not the finished bibliography.
| Area | Primary reference | What it informs here |
|---|---|---|
| OpenAI agent runtime | OpenAI Agents SDK for Python and Agents SDK quickstart | Agent/runner structure, typed tools, traces, and the optional model-backed runtime |
| OpenAI agent evaluation | Agent evals | Reproducible agent-quality measurement and trace-oriented evaluation |
| Anthropic eval design | Demystifying evals for AI agents | Tasks, trials, graders, transcripts, outcomes, and evaluation workflow |
| Anthropic agent design | Building effective agents | Choosing workflow complexity and keeping orchestration understandable |
| Long-running agent harnesses | Effective harnesses for long-running agents | Checkpoints, progress preservation, restart/resume evaluation, and durable-state limits |
| Multi-agent production architecture | How we built our multi-agent research system | Delegation, coordination, shared context, parallel work, synthesis, and matched-budget evaluation |
| Skill evaluation | OpenAI skill evals | Explicit, implicit, competing, stale, and incorrect activation; selection versus execution errors |
| Tool-agent benchmark | τ-bench and its reference implementation | Stateful tool interaction, policy adherence, and end-state evaluation |
| Multi-turn benchmark | τ²-bench | Multi-turn, dual-control interaction and stateful evaluation |
| Knowledge and voice agent benchmarking | Sierra τ³ and τ-Voice | Knowledge-to-action ablations, oracle-context limits, audio timelines, interruptions, and matched text/voice tasks |
| Dynamic broad behavioral auditing | Anthropic Petri and its 2026 stewardship update | Simulated users/tools, auditor/judge roles, broad exploration, and lifecycle verification |
| Targeted behavioral suite generation | Anthropic Bloom | Behavior-to-scenario generation, diverse rollouts, judgment, seeds, and validation limits |
| Adaptive multi-turn application tests | Giskard multi-turn testing | Dynamic simulated users, shared traces, stateful goals, and simulator caveats |
| LLM judge foundations | Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena | Judge agreement, bias, limitations, and the need for calibration |
| Agent benchmark breadth | AgentBench | Evaluating agents across interactive environments rather than text alone |
| Trace interoperability | OpenTelemetry generative AI semantic conventions | Provider-neutral trace naming and observability boundaries |
| CI enforcement | GitHub protected branches | Making an eval job a required status check |
| Progressive delivery | Google SRE: Canarying releases | Promotion, hold, and rollback decisions using live evidence |
How references will grow¶
New sources enter through a research question or a build decision. They are mapped to one of the nineteen working questions: evaluation units, dataset roles, label hygiene, repeatability, release vectors, offline-to-live validity, harness effects, provider boundaries, evaluator evolution, retrieval, incident promotion, rubric quality, red-teaming, operational bounds, CX outcome definitions, trace localization, multi-turn failure, and overfitting.
Research spine¶
The larger study and R/Q collection has been normalized into nineteen public questions. The private question bank remains private; each public answer will be written afresh, supported by primary evidence, and proved with a CX artifact.
| ID | Question the primer must answer | CX proof |
|---|---|---|
| RQ-01 | What is the unit under evaluation? | Grade one run at step, trajectory, conversation, and outcome level |
| RQ-02 | Why do capability, optimisation, regression, adversarial, calibration, sealed, and production-shadow datasets differ? | Versioned manifests, visibility rules, and promotion history |
| RQ-03 | Which facts can code establish, and which need people or calibrated models? | Evaluator-routing table plus known-good and known-bad tests |
| RQ-04 | How do we prevent hidden labels from reaching the agent, simulator, or judge? | Separate agent input and evaluator-only oracle, with leakage tests |
| RQ-05 | How many stochastic trials are enough? | Repeat policy, reliability metrics, and confidence bounds |
| RQ-06 | How does an evidence vector become block, constrain, canary, expand, or rollback? | Versioned policy and reconstructable decision |
| RQ-07 | Do offline evals predict production behavior? | Offline-to-canary predictive-validity report |
| RQ-08 | How much does the harness alter the measured result? | Controlled runtime and resource-limit ablation |
| RQ-09 | What must the product own, and what can a platform provide? | Provider-neutral kernel exercised through two adapters |
| RQ-10 | How does an evaluator change without silently rewriting history? | Shadow comparison, calibration report, and evaluator release record |
| RQ-11 | How do retrieval and answer generation fail independently? | Retrieval-versus-generation diagnostic matrix |
| RQ-12 | How does a production failure become durable regression coverage? | Incident-to-case receipt and coverage-growth metric |
| RQ-13 | What makes a rubric observable and discriminating? | Boundary examples, disagreement review, and rubric tests |
| RQ-14 | How do safety evals test the whole system? | Threat-linked cases for injection, authorization, privacy, unsafe tools, and escalation |
| RQ-15 | How do latency, cost, retries, and tool errors become non-compensable constraints? | Tail-latency, cost-per-success, and gate evidence |
| RQ-16 | How do containment, deflection, verified resolution, adoption, and business value differ? | Explicit denominators and quality-adjusted CX outcomes |
| RQ-17 | How do traces localize the failure and critical-path delay? | Failure taxonomy, parser, and component attribution |
| RQ-18 | What fails only across a session? | Multi-turn, memory, commitment, and perturbation cases |
| RQ-19 | How do criteria, golden cases, prompts, and fixes interact without overfitting? | Criteria-before-prompt experiment with held-out evidence |
A source remains only if it changes the explanation, implementation, experiment, or decision. The library is curated for depth and auditability, not link volume.
Expanded primary-source map¶
Measurement, human evaluation, and judges¶
| Topic | Primary source | Book use |
|---|---|---|
| Holistic multi-metric evaluation | HELM | Scenarios, desiderata, transparency, and limits of one-number evaluation |
| Human pairwise preference | Chatbot Arena | Pairwise design, crowdsourced preference, and leaderboard interpretation |
| LLM-judge behavior | MT-Bench and Chatbot Arena judge study | Position, verbosity, self-preference, and human comparison |
| Rubric-guided model evaluation | G-Eval | Model-based evaluator design and human correlation claims |
| Open rubric evaluator | Prometheus | Fine-grained rubric-based grading |
| Selective judge escalation | Trust or Escalate | Calibration sets, abstention, coverage, and human escalation |
| Probability calibration | On Calibration of Modern Neural Networks | Reliability diagrams, temperature scaling, and calibration error |
| Generative uncertainty | Semantic Uncertainty | Meaning-aware uncertainty across generated answers |
| Extreme-tail reliability | Measuring Five-Nines Reliability | CEM importance sampling, proposal-support assumptions, estimator efficiency, and the research-to-production boundary |
| Adaptive/IRT evaluation | Computerized adaptive testing for LLM medical benchmarking and Can We Trust Item Response Theory for AI Evaluation? | Cost reduction, calibrated item banks, rank stability, population-regime failures, and non-adaptive safety cores |
| Evaluator meta-evaluation | AgentRewardBench | Expert-grounded comparison of rule and LLM evaluators for agent trajectories |
| Corrected judge reporting | How to Correctly Report LLM-as-a-Judge Evaluations and No Free Labels | Noisy-diagnostic correction, calibration uncertainty, reference quality, and shift assumptions |
Behavioral testing, safety, fairness, and alignment¶
| Topic | Primary source | Book use |
|---|---|---|
| Behavioral test design | CheckList | Capability, invariance, and directional-expectation tests |
| Automated red teaming | HarmBench | Standardized behavior and attack evaluation |
| Jailbreak reproducibility | JailbreakBench | Threat, attack, defense, and evaluator separation |
| Over-refusal | XSTest | Benign near-neighbors and exaggerated safety behavior |
| Bias in ambiguous QA | BBQ | Ambiguous/disambiguated bias cases and benchmark limits |
| Stereotype measurement | StereoSet | Language-model stereotype evaluation |
| Toxic degeneration | RealToxicityPrompts | Naturally occurring prompts and classifier-dependent toxicity measurement |
| Preference-based instruction following | InstructGPT | Human demonstrations, preference data, reward models, and policy evaluation |
| Constitutional alignment | Constitutional AI | Rule-guided feedback and independent safety evaluation |
| Reward overoptimization | Scaling Laws for Reward Model Overoptimization | Proxy optimization and Goodhart-style failure |
| Hidden-objective auditing | Auditing language models for hidden objectives | Blind audit games, model organisms, mixed audit methods, and transfer limits |
| Chain-of-thought monitorability | OpenAI monitorability evaluations and internal-workload monitoring disclosure | Two-sided monitor evaluation, operational use, fragile observability, and defense-in-depth limits |
Interpretability and explanation evaluation¶
| Topic | Primary source | Book use |
|---|---|---|
| Faithfulness versus plausibility | Jacovi and Goldberg — Towards Faithfully Interpretable NLP Systems | Explicit definitions, graded faithfulness, and causal-evaluation discipline |
| Attribution sanity checks | Adebayo et al. — Sanity Checks for Saliency Maps | Model/data randomization controls and protection against visually persuasive false explanations |
| Attribution-graph evaluation | Anthropic — Circuit Tracing methods | Interpretability, intervention validation, sufficiency/completeness, graph scope, and limitations |
Factuality, retrieval, research, and agents¶
| Topic | Primary source | Book use |
|---|---|---|
| Truthfulness | TruthfulQA | Misconception-focused truth evaluation and scope limits |
| Atomic factual precision | FActScore | Claim decomposition and evidence support |
| RAG evaluation | RAGAS | Retrieval/generation dimensions and automated-proxy caveats |
| General assistant agents | GAIA | Reasoning, tools, browsing, multimodality, and end-to-end outcome |
| Browsing agents | BrowseComp | Obscure fact finding, automatic verification, and narrow-construct caution |
| Benchmark evaluation awareness | Anthropic's BrowseComp investigation | Task recognition, leaked-answer retrieval, integrity investigation, and score caveats |
| Long-form research safety | Deep Research system card | Prompt injection, factuality, safety, and long-output adaptation |
| Stateful policy/tool agents | τ-bench | Tools, policy, environment state, and outcomes |
| Multi-turn dual-control agents | τ²-bench | Stateful user-agent interaction and session evaluation |
| Interactive agent breadth | AgentBench | Multiple agent environments and scaffolding effects |
| Factuality suite by evidence mode | Google DeepMind FACTS | Parametric, search, grounding, and visual factuality as distinct constructs |
| Repository coding agents | SWE-bench | Real repository tasks, executable outcomes, and environment validity |
| Long-term conversational memory | LongMemEval | Multi-session extraction, updates, temporal reasoning, abstention, and benchmark-to-product limits |
| Long-context retrieval without lexical cues | NoLiMa | Latent-association retrieval under long context and stress-test boundaries |
| Personalization field validity | The Inadequacy of Offline LLM Evaluations | Real-user evidence for reset-versus-persist evaluation and the offline-to-field gap |
Benchmarks and reproducibility¶
| Benchmark or method | Primary source | Book use |
|---|---|---|
| Broad academic knowledge | MMLU | Narrow construct versus application inference |
| Diverse capability collection | BIG-bench | Task breadth, aggregation, and saturation |
| Graduate-level expert QA | GPQA | Expert-domain question construction and limits |
| Mathematical word problems | GSM8K | Multi-step answer accuracy and reasoning caveats |
| Executable code correctness | HumanEval | Test execution and pass@k |
| Frontier academic questions | Humanity’s Last Exam | Hard-question capability and expert-verification boundaries |
| Reproducible evaluation practice | Lessons from the Trenches | Prompt, implementation, and reporting sensitivity |
| Evaluator execution boundary | Inspect AI security guidance and PaperBench scoring design | Model-action sandbox limits, trusted eval code, and fresh scoring state |
Production, governance, and operations¶
| Topic | Primary source | Book use |
|---|---|---|
| Deployment-like replay | OpenAI deployment simulation | Recent production-like context, pre-release failure mining, and forecast validation |
| Operational automated auditing | Anthropic Petri operational update | Named pre-deployment/model-assessment use, external adoption, and remaining realism limits |
| Realtime audio deployment | GPT-4o system card and generally available Realtime API | Audio-specific pre-deployment evals, live safeguards, and the incomplete end-to-end quality boundary |
| Evaluation-system validity | OpenAI trustworthy third-party evaluations | Environment, harness, contamination, budget, and claim disclosure |
| Model failover | Sierra model failover | Prevalidated alternatives, failure injection, switching boundaries, and fallback-path evaluation |
| Online coding-agent evaluation | CursorBench | Online outcomes, human workload, and failures missed by offline correctness graders |
| Benchmark integrity investigation | Cursor reward hacking investigation | Permitted information access, known-fix contamination, and score-integrity controls |
| Deep-agent evaluation operations | How LangChain builds evals for Deep Agents | Separating software health from model capability, artifacts, reruns, and operational eval service concerns |
| Trace semantics | OpenTelemetry GenAI conventions | Portable telemetry and sensitive-field boundaries |
| Canary control | Google SRE Workbook: Canarying releases | Control-relative rollout, analysis, and rollback |
| AI risk-management profile | NIST AI 600-1 Generative AI Profile | Risk-to-measurement traceability and lifecycle controls |
| AI management system | ISO/IEC 42001 overview | Organizational management-system context |
| European AI regulation | Official EU AI Act portal | Starting point for jurisdiction-specific governance review; not legal advice |
Open-source implementation map¶
Official repositories are implementation evidence, not proof that a default metric fits this product:
- Promptfoo
- DeepEval
- Inspect AI
- LM Evaluation Harness
- LightEval
- HELM
- Phoenix
- Langfuse
- Opik
- Ragas
- Giskard
- Label Studio
Source-use rules¶
- Benchmark scores from old papers illustrate protocols, not current model rankings.
- Course duration, access, APIs, licenses, and platform lifecycle are dated claims and must be reverified.
- Vendor case studies can motivate a pattern but do not establish universal effectiveness.
- Secondary research identifies topics; public claims should link to primary evidence.
- A citation supports only the nearby scoped claim, not an entire chapter.
- Local synthetic results are labeled as synthetic and illustrative.
- Regulatory mappings require qualified legal and compliance review for the actual jurisdiction and use case.