ASD-STE100 (Simplified Technical English, or STE) is a controlled-language standard created by the aerospace and defence industry to make maintenance documentation unambiguous for a global audience. It combines roughly 60 writing rules — short sentences, active voice, present tense, one instruction per sentence, no ambiguous verbs — with a controlled dictionary where each approved word carries exactly one meaning. It has been in production use for decades.

Why does STE help with LLM prompting?

Two reasons. As an input constraint, asking a model to reply in STE forces short declarative sentences, one idea each, with a restricted vocabulary — which strips hedging and ambiguity out of the answer. As an output format, STE is faster and less error-prone to read than prose, which matters when you are scanning agent output or procedures. It is a deterministic, rule-based style the model can actually follow.

Can I use STE in Claude Code or Codex?

Yes. We packaged the rules and the controlled-dictionary guidance as an open plugin: a slash command and output style for Claude Code, and an AGENTS.md drop-in for Codex. Install in Claude Code with /plugin marketplace add menonpg/ste-prompt then /plugin install ste-prompt@menonlab. You can also invoke it on demand (rewrite this in STE) or set it as a persistent output style so an agent writes its explanations and runbooks in Simplified Technical English by default.

Prompting in Simplified Technical English: Borrowing ASD-STE100 for LLM Output

Q: Does Simplified Technical English help with RAG and retrieval?

Yes — this is where we see the biggest practical payoff. Across the retrieval systems we build over professional corpora, the content that retrieves cleanly and answers correctly is the content already written like a controlled language: one question, one answer, one fact per line. Prose that buries several facts in a compound sentence produces muddy embeddings and hedged answers. Writing documentation in something close to STE is a cheap, durable retrieval-quality upgrade.

By Prahlad Menon Published 2026-10-08 5 min read

A LinkedIn clip made the rounds this week claiming Andrej Karpathy had “released a new prompting technique” called ASD-STE100. The framing is off — nobody released anything, and ASD-STE100 is older than most of the people reposting it — but the underlying observation is genuinely useful, and it lines up with something we keep relearning while building retrieval systems over dense professional corpora.

What ASD-STE100 actually is

Simplified Technical English (STE), formally ASD-STE100, is a controlled language. The aerospace and defence industry built it so that a maintenance manual written in English could be read correctly by a technician anywhere in the world, under pressure, with no room for misreading. It has two halves:

~60 writing rules. Keep procedural sentences to 20 words or fewer. One instruction per sentence. Active voice. Present tense. Start a procedure with the command verb. No gerunds where a plain verb works. Always use the article (“the pump,” never “pump”). Do not use a noun as a verb.
A controlled dictionary. Each approved word has one meaning and one part of speech. “Follow” means “come after” — so you do not “follow the safety instructions,” you obey them. “Fall” is the approved verb; “drop” is not. If a word is not approved, you rewrite around it.

The result reads a little flat. That is the point. Flat text has nowhere to hide ambiguity.

Why it maps onto LLMs so well

There are two distinct ways to use it, and they are worth separating.

As an output constraint. When you tell a model “answer in ASD-STE100 Simplified Technical English,” you are not just asking for a tone. You are imposing short declarative sentences, one idea each, active voice, and a shrunken vocabulary. Those constraints mechanically squeeze out the two things that make LLM prose hard to trust: hedging (“this might potentially help in some cases”) and compound sentences that smuggle three claims into one. What is left is checkable.

As a readability format. Karpathy’s actual point in the clip being referenced was about how we consume model output — ranking STE-style writing, diagrams, HTML pages, and explainer videos as different channels for the same information. STE wins for anything procedural: runbooks, agent step logs, API how-tos. You scan it faster and you misread it less.

What our RAG work taught us the hard way

This is the same lesson our retrieval systems keep handing us, and it is worth being concrete about.

We build and run retrieval-augmented assistants over dense professional corpora — technical literature, FAQs, author and policy documents, fee schedules. These are systems where domain experts ask real questions (“What is the fee for the open-access option?”) and expect an exact answer, with citations, every time. There is no room for a plausible-but-wrong response.

Here is the pattern we see across all of it. When we chunk and index these documents, the content that retrieves cleanly and answers correctly is the content that was already written like a controlled language — one question, one answer, one fact per line. FAQ entries. Fee tables. Eligibility criteria. Step-by-step procedures. The retriever finds them, the model grounds on them, and the answer is unambiguous.

The content that fumbles is the prose — the flowing paragraph that buries three facts in a compound sentence with two subordinate clauses. The embedding is muddy because the passage is about three things at once. The model hedges because the source hedged. Every time we re-index an updated corpus, the chunks that behave are, again, the question-shaped ones.

So STE is not an abstract writing-style preference for us. It is the formalized version of the thing that makes a RAG corpus actually work. If you are writing documentation that an AI will later retrieve over — internal runbooks, API docs, a knowledge base, policy content — writing it in something close to Simplified Technical English is the cheapest retrieval-quality upgrade you can make. You are doing the disambiguation up front, once, instead of hoping the model does it at query time, every time.

The catch

STE is a rule-based style, which is exactly why a model can follow it — and exactly why it has limits. It is built for procedures and descriptions, not for nuance, caveats, or anything where the hedging is the content. Do not force a risk discussion or a research summary into it. Use it where ambiguity is the enemy: instructions, runbooks, agent output you have to act on quickly.

We packaged it as a plugin

Reading about a technique is less useful than being able to flip it on. So we built STE-Prompt, an open, MIT-licensed plugin that carries the writing rules and the controlled-dictionary guidance into your coding agent:

Claude Code: a /ste slash command to rewrite a block on demand, plus an output style you can set so the agent writes every explanation and runbook in Simplified Technical English by default.
Codex / other agents: a drop-in AGENTS.md section with the same rule set, so the behavior travels with the repo.

It ships the condensed rule set, a starter list of approved-verb substitutions (obey, not follow; make sure, not ensure; remove, not strip out), and before/after examples the model can anchor on.

Repo: github.com/menonpg/ste-prompt · Landing: ste.themenonlab.com · Discuss on Reddit: r/claudeskills

Install it in Claude Code in one line:

/plugin marketplace add menonpg/ste-prompt
/plugin install ste-prompt@menonlab

Then rewrite anything on demand:

/ste  rewrite the deploy steps above in Simplified Technical English

Borrowed from aerospace, where a misread sentence has consequences. It turns out that is a good bar for agent output too.