In the late 1970s and early 1980s, European airlines had a writing problem. Aircraft maintenance manuals were written in English, often by native speakers, and read by mechanics across Europe and beyond for whom English was a second or third language. A misread procedure on an aircraft is not an inconvenience. The industry's answer was a controlled form of English: a limited vocabulary where each approved word has one meaning, and a set of writing rules that keep sentences short, direct and unambiguous.
That work became ASD-STE100 Simplified Technical English, usually shortened to STE. Forty years later it reads like a specification for a problem the software industry has only just discovered: how to write instructions that a reader with no shared context, no chance to ask a question and a tendency to take things literally will act on correctly the first time.
That reader now includes AI agents. It also includes the many South Africans who work, and receive government services, in their second or third language. CloudNala's view is that STE is not a style for everything, but for the documents where a misread instruction causes real damage, it is the best-tested discipline available, and it is free.
This article explains what the standard is, where it fits, where it does not, and how we apply it to agent instructions, specifications, runbooks and proposals.
What the standard actually is
ASD-STE100 is owned by ASD, the Aerospace, Security and Defence Industries Association of Europe, and maintained by a dedicated ASD group, the STEMG. It began as the AECMA Simplified English Guide, first issued in 1985, and took its current name after the 2004 merger that created ASD. The name is a registered trademark of ASD.
The current version is Issue 9, published in 2025. According to ASD's announcement, Issue 9 runs to 434 pages, revises the wording of 31 of its 53 writing rules without adding new ones, and updates 555 dictionary entries, including aligning its terminology with ISO 1087-1. The standard is available free of charge: a copy is requested through the official site, asd-ste100.org, rather than bought. It has been free since Issue 6 in 2013.
Although it was born in aerospace, its reach has spread. Distribution records cited for Issue 8 showed most recipients outside aerospace and defence, and ASD's Issue 9 announcement says STE is used in 129 countries.
The standard has two parts.
Part 1 is the writing rules. There are 53 of them, grouped by topic. In paraphrase, they cover things like:
- using only approved words, in their approved meaning and part of speech;
- keeping noun clusters short (no more than three words strung together as a noun);
- using simple verb forms and the active voice;
- keeping sentences short: no more than 20 words in procedural text and 25 in descriptive text;
- writing one instruction per sentence in a procedure, in the imperative;
- keeping paragraphs to one topic and no more than six sentences;
- writing warnings and cautions so that the command or condition comes first.
Part 2 is the dictionary. It lists the approved words, roughly 900 of them, each with one meaning and examples, and it lists many common unapproved words alongside approved alternatives. The principle is "one word, one meaning": if a word in the dictionary is approved as a verb meaning one thing, it may not also be used to mean something else.
The dictionary deliberately does not try to list every technical term. The standard allows each organisation to add its own technical names (products, systems, components) and technical verbs (actions specific to the domain), provided they are used consistently. In practice, this project term list is where most of the practical value sits.
We have paraphrased the rules here rather than quoting them. For the exact wording, request the standard itself; it is the authority, and the paraphrase above is not a substitute.
Why a 1980s standard fits the agent era
Three kinds of reader have something in common with a mechanic reading a procedure in a second language.
AI agents. An agent following an AGENTS.md file, a skill, a runbook or a set of acceptance criteria cannot ask the author what they meant. It takes words at face value, and it fills ambiguity with plausible guesses. "Ensure the service is properly configured before deploying" tells an agent almost nothing. "Run the configuration check. If the check fails, stop. Do not deploy." tells it exactly what to do and when to stop. Our article on harness engineering describes instructions like these as guides: the controls that steer an agent before it acts. Controlled language makes guides more reliable.
Multilingual teams and citizens. South Africa has twelve official languages, including South African Sign Language since 2023, and English is a second or third language for a large share of the people who read workplace procedures and government service content in English. Idioms, phrasal verbs ("roll out", "set up", "take over") and long sentences with several clauses are exactly what makes English hard for second-language readers. They are also exactly what STE removes. Machine translation into other languages also works noticeably better on short, literal source text.
Reviewers under time pressure. Short sentences with one instruction each are easier to check. A reviewer can tick each line against the system. A paragraph of nested conditions cannot be ticked; it can only be re-read.
There is an honest qualification. Modern language models are very good at interpreting loose English, much better than a literal parser. The case for controlled language is not that agents cannot understand normal prose. It is that loose prose leaves room for several reasonable interpretations, and an agent will pick one without telling you which. Controlled language removes the room.
A few rewrites
These examples are our own, written to illustrate the rules, not taken from the standard.
An agent instruction.
Before: It's important to make sure that any database migrations are thoroughly tested and that you don't push anything that might break existing functionality for users of the system.
After: Run all migration tests before you commit. If a test fails, stop and report the failure. Do not change the existing API responses.
The before version contains a judgement ("thoroughly", "might break") the agent has to interpret. The after version contains three actions and one boundary, each checkable.
An acceptance criterion.
Before: The system should handle invalid ID numbers gracefully and give appropriate feedback.
After: If the ID number has fewer than 13 digits, show the message "Enter all 13 digits of your ID number". Do not submit the form.
"Gracefully" and "appropriate" are where defects hide. The rewrite is testable.
A runbook step.
Before: Once you've confirmed things look okay on the monitoring side, go ahead and roll the change out to the remaining nodes, keeping an eye on error rates as you go.
After: Examine the error-rate graph. If the error rate is more than 1%, stop the release. If the error rate is 1% or less, release the change to the remaining nodes. Examine the error-rate graph after each node.
The after version is longer in sentences but shorter in ambiguity. It also exposes a decision the before version hid: what counts as "okay".
A proposal assumption.
Before: We have assumed that the client will be able to provide access to the relevant environments in a timely manner.
After: The client gives the supplier read access to the test environment before the project starts. If access is late, the delivery date moves by the same number of working days.
This one is not strict STE ("supplier" and "client" would be defined terms in the project list), but the discipline is the same: who does what, by when, and what happens if they do not. Our proposal series makes the same point about requirements, assumptions and traceability.
Where it fits, and where it does not
Strong fit: runbooks and operating procedures, agent instructions and skills, acceptance criteria, warnings and cautions, installation and maintenance steps, and anything a person or agent must follow step by step without help.
Partial fit: specification narrative, architecture decision records, citizen-facing service content, and the assumptions and exclusions sections of proposals and statements of work. Apply the core rules (short sentences, one meaning per term, active voice, explicit conditions) without enforcing the full dictionary.
Poor fit: executive summaries, marketing, thought leadership (this article is not written in STE, and should not be), persuasive proposal sections and legal drafting. Persuasion relies on rhythm, emphasis and nuance that controlled language deliberately removes. Legal drafting has its own conventions and its own authority; do not substitute one standard for another.
The test we use: must the reader act correctly on this text, possibly in a second language, without being able to ask the writer? If yes, controlled language earns its place. If the reader's job is to be persuaded or to understand a nuanced argument, it usually does not.
How CloudNala applies it
We do not claim STE certification, and we do not write everything in it. We apply its rules where they reduce the risk of a wrong action.
Agent instructions and skills. Repository instruction files, skills and agent prompts are written with short imperative sentences, one instruction each, explicit stop conditions and a defined term for every system name. When an agent misbehaves, the first check is whether an instruction allowed two readings.
Specifications and acceptance criteria. Acceptance criteria use one condition and one result per sentence, with defined terms. This connects directly to spec-driven development, where the specification is what the agent builds from, and to our series on the AI-native delivery loop, where the specification becomes the control surface.
Runbooks and handover packs. Operational procedures that a support team will follow at 2am follow the procedural rules closely: imperative steps, conditions first, warnings before the step they apply to.
Proposals. Assumptions, exclusions, dependencies and acceptance criteria in proposals and statements of work use the core rules. The persuasive sections, such as the executive summary and win themes, do not. Write for two readers describes that split.
Public-sector content. Where we help with citizen-facing service content, the core rules support plain language for second-language readers and make translation easier.
A practical adoption path
- Pick one document type where misreading is expensive. Runbooks or agent instructions are good candidates. Do not start with everything.
- Build a project term list. Name each system, component and action once, define it, and use that name every time. This step alone removes a surprising amount of ambiguity, and it is useful even if you go no further.
- Apply the core rules by hand to a handful of real documents: sentence length, one instruction per sentence, active voice, conditions before actions, no idioms or phrasal verbs.
- Add a checker to the pipeline. Commercial STE checkers exist, and a simple script can flag sentence length, banned words from your own list and passive constructions. AI assistants can also suggest rewrites, but treat their output as a draft to review: a model that rewrites into "STE" can still introduce unapproved words or change meaning. Check the result against the standard and against the original intent.
- Test with real readers. Ask the people who follow the procedure, including second-language readers, where they hesitated. For agent instructions, run the same task several times and see whether behaviour becomes more consistent.
- Extend to the next document type once the first one shows fewer questions and less rework.
Request the standard itself before step 3. It is free, and the paraphrased rules in any article, including this one, are not a substitute for the source.
The point
Most of the writing advice offered to people working with AI is about prompting: clever phrasing, role-play, examples. STE comes from the opposite direction. It assumes the reader is capable but literal, has no shared context and cannot ask a question, and it optimises the text so that only one reading is possible.
That assumption describes an agent following an instruction file. It describes a support engineer following a runbook under pressure. It describes a citizen completing a form in their second language. A standard written for aircraft mechanics turns out to fit all three, and it has been refined for forty years by people for whom a misread sentence had serious consequences.
How CloudNala can help
We help teams write the documents that agents and people must act on correctly: agent instructions and skills, acceptance criteria, runbooks, handover packs and the assumption and exclusion sections of proposals. We can review a sample against controlled-language rules, build a project term list with your team, and set up a lightweight checking step in your delivery pipeline.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technical Writing Review or write to us at consult@cloudnala.co.za