warning · Section 7: Safety instructions
Rule 7.3: Give an explanation to show the risk or possible result
If it is possible, after the command or condition in a safety instruction (rule 7.2), give an explanation that clearly states the specific risk or possible result if the reader does not obey it. A concrete, specified risk helps the reader understand why the precaution matters and makes them more likely to follow it. The explanation is conditional on it being possible to state — not every WARNING or CAUTION is automatically non-STE for omitting one.
This rule needs human judgement. A checker can flag candidates; it cannot decide.
Safety instructions are where a model's findings are least reliable and a wrong rewrite costs most. Nothing a prompt returns on a warning or caution should reach a reader without a person who knows the standard having read it first.
What a checker looks for
Usually a deviation, and context can excuse it.
- Flag a WARNING or CAUTION with no explanation as needing review, not as an automatic error — escalate to an error only when the risk/result is clearly derivable from the available context or an applicable directive requires it.
- Flag an explanation that is vague or generic (e.g., "this is dangerous," "this could cause a problem") rather than a specific, concrete risk or result (the actual injury, damage, or hazardous mechanism) — this remains a hard flag, since a vague explanation is present but inadequate.
- Check that the explanation's severity matches the signal word used (rule 7.1): a WARNING's explanation should describe injury or death, a CAUTION's explanation should describe damage to objects or equipment.
How to fix it
Where it is possible to state the risk or result, add a concise sentence after the command/condition naming the specific injury, damage, or hazard mechanism, using specific technical language instead of generic danger language.
Constraints on the fix
- Keep the explanation factual and specific to the described hazard; do not invent a risk that is not supported by the context.
- Do not assert a missing explanation is a definite error when the risk/result cannot be determined from the available text — flag it for review instead.
Examples
Not STE: CAUTION: DO NOT USE BLEACH OR CLEANSERS THAT CONTAIN CHLORINE TO CLEAN THE UNIT.
STE: CAUTION: DO NOT USE BLEACH OR CLEANSERS THAT CONTAIN CHLORINE TO CLEAN THE UNIT. THESE CLEANING AGENTS CAN CAUSE CORROSION.
Not STE: WARNING: DO NOT SWALLOW THE SOLVENT. THIS IS DANGEROUS.
STE: WARNING: DO NOT SWALLOW THE SOLVENT. ALWAYS MAKE SURE THAT YOU KNOW THE SAFETY PRECAUTIONS AND FIRST AID INSTRUCTIONS FOR SOLVENTS. SOLVENTS ARE POISONOUS AND CAN CAUSE INJURY OR DEATH.
Related rules
Where this fits in AI governance
A rule a checker can test is a rule a model can be held to. The same discipline, on the governance side of this site.
- Inadequate human oversight design
A safety instruction is the last place to discover that the review step was designed to be skipped. - Human-in-the-loop review
Warnings and cautions should never publish from a model call without a person having read them. - Output validation guardrails
A controlled language is a checkable output constraint. This is the control that treats model output as something to be checked rather than trusted.
Source
ASD-STE100 Issue 9, Section 7 - Safety instructions, page 1-7-4.
This page is commentary and does not reproduce the standard. About this rule pack.