The 1986 Airline Writing Standard Your AI Docs Need

In AI Can Write the Code. You Still Have to Guide the App. I argued that models fill boxes while you still draw them: scope, architecture, authentication, authorization, tests, ADRs. Skip that and you get a pretty demo that dies on user two.

Docs fail the same way, only with nicer grammar. Ask an agent for a README or a Habit Board runbook and it comes back looking finished, tidy headings and smooth tone included. Then someone follows the steps and finds the hard parts missing, the verbs soft, and every real constraint sanded into corporate padding.

So this is the docs half of that argument. The cage I keep reaching for is older than ChatGPT by decades, and it came out of aircraft maintenance manuals.

It started with plane manuals

European airlines needed maintenance docs technicians could follow even when English wasn't their first language. Misread a procedure on an airframe and you're not debating style. You're arguing with availability and safety.

In the late 1970s those airlines pushed the European aerospace industry (then AECMA, now ASD), with help from the U.S. Aerospace Industries Association, to build a controlled form of English for maintenance text. The working group looked at other controlled languages, then made its own. First public product: the AECMA Simplified English Guide (document PSC-85-16598), out in 1986. Writing rules plus a controlled dictionary. From there it became a requirement in ATA maintenance and training specs, later also S1000D, then ASD-STE100 as a specification in 2005, and Issue 9 in January 2025 as a standard for technical documentation.

Nobody was chasing "friendly" copy. They wanted one approved meaning per word, short procedures, and fewer ways to misread a step while holding tools. Defense work and other safety-critical industries picked up the same idea, and a lot of primary maintenance text in those worlds is still written in STE on purpose.

That's the lineage behind ASD-STE100 Issue 9. When I tell people to put STE around agent docs, I'm not inventing a vibe-coding aesthetic. I'm borrowing a cage airlines paid for because average English was already too dangerous.

How AI writing slop gets made

Airlines built that cage against ambiguous human English. Language models manufacture a new supply of the same problem at machine speed.

They don't outline a thought and then type it. They predict the next token, glue it on, predict again. The highest-probability continuation is the expected one, so safe words keep winning and specific stakes keep losing.

A few forces stack on that loop:

Work on LLM "slop" (papers and writeups on repetitive phrase overuse, plus sampler tricks meant to suppress it) keeps pointing at the same shape: certain stock phrases show up far more in model text than in comparable human writing. Detector chatter often mentions low perplexity (predictable word sequences) and low burstiness (flat sentence rhythm). Those metrics are messy and they false-positive on careful human prose, so treat them as a hint about the mechanism, not a verdict.

In docs the failure is plainer:

There's another trap specific to docs. Models are rewarded for clean prose, so awkward but true details look like noise. Exceptions get smoothed. Conditions disappear. You ship text that reads better and is slightly wrong. Reviewers skim because nothing looks broken, and tickets start with "I followed the docs."

Same shape as the Habit Board feature dump in the previous post. The agent invents a complete-looking surface. You still have to reject the invented defaults.

What ASD-STE100 actually is

STE is the modern name for that airline writing cage. ASD-STE100 (opens in a new tab) is a controlled natural language for technical documentation, and Issue 9 (15 January 2025) is current. The subtitle frames it as a standard for technical documentation, not only aerospace manuals, but the DNA is still the plane-manual problem: the reader has to do the right action.

It has two parts. Writing rules cover grammar and style. A controlled dictionary lists approved words, each with an approved part of speech and meaning. You may also add technical nouns (TNs) and technical verbs (TVs) for your product, industry, or subject field, which is how Postgres, webhook, or rate limit stay legal without turning the dictionary into a free-for-all.

Issue 9 reworked a large share of the 53 writing rules and cleaned up terminology classifications, including clearer TN / TV wording lined up with ISO terminology practice. ASD's public materials keep hammering clarity, safety, and global readability.

STE is not a "make it sound human" guide. It often strips the conversational habits that make blog prose feel alive: contractions, long flowing sentences, playful synonyms. For procedures that's the feature. Ambiguity is expensive when someone's holding a wrench, running a migration, or reading a runbook at 2am.

The previous post was about drawing the product box. This one is about drawing the language box before the agent fills the docs.

Why STE cuts AI fluff

Once you see how slop is produced, the STE rules stop looking arbitrary. They forbid the exact habits models reach for first: synonyms, hedges, and soft verbs.

Take a fake Habit Board API note. AI-default first:

Same intent, STE-shaped:

Same meaning, fewer words, no mood language. A checker can score pieces of the second version. The first mostly scores as "sounds professional."

The same contrast shows up in install steps:

AI-default:
After ensuring the instance is ready, you should proceed to install the agent,
making sure that networking has been configured appropriately.

STE-shaped:
Make sure the instance is ready.
Install the agent.
Configure the network.

The STE version isn't clever. Clever is where models hide missing steps.

Rules worth learning first

You don't need all 53 rules on day one. If an agent just handed you a procedure, these are the checks that catch most of the mess:

Not every STE rule is machine-checkable. Topic-sentence quality, "one instruction unless simultaneous," and some meaning calls still need a human. ASD's tools page (opens in a new tab) is blunt about this: tools help writers who already understand STE. They don't write STE for you, and they don't reliably convert non-STE text into STE.

Project terms keep product language honest

Dictionary rules only work if product language has a home. Ban every word outside the core dictionary with no project glossary and your checker screams at Kubernetes, OIDC, and idempotent. That isn't STE working. That's a missing TN/TV list.

Treat project terms as approved technical vocabulary, the same way the previous post treated entities and ownership as non-negotiable product facts:

Write the glossary before you ask an agent for a full manual. Otherwise the model invents three names for the same object and the docs drift inside one PR. Docs version of silent dependency inflation.

A workflow that survives agent drafts

Rules and glossaries still need a review loop. I use the same sequence whether a human or a model wrote the first pass, and it mirrors plan-then-build from the previous post: evidence before "done."

1. Scope the text as procedure, description, safety, or note. Notes give information. They don't hide instructions.
2. Run structural checks the term checker can see: dictionary, TN/TV, verb forms, contractions, sentence length, passive, semicolon.
3. Look up doubtful words in the Issue 9 dictionary (official PDF search, or a lookup helper).
4. Write a findings table. Not vibes.
5. Plan the rewrite before you rewrite.
6. Apply, then re-check.

Findings format that stays useful in PRs:

## STE findings

| Severity | Rule | Location | Issue | Evidence |
| --- | --- | --- | --- | --- |
| must-fix | 1.1 | para 2, "utilize" | rejected dictionary word | alternatives: use |
| limit | 5.1 | sent 4 | 24 words (limit 20) | quote the sentence |
| judgment | 5.2 | sent 7 | two instructions | quote the sentence |

Severity:

• must-fix: clear dictionary / checker violations
• limit: rules with checker gaps (note the gap)
• judgment: human STE judgment the checker cannot settle

Then the rewrite plan, still before the rewrite:

## Rewrite plan

1. Goal: STE Issue 9 compliance for the install procedure
2. Term replacements:
   - utilize → use (1.1)
   - ensure that → make sure that / rewrite as imperative
3. Structure changes:
   - Split sent 4 into two sentences (5.1)
   - Change passive in sent 9 to active (3.6)
4. Open questions:
   - Is "webhook" an approved project TN?
5. Out of scope:
   - Marketing landing page copy

Only after that plan do you rewrite. Word-for-word swaps aren't always enough. Sometimes you need a different sentence construction (STE writing practice 9.1). Agents are bad at noticing that unless you force a plan step.

Run that loop on something tiny and the difference stops being abstract. Here's a short install procedure, AI-default first:

After findings and a rewrite plan, the STE-shaped version looks like this:

Easier to translate, easier to walk by hand, and harder for a model to pad.

Agents: one useful place in the stack

Once that human loop feels boring, put it around the agent. In the previous post, rules, skills, MCP, and subagents were how you kept code agents inside the box. Docs agents need the same treatment. Put STE around the draft. Don't stop at "write better."

ASD and the STEMG do not endorse, certify, or authorize software tools, including AI tools (opens in a new tab). Providers can't claim ASD approval. Checkers can be wrong, noisy, or configured for some other controlled English. Privacy matters if text leaves your network. You still own the meaning.

A prompt that beats "write in STE" forces the same evidence you would demand by hand:

If the agent skips the findings table, the draft isn't done. Same rule as tests in the previous post: no evidence, no merge.

When STE is the wrong tool

None of this means every sentence on your blog should sound like a maintenance card. Use STE where misunderstanding has a cost: install guides, maintenance procedures, safety notes, API how-tos, incident runbooks, operator manuals.

It's usually the wrong default for personal essays, marketing pages that need brand voice, exploratory design notes where you're still arguing with yourself, or anything trying to be funny on purpose.

You can still steal habits (shorter sentences, one meaning per term) without claiming full Issue 9 compliance. Don't pretend a blog post is an aircraft manual. The previous post wasn't written in STE. This one isn't either. The callout samples are.

What to do Monday

If you haven't read the product-guidance half yet, start with AI Can Write the Code. You Still Have to Guide the App.. Then request Issue 9 from asd-ste100.org (opens in a new tab) and read the writing-rules overview plus the dictionary intro. Make a one-page project TN/TV list next to your ADRs and AGENTS.md. Grab one AI-generated procedure you already distrust and run findings → plan → rewrite by hand once. Automate the checklist in an agent skill only after that loop feels real.

AI can write the docs the same way it can write the code. You still draw the box. For procedures, airlines drew that box in 1986, and Issue 9 is the current version. Use it so agents stop shipping polished averages as operator manuals.

Feature lists build demos. Guidance builds apps, and controlled language is what makes the docs followable.