Evaluate ambient quality agents before trusting their findings

Coverage comes before a quality percentage

An observer reports zero findings after deployment. There are at least three plausible explanations: the application behaved well, the selected population missed the failure, or collection failed. A single green status cannot distinguish them. In this original measurement design, count eligible sessions, selected sessions, fetched sessions, successfully graded sessions, failed grading attempts, exclusions, and reviewed findings separately. Preserve the observation window and the event-time range. A job completion timestamp is not a description of the traffic it examined.

For an illustrative batch, 1,000 sessions are eligible, 200 selected, 180 fetched, and 160 successfully graded. Selection coverage is 20%; successful grading covers 80% of the selected set and 16% of the eligible population. The missing 40 selected sessions must retain their failure or exclusion reasons. Reporting '160 sessions processed' alone hides the selection and transport losses. A per-session quality estimate needs a sampling argument before it can describe the wider population.

A worked example separates precision from recall

Suppose a representative labeled evaluation set contains 200 sessions, including 60 genuine failures. The worker flags 40 sessions. Independent labels confirm that 30 flags are correct and 10 are false positives. The worker misses 30 failures, leaving 130 true negatives. Alert precision is 30 / 40 = 75%; failure recall is 30 / 60 = 50%. These are invented teaching numbers, not vendor results. Precision and recall use different denominators, as documented in scikit-learn's metric guidance.

If reviewers label only the 40 alerts, they can estimate precision for those reviewed alerts; they cannot calculate recall because the unflagged failures are unknown. For clustered output, report whether the unit is a session, finding, or cluster. Ten reviewed clusters are not ten reviewed sessions, and a large cluster does not multiply the number of independently verified failures.

Keep tuning cases out of the acceptance decision

Use a calibration partition to refine prompts, rubrics, and deterministic rules. Keep a locked acceptance partition for the release decision. Group related incident variants before splitting: a near-duplicate of yesterday's failure should not become today's apparently independent proof. Add a later time window and a different incident family when the application changes. Version the dataset, rubric, model, tool schema, source revision, and scoring code alongside the results.

Scikit-learn's leakage guidance explains why fitting transformations or selecting features with test data biases evaluation. Source: data leakage guidance. Applied to this proposed observer workflow, repeatedly rewriting a rubric after inspecting the acceptance cases turns that set into tuning data. Create a new acceptance set when that happens. Preserve reviewer disagreements as evidence of an ambiguous category; do not conceal them behind a single convenient label.

Judge evidence, diagnosis, and repairs separately

A candidate can identify a genuine bad outcome and still name the wrong cause. Review evidence validity first: does the event exist, does the revision match, and is the trace complete enough? Next assess the failure classification. Then assess the proposed causal explanation. Finally, test whether the candidate repair changes the independently measured outcome. A source citation is a traceability aid, not a causal experiment.

In the shipment example, a repair that always avoids saying 'booked' could eliminate unsupported completion language while leaving every replacement uncreated. Include both safety and task-success assertions. Compare baseline and candidate on the same controlled fixtures, then examine unaffected cases for regressions. A replay with mocked tool responses tests behavior under those responses; it does not establish how a live model and changing warehouse system will behave next week.

Move from shadow mode to bounded repair trials

Start in read-only shadow mode, where the observer writes findings for review and has no repair capability. Define acceptance thresholds from the cost of missed failures and false alerts in your own application. A medical workflow and an internal documentation helper should not inherit the same threshold merely because they use the same framework. Require minimum sample sizes and evidence-completeness expectations in addition to a percentage.

For an approved repair, use a limited canary with a control and a rollback decision owned outside the model. Google SRE's canary guidance emphasizes representative metrics, attributable changes, and enough traffic and time to support an assessment. Source: canary evaluation. In this original design, the observer supplies supporting findings while ordinary service metrics and business outcomes remain release gates. Pause on missing telemetry; an unobservable canary is not a passing canary.

Make the observer observable too

Track ingestion lag, investigation duration, fetch failures, grading failures, deduplication counts, quarantine volume, review backlog, and resource cost. Attach a run identifier and configuration revision to every metric. Alert on sustained missing evidence, not just rising finding counts. Budget limits and concurrency caps protect the observed application from an investigation worker that retries excessively. A kill switch should stop new work without erasing evidence already collected.

The incident playbook should answer who owns a broken collector, who resolves an ambiguous finding, and who can approve a repair. Test the pause and recovery path with a synthetic incident. A system is operationally understandable when an on-call engineer can explain what it examined, what it skipped, and what action it was allowed to take. 'The agent completed successfully' is too small a statement for that responsibility.

Sources and the evidence needed for a rollout decision

The linked metric, leakage, and canary references support the evaluation principles. All numerical examples, workflow gates, and operational recommendations here are original illustrations, not measured production results or Google service guarantees. The series establishes a method for making claims checkable. Your rollout decision still needs your application's labeled cases, tested access boundaries, and observed operating data.