In one paragraph

Most attempts to get a language model to produce Simplified Technical English follow the same shape. Find the rules, paste them into a system prompt, add the text, ask for a compliant version. The output is shorter, more imperative and generally better writing, and it is not STE. The reason is structural rather than a matter of prompt quality. ASD-STE100 has two inseparable parts, and only one of them is rules. The other is a controlled dictionary of roughly 2,000 entries specifying which words are approved, as which part of speech, with which meanings, and what to use instead when a word is not approved. A model asked to apply that from memory will approve words that are not approved, because it has no list. Fixing that is the whole problem, and it is not a prompting problem.

Why the single-prompt approach underperforms

Three failures, in descending order of how much they matter.

The dictionary is not in the prompt, and cannot usefully be. Approved-word decisions are lookups against a fixed list. A model without the list will guess, and it will guess plausibly, which is worse than guessing badly. Text that reads as controlled language while containing unapproved vocabulary is harder to catch than text that obviously failed.

Fifty-three rules in one call means each gets a fraction of the attention. The rules are not independent. Rule 3.3 permits a past participle as an adjective, rule 3.4 prohibits auxiliary constructions, and rule 3.6 requires the active voice, and all three match the same surface form. Deciding between them requires working through a precedence order. A single pass over the whole standard tends to apply whichever rule the model reached first.

Checking and rewriting are different jobs. Checking asks which rules a passage deviates from and where. Rewriting asks for compliant text preserving the instruction exactly. Asking for both at once produces a rewrite with a plausible list of reasons attached, and the reasons are generated alongside the text rather than derived from it.

The order that works

Four stages. The first two prepare the call rather than replace it.

Resolve the vocabulary first. Before any prompt is built, look every word up. That establishes which are approved, which part of speech they are approved as, and what the approved alternative is for the ones that are not. It is a lookup and it is instant. The result goes into the prompt as evidence, so the model is told what the list says instead of recalling it, and the model still decides. A lookup on its own cannot decide, for the reason in the limitations below.

Segment and count next. Split the text into blocks, label each one by type, and tokenise under the standard's own counting rules. Several rules apply different limits depending on whether a block is a procedural work step, a warning, a note or a descriptive paragraph, so without the labels the model has to infer the type and then apply a limit to its own inference. The same arithmetic is worth keeping afterwards, to check that a rewrite really did come back under the limit. Article Deterministic work belongs either side of the model call works through why that matters beyond the token saving.

Then check by rule section, one call each. The standard is organised into nine sections, and they are a sensible chunking. Send the rules for one section, against text that has already been segmented and vocabulary-resolved, and ask only for deviations from those rules. Sections that only apply to procedural writing do not need to run on a descriptive document.

Rewrite last, and separately. Once the deviations are known, a rewrite call can be given the specific findings and asked to fix them. That is a much narrower instruction than "make this STE", and it is auditable afterwards because each change traces to a rule.

Practical prompt shape

For a check call against one section, the useful structure is:

  • Role. Evaluating text against specified ASD-STE100 rules. Not rewriting.
  • The rules in scope. Only this section's, each with its statement and its detection criteria.
  • Dictionary findings, already resolved. The words in this text that are not approved, and their approved alternatives. Words absent from the dictionary, marked unresolved.
  • Precedence. Where two of the rules in scope can match the same construction, which governs.
  • The text, already segmented into blocks with each block labelled by type.
  • Output shape. A structured list of deviations, each carrying a rule id, the exact quoted span, and a reason. No prose.

Two details matter more than they look.

Label the blocks. Several rules apply different limits depending on whether text is a procedural work step, a warning, a caution, a note or a descriptive paragraph. A procedural sentence is capped at 20 words and a note at 25. Without the label the model has to infer the type and then apply a limit to its own inference. Where the type is genuinely unknown, the honest output is that context is required, not a guess.

Ask for structured output against a schema. Deviations should come back as records with a rule id and a quoted span, not as paragraphs. Anything you cannot parse you cannot count, and anything you cannot count you cannot regression-test.

Using the rule pack directly

The rule pack behind this section's rule pages is published under an MIT licence, and it travels. It ships as structured rule records with detection criteria, rewrite guidance and worked examples, a JSON schema for the expected response shape, and pre-rendered system prompts. The standard itself is not included, because it is separately owned and licensed.

If you are building this into your own agent, take the rule records and render your own prompts per section rather than using the consolidated one. The consolidated prompt exists for convenience and it is 89KB, which is roughly 22,000 tokens on every call before your text.

What this will not do

Three limits, stated because a controlled-language tool that overstates itself is worse than none.

A dictionary lookup cannot decide a word on its own. The standard's own example for rule 1.3 is "Follow the safety instructions", which must be "Obey the safety instructions". "Follow" is an approved word, so the lookup passes it. It is approved only with the meaning "come after, go after", and the deviation is in the sense rather than the word. A lookup used as a verdict does not merely miss this. It certifies it. That is why the resolved vocabulary belongs in the prompt as evidence and never as the answer.

Seven of the 53 rules need human judgement whatever the tooling. Whether a company-approved term exists for a concept, whether a vertical list would genuinely help, whether a paragraph's key words carry its logical structure, whether a safety explanation matches its signal word. A checker can raise candidates on these. It cannot decide them.

A dictionary extraction is not the dictionary. Ours holds 2,037 entries against the 2,149 the standard declares. A word the checker cannot resolve is reported as needing review and never passed silently, which is the only defensible handling.

None of this certifies compliance. It supports review by a person who knows the standard. Output from it should not be presented as evidence that a document conforms.

That is also the position of the body that owns the standard. ASD's Maintenance Group said in June 2026 that AI can support STE writing but cannot replace human oversight, that accountability stays with the author, and that it endorses no AI tool. Everything on this page assumes all three.

Where to start

Take one of the published prompts and run it against a page of your own documentation. Six of them need nothing but your text. Then read the deviations against the rules they cite. The most common surprise is not the sentence-length findings, which people expect. It is how many ordinary words turn out to be unapproved, and how narrow the approved meanings are for the ones that are.

If you need the standard itself, obtain it directly from ASD; it is free to request. ASD's June 2026 white paper on STE and AI states the Maintenance Group's position on the use of AI with the standard; this guide is consistent with it. This site publishes commentary on the rules and does not reproduce the standard.