A typical draft vs ASD-STE100

I found ASD-STE100 through a video that calls it the cure for AI slop. The claim is that the reason LLM output reads like LLM output is not the vocabulary — it is the shape. Stacked auxiliaries, 40-word sentences with three subordinate clauses, passive verbs with nobody doing the acting. The first aerospace guide appeared in 1986. Its current rules restrict those patterns because a mechanic in a hangar cannot afford to re-read a sentence. The standard says nothing about marketing adjectives or nominalizations as categories — those are my own additions, and I keep them in a separate table below for exactly that reason.

What I could not find anywhere was the boring artifact: the same text, written both ways, so you can see what the standard actually costs and what it buys. Search results give you the spec, some consultancy pages, and a lot of posts about banning the em dash. So I wrote the comparison instead, with the standard open next to it.

ASD-STE100 is a controlled language: a fixed dictionary plus a set of writing rules. The European aerospace industry started work on it in the late 1970s and published the first release in 1986, as an AECMA document, because maintenance manuals written in fluent English were being read by technicians who did not speak it fluently. Ambiguity in that context is not a style problem. The standard is maintained today by ASD and its Simplified Technical English Maintenance Group, and the standard is free to download.

Two halves. The dictionary approves roughly 900 general words. In general, each approved word has one meaning and one part of speech, although the dictionary contains exceptions. fall means to move down, so you cannot write that latency falls. Technical nouns and verbs for your own domain are allowed on top of that list — you are not limited to 900 words total. The writing rules cover sentence length, voice, tense, punctuation and structure, and those are the part that does the work outside aerospace.

Worth settling before the examples, because the two get used interchangeably and they are different kinds of object. Plain language is defined by the outcome: ISO 24495-1:2023 calls writing plain when the intended reader can find what they need, understand it, and use it. It does not hand you a word list. How you get there is judgment.

STE is defined by the input. A fixed dictionary, 53 numbered rules, a word cap you can count. It can be written into a contract and a large part of it can be checked by a machine. That checkability suits contractual workflows today and also makes the rules easier for an LLM to follow.

The two overlap but neither contains the other. A text can be plain and fail STE — this paragraph does. A text can pass every STE rule and still leave the reader stuck, because no rule about sentence length can tell you that you documented the wrong thing.

Issue 9 has 53 numbered writing rules in nine sections, plus the dictionary. Below are the ones that change how ordinary technical text reads, with the rule numbers so you can check me against the source. The rule wording is my paraphrase, because the standard is copyrighted. In the tables below, an example in quotation marks is the standard's own — that is Rules 1.2, 3.4 and 3.7, and nothing else. Everything unquoted I wrote to fit software, so hold me and not ASD responsible for those.

And these are mine, not the standard's

Five habits I apply on top of STE, kept in a separate table so nobody quotes them back at me as aerospace rules. They are editorial choices, not compliance requirements.

Five kinds of text an engineer actually writes. Be clear about what the left column is: an unedited first draft, the way I would have written it on a normal day or the way a chat model hands it to you. It is not a plain-language version — a careful plain-English writer would already have cut most of what is flagged. The comparison is draft-to-STE, not method-to-method.

The flags are a mixed bag, and it matters which is which: some break a numbered rule (a passive with a known actor, a contraction, a 40-word sentence), others are my own editorial calls (an adjective I cannot measure, stock warmth). Word counts and the longest sentence in each panel are counted at render time, so those numbers cannot drift from the text.

Look at what got flagged. Almost none of it is vocabulary. It is hedging (may help to improve), passive verbs with a hidden actor (requests are counted), nominalizations (perform an analysis), stock warmth (don’t hesitate to reach out), and sentences that hold three ideas at once. That list is a fairly complete description of what people mean by slop.

Banning words treats the symptom. A writing system removes the shape that produces the words.

This is also why a banned-words list disappoints. Strike seamless and the model writes frictionless. Cap the sentence at the applicable 20- or 25-word limit, prefer a named actor, and demand one instruction per sentence in procedures, and there is nowhere left for a filler adjective to sit — the sentence has no room for anything but a subject, a verb and an object. The author of the video ran that comparison against several models and published the kit and the numbers: a writing system beat a banned-words list on every model tested. I have not reproduced that experiment, so treat it as his result and not as mine. On this page the only evidence is five rewrites and the counters next to them.

The part I did not expect — with a caveat

My rewrites came out more specific, not just shorter. Be careful about what that proves. STE does not require a status code or a timeout value; the standard asks you to keep the meaning of the source. What happened is narrower and more interesting: once I could not lean on “subsequent requests will be rejected” or “a more robust refresh mechanism”, the sentence had nowhere to hide, and I had to go and find the numbers. The rewrite only became useful after I supplied the operational detail the original had omitted.

So two separate things happen when you apply STE to a vague draft: the form gets fixed by the rules, and the content gets fixed by you, because the rules make the hole visible. Only the first half is the standard's doing. That is also the real cost — it makes writing slower in a useful way.

STE strips voice on purpose. That is a feature in a maintenance manual and a bug almost everywhere else. The hero line on this site reads:

I build digital stuff that actually works.

In STE that becomes something like “This person writes software. The software operates correctly.” Both sentences are clear. One of them is worth reading. Anything persuasive, funny or personal — landing pages, essays, cover letters, this paragraph — loses more than it gains.

• Short sentences can drone. Five 12-word declaratives in a row read like a robot. Vary the length inside the cap.
• It can add words. Splitting a dense sentence into three costs you the connective tissue. STE optimizes for reading speed and accuracy, not word count.
• It does not make anything true. A hollow paragraph rewritten in STE is a shorter hollow paragraph. It fixes form, never substance.
• Full compliance needs a human. Whether a sentence “makes good sense” and whether you picked the right technical noun are judgment calls. A linter can only catch the mechanical part.

So I use it in two modes. Strict for procedures, error messages, runbooks and API reference — every rule, both length caps. Loose for READMEs, PR descriptions and commit messages — keep active voice, one idea per sentence and the length cap, drop the dictionary lockdown. For anything with a voice, ignore it entirely.

This is my editing shortcut, not a compliance test. Procedures have a 20-word limit, descriptions have a 25-word limit, and full compliance also requires the dictionary. Run this over a draft — yours or a model’s — and fix what it catches:

1. 1Any procedural sentence over 20 words, or descriptive sentence over 25? Split it at the first and or which.
2. 2Any semicolon? Make it a period.
3. 3Any passive verb with a known actor? Put the actor in front: the parser reads the file.
4. 4Any nominalization or hedge — perform an analysis, may help to improve? Use one plain verb.
5. 5Any adjective that cannot be measured — robust, seamless, powerful? Delete it, then write the number it was standing in for.
6. 6Is one thing named two ways across the document? Pick one name and use it every time.

Step 5 is where the work is, and it is the one that changes the content rather than the prose. Next in this series I want to build a small browser lint for this, and run my own before/after numbers instead of borrowing someone else’s.

• asd-ste100.org — the official standard. Every rule number comes from Issue 9, dated 15 January 2025, as do the quoted examples for Rules 1.2, 3.4 and 3.7. The remaining examples and all five rewrites are mine. The document is copyrighted, so the rule wording here is my paraphrase.
• ASD on STE software — ASD and the STE Maintenance Group do not endorse, certify or authorize any checker, AI-based or otherwise.
• ISO 24495-1:2023 — the plain-language standard, for the distinction above.
• “The cure for AI slop is a 1986 aircraft manual” — where I got the idea.
• The companion repository — a distilled STE agent skill, a heuristic anti-slop linter, and the cross-model experiment data.