Sung J. Kang
sjk@sungjkang.com:~/writing $  
2026-09-24 writingaistandards 4 min read

ISO 24495-2 and ASD-STE100 Against AI Slop

AI-generated prose has a specific signature. It hedges instead of stating a claim. It clears its throat before getting to the point. It hides the actor behind passive voice. None of this is new. Two existing standards already solved this problem for legal writing and technical writing, years before anyone needed to fix an LLM’s output.

ISO 24495-2 is the plain language standard for legal communication, published in 2025. It builds on ISO 24495-1, which set general plain language principles in 2023. The standard exists because legal documents share the same failures as AI text: passive voice that hides who did what, and nominalizations that turn actions into nouns. Obligations end up buried three clauses deep. ISO 24495-2 forces writers to address the reader directly, use active voice, and put one idea per sentence.

ASD-STE100 solves a narrower problem. It’s Simplified Technical English, built by the aerospace industry for maintenance manuals. A mechanic reading a repair procedure can’t afford ambiguity, so STE100 restricts the vocabulary to a fixed dictionary and assigns each approved word exactly one meaning. You can’t write “close” to mean both “shut” and “near” in an STE100 document. You pick one meaning and use a different word for the other.

Both standards fix the same failure that produces AI slop. No rule forces specificity, so the writer defaults to hedging. Give a writer, human or model, a constraint that requires naming an actor and picking one meaning, and the slop has nowhere left to hide.

Here’s a paragraph explaining an API rate limit, first as typical AI slop, then rewritten under each standard.

AI slop:

In today’s fast-paced API landscape, it’s important to understand that rate limiting isn’t just a technical detail, it’s a critical part of ensuring platform stability and a great experience for everyone involved. Generally speaking, most requests will complete successfully, but in certain circumstances, particularly during periods of high traffic, your requests may be throttled by the system. It’s worth noting that this isn’t necessarily indicative of a problem with your integration, but rather a feature designed to protect the platform for all users. If you find that you’re being rate limited, you might want to consider implementing an exponential backoff strategy, which is generally considered a best practice within the industry.

Under ISO 24495-2:

Your account can send up to 100 requests per minute. If you exceed that limit, we reject the extra requests and return a 429 status code. You must wait before retrying. We recommend exponential backoff: double your wait time after each rejected request. This limit protects the platform for every account, including yours.

Under ASD-STE100:

The limit is 100 requests each minute. If you send more than 100 requests in one minute, the system rejects the extra requests. The system sends error code 429 for each rejected request. Wait before you send the request again. Increase the wait time after each rejected request. This procedure has the name exponential backoff.

I’m not a certified STE100 checker, so treat that last one as directionally accurate, not certified compliant. The vocabulary restriction alone would take a real dictionary lookup to get exactly right.

The ISO version keeps normal sentence variety and still reads like prose, since plain language for legal communication is written for someone reading a contract or a policy, not following steps. The STE100 version breaks every sentence into a single action and drops connecting words, since it’s written for someone mid-repair with a manual open. Neither sounds like marketing copy. Both are shorter than the original despite adding no new information, because slop is the extra words.

I run technical explanations through STE100’s constraint when I want the shortest accurate version. I use ISO 24495-2’s when I’m writing something with a real obligation attached, like a terms of service page or a runbook people are on the hook to follow. Neither replaces editing. They give you a rule to point at the moment a sentence starts hedging.