Use these anywhere, right now

Multi-word nouns

Standalone — paste this in with your text and it works, no other input needed.

Rules it covers

The prompt

~2277 tokens, generated from the rule pack, never hand-typed.

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 2.1 — Write multi-word nouns of no more than three words (default severity: warning)
Statement: A multi-word noun is a string of nouns and/or adjectives (with no article or preposition breaking it up) that together modify a head noun and function as one part of speech. Keep every multi-word noun to a maximum of three words; if a concept needs more, restructure the phrase (for example with prepositions such as 'of,' 'on,' 'in,' or 'for') instead of stacking more than three words together.
Detection criteria:
- Identify unbroken strings of nouns/adjectives (no article, preposition, or conjunction between them) that modify a single head noun, and flag any such string longer than three words, e.g. 'Runway light connection resistance calibration' (5 words).
- Count a hyphenated compound that functions as one unit as a single word within the string (per rule 2.2's hyphen method); only flag when the string still exceeds three words after hyphenated units are collapsed to one word each.
- Pay special attention to procedure/instruction sentences where several nouns are stacked immediately before the object of an instruction (e.g. 'Install the forward turbine overheat thermocouple terminal tags').
Do NOT flag (non-violations):
- A multi-word noun of three words or fewer is compliant, even if it is a dense technical compound (e.g. 'actuator operating rod').
- Words separated by a preposition or article (e.g. 'resistance of the connection') are not one multi-word noun string and are not counted together.
- The 'no article/preposition breaks up the string' parsing test is a derived syntactic heuristic for identifying multi-word noun boundaries, not wording from the standard itself — treat ambiguous parses as needing review.
Example — Non-STE: "Runway light connection resistance calibration." -> STE: "Calibration of the resistance of the runway light connection."

### Rule 2.2 — Write long technical nouns in full, then shorten or hyphenate them (default severity: warning)
Statement: When an approved technical noun (from official company, engineering, or parts-catalog documentation) itself has more than three words and cannot be shortened in meaning, write it out in full the first time it occurs in the text. After that first occurrence, if possible, you can either (a) switch to a shorter form or an approved abbreviation for the rest of the document, or (b) use hyphens between words that function together as one unit so the phrase reads as three words or fewer. Abbreviating or hyphenating is not necessary for an approved technical noun that already has three words or fewer, and you must never alter hyphens or abbreviations that are already fixed parts of an official approved technical noun.
Detection criteria:
- Flag a 4+-word official/technical noun only when its repeated full-length use, or an unclear/incorrect abbreviation or hyphenation, actually makes the text hard to follow — repeating the full form after first occurrence is not automatically non-STE, since shortening is conditional ('if possible'), not mandatory.
- Flag an abbreviation or acronym for a long technical noun that appears before that noun has ever been written out in full.
- Flag hyphens chained across more than three word-units purely to force a long multi-word noun under the three-word cap (e.g. 'main-gear-door-retraction-winch handle' hyphenated into what reads as only two words).
- Treat an abbreviation or hyphen applied to an approved technical noun that already has three words or fewer as a hard violation, matching the standard's own worked examples ('Do not write: ... DA ... PVA ...' / 'WRITE: ... diaphragm assembly ... poppet valve assembly ...', page 1-2-3): it is unnecessary and the standard shows it as non-compliant, not merely undesirable.
Do NOT flag (non-violations):
- Hyphens or abbreviations that are already fixed parts of an official/approved technical noun (e.g. 'inward-outward valve') must be kept exactly as given, even though the rule otherwise discourages hyphenating short nouns.
- Hyphenating two or three words that genuinely operate as a single unit (e.g. 'cutoff-switch power connection') is compliant, not a violation of rule 2.1 or 2.2.
Example — Non-STE: "The primary parts of the valve are: - The DA (8) - The PVA (15) - The BA (17) - The VB (20)." -> STE: "The primary parts of the valve are: - The diaphragm assembly (8) - The poppet valve assembly (15) - The bush assembly (17) - The valve body (20)."

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": []}.

Expected response 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"
    }
  ]
}

Run against the demo passage

What this prompt returns against the 114-word worked example.

  • Rule 2.1 · warning "forward equipment bay distribution panel isolation switch" — A seven-word unbroken noun string against the three-word limit. Restructure with prepositions rather than stacking the nouns.

What it cannot decide alone

Both rules in this chunk are text-based and fully in scope for a model working from the text alone, with no rule here flagged as needing human judgement. The judgement call that remains is where a long noun string naturally splits when it is restructured — the rule gives the constraint, not a single correct rewrite.

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.

Source: ASD-STE100 Issue 9. This page is commentary and does not reproduce the standard. About this rule pack.