A 1983 aerospace standard for unambiguous writing is becoming the unlikely weapon against AI documentation slop

A 1983 Aerospace Writing Standard Is Becoming the Unexpected Guardrail Against AI Documentation Slop

ASD-STE100 Simplified Technical English has spent four decades doing one job for aerospace and defense: making maintenance instructions clear enough that a tired mechanic cannot misread them. Now an open-source agent skill is repurposing those same rules to fix a different ambiguity problem, the one that large language models create every time they generate technical documentation.

The skill, called SimpleEnglish, loads STE's 53 writing rules into coding agents including Claude Code, Cursor, VS Code Copilot, OpenAI Codex, and Gemini CLI 1. According to the project's own benchmarks, it reduced STE specification violations by 72.9 percent across six Claude models and eight writing tasks, measuring 96 total generations 2. Output tokens dropped on every model tested, meaning the constrained text was also shorter 2.

What a controlled language actually controls

STE's rules are blunt instruments. They cap instructions at 20 words and descriptions at 25, require active voice, permit only simple verb tenses, and restrict the approved vocabulary to roughly 900 words 3. The current edition, Issue 9, was published in January 2025 3.

The SimpleEnglish project says it built its rule set against the primary STE specification text rather than online summaries, and it identifies the modals "should," "would," "may," and "might" as banned while "can," "will," and "must" are permitted 1. Those four banned words are the backbone of AI hedging. They are how a model hedges a claim without committing to it.

The before-and-after examples are where the point lands. Without the skill, Claude described a database tool as letting users "seamlessly synchronize their Postgres tables to S3 with minimal configuration overhead." With the skill loaded, the same model produced: "sqlpipe copies your Postgres tables to S3. It needs one configuration file." 1. Across the entire benchmark, the word "seamlessly" appeared zero times in skill-loaded output 2.

Why constraining output beats asking nicely

Most approaches to improving LLM output fall into two familiar buckets. You can prompt-nag, stacking adjectives like clear, concise, and professional into the system prompt and hoping the model internalizes them. Or you can post-process, running generated text through a cleanup pass that strips filler after the fact. Both treat the model as a black box.

STE does neither. By loading 53 hard constraints into the system prompt, the skill narrows the space of permissible output before the model generates a token. The model cannot produce a 40-word run-on because the rules cap sentence length. It cannot slip into passive voice because the rules forbid that too. The constraint is structural, not advisory. The project reports that without the skill, baseline agents confidently invented STE rule numbers, citing a nonexistent rule about short sentences when the actual rule at that number governs verb forms 1. That is the gap between asking a model to follow a standard and forcing it to.

This is the same principle that made STE effective in its original domain. European airlines approached the European Association of Aerospace Industries in the late 1970s because maintenance documentation was inconsistent across manufacturers and too ambiguous for non-native English speakers to follow safely 4. AECMA formed its Simplified Technical English Maintenance Group in 1983 and released the first guide shortly after 3. The problem then was human inconsistency, with Boeing, Douglas, Lockheed, and European manufacturers all writing in different dialects of English 3. The problem now is machine inconsistency at scale. The structural fix is the same one.

Beyond READMEs

The skill ships adaptations for error messages, incident reports, release notes, and system prompts 1. For incident reports, the contrast is sharp. Without the skill, Claude produced the kind of corporate hedging that populates status pages: vague acknowledgment, conditional verbs, no specifics. With the skill, it wrote: "Between 14:02 and 14:31 UTC, 12% of requests failed." 1. Four sentences followed, each stating a fact: the cause, the remediation, the timestamp.

The project's author makes a point about system prompts worth sitting with. A system prompt is a procedure for a reader that cannot ask follow-up questions. Models read the word "should" as optional. STE bans "should" 1.

The honest caveats

The benchmark is self-reported by the project, not independently verified. The evaluation linter is regex-based, and the project openly acknowledges it undercounts real STE violations because it lacks part-of-speech detection 2. Each result represents a single generation, so variance is unmeasured 2. The ASD, which owns the STE standard, does not certify any tool as STE-compliant 2.

Even with those caveats, the direction is clear. A discipline developed by aerospace engineers who understood that ambiguous instructions can kill does more to discipline machine-generated prose than any amount of prompt engineering. The lesson is not that STE specifically is the answer for every use case. It is that the most reliable way to control what a language model produces is to import a set of rules that humans already stress-tested against the consequences of being wrong. The aerospace industry solved this problem forty years ago. The solution was never a smarter writer. It was a smaller vocabulary, shorter sentences, and a ban on every word that lets you avoid committing to what you mean.