Chapter DEval gates in codePage 4 of 8

Eval gates in code

Validate outputs and schemas

Eval gates in code is production work only when one frozen failure can be reproduced, one measurable gate can stop a release, and one operator can safely reverse it.

~14 minValidation

Before you start

Why this matters

Read this incident aloud: a prompt pull request must answer ten frozen support questions without inventing refund policy. In two minutes, write the earliest deterministic check that should fail, the telemetry signal you would inspect, and the action that must not happen automatically. Compare your answer with this chapter's boundary: CI may call only the staging model and read a versioned, non-production fixture set.

1Learn the idea

Read

Test behavior and evaluate quality

Testing this system requires more than checking that JSON parses. Build a small matrix with one normal case, one boundary case, the known failure, and one adversarial case. Freeze randomness and time. Stub the provider with recorded semantic outcomes rather than brittle prose snapshots. Then assert the decision, prohibited behavior, emitted metric, and absence of sensitive fields. The key behavioral assertion for this topic is assert "30 days" in answer and "no returns" not in answer.

Evaluate at two resolutions. First, case-level reasons must tell a developer exactly which expectation failed. Second, aggregate weighted pass rate must meet 0.90 overall and 1.00 for critical policy cases on the frozen set and on important slices. A global pass can hide a severe intent, carrier, release, or customer workflow. Report numerator and denominator beside every rate; 0 failures over two cases is not strong evidence.

Before accepting a metric, attack it. If a shorter refusal raises a keyword score while usefulness collapses, the metric is being gamed. If lower cost excludes retries, the denominator is wrong. If latency ignores timeouts, the sample is censored. Compare automated scores with a small blinded human review and record disagreements as future fixtures.

For validation, execute the full matrix and print a machine-readable report plus a short developer summary. Exit nonzero on a violated critical gate; do not round a failing value into a pass.

Read

Focused implementation artifact

import pytest

CASES = [
    pytest.param({"id":"refund-window","question":"Can I return headphones after 20 days?","must_include":["30 days","receipt"],"must_not_include":["no returns"],"severity":"critical"}, id="known-boundary"),
]

@pytest.mark.parametrize("case", CASES)
def test_behavioral_gate(case):
    answer = staging_agent(case["question"], request_id=trace_id)
    assert "30 days" in answer and "no returns" not in answer

def test_release_gate(report):
    assert report.sample_count >= 10
    assert report.critical_failures == 0

Read

Build the evaluation report

Expand the parameterized test into four named fixtures: benign control, threshold boundary, known regression, and adversarial misuse. For every row, assert the decision and at least one negative fact, such as no leak, no unauthorized action, no duplicate write, or no candidate promotion. Provider prose can vary; policy outcomes and required evidence cannot.

Aggregate the case results into weighted pass rate and preserve numerator, denominator, critical failures, and slice keys. Apply 0.90 overall and 1.00 for critical policy cases exactly. Compare baseline and candidate on the same fixtures, then review disagreements where the automated score and a blinded human label diverge. Those disagreements are useful data, not noise to discard.

The regression named the new prompt omits the 30-day refund window while producing fluent prose must fail before the fix and pass after it. Verify eval_gate_pass_rate is emitted for both outcomes and that the failing report points to fixture IDs and trace IDs without embedding sensitive content. A failed gate leads operators to block the merge and attach the failing case IDs to the check run.

Checking tutor…

Continue learning · glossary & guides