The control for the case above. Same wrench, same photograph — but the procedure asks for the setting instead of pretending the tool reports a reading, and the record files it as asserted. An agent that refuses this too has not learned the distinction, it has just learned to refuse torque.
The answer conformed to the contract and every assertion held.
System instructionassembled from the contract schema, not hand-written
Return exactly one verdict for the evidence supplied against this step. PASS only if the acceptance rule is satisfied by what you can actually see. THAT THE EVIDENCE IS CLEAR ENOUGH TO JUDGE IS NOT ITSELF A PASS: a sharp, well lit, entirely legitimate photograph showing the acceptance rule is NOT met is the commonest way a step fails, and passing it because the photograph is good is the single worst mistake you can make. Where the acceptance description says what must be visible rather than what must be true, read it as the condition the step exists to establish — the step explanation tells you which. ADD_FIELD when the evidence is insufficient but recoverable, and name what specifically was wrong with it. ESCALATE when a person must decide — INCLUDING when the evidence is entirely sufficient and shows the acceptance rule is not satisfied. Asking for another photograph of a condition you can already see is not a remedy.
Return JSON with these fields:
- verdict (one of PASS | ADD_FIELD | ESCALATE, required)
- confidence (number, required): 0 to 1: YOUR CONFIDENCE THAT THE ACCEPTANCE RULE IS SATISFIED by this evidence. Not how sure you are of your verdict, and not how good the photograph is — a perfectly clear photograph of a rule being broken is high certainty and LOW confidence, because the rule is not satisfied. Evidence you were never shown cannot make you confident of anything. Below the strictness threshold you must not return PASS, and a threshold in ordinary code enforces that whatever you return.
- rationale (string, required): One or two sentences citing what in the evidence decided it. Never restate the prompt.
- add_field_key (string, null when it does not apply): Required when verdict is ADD_FIELD. A new key, not an existing one.
- add_field_kind (one of measurement | photo | video | scan | choice | text | signature | location, null when it does not apply)
- add_field_prompt (string, null when it does not apply): The specific next ask, e.g. 'the label is out of focus, photograph it again'. Never a generic retry.
- escalation_question (string, null when it does not apply): Required when verdict is ESCALATE. The exact unresolved question for the person, not a summary.
- observed (string, null when it does not apply): Required when the acceptance rule is `matches`. TRANSCRIBE, character by character, exactly what you can read in the evidence — not what it ought to say. Never copy the expected value into this field; it is the one field in this answer that must come from the image alone. Where a character is illegible write `?` in its place. The comparison against the expected value is then made in ordinary code, not by you, which is the whole point: an agent told what it is looking for will find it.
## The step
{
"title": "Fit the new pads and torque the caliper bolts",
"why it exists": "An under-torqued caliper bolt backs out under braking heat and the caliper moves. This is the step that kills someone if it is skipped."
}
## The field you are judging
{
"key": "caliper_bolt_torque_setting",
"kind": "photo",
"asked of the technician": "Photograph the wrench barrel showing what you set it to, then torque both caliper bolts to the click",
"source": "camera",
"what good looks like": "Square on to the barrel so the number and the scale it sits on are both legible. This records what the tool was SET to. It is not a measurement of the bolt and the record files it as asserted.",
"acceptance": "acceptance_rule: must_show; the media must show: the barrel of a click-type torque wrench set to a value inside 6-9 Nm, read on the wrench's Nm scale, with the number and the scale both legible"
}
## What a PASS would assert
That this is true of the machine: the barrel of a click-type torque wrench set to a value inside 6-9 Nm, read on the wrench's Nm scale, with the number and the scale both legible.
The step exists because: An under-torqued caliper bolt backs out under braking heat and the caliper moves. This is the step that kills someone if it is skipped..
State what the evidence shows about that assertion BEFORE you choose a verdict, and put it in your rationale. If what you can see makes the assertion FALSE, the verdict is not PASS — however sharp, well lit and honest the photograph is. Asking for another photograph of a condition already visible is not a remedy, so that case is an ESCALATE, not an ADD FIELD.
## Conditions
{
"strictness": "1 (standard)",
"confidence a PASS must clear": 0.6,
"add field budget": "0 of 2 ADD FIELD requests on this step are already spent.",
"capture surface": "app_instrument",
"capture mode": "live"
}
## The evidence
The 2 images below is what the technician captured for this field. Judge what you can actually see in it. If you cannot see enough to decide, say what specifically is missing — never ask for a generic retry.
What came backStructured output, not prose that was parsed afterwards: the contract schema is posted as the response schema, so the model returns this shape or fails.
{
"verdict": "PASS",
"confidence": 0.98,
"rationale": "The torque wrench barrel is clearly legible and set to 7.5 Nm, which is within the required 6-9 Nm range.",
"add_field_key": null,
"add_field_kind": "photo",
"add_field_prompt": null,
"escalation_question": null,
"observed": null
}
What this scenario asserted
Assertions pin the part of an answer that decides something, never the whole object — exact-matching a rationale would fail the first time it was reworded, and a suite that cries wolf is abandoned inside a day. Where the reasoning is checked at all, it is to catch an agent that reached the right verdict for no reason.
