Skip to content

Simplified Technical English

Braden Seaborn edited this page Aug 26, 2026 · 1 revision

Simplified Technical English

ASD-STE100 Simplified Technical English (STE) is a controlled language for technical documentation. A controlled language restricts the vocabulary and the grammar of a natural language to a defined subset. STE restricts English. A procedure written by an engineer in Toulouse then carries one meaning for a mechanic in São Paulo who learned English as a third language.

The specification has two parts: a set of writing rules, and a Dictionary of approved words. Together they remove the choices that make English ambiguous — the synonym, the stacked compound noun, the passive sentence with no agent, the modal verb that leaves an instruction optional.

This page explains the standard. For what this repository's tool does, see How the Linter Works. For the honest statement of how the two relate, jump to How this project relates to the standard.


Contents


Where it came from

The civil aviation industry created STE to solve a documentation problem with a safety cost. By the late 1970s a maintenance manual for one aircraft ran to tens of thousands of pages. A growing share of the mechanics reading it had learned English as a second or third language. A misread maintenance instruction is a safety event. In 1979 the European airline industry asked AECMA — the European association of aerospace manufacturers — for a form of English that removed that risk.

AECMA first surveyed the controlled languages already in use in other industries. In 1983 it decided to produce its own, and formed the working group that became the Simplified Technical English Maintenance Group (STEMG). The Aerospace Industries Association of America joined the work. The result was AECMA Document PSC-85-16598, the AECMA Simplified English Guide.

Sources disagree on the publication year. ASD's own history page states that STE was first released in 1986. Wikipedia and other technical-writing sources give 1985, which matches the 85 in the document number. The copyright page of the specification lists AECMA copyrights beginning in 1986. This page names the document instead of picking a year.

In 2004 AECMA merged with two other associations to form ASD, the AeroSpace and Defence Industries Association of Europe. The guide became ASD Simplified Technical English, Specification ASD-STE100. The STEMG still maintains it, and by its own count has produced 17 releases across more than 90 working meetings in 13 countries. The current edition is Issue 9, dated 15 January 2025, with the subtitle Standard for technical documentation.


What is in the specification

Part 1 — Writing rules

Part 1 holds 53 numbered rules in nine sections:

Section Title What it governs
1 Words Approved words, technical nouns, technical verbs
2 Multi-word nouns Noun clusters and how to break them apart
3 Verbs Permitted tenses, the active voice, the -ing form
4 Sentences Length, one idea per sentence, vertical lists, articles
5 Procedural writing Instructions, imperatives, one action per step
6 Descriptive writing Paragraph structure and connected text
7 Safety instructions Warnings, cautions, and where they sit
8 Punctuation and word count Permitted marks, sentence-length limits
9 Writing practices Consistency across a document set

Eight General Recommendations (GR-1 through GR-8) follow the rules. Issue 9 added GR-7 on inclusive language and GR-8 on the possessive form. Issue 9 revised the wording of 31 of the 53 rules and introduced no new ones. The rule count is unchanged from Issue 8, and a source quoting a different number is describing an earlier issue.

Two properties of the rule set matter more than any individual rule.

Classification comes before checking. Every passage is either procedural or descriptive, and that classification decides which of the remaining rules apply. An instruction and an explanation are held to different standards, because a reader does different work with each.

The limits are numeric. Published summaries of the rules give these figures: a 20-word ceiling on a procedural sentence, and 25 on a descriptive one. A descriptive paragraph holds six sentences, and a noun cluster holds three words. The semicolon is banned outright. Numeric limits are what make a rule set checkable instead of aspirational.

Part 2 — The Dictionary

Part 2 is a controlled vocabulary of 900 approved words. Every entry binds one word to one part of speech and one approved meaning.

The word list marks approval by typography: a word printed in UPPERCASE is approved in STE, and a word printed in lowercase is not. Each entry gives the approved meaning and an STE example of correct use. An entry for a non-approved word also gives the approved words that replace it, and a non-STE example of the use being rejected. Issue 9 renamed those two example columns to STE EXAMPLE and Non-STE example.

Counts vary between sources. ASD gives a figure of 900 approved words; other summaries give 850 general words, counting the categories differently.


One word, one meaning

The Dictionary's central discipline is one word, one part of speech, one meaning.

English offers begin, commence, initiate, and start for a single idea. STE approves start and rejects the other three. The gain is not brevity. The gain is that a reader who has learned one word has learned the concept. No reader has to work out whether a different word in a different manual signals a different action.

The restriction extends to part of speech. A word approved as a noun is not available as a verb. Ordinary English allows the shift; STE does not. GREASE is approved as a noun. "Grease the fasteners" is not STE; "Apply grease to the fasteners" is.

The same discipline governs close. STE approves it as a verb for two engineering senses: moving two parts together, and operating a circuit breaker. It does not approve it for closing a meeting or closing a business.

A non-approved word is not banned for being a bad word. The ban exists because a second word for an existing concept is a second thing for the reader to learn, and a second place for two writers to disagree.


Technical nouns and technical verbs

No dictionary of 900 words describes an aircraft. STE handles this with two controlled openings in the vocabulary.

Rule 1.5 admits technical nouns and Rule 1.12 admits technical verbs: subject-specific vocabulary that a project needs and the Dictionary does not carry. The opening is bounded in two ways. The term has to fall inside one of the numbered categories the rules list. It also has to come from a controlled source — official documentation, engineering drawings, a company glossary, or a terminology database. Terms such as overhead panel, aural warning system, and discoloration enter a manual through this route, not through a writer's preference.

Issue 9 renamed technical name to technical noun throughout Part 1. Literature written against Issue 8 and earlier uses the older term for the same mechanism.


Worked examples

The pairs below show the STE style applied to maintenance-documentation prose. They are written for this page, not quoted from the specification, whose own examples are copyrighted.

A non-approved verb built from an approved noun.

Before:  Grease the bearing housing.
After:   Apply grease to the bearing housing.

GREASE is approved as a noun only. The rewrite keeps the noun and supplies an approved verb.

Synonyms, a hidden agent, and a wordy opener.

Before:  Prior to commencing the removal procedure, it must be ensured that
         sufficient clearance is available.
After:   Before you start the removal procedure, make sure that there is
         enough clearance.

Four changes: prior to becomes before; commencing becomes the approved start; the agentless passive it must be ensured becomes an instruction addressed to the reader; sufficient becomes a plainer word. The sentence drops from 17 words to 15, and from two readings to one.

A stacked noun cluster.

Before:  Remove the forward cargo compartment door actuator retaining bolt.
After:   Remove the retaining bolt from the actuator on the forward cargo door.

The original strings seven nouns together and leaves the reader to guess the grouping. Is it the door actuator, or the actuator retaining bolt? The rewrite caps the cluster at three words and restores the relationships with prepositions.

Four instructions in one sentence.

Before:  The filter should be removed and the housing cleaned, after which a
         new filter can be installed and the access panel closed.
After:   1. Remove the filter.
         2. Clean the housing.
         3. Install a new filter.
         4. Close the access panel.

A mechanic working through the original has to hold four actions and their order in memory. The rewrite gives one instruction per step, in the imperative, in sequence. The modals should and can also disappear, and with them the question of whether any step is optional.


Where STE is used

STE began in civil aviation maintenance documentation and remains standard there. S1000D, the international specification for technical publications across aerospace and defence, references STE as the language for data-module content. The copyright page of ASD-STE100 grants usage rights to airworthiness authorities, to the defence ministries of the ASD, AIA, and AIAC member countries, and to Airlines for America. That list indicates where the specification expects to be read.

Adoption spread far outside aerospace: rail, automotive, medical devices, energy, and software documentation. Wikipedia records that STE is referenced in ISO 24620-4:2023 on language resource management. ASD describes Issue 9 as the point at which the specification became an international standard.

Two properties carry STE across domains.

Translation cost. A controlled source text produces high match rates in translation memory and fewer distinct segments to translate. The same sentence written four ways costs four translations in every target language; written once, it costs one.

Bounded readings. A restricted vocabulary narrows the set of interpretations an instruction supports. Requirements engineering wants the same property from a specification. That overlap explains why STE ideas keep surfacing in requirements-quality work. The INCOSE guide to writing requirements, the NASA Systems Engineering Handbook, and the requirements-smell literature converge on rules STE reached first, from a different direction.


How this project relates to the standard

Read this section before you describe STE-Linter to anyone else.

This project is not an implementation of ASD-STE100. The project is not licensed by ASD, not certified by ASD or the STEMG, and not affiliated with either. It makes no claim of conformance. ASD is explicit on the point: "ASD and the STEMG DO NOT endorse or certify any company, organization, or individual that sells tools claimed to be 'fully compliant' with ASD-STE100."

This project does not ship the STE Dictionary. The Dictionary is Part 2 of a copyrighted specification. Its copyright page states that "no reproduction or publication of it, in whole or in part, shall be made without the written authority of an officer of ASD". The same page grants usage rights to eight named categories of organization. Those categories are ASD, AIA, AIAC, and ICCAIA members, their customers, the defence ministries of those countries, Airlines for America, airworthiness authorities, and universities and research institutes for educational purposes.

The word lists in src/ste100/data/ come from openly licensed sources instead. Provenance is recorded at two levels of detail.

substitutions.json, the T1 table, carries a source on every one of its 424 entries, and ste100 --explain <RULE_ID> prints it. The four values are retext_simplify (205 entries), vale_redhat.simple_words (105), vale_microsoft.wordiness (86), and a merged wordiness list (28). The T2, T3, and T6 tables carry no per-entry source. Their provenance is recorded at the table level in docs/rules.md.

The rules here are not the 53 rules. They do not map onto STE's numbered rules. They do not encode the procedural/descriptive classification that Part 1 depends on. They do not check approved-word status against any approved-word list. The STE- prefix on every rule ID names this tool's own rule namespace. It does not assert that a rule derives from a numbered ASD-STE100 rule.

A clean run is not evidence of STE conformance. A failing run is not evidence of non-conformance either. Conformance is assessed against the specification, by people trained on it. ASD notes that only UNINETTUNO University, under an agreement with ASD, certifies STE trainers.

What the project does take from STE is the set of principles. One word for one meaning. Short sentences. One instruction per sentence. The active voice. No optionality hidden inside prose, and numeric limits instead of advice.

Those principles sit alongside sources this project draws on directly. They are the INCOSE Guide for Writing Requirements, the NASA Systems Engineering Handbook, and MIL-STD-961E. Two research sources join them: the EARS templates of Mavin et al., and the requirements-smell catalogue of Femmer et al. See How the Linter Works for where each one lands in the rule set. docs/rules.md catalogues every rule with its cited source.

Get the specification itself. ASD distributes ASD-STE100 free of charge as a PDF, to anyone who asks, from asd-ste100.org. If you write aerospace or defence documentation, that document is your reference. Not this wiki, and not this tool.


Sources

History, structure, and the current edition:

Rule summaries and illustrative rewrites:

Requirements-quality sources this project draws on alongside STE:

  • Mavin, Wilkinson, Harwood, Novak, "Easy Approach to Requirements Syntax (EARS)", 17th IEEE International Requirements Engineering Conference, 2009
  • Femmer, Méndez Fernández, Wagner, Eder, "Rapid quality assurance with Requirements Smells", Journal of Systems and Software 123, 2017, pages 190–213
  • INCOSE, Guide for Writing Requirements; NASA, Systems Engineering Handbook; MIL-STD-961E

Next: How the Linter Works · CLI Reference · Agent Skill · Contributing

Clone this wiki locally