Write for readers that can't ask back: Simplified Technical English for agents

12 Oct 2026 · 5 min read ·9 views

When a colleague misreads one of my Slack messages, they ask a follow-up question. An agent reading a tool description or an error string can't. It picks one reading and acts on it. I wanted a writing discipline for that reader, and it turns out the aerospace industry built one decades ago.

Where it comes from

ASD-STE100, Simplified Technical English, is a controlled-language standard maintained by ASD, the AeroSpace and Defence Industries Association of Europe. It started in the 1980s as AECMA Simplified English, written for aircraft maintenance manuals. Those manuals are read by technicians around the world, often in a second language, and a misread step can ground an aircraft or hurt someone. The current edition is Issue 9, published in January 2025.

The standard targets two sources of misreading: words with more than one meaning, and sentences with more than one possible structure. The classic example is close the valve. A tired reader can take close as an adjective, "the valve that is near", instead of a command. STE removes that choice before it reaches the reader.

The core rules

One word, one meaning. An approved word has one meaning and one part of speech. You don't rotate check, verify and confirm for the same action.
Verbs, not nominalizations. "Analyze the log", not "perform an analysis of the log".
Active voice and simple tenses. "The agent deletes the file", not "the file is deleted".
No phrasal verbs. "Start the job", not "spin up the job". A two-word verb has meanings its parts don't predict.
Short sentences, one instruction each. Roughly 20 words for procedures and 25 for descriptions.
No semicolons. Split the sentence instead.

Two kinds of rule

The rules split into two groups, and the split matters if you use STE outside aerospace. Structural rules (length, voice, tense, phrasal verbs, punctuation) can be checked from the text alone. Lexical rules depend on ASD's dictionary of roughly 900 approved words, and without it you can only check consistency, not approval.

Two columns: structural rules you can check from the text, and lexical rules that need the ASD dictionary — Enforce the structural rules. Treat the lexical rules as a direction, not a compliance claim.

That dictionary is free to request from ASD but not free to redistribute. So the Claude Code skill I use for this applies the principle (plainest common word, used the same way every time) and doesn't pretend to check against the official list.

A worked rewrite

Here is a sentence of the kind I see in runbooks and agent prompts:

The configuration file may potentially need to be updated by the user before the service can be restarted, since the database connection string, which is typically stored under the datasource key, should be checked and, if it is not valid, it might cause the application to fail on startup.

One sentence, 49 words, two passives, a nested relative clause, and three qualifiers. After the rewrite:

Before you restart the service, you may need to update the configuration file. Check the database connection string. It usually appears under the datasource key. If the connection string is not valid, the application might fail on startup.

Side-by-side comparison of the 49-word original sentence and the four-sentence rewrite — Shorter sentences, same claims. Nothing became more certain than the source.

Hedges are content

The most useful lesson for me wasn't in the rule list. It was what not to cut. The rewrite keeps may and might. It drops potentially because "may potentially" says the same thing twice.

A length cap tempts you to turn "the application might fail" into "the application fails". That reads cleaner and it's a different claim. For an agent, that difference changes what it does next: retry, escalate, or report a failure that never happened. A good rewrite changes the form and keeps the author's confidence exactly where it was. It also adds nothing. If the cleaner version supplies a cause the source didn't state, it has stopped being a rewrite.

Where I use it

I apply the strict mode to anything another program parses: tool and function descriptions, error messages, inter-agent instructions, and system prompts. For READMEs and PR descriptions I keep the structural rules and relax the vocabulary, because prose needs some range.

I don't use it for creative or persuasive writing. STE is deliberately flat. It also doesn't make weak content useful. A hollow paragraph rewritten under these rules becomes a short, clean, hollow paragraph.

Caveats

This is STE-inspired, not certified STE. Real maintenance documentation needs the official standard and dictionary.
The dictionary is licensed. Request it from ASD's downloads page rather than copying a list from somewhere else.
Present perfect is excluded by STE, but "the job has completed" can carry information that "the job completed" doesn't. When it does, I keep it and say so.

The rule I'd keep if I could only keep one: write so that the reader has exactly one way to understand you, and don't make yourself sound more certain than you are.