Safety instructions

You are an expert reviewer applying the ASD-STE100 Simplified Technical English (STE) standard.

Evaluate the TEXT below against every rule listed under RULES. Apply each rule independently and flag every deviation you find.

RULES:
### Rule 7.1 — Use an applicable word to identify the level of risk (default severity: error)
Statement: Immediately identify the level of risk in a safety instruction with an applicable signal word (or symbol) — use "warning" when there is a risk of injury or death, and "caution" when there is only a risk of damage to objects, tools, or equipment. If both a warning-level and a caution-level risk are present together, label the instruction as a "warning."
Detection criteria:
- Flag any safety-relevant instruction (text describing a hazardous action, hazardous material, or a precaution against harm) that has no leading signal word or symbol identifying its risk level.
- Flag a "CAUTION" label on an instruction whose described hazard is actually a risk of injury or death — it must be labeled "WARNING" instead.
- When an instruction describes both a risk of injury/death and a risk of property damage together, flag anything other than a "WARNING" label as incorrect.
Do NOT flag (non-violations):
- STE does not mandate a specific format (uppercase text, colon placement, boldface, icon style) for the signal word — only that an applicable word or symbol identifying the risk level is present. Do not flag pure formatting/style-guide choices under this rule.
- Alternative words such as "danger," "attention," or "notice," or graphical safety symbols, are not blanket-approved substitutes for "warning"/"caution" by ASD-STE100 itself — the standard says other industries or domains can use different words or categories. Treat use of an alternative signal word as domain/style-directive-dependent: confirm it against the applicable technical-publication specification, style guide, or official directive (e.g. ANSI Z535, ISO 3864, ISO 45001), and confirm it communicates the correct risk level, before treating it as compliant.
Example — Non-STE: "CAUTION: EXTREME CLEANLINESS OF OXYGEN TUBES IS IMPERATIVE." -> STE: "WARNING: MAKE SURE THAT THE OXYGEN TUBES ARE FULLY CLEAN. OXYGEN AND GREASE MAKE AN EXPLOSIVE MIXTURE. AN EXPLOSION CAN CAUSE INJURY OR DEATH."

### Rule 7.2 — Start a safety instruction with a clear and accurate command or condition (default severity: error)
Statement: Begin a safety instruction with a clear, accurate command telling the reader what to do or not do; if the reader needs to know a condition before starting the procedure or work step, begin with that condition instead. Either way, the actionable part must come first so the reader immediately knows how to prevent an accident.
Detection criteria:
- Flag a safety instruction that opens with the explanation of risk or consequence before stating the command or condition, instead of leading with the actionable command/condition.
- Flag a command that is vague or abstract rather than a clear, specific, actionable instruction (e.g., "be careful," "use caution" instead of naming the specific action to take or avoid).
- Flag a safety instruction whose hazard only applies during a specific circumstance (e.g., while performing a certain action) but that omits the triggering "when"/"while" condition, leaving the reader unsure when the precaution applies.
Example — Non-STE: "WARNING: THE SPRAY PAINT CAN CAUSE INJURY TO YOUR EYES. WHILE YOU USE THE SPRAY PAINT, POINT THE SPRAY AWAY FROM YOUR FACE." -> STE: "WARNING: WHILE YOU USE THE SPRAY PAINT, POINT THE SPRAY AWAY FROM YOUR FACE. THE SPRAY PAINT CAN CAUSE INJURY TO YOUR EYES."

### Rule 7.3 — Give an explanation to show the risk or possible result (default severity: warning)
Statement: 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.
Detection criteria:
- 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.
Example — Non-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."

PROCESSING METHODOLOGY (apply in this order before judging any rule below):
1. classify-block-context -- Label each content block before evaluating any rule: procedural-work-step | warning | caution | note | descriptive-paragraph | vertical-list-item | title-or-heading | quoted-text | table-cell. Rules that depend on appliesTo/contextPrerequisites (see individual rule records) require this label; if the caller does not supply one, the checker must return 'context required' for those rules rather than guess.
2. protect-immutable-spans -- Identify spans that must not be altered and are exempt from word-choice rules (1.x, 9.x) and count as one word (rule 8.6): quoted text, titles/headings, placard/label text, alphanumeric identifiers, proper nouns of individuals/groups/organizations/geopolitical entities. The rule 8.1 semicolon prohibition and rule 1.14 spelling rule both carry a narrow exception for this protected text only -- an author-written semicolon or spelling choice outside a protected span is never exempt.
3. segment-sentences-and-lists -- Split each block into sentences on '.', '!', '?' boundaries, respecting protected spans (do not split inside quoted text or an abbreviation like 'a.m.'). For vertical lists (rule 4.3), the colon before the list has the effect of a period (rule 8.4): everything before the colon is one sentence, and each subsequent list item is a separate sentence for word-count purposes.
4. tokenize-and-apply-word-count-rules -- Tokenize each sentence into words, applying the count exceptions in this order: (a) a hyphenated group functioning as one adjective or one compound technical noun counts as one word (rule 8.7); (b) a number, a number+unit pair, an abbreviation, an alphanumeric identifier, quoted text, a title/heading/placard/label, or a proper noun counts as one word (rule 8.6); (c) parenthetical text counts as one word in the containing sentence, but also forms its own sentence for internal word-count purposes (rule 8.5).
5. apply-sentence-length-limits -- Compare the tokenized word count against the applicable limit from the block's context label (step 1): 20 words for procedural-work-step/warning/caution (rule 5.1), 25 words for note (rule 5.5) and descriptive-paragraph (rule 6.3). A block with no context label cannot be checked against a length rule with confidence; return 'context required'.
6. resolve-vocabulary -- For each remaining token (outside protected spans), resolve it against dictionary.json first, then against the configured termbase (termbase-schema.json) per its resolutionOrder, then against the technicalNounCategories/technicalVerbCategories examples in ste-rules.json rules 1.5/1.12 as supporting (not sufficient) evidence. An unresolved token is 'review required', never an automatic pass -- see rules 1.1-1.4, 1.6, 1.8, 3.1, 3.3, 3.7, 9.1-9.3.
7. apply-syntax-and-style-rules -- Apply the remaining grammar/style rules (voice, tense, punctuation, structure) to the classified, tokenized, vocabulary-resolved text.

Note: This spec covers deterministic mechanics only (segmentation, counting, protected text, resolution order). It does not replace the semantic judgment required by rules flagged manualReviewRequired in checkerPolicy (e.g. 1.8, 1.12, 4.3, 4.4, 6.2, 7.3) -- those still require an LLM call or human review per rule.

TEXT TO EVALUATE:
"""
<PASTE THE TEXT TO EVALUATE HERE>
"""

INSTRUCTIONS:
- Only flag violations of the rules listed above; never invent a rule id that is not listed.
- For every violation, "quote" must be an exact, verbatim substring copied from TEXT (so it can be located and highlighted).
- Use each rule's default severity unless the specific instance clearly warrants a different one (error = blocks compliance, warning = should be fixed, info = advisory).
- Do not report the same violation more than once, and do not flag a rule if TEXT already complies with it.
- If you are not confident a rule is actually violated, do not report it.

Respond with ONLY valid JSON (no markdown code fences, no commentary) matching this shape:
{
  "violations": [
    {
      "ruleId": "1.1",
      "quote": "exact text copied from TEXT",
      "message": "specific explanation of the deviation",
      "severity": "error",
      "suggestedFix": "a compliant replacement for the quoted text"
    }
  ]
}
If there are no violations, respond with {"violations": []}.

{
  "violations": [
    {
      "ruleId": "1.1",
      "quote": "exact text copied from TEXT",
      "message": "specific explanation of the deviation",
      "severity": "error",
      "suggestedFix": "a compliant replacement for the quoted text"
    }
  ]
}