Plain English is a number
Every support prompt has a line asking for simple language. It reads like a standard, and it is the one rule in the file the model gets to mark for itself.
TL;DR A rule that says use simple language leaves the model to decide what simple means, so write plain English as things you can count and name: a word limit per sentence, a sentence limit per reply, and a glossary rule for each term your customers do not use.
Harbour Energy’s chat assistant, Pip, answers billing questions for a gas and electricity supplier. The content design team wrote its tone section after a review of complaints: customers did not understand the replies. So the prompt asks for simple language, no jargon, and clarity. A year later the metering team added one line of their own for smart meter faults. Everyone involved meant well, and every line reads fine.
§1The plain-language section that checks clean
# Role You are Pip, the support assistant for Harbour Energy. # Constraints - MUST use simple language. - MUST avoid jargon. - MUST be clear and easy to understand. - MUST keep every reply to at most 4 sentences. - WHEN the customer asks about a smart meter fault THEN MUST use technical language.
$ typeglish check pip-before.tg pip-before.tg:7:1 warn prompt/unmeasurable Unmeasurable rule — no observable action or bound, so nothing can check compliance. Name a concrete action ("cite the source", "at most 3 sentences") or move it to a prose block. ✓ 1 file — 0 error, 1 warning, 0 info $ typeglish score pip-before.tg pip-before.tg — C (79/100) proven errors: none tiers: base+z3 planes runtime 88 (what the model reads) · hygiene 50 (source only) facets enforceability 79 x.21 · hardness 100 x.12 · directness 98 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 0 x.12 (hygiene) · style 50 x.08 · security 100 x.08 lever annotation 0/100 (up to +12 overall) — 6 statements without a @@ note (L2 L5 L6 L7 L8 L9) — put a "@@ why" line directly above each rules 5 of 5 rule-shaped lines read · 3 not provable · 1 unmeasurable L5 ~ unprovable MUST use simple language. the checker knows "use" but cannot prove this shape: "use" is a light verb with nothing bound to it → name the tool or object it acts on (call @[tool], make a note) L7 ~ unmeasurable MUST be clear and easy to understand. no observable action or bound, so nothing can check compliance → name a concrete action or a bound ("at most 3 sentences") L9 ~ unprovable WHEN the customer asks about a smart meter fault THEN MUST use technical language. the checker knows "use" but cannot prove this shape: "use" is a light verb with nothing bound to it → name the tool or object it acts on (call @[tool], make a note) $ typeglish statements pip-before.tg - MUST use simple language. Requires Pip to use simple language. partial coverage; ~7 tokens; 0 diagnostics; 0 relations - WHEN the customer asks about a smart meter fault THEN MUST use technical language. When the customer asks about a smart meter fault: Requires Pip to use technical language. partial coverage; ~20 tokens; 0 diagnostics; 0 relations
The checker flags the line that is obviously empty: be clear and easy to understand names no action and no bound, so it gets prompt/unmeasurable. The other two style lines pass because they have a verb. Use is a verb. It is just one with nothing attached that anybody could measure.
§2Simple, according to whom
A rule is something you could check against a transcript. Try that with line 5. Take a reply Pip wrote about a standing charge and ask whether it used simple language. The content designer says no: it said standing charge. The billing lead says yes: that is what the bill calls it. The model, which wrote the reply, already thinks yes, because it chose those words while trying to follow the rule.
That is the problem with an adjective standing in for a standard. It does not tell the model anything it was not going to do anyway. Every model already believes its replies are clear. Use simple language asks it to keep doing what it thinks it is doing, and leaves the definition of simple to the reader with the least idea what your customers find hard.
It also cannot conflict with anything. Line 9 asks for technical language, and to a person that reads as the opposite of line 5 for every smart meter chat. The checker sees two rules with the light verb use and nothing it can bind, so it relates them to nothing. The model gets both and picks per chat.
If two people can read the same reply and disagree about whether it followed the rule, the rule is a preference with a MUST in front.
§3Length is the part you can count
Most of what plain-language guidance actually asks for is length. Short sentences. Short replies. One idea at a time. Those are numbers, and numbers are the thing a checker is good at. Why your agent writes an essay in a chat bubble makes the same move for reply length: count it in sentences and the rule becomes something the checker can compare.
So the first rewrite is to put a number on the sentence. Plain-language style guides each set their own target; use the one your content team already uses, and write it down as a bound. The payoff shows up the first time someone else writes one too. Here is the accessibility review, six months later, adding the limit from their own guide below the one content design wrote:
# Role You are Pip, the support assistant for Harbour Energy. # Constraints - MUST keep every sentence to at most 15 words. - MUST keep every reply to at most 4 sentences. - MUST keep every sentence to at most 20 words.
$ typeglish check pip-two.tg pip-two.tg:5:1 error logic/quantifier-strength Conflicts with line 7. One rule, two counts — "keep every sentence to at most 15 words." already sits inside "keep every sentence to at most 20 words." (per sentence); the looser bound is dead weight. Keep the tighter line. ↳ line 7: - MUST keep every sentence to at most 20 words. pip-two.tg:7:1 error logic/quantifier-strength Conflicts with line 5. One rule, two counts — "keep every sentence to at most 15 words." already sits inside "keep every sentence to at most 20 words." (per sentence); the looser bound is dead weight. Keep the tighter line. ↳ line 5: - MUST keep every sentence to at most 15 words. ✗ 1 file — 2 error, 0 warning, 0 info $ typeglish build pip-two.tg typeglish build: pip-two.tg refused — nothing written
Compare that with the adjectives. Use short sentences next to keep every sentence to at most 20 words would ship without a word from the checker, and nobody would know which one the model was following. Once both teams write a number, the disagreement is a proven error with two line numbers on it. That is a conversation between two teams in a pull request, not a coin flip in front of a customer.
§4Jargon is a list of words
Avoid jargon has the same flaw as use simple language: the model decides what counts. But jargon is not a feeling. It is a specific, finite set of words your company uses and your customers do not, and you can find most of them by searching your transcripts for the terms customers ask you to explain. For Harbour Energy that list starts with standing charge, unit rate and MPAN.
Each one gets its own rule, and each rule says what to do instead. A glossary rule that only bans a word leaves the model to invent the replacement; one that names the replacement gives every chat the same wording, and gives you something to assert in a test. Your agent has never heard of a wallboard covers the other direction, the words the model has to understand rather than avoid.
Metering’s line gets the same treatment. They did not actually want technical language. They wanted the code on the meter screen, because that is what the engineer needs. So that is the rule.
# Role @@ role: one sentence names the speaker, so every later "you" is Pip You are Pip, the support assistant for Harbour Energy. # Constraints @@ sentence_length: long sentences are where customers on a phone, or reading in a second language, lose the thread - MUST keep every sentence to at most 15 words. @@ reply_length: four short sentences is one screen of chat on a phone - MUST keep every reply to at most 4 sentences. @@ standing_charge: billing calls it a standing charge; customers ask what the daily fee is - WHEN the customer asks about a standing charge THEN MUST describe it as a daily fixed charge. @@ unit_rate: customers do not know what a unit is - WHEN the customer asks about a unit rate THEN MUST state their price per kilowatt hour. @@ meter_fault: the engineer needs the code the meter shows, and the customer can read it out - WHEN the customer asks about a smart meter fault THEN MUST ask for their error code. @@ mpan: the supply number is in the account, the customer should never have to find it - NEVER ask the customer for their MPAN. $TEST standing_charge_question - input:: What is this standing charge on my bill? I never agreed to it. - expect:: - describes it as a daily fixed charge - contains "daily fixed charge" - at most 4 sentences - matches /^(?![\s\S]*(?:[^.!?\s]+\s+){15}[^.!?\s]+)/ $TEST meter_fault - input:: My smart meter screen is blank apart from an error. What do I do? - expect:: - asks for their error code - matches /^(?![\s\S]*MPAN)/i $TEST unit_rate_question - input:: Your letter says my unit rate is going up. What does that mean in money? - expect:: - states their price per kilowatt hour - contains "per kilowatt hour"
standing_charge_question fails any run of 16 words with no full stop, question mark or exclamation mark between them, so the 15-word limit is checked on every live run, not just read.$ typeglish check pip.tg ✓ 1 file — 0 error, 0 warning, 0 info $ typeglish score pip.tg pip.tg — A (99/100) proven errors: none tiers: base+z3 planes runtime 98 (what the model reads) · hygiene 100 (source only) facets enforceability 100 x.21 · hardness 100 x.12 · directness 83 x.08 · consistency 100 x.17 · structure 100 x.12 (hygiene) · annotation 100 x.12 (hygiene) · style 100 x.08 · security 100 x.08 lever directness 83/100 (up to +1 overall) — Use the imperative or a named doer ("Verify the order.", "You must ..."), keep the active voice (not "is verified" / "a review must take place"), and make every it/this point at something the prompt introduced. rules 6 of 6 rule-shaped lines read · 6/6 covered by $TEST $ typeglish test pip.tg --dry ✓ pip.tg coverage: 6/6 rules exercised · standing_charge_question — "What is this standing charge on my bill? I never agreed to i" (not run) ✓ contains "daily fixed charge" ✓ at most 4 sentences ✓ matches /^(?![\s\S]*(?:[^.!?\s]+\s+){15}[^.!?\s]+)/ · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · meter_fault — "My smart meter screen is blank apart from an error. What do " (not run) ✓ matches /^(?![\s\S]*MPAN)/i · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · unit_rate_question — "Your letter says my unit rate is going up. What does that me" (not run) ✓ contains "per kilowatt hour" · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) ✓ 1 prompt — 0 failed $ typeglish build pip.tg ✓ built .typeglish/dist/pip.txt ← pip.tg (225b908e307c, full) $ cat .typeglish/dist/pip.txt # Role You are Pip, the support assistant for Harbour Energy. # Constraints - MUST keep every sentence to at most 15 words. - MUST keep every reply to at most 4 sentences. - WHEN the customer asks about a standing charge THEN MUST describe it as a daily fixed charge. - WHEN the customer asks about a unit rate THEN MUST state their price per kilowatt hour. - WHEN the customer asks about a smart meter fault THEN MUST ask for their error code. - NEVER ask the customer for their MPAN.
@@ notes keep the reason for each glossary rule in the source and out of the artifact: the model reads six rules, and the next person reads why.Nothing in the final file says simple. It does not need to. A reply that keeps every sentence under 15 words, stays under four sentences, and swaps out the three words customers complain about is what content design meant by simple. Now it is also what the prompt says.
§5The plain-language audit
Every support prompt has a tone section. This turns it into rules in about half an hour.
- Find the adjectives. Search for simple, clear, plain, easy, concise, jargon. Each one is a standard nobody wrote down.
- Ask what the writer would count. Usually it is sentence length and reply length. Write both as at most N, and use one form for each limit so the checker can compare them.
- Turn jargon into a list. Pull the terms customers ask you to explain out of your transcripts. One rule per term, each naming the word to use instead.
- Find the line that pulls the other way. A technical rule, a legal disclosure, a be thorough. Ask what its writer actually needed, as metering needed the error code, and write that.
- Assert the numbers.
at most 4 sentencesand a sentence-length regex are deterministic asserts. They fail a reply without a judge.
The habit underneath is small. When a rule describes a quality, ask how you would grade a transcript against it. If the answer is a number or a word list, write that down instead. If there is no answer, the line belongs in a prose note for the humans, not in the rules for the model.
§6Common questions
- How do I make my AI support agent use simple language?
- Replace the adjective with things you can count and name. Set a word limit per sentence and a sentence limit per reply, written as at most N, and add one rule per jargon term that names the word to use instead. Then test the limits with deterministic asserts, so a reply that runs long fails without a judge.
- Why does my chatbot still use jargon when the prompt says to avoid it?
- Avoid jargon leaves the model to decide which words count, and it already thinks its own words are fine. Jargon is a specific list: the terms your customers ask you to explain. Give each one its own rule that names the replacement, like describing a standing charge as a daily fixed charge, and assert the replacement in a test.
- Does TypeGlish flag a rule like use simple language?
- Not as an error. In typeglish 0.11.0, MUST be clear and easy to understand gets prompt/unmeasurable, but MUST use simple language checks clean and the score lists it as unprovable, because use is a light verb with nothing measurable bound to it. Word and sentence limits written as at most N are provable, and two limits on the same thing that nest are refused with logic/quantifier-strength.
- What is a good sentence length limit for a customer service chatbot?
- Use the number your content or accessibility team already works to, so the prompt and the style guide agree. Whatever you pick, write it once as at most N words per sentence; if a second team adds a different limit, the checker refuses the build until one is removed.
logic/quantifier-strength is a blocking error: when two bounds on the same thing nest, typeglish build writes nothing until one goes, so two teams’ sentence limits cannot both ship. It only works on bounds the checker can read, which is the argument for writing every limit as at most N. The brand team’s version of the jargon problem is in Teardown: the do-not-say list from the brand team.