Retrieval and evidence
Measure relevant evidence recall, citation correctness, permission filtering, and response to missing sources.
A model benchmark is not an acceptance test. Production readiness must be evaluated across evidence retrieval, output quality, tool behaviour, workflow reliability, human control, and operating outcomes.
By Onyx Devs Lab · Published · Updated
Each layer answers a different production question.
Measure relevant evidence recall, citation correctness, permission filtering, and response to missing sources.
Use domain rubrics for factuality, completeness, policy compliance, calibration, and appropriate refusal.
Test argument construction, authorisation, idempotency, retries, post-action verification, latency, and cost.
Offline scores are necessary but insufficient.
Build sets from common work, high-impact edge cases, historical failures, and adversarial inputs.
Define thresholds by risk tier and prevent averages from hiding severe failures.
Capture corrections, escalation, abandonment, overrides, and downstream outcomes without treating every user action as ground truth.
State what the system may influence and who bears the consequence.
Record inputs, expected evidence, rubric, risk tier, and acceptable alternatives.
Include retrieval, model, tools, permissions, interface, and human handoff.
Track drift, failures, cost, latency, overrides, and the agreed business metric.
No. A model can score well while retrieval misses protected evidence, tools perform the wrong action, or the workflow fails to provide human control.
It should cover the decision and risk space rather than chase an arbitrary count. Begin with high-frequency and high-consequence cases, then expand from observed failures.
No. User feedback is useful operational evidence, but many users cannot verify hidden factual, policy, permission, or downstream errors.
We will first clarify the workflow, evidence, data boundary, and outcome standard before recommending the next step.
Contact Onyx