Read an evaluation result from evidence to decision

Start with the question the result answers, not the color of its badge. A provider call, case evaluation, multi-judge composition, measurement revision, and release gate describe different layers of the system.

​

Read in this order

Identify the case and instrument. Locate the application input and output, the evaluator version, the questions or rubric, the reference evidence, and the input-construction identity. A case judged with different source evidence is not an exact repeat. Check execution completeness. Read the child attempts and terminal execution states. A provider timeout, malformed answer, or missing attempt is evidence about execution reliability, not automatically a finding that the application behaved badly. Read the terminal composed outcome. Fallbacks and repeated stability runs can change the final outcome. Preserve each child observation, but do not let the first child replace the final result. Read the measurement population. Confirm which independent cases and reference labels were included, which pairs matched, which observations were unavailable, and how uncertainty was calculated. Read qualification and authority separately. The evidence can support a scientific conclusion without authorizing a deployment or side effect.

​

Outcome vocabulary

These are layer-specific values. A comparison may use a different, documented projection such as unresolved; do not assume one universal enum governs every UI, API, and CLI.

​

What a useful explanation looks like

For a typed decision judge, an explanation can say: “The evidence-sufficiency requirement was not met, so the primary check did not yield an authoritative result.” That is an explanation of the rule and evidence. It should not invent a paragraph of Jev reasoning. Native decision-model results explicitly do not contain a generated critique.

​

Contradictions are a stop condition

Suppose the child record says escalate_frontier, but a later frontier attempt successfully completed. The original child remains an accurate history of the request; it is not necessarily the final outcome. Conversely, one passing stability run cannot justify a passing comparison if another required run failed. If the summary, persisted outcome, and child history disagree, retain the evidence and report the inconsistency instead of selecting the most favorable field.

​

Provenance supports inspection, not unlimited claims

Hashes and version identifiers connect a result to particular inputs and policies. They do not, by themselves, establish that the reference labels are correct, the dataset is representative, or an action was actually prevented in production. Use Controls and evidence to describe those boundaries, and Cost and latency to interpret operational measurements.