ASD-STE100: Stop AI-Sounding Writing With This Standard

Stop AI-sounding drafts with ASD-STE100 Simplified Technical English, the 53-rule, 900-word aerospace standard you can load straight into your LLM.

Share
ASD-STE100: Stop AI-Sounding Writing With This Standard

If your drafts keep coming back full of em-dashes and that unmistakable "written by a chatbot" cadence, the fix isn't a better prompt. It's a 40-year-old aerospace writing standard called ASD-STE100 Simplified Technical English. Once you feed it to your LLM, the AI smell mostly disappears.

Table of Contents

What Is ASD-STE100 Simplified Technical English?

ASD-STE100 Simplified Technical English ("STE") is what's known as a controlled natural language. Instead of letting a writer use any word or sentence structure English allows, STE restricts you to a fixed rulebook and a fixed vocabulary.

The goal is that two different writers, on two different continents, produce text that reads the same way and can't be misread.

That constraint is exactly why it's useful for LLM output. Models default to hedging, stacking clauses, and reaching for the same handful of "AI-flavoured" transition words. STE removes the wiggle room those habits live in.

Where STE Came From

The standard didn't start as a writing-style trend. It started because people were maintaining aircraft. European airlines and AECMA (the European Association of Aerospace Industries) set up a working group in mid-1983 near Amsterdam to define a shared approach to English-language documentation, which became the AECMA Simplified English project. The goal was making aircraft maintenance documentation easier to understand for readers with only a basic command of English, and the resulting guide was released in 1986.

AIA, the Aerospace Industries Association of America, was brought in to support the effort. In 2004, after AECMA merged with two other associations to form ASD, the guide was renamed ASD Simplified Technical English, Specification ASD-STE100.

The biggest recent shift: Issue 9 was released on January 15, 2025, and marked STE's move from a specification into a full international standard, the product of three years of collaborative work by the STE Maintenance Group and its national support teams. Today the standard has moved well past aviation. It's now used across rail, automotive, oil and gas, IT, and medical device documentation.

What's Actually Inside the Standard

STE has two parts, and both matter if you're building a prompt or a skill file around it.

Part 1: The Writing Rules

There are 53 writing rules spread across 9 sections, covering word choice, grammar, sentence structure, and style. Here's some of the examples:

Active voice over passive

  • Non-STE: "The panel was removed by the technician."
  • STE: "The technician removed the panel."

One instruction per sentence, not stacked clauses

  • Non-STE: "Remove the panel, which is held by four screws, and check the wiring for damage."
  • STE: "Remove the panel. Four screws hold the panel. Check the wiring. Make sure the wiring is not damaged."

Simple verb forms over nominalizations (turning a verb into a noun makes sentences longer and vaguer)

  • Non-STE: "Before acceptance of the unit, do the specified test procedure."
  • STE: "BEFORE YOU ACCEPT THE UNIT, DO THE SPECIFIED TEST PROCEDURE."

Part 2: The Dictionary

STE's dictionary holds roughly 900 approved words, each with one meaning and one part of speech, plus a separate list of around 1,200 words to avoid, with suggested replacements for each. A word can't be a noun in one sentence and a verb in the next.

Each approved word gets locked to one meaning and often one part of speech:

  • close: approved only as a verb, with two specific meanings (operating a circuit breaker, or moving something to block an opening). So "do not go close to the test rig" is not approved STE, since that uses "close" as an adverb.
  • fall: approved to mean "to move down by the force of gravity" only. Not "to decrease," which is how the word gets used loosely in everyday English.
  • start: the chosen word where English has several synonyms; STE picks "start" and drops "begin," "commence," and "initiate" entirely.
  • access / accessible: access is an approved noun meaning "the ability to go into or near"; accessible is the matching adjective, so instructions read "get access to the accumulator" rather than "the accumulator is accessible."

Why STE Fixes That "AI Wrote This" Feeling

Most of what reads as "obviously AI" isn't really about vocabulary but sentence rhythm. Models tend to pad statements with qualifiers, chain clauses together with em-dashes, and default to passive constructions that sound formal but say less.

STE's rule set attacks exactly that pattern:
short sentences, active voice, and a hard limit on ambiguity per word.

The dictionary restriction does something extra because each approved word only has one meaning, the model can't lean on vague, multi-purpose words to sound sophisticated while saying nothing. You end up with text that reads more like a person stating a fact and less like a model performing confidence.

Two Ways to Put STE to Work in Your LLM

You've got two practical setups, and which one fits depends on whether you want STE everywhere or only for specific documents.

1. Put it in memory (always-on).

This is the simpler route if you want every conversation with your model to default to STE-style output. It's the best option if STE isn't a one-off task for you but a permanent writing preference.

You just tell it directly:
"I want you to always use ASD-STE100 Simplified Technical English when you talk to me. Suggest a skill write-up to be included in your memory."

2. Scope it as a project skill.

This is the better fit if STE only applies to specific work i.e. technical documentation, procedure write-ups, anything where you don't want every casual chat reply forced into 53-rule compliance. A skill only triggers when you're working in that context, so your everyday conversation stays normal and STE kicks in specifically when you ask for it or when the model recognises a documentation task.

If you don't want to build the rule set from scratch, I've published an STE-style skill file on GitHub you can pull straight into a project.

GitHub - anasabaziz/AI-Skills: This Repositary contains useful skills made by Anas Ab Aziz
This Repositary contains useful skills made by Anas Ab Aziz - anasabaziz/AI-Skills

Is It Worth Setting Up?

For anyone producing documentation, workflow write-ups, or technical explainers with an LLM, yes! it's worth the ten minutes it takes to set up.

STE wasn't designed to make writing sound clever; it was designed so nobody misreads an instruction on an aircraft. That same bluntness is exactly the antidote to AI writing's worst habit: sounding confident while saying very little.


Tried this with your own documentation workflow? I'd genuinely like to hear whether it changed your output. Drop a comment with what you're using it for.