---
name: simplified-technical-english
description: ASD-STE100 principle subset for procedural/technical docs — imperative one-instruction sentences, ≤20/25 words, one word = one meaning, warnings before steps. Load when writing or reviewing runbooks, deploy docs, handoff steps, completion briefs, error messages, UI microcopy.
---

# Simplified Technical English (ASD-STE100 principles)

**When to load:** writing or reviewing procedural/technical documentation — runbooks,
deploy docs, agent handoff implementation steps, completion briefs, README/ops docs,
error messages, UI microcopy.

**When NOT to apply:** stakeholder emails (each audience keeps its own language — planner
language for an operator, value framing for a sponsor), call packs, spec rationale/trade-off sections, anything persuasive or
relationship-carrying. STE is for documents a reader must *execute or act on without
ambiguity*, not documents that argue or persuade.

## Why this exists (04 Aug 2026)

LLM-written docs drift into slop: hedging, synonym cycling ("check / verify / validate /
ensure" for the same act), adjective inflation, passive fog, meandering paragraphs.
ASD-STE100 (the aerospace/defence Simplified Technical English standard — note: **ASD**,
often mistyped ADS) bans each of these *mechanically*, so quality becomes a checkable
constraint instead of taste. We adopt the principle subset below — not certified STE
(full compliance needs the official controlled dictionary, free on request from
asd-ste100.org).

## The rules (adopted subset)

Structure:
- One topic per paragraph. Maximum 6 sentences per paragraph.
- Procedural sentences ≤ 20 words. Descriptive sentences ≤ 25 words.
- One instruction per sentence.
- Warnings and cautions come BEFORE the step they protect, written as commands.

Sentences:
- Instructions are imperative: "Remove the lock file", never "the lock file should be removed".
- Active voice. Name the actor: "The deploy workflow restarts the service", not
  "the service is restarted".
- Simple tenses only (past, present, future). Avoid gerund/-ing constructions where a
  finite verb works.

Words:
- One word = one meaning, used consistently. Pick ONE verb per action for the whole
  document (e.g. always "check", never rotating through verify/inspect/confirm).
- Call a thing by one name everywhere. No elegant variation ("the database / the store /
  DuckDB" → pick one).
- Use an article ("the", "a") before nouns — dropped articles read as slop-telegraphese.
- Prefer the short common word: "use" not "utilise", "start" not "initiate", "do" not
  "perform".
- No hedging fillers ("simply", "just", "basically", "as needed", "should probably").
  If a condition matters, state it; if not, delete it.

## Review checklist (fast pass over any doc in scope)

1. Any sentence over ~20/25 words? Split it.
2. Any passive step? Rewrite imperative.
3. Same action named two ways? Unify.
4. Any warning after its step? Move it before.
5. Any filler adverb or hedge? Delete or replace with the actual condition.

## Provenance

Written 2026-08-04 from a public rule of thumb (source: a tweet — "You can get
LLMs to write good non-AI-slop-sounding technical documentation by requiring them to
adhere to ASD-STE100 Simplified Technical English"). Passive reference — load on
demand, never injected.