What is ASD-STE100, and how do I keep the prose true in CI?

ASD-STE100 is a controlled language from ASD. It restricts vocabulary and grammar so a sentence has one meaning. That is the same goal as a requirement: read one way, and a test can check it. Wikipedia files it under Simplified Technical English. The official site sells the Issue 9 dictionary. Acrolinx and the ASD trainers teach writers. This page is the lint: six structural rules on the YAML the audit already reads.

The writing-rules H1 lives on the INCOSE Guide for Writing Requirements. The compiler H1 lives on FRETish. FRETish is already a controlled form. STE100 does not rewrite the formula. It scans description, rationale, stakeholder story, and acceptance-criteria text, plus the same fields on known issues, problem reports, changes, concerns, accepted risks, mirrors, and vectors.

proof lint --check spec_lint_prose_ste100
proof lint --check spec_lint_prose_ste100 --format json
proof audit --check spec_lint_prose_ste100 --verbose
proof help spec_lint_prose_ste100

On this install the teaching sentence is a parser bound. The miss is the hedge. Until the lint runs, CI cannot fail when "might" lands in the description.

The teaching requirement is SYS-REQ-014. The description still says the parser might reject oversized input. That is S4. The rewrite is three testable sentences.

id: SYS-REQ-014
description: the parser might reject oversized input

proof/specs/system/requirements/SYS-REQ-014.yaml lint-prose-ste100: SYS-REQ-014 description S4 hedge "might" weakens the claim. Fix: state the concrete condition a reviewer can check instead.

id: SYS-REQ-014
description: |
  The parser shall bound time and memory per call.
  The parser shall reject an input larger than 64 KiB.
  A rejected input shall not stop other requests.

The six rules, each independently toggleable: S1 sentence length (25 words descriptive, 20 procedural), S2 more than six sentences in a field, S3 a be-form plus -ed/-en that reads as passive, S4 hedge phrases, S5 chained imperatives on procedural fields, S6 your restricted_terms. Titles get S1, S4, and S6 only. History, log, and waive reasons stay out of scope. Findings are capped at ten listed per run. The check is default-on at warning. Only disabled: true opts a project out.

The default incumbent engine has no dictionary data. Rule 6 of the standard (approved, plain words) stays a human sweep unless you set engine: library, and even then you still need a domain dictionary or the scan floods. Canonical vague words such as "appropriate" remain human-sweep scope. S3 is a heuristic, not a parser: it matches a be-form plus a word ending in -ed or -en, so it over- and under-approximates true English passive. The message says the sentence reads as passive. Reviewers judge. Proof is not an official ASD trainer. Proof does not sell Issue 9. A warning is not a build fail until you raise the severity. We have not run this against a frozen ASD or Acrolinx corpus. The loss is named, not scored.

The writing-rules H1 stays on the INCOSE Guide for Writing Requirements. The compiler H1 stays on FRETish. Jama still authors.

What is Simplified Technical English? The Wikipedia name for ASD-STE100. Same URL. Do not mint a twin.

What is the INCOSE Guide for Writing Requirements? The writing-rules document. Different H1. INCOSE GtWR.

What is FRETish? The structured English that compiles. STE100 does not rewrite the formula. FRETish.

What is a software requirements specification? The artefact that lists the shalls. SRS.

Is Proof an ASD-STE100 trainer? No. Jama still authors. Proof lints the sentence so CI can fail when a hedge lands in the YAML.