error · Section 5: Procedural writing
Rule 5.4: State a leading condition as a descriptive statement, separated by a comma
When a work step depends on a condition the reader must know about first, start the instruction with a descriptive statement of that condition, then divide the condition from the command with a comma, placing the imperative instruction after the comma.
What a checker looks for
A clear deviation from the rule.
- Flag an instruction where a condition (introduced by "if", "when", etc.) appears after the command instead of before it (e.g. "Set the switch to NORMAL when the light comes on.").
- Flag a leading condition that is not separated from the following command by a comma, or where the comma is misplaced such that it could change which word an adverb or clause modifies.
What this rule does not cover
- A sentence with no genuine leading condition does not need to be restructured under this rule.
How to fix it
Move the condition (the "if"/"when" clause) to the start of the sentence, place a comma at the end of the condition, and follow it with the imperative command.
Constraints on the fix
- Place the comma precisely at the boundary between the condition and the command — a misplaced comma can change which verb an adverb modifies and alter the sentence's meaning.
Examples
Not STE: Set the switch to NORMAL when the light comes on.
STE: When the light comes on, set the switch to NORMAL.
Not STE: Disconnect the Constant Speed Drive (CSD) from the gearbox, if it does not operate correctly.
STE: If the Constant Speed Drive (CSD) does not operate correctly, disconnect it from the gearbox.
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.
- Improper output handling
A procedural instruction acted on without a check is the same failure whether the reader is a technician or a downstream system. - Human-in-the-loop review
Procedures are where a generated instruction should not reach a reader without a person having read it first. - 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 5 - Procedural writing, page 1-5-4.
This page is commentary and does not reproduce the standard. About this rule pack.