Using ASD-STE100 to clean up AI writing and prompts

"To ensure a seamless experience, proactively leverage the retry mechanism when transient rate-limit scenarios arise."

Somebody needs to retry a request. Apparently, they also need to attend a product launch. The sentence gives them neither a delay nor a limit on attempts, but it does sound pleased with itself.

Ruben Hassid's post proposes a short instruction for this kind of writing:

Use ASD-STE100.

ASD-STE100 is Simplified Technical English, a controlled language developed for technical documentation. The name points to a specific collection of vocabulary and writing rules. That makes it a more useful cue than asking a model to "sound less AI", which could mean almost anything.

The public part of Hassid's post shows preferred responses and says the shortcut helps with 80% of chats. It gives no test set, scoring method or compliance audit for that percentage. His examples make the idea worth trying; they do not establish how reliably it works across models and tasks. I could read the public section, not the paid material after it.

For quick drafts, the short cue is convenient. For an application that generates instructions, I would use an explicit writing profile, a domain glossary and checks that the answer preserves the source. For formal STE documentation, the complete standard and a qualified review belong in the process.

The distinction becomes useful when the model removes a condition along with the fluff. "Retry after 60 seconds" is wonderfully short. It can also be the wrong instruction.

The worked policies and rewrites below are examples written for this article. They let us examine specific changes without pretending that an attractive before-and-after pair is a model benchmark.

What ASD-STE100 actually controls

The official STE site identifies Issue 9, dated 15 January 2025, as the current issue. Its overview lists 53 writing rules and approximately 900 approved words, with provisions for technical terminology.

The vocabulary control is more demanding than choosing short words. An approved word has permitted uses, including its meaning and part of speech. The current FAQ gives a useful example: check is approved as a noun, rather than a verb. It also distinguishes the physical meaning of fall from its use for a numerical decrease. A sentence can be perfectly understandable to a native speaker and still fail these controls.

Software documentation also needs terms such as API, embedding and fencing token. Issue 9 permits technical nouns and technical verbs under defined conditions. A maintained domain glossary lets a writer identify the right term for an operation or component. It also prevents convenient synonyms from obscuring a distinction.

Here are several rules from the Issue 9 manual, paraphrased rather than reproduced as a checklist of the whole standard:

Area	Requirement
Procedural sentences	At most 20 words; normally one instruction per sentence
Instructions	Use the imperative; put a necessary condition before its action
Descriptive sentences	At most 25 words
Descriptive paragraphs	One topic, with at most six sentences
Voice	Use active voice; descriptive passive has an exception when the actor is unknown
Multi-word nouns	Generally at most three words; clarify longer technical nouns

The procedure limit and the description limit serve different kinds of text. A note can explain something without becoming a numbered instruction. The exception for simultaneous actions also matters: separating two actions that must happen together can change the procedure.

Formal word counting has its own conventions for identifiers, units, names and other forms. A whitespace counter in a Python script is an approximate length check. A full compliance process also examines vocabulary, grammar, terminology and the organization of the document.

That is enough to explain why an acronym can steer a model toward more controlled writing. It also explains why copying a few of these rules into a prompt produces a STE-inspired profile, rather than proof of compliance with all of ASD-STE100.

What the two-word prompt asks a model to do

The short instruction delegates most of the interpretation to the model. It must recognize the name, recall relevant rules, decide which apply to the task and follow them while answering the original question. Different models can interpret that request differently. A model might produce short, direct prose while ignoring approved vocabulary or treating every answer as a maintenance procedure.

The plausible mechanism is ordinary instruction following. Naming a familiar writing system supplies a compact cue for a set of stylistic choices. The claim that a particular model has learned those choices well enough to apply them consistently remains something to test. There is no reason to infer a new reasoning capability from the name in the prompt.

Anthropic's prompting guidance recommends clear output constraints, relevant examples and a separation between instructions and supplied context. These principles support making the important requirements explicit. The guidance does not establish that mentioning ASD-STE100 by itself improves factual accuracy.

The standard's maintainers have addressed AI directly. Their June 2026 white paper describes possible benefits in drafting, terminology and translation, alongside variable accuracy in compliance checking and a continuing need for human oversight. It recommends benchmarks and validation. It does not report a percentage improvement from the short prompt.

This is where I would separate three uses:

Use	Suitable setup	What you can reasonably claim
A quick personal draft	The short cue, followed by your own editing	You requested a controlled writing style
Product help, support or generated instructions	An explicit house profile, domain terms, reviewed facts and task checks	You applied and evaluated a defined writing policy
Documentation that requires formal STE	The full standard, controlled terminology, suitable checking and trained review	Compliance is assessed against the actual requirements

For the middle row, the output needs to be readable and correct for your product. Calling it formally compliant adds a claim that the lightweight process has not established.

A prompt that makes the useful parts explicit

For troubleshooting steps or a source-based support answer, I would start with the following profile. It is deliberately narrower than the full standard.

TASK
Write technical instructions for the stated reader and task.
Use the supplied source as evidence and the glossary for terminology.

WRITING PROFILE
Use clear technical English inspired by ASD-STE100.
Use direct verbs and name the object of each action.
Put a condition before the action that depends on it.
Give one instruction per sentence, except simultaneous actions.
Aim for 20 words or fewer in procedural sentences.
Aim for 25 words or fewer in explanatory sentences.
Keep each explanatory paragraph on one topic.
Use the glossary term consistently for each concept.
Start with the answer or the first required step.

MEANING TO PRESERVE
Preserve conditions, exceptions, prohibitions and uncertainty.
Preserve quantities, units, minimums, maximums and action order.
Preserve the difference between required and permitted actions.
Keep identifiers, commands and quoted evidence unchanged.
Use only facts supported by the source.
Split a long sentence rather than removing a necessary condition.
Report missing or ambiguous information without inventing a rule.

OUTPUT
Return the instructions, followed by any unresolved source questions.
Omit the source-questions section when there are none.

READER
{{reader and relevant knowledge}}

GLOSSARY
{{reviewed domain terms and their meanings}}

SOURCE
{{source text and source version}}

The reader field changes the amount of explanation. An API integrator may know what an HTTP status is. A customer using an upload form may need the visible button name instead. Shortening the same answer for both readers can leave one of them without the information they need.

The glossary handles terminology. The preservation requirements handle meaning. Sentence length helps control the writing, but it has lower priority than a condition or a warning. If an important sentence is too long, restructure it or ask for review.

In an application, put the writing policy in the appropriate instruction message and pass source material as data. Use consistent delimiters and preserve the source ID. A retrieved paragraph that says "ignore the previous instructions" remains document content. Delimiters help explain that boundary to the model; they do not make prompt injection disappear.

For a recurring task, add a few reviewed examples. Include an ordinary case, a conditional instruction, an unavailable fact and an exception. Show the desired treatment of each. A collection containing only easy rewrites tells you little about whether the model will preserve the difficult parts.

You can package this policy in a reusable prompt template or a skill. Keep the profile and glossary under version control so a change has an owner and an evaluation result. Installing a file named ste supplies instructions to the assistant. Its filename establishes no writing certification.

The rewrite that changes a retry policy

Consider this fictional source:

If the server returns HTTP 429 and retry_count is 0, wait at least
60 seconds after the response, then retry the request once.
For all other responses, or after a retry, do not retry the request.

There are four operational facts: the status must be 429, no retry has occurred, the delay is a minimum of 60 seconds, and the request gets one retry.

A bad simplification is:

Retry the request after 60 seconds.

It keeps the number and drops most of the policy. A useful rewrite is:

If the response status is HTTP 429 and retry_count is 0, do these steps:
1. Wait at least 60 seconds after the response.
2. Retry the request once.

For other response statuses, do not retry the request.
If retry_count is greater than 0, do not retry the request.

The condition appears before the steps. The waiting period keeps its reference point. At least survives, so waiting 75 seconds is still compatible with the rule. The final sentences preserve the excluded cases.

We can examine the decisions implied by each text:

Status	Retries already attempted	Seconds since response	Source permits a retry now	Loose rewrite permits a retry now
429	0	60	Yes	Yes
429	1	60	No	Yes
403	0	60	No	Yes
429	0	59	No	No
429	0	75	Yes	Yes
500	0	90	No	Yes

For this example, interpret "after 60 seconds" as allowing a retry once 60 seconds have elapsed. A different interpretation of that phrase would add another ambiguity. Under the interpretation above, the loose rewrite disagrees with the source in three of six cases.

Here is a small check of those reviewed interpretations:

def faithful_policy(status, retry_count, elapsed_seconds):
    return (
        status == 429
        and retry_count == 0
        and elapsed_seconds >= 60
    )

def loose_policy(status, retry_count, elapsed_seconds):
    return elapsed_seconds >= 60

cases = [
    (429, 0, 60, True),
    (429, 1, 60, False),
    (403, 0, 60, False),
    (429, 0, 59, False),
    (429, 0, 75, True),
    (500, 0, 90, False),
]

def agreement(policy):
    return sum(
        policy(status, retries, elapsed) == expected
        for status, retries, elapsed, expected in cases
    )

assert agreement(faithful_policy) == 6
assert agreement(loose_policy) == 3

A human maps the prose to these decisions; the code checks the maps against the cases. For generated text, that mapping can be a reviewed answer to a scenario question: "The request returned 403. Can I retry it?" A model that grades its own rewrite can help flag problems, but I would retain reviewed answers for important cases.

There is a subtler trap in permission wording. "You may retry only if both conditions hold" gives necessary conditions. It does not say that those conditions alone grant permission. Another approval requirement might exist. Rewriting it as "If both conditions hold, retry" adds an instruction the source did not contain. The source above explicitly supplies the action, so that issue does not arise in its rewrite.

The distinction matters in agent instructions. A polished sentence can authorize an action that the original text merely limited.

A glossary has to preserve software distinctions

AI writing often rotates through synonyms to avoid repetition. In technical documentation, that habit can make two different components look identical, or one component look like several.

For a job-processing system, a small glossary might look like this:

Term	Meaning for this product	Writing choice
Job	A stored record representing requested work	Keep job for that record
Worker	A process that attempts the work	Name the worker when it performs an action
Lease	Temporary ownership of an attempt	Preserve expiry and ownership conditions
Fencing token	A value checked before accepting an attempt's write	Explain the check without replacing the term with lock
retry_count	The number of retries already attempted for this request	Keep the identifier exactly as written

Replacing fencing token with lock shortens the text and changes the mechanism. Calling the worker a job in the next sentence confuses the actor with the stored object. The glossary gives the model a reason to repeat the accurate term.

The same applies to a cache. A KV cache and a cache of completed responses store different things. "The system remembers the answer" is a poor explanation of KV caching, however friendly it sounds. Define the term, then use it consistently.

Active voice also needs care. If the source says "The record was deleted" and the actor is unknown, a rewrite that says "The worker deleted the record" invents an attribution. Keep the unknown actor visible. Forcing every sentence into a preferred grammatical form can introduce a factual claim.

For code and command examples, preserve the executable text. An editor must not replace --dry-run with --preview because the second phrase sounds simpler. Write a clearer explanation around the command, and check that the explanation describes its actual behavior.

Using the profile in RAG and customer support

The writing step should sit after retrieval and evidence selection. First establish which source and version support the answer. Then write the answer in the chosen style.

Suppose a fictional policy says:

Refund requests submitted within 30 calendar days of delivery
are eligible for review. Approval depends on the inspection result.

This answer changes the policy:

Apply within 30 days and you will receive a refund.

It turns eligibility for review into approval, removes the start of the time period and drops calendar. A better answer to "How do I ask for a refund?" is:

Submit the refund request within 30 calendar days of delivery.
Requests submitted within this period are eligible for review.
Approval depends on the inspection result.

The relevant reading questions are concrete: When does the period start? Are the days calendar days? Does submitting the request guarantee approval? The source and the answer should support the same replies.

Research on simplification gives a reason to make this check explicit. Evaluating Factuality in Text Simplification examines unsupported additions and information omitted during simplification. Do Text Simplification Systems Preserve Meaning? uses reading-comprehension questions to evaluate preservation. These papers concern simplification systems; they do not benchmark the ASD prompt. Their evaluation problem is directly relevant to a rewrite stage.

I would retain an evidence record before generating the prose:

{
  "source_id": "refund-policy-v3",
  "facts": {
    "window_days": 30,
    "day_type": "calendar",
    "window_starts_at": "delivery",
    "outcome": "eligible_for_review",
    "approval_depends_on": "inspection_result"
  }
}

These fields are an application design for the example. They make the distinctions visible to reviewers and checks. A model can still extract a wrong field, so the extraction stage needs validation too.

Anthropic's source-grounding guidance recommends locating supporting evidence, checking claims and allowing missing-information responses. Those requirements should survive the style instruction. If the retrieved policy does not say whether a particular product qualifies, a direct answer can say that information is unavailable. It should not fill the gap with a cheerful promise.

Keep exact quotations exact. A simpler paraphrase can sit beside the quotation, with its own label, rather than silently altering the evidence. Preserve citations and document versions in the application record.

If you experiment with simplified text for indexing, store it as a derived representation linked to the original source. Compare retrieval results before relying on it. Removing an exception or a product-specific term can affect which passage a request retrieves. The writing standard supplies no guarantee that a rewritten passage will be a better embedding input.

Function descriptions and agent instructions

Controlled writing can help expose the difference between a tool that checks something and a tool that changes it. That difference is useful to an LLM choosing a function.

A description such as "Seamlessly handle refund workflows" gives the model little to work with. Here are two more useful descriptions for fictional tools:

[
  {
    "name": "check_refund_eligibility",
    "description": "Check whether an order meets the refund policy. Use this function when the user asks whether an order qualifies. It returns the eligibility result and reasons. It does not issue a refund."
  },
  {
    "name": "issue_refund",
    "description": "Issue an approved refund for an order. Use this function after eligibility and the required approval have been verified. It returns the refund ID and status."
  }
]

The descriptions identify the capability, the selection condition and the effect. Those details earn their words. Anthropic's tool-definition guidance asks for this kind of detail and recommends several sentences. Compressing every function into a three-word label would remove information the selector needs.

Keep parameter types and allowed values in the actual tool schema. Preserve function names and IDs even when revising their descriptions. Application code checks eligibility, approval and argument validity before a tool changes an order. A prose instruction to verify approval is useful context; the application must enforce that requirement.

For returned data, use an appropriate constrained-output feature where available, followed by schema and business-rule validation. Structured output documentation describes enforcing an output shape. It addresses a different property from the writing profile. A perfectly shaped object can still contain the wrong selected tool or an unsupported fact.

Multi-action requests add another preservation requirement. "Check whether this order qualifies, and email me the result" contains two tasks. Rewriting it to "Check the refund" drops the email request. Preserve each action, its arguments, and any condition or ordering dependency.

For a classifier or embedding router, I would keep the original request alongside any normalized form. Compare routing accuracy and recall on both, including negation and compound requests. Rewriting all inputs into short English can erase the distinctions your router learned. The intent-routing article covers that classifier-versus-retrieval choice in more detail.

English simplification and multilingual applications

ASD-STE100 controls English. Applying its name to a Portuguese or Spanish answer does not establish a controlled-language standard for that output.

For multilingual support, specify the response language and maintain reviewed terminology for each language. Preserve function IDs, status codes, product names and quantities across the language boundary. Decide separately how to present dates, units and local conventions.

Consider this invented request:

Cancela el pedido 5901, pero no cierres mi cuenta.

It asks to cancel an order while preserving the account. An English working translation must retain both the requested action and the prohibition. A normalization that extracts only "cancel account" has changed the task before the model writes an answer.

An English intermediate representation can be useful when the application already operates on reviewed English facts. It also introduces another transformation to check. If the user supplied 05/06/2026 without a known date convention, preserve the ambiguity or ask which date they mean. A tidy rewrite should not guess the month.

I would evaluate each language and mixed-language requests separately. Include local product vocabulary, informal messages, negation and multiple actions. The practical value of controlled source English for translators is a reasonable motivation for testing it, not a promise of equal translation quality across languages.

The STE maintainers discuss multilingual consistency as a possible AI benefit in their white paper. Their emphasis on oversight applies here too: simplifying an English source and checking the translated result are separate pieces of work.

Fine-tuning a model on cleaner writing

A recurring task can eventually justify training examples that embody the profile. I would establish the prompt-and-glossary baseline first, then look at the errors that remain. If a model repeatedly ignores the same output requirements despite adequate facts and instructions, supervised adaptation becomes a plausible experiment.

For a rewrite dataset, each example needs the source, the intended reader, the terminology in force and a reviewed target. Include exceptions, uncertain evidence, unknown actors and awkward conditions. Targets that merely sound concise can teach the model to omit exactly the material you need preserved.

Keep the source version and reviewer decisions with the example. If a reviewer changed a minimum delay into an exact delay, the resulting training pair contains a semantic error even when every sentence passes a length check.

Avoid splitting lightly edited versions of the same document between training and evaluation. Hold out source documents or document families when the claim concerns generalization to new material. Reserve unseen domain terms if the application must cope with new terminology. Evaluate faithfulness and task decisions alongside the writing profile.

Automatic rewrites can supply draft targets for review. Keeping all of them because they score well on short sentences would reward the easiest measurable property. Training on an incorrect promise of approval does not become a good idea because the promise uses approved-looking words.

The full STE manual and dictionary are copyrighted. Free access is not an open-source license. Read the relevant usage permissions before redistributing material or using it in a training pipeline. This article links the official sources and supplies original examples; it does not publish the dictionary or a replacement manual.

How I would evaluate the prompt

The question is whether the defined task improves. "Sounds less AI" is a useful reader preference, but it is too vague to carry the whole evaluation.

Compare four configurations on the same source cases: your current prompt, a plain-English instruction, the short ASD cue, and the explicit profile with glossary and examples. Record the actual prompt versions. Keep the model version, supplied context and generation settings fixed where possible. Repeat cases when output variability matters.

For a small pilot, I would include material from actual task categories: procedures, explanations, missing information, conditions and exceptions, and domain terminology. Add adversarial cases based on plausible editing mistakes. The retry and refund examples above suggest several without needing a large dataset.

Give reviewers the source and rewritten text without revealing which prompt produced it. Ask specific questions before asking which version they prefer:

Property	Check	Failure example
Supported facts	Does each factual proposition have source support?	An unknown actor becomes a named worker
Required facts	Are the annotated conditions and limits present?	The retry limit disappears
Decisions	Do scenario answers match the reviewed source answers?	A 403 response becomes retryable
Permission and obligation	Does the output preserve what is allowed or required?	Eligibility becomes approval
Terminology	Does the output use the correct domain term?	A fencing token becomes a lock
Writing profile	Does the output meet the chosen length and structure rules?	A condition is buried after the action
Output format	Does the response validate against the required schema?	A required ID is missing
Reader usefulness	Can the intended reader find and complete the task?	Short steps omit a needed prerequisite

For required-fact coverage, count how many reviewed facts the answer retains out of how many the case requires. Keep incorrect additions as a separate count. An answer can retain all required facts while adding a false guarantee.

For decision agreement, count scenarios with the same permitted or required action as the source. Use reviewed answers to questions such as "Can the request be retried now?" and compare the actions that each answer permits.

Report how many cases pass all required checks, describe the failures and break results down by task category. If one failure could trigger a wrong operation, its severity matters more than the average style score.

Anthropic's evaluation guidance supports task-specific criteria, edge cases and a choice of code, human or model-based checks. Use deterministic checks for exact IDs, numbers, schemas and known decision cases. Use qualified review for meaning and full STE assessment. A second model can assist review, but agreement between two models can still preserve the same mistake.

The official STE software guidance also places limits on automated checking. Domain terminology and expert judgment remain relevant, and ASD does not endorse or certify the tools. A useful checker should report what it examined, rather than award a generic green tick to the entire document.

A sentence-length check can be one part of that report. Keep it separate from the factual checks so a short answer cannot compensate for a missing prohibition.

Cost, defaults and where to keep a human voice

The short cue adds little input text. An explicit profile, glossary, examples and a verification stage add more. Any reduction in output length has to be compared with those extra input tokens and calls. Words, model tokens and elapsed time are different quantities; estimate cost from the actual tokenizer and pricing for the deployed model.

For a support application, record end-to-end latency, input and output tokens, correction attempts and the share of answers sent for human review. Reuse a stable profile across requests where the provider supports suitable caching, but measure the complete workflow. The earlier KV cache article explains why repeated prefix work and answer generation have different costs.

Here are the defaults I would actually use:

Task	Writing choice	Reason
Runbook or troubleshooting procedure	Explicit STE-inspired profile, reviewed terms and decision tests	The reader needs conditions and actions in a usable order
Source-based customer support	Plain, direct answer with the profile applied to instructions	Preserve evidence and avoid turning a policy limit into a promise
Tool description	Direct capability, selection criteria, parameters and effects	The selector needs enough detail to distinguish nearby tools
A longer technical explanation	Plain English, accurate terms and selective use of procedural rules	The reader also needs relationships, examples and context
A personal essay or a joke	An ordinary editorial brief and human editing	A maintenance-writing profile can flatten the intended voice
A quotation or executable command	Preserve the original text	The exact wording or syntax is part of the evidence
Formal STE documentation	Full standard, maintained glossary and trained review	The compliance claim concerns more than prose style

For an essay, "Use concrete examples and remove filler" can be a better instruction than imposing a procedure format on every paragraph. A little variation in sentence length helps a long explanation read naturally. Technical accuracy and a consistent glossary are still useful.

A support answer can also acknowledge a frustrating problem without performing enthusiasm. "The upload failed because the file exceeds the 20 MB limit" tells the reader something. "I understand how important a seamless upload experience is" adds length while avoiding the cause. If the cause is unknown, say what is known and what to check next.

That is where the ASD idea earns its place in applied AI. It gives us concrete ways to control writing that users must act on. The engineering work is preserving the facts, permissions and conditions while removing the verbal padding. A shorter wrong instruction is still the wrong instruction, and now the reader reaches it faster.