ASD-STE100 — Simplified Technical English

Write English in ASD-STE100 Simplified Technical English. STE is a controlled language. The aerospace industry built it so a reader who cannot ask a follow-up question still reads the text one way only. The rules are countable. Check your prose against them as you write.

When to use

• A skill requires it. The visual-explainer and visual-plan skills require it for every human-readable string in their output.
• The user asks for Simplified Technical English, or for plain, unambiguous prose.

Precedence

These rules set the default shape of the English you write. A more specific instruction takes precedence on whatever it addresses. This includes an instruction from the user, from project instructions, from an invoked skill, or from an established convention in the file you edit. Where the more specific instruction is silent, these rules apply.

Follow the more specific instruction without comment. Do not cite this style as a reason to override it. Do not ask permission. This exception applies to an explicit instruction only. Do not relax these rules because a topic feels casual or because other prose seems friendlier.

Never apply these rules to

• Code. This includes identifiers, syntax, and string literals.
• Quoted material. This includes error output, command output, file contents, and another person's words. To rewrite a quotation is falsification, not simplification.
• Text where the exact wording carries the meaning. This includes a command to run, an API name, a config key, and an exact error string.

Rules

Headings and titles

A heading names its subject. It is not a slogan. A reader who sees only the heading must understand what the section is about.

• Name the real workflow, system, page, endpoint, or step.
• Do not write a marketing phrase, a tagline, or an abstract slogan.
• Bad (slogan): "From customer task to phone conversation".
• Good (plain): "How the phone-call workflow works".

This rule applies to every title, scene heading, and section heading.

Project vocabulary

STE permits a project to define its own approved vocabulary of technical nouns and verbs. A CONTEXT.md file at a repository root is that vocabulary.

If the project has a CONTEXT.md, use its terms exactly as it defines them, in the part of speech it defines. Never substitute a synonym for a term it defines. Never use a word that its _Avoid_ lines reject. Do not redefine its terms inline, because the glossary is the definition.

If the project has no CONTEXT.md, do not invent one. Do not present any term as already established. The rules above apply without change: define a term at first use, prefer the plainest word, and use one term for one concept.

Length is not terseness

The caps apply to each sentence, not to the response. Clarity is the goal, not concision. A long answer in short sentences is correct.

Never drop a fact, a condition, a caveat, or a scope qualifier to meet a limit. Split the sentence instead.