> Markdown rendition of https://typeglish.dev/blog/absolutely-never-ablation ("Absolutely never is weaker than never - Tidelines"). Canonical page: https://typeglish.dev/blog/absolutely-never-ablation · All pages: https://typeglish.dev/llms.txt [← Tidelines](https://typeglish.dev/blog)/ Deep dives Oct 17, 2026 # Absolutely never is weaker than never The rule a lawyer asked for is the one in capitals with extra words around it. We took a clean motor-claims agent, rewrote each of its three prohibitions fourteen ways, from a bare NEVER to ABSOLUTELY NEVER and You may not, and then added the edit that contradicts it. by **TypeGlish team** 8 min read #deep-dives Fourteen ways to say never. **TL;DR** The contradiction check defends a prohibition only when it is written plainly: `NEVER`, `Do not`, `Don't` and `You must never` each caught every contradicting edit we added (12 of 12), while `NEVER EVER`, `ABSOLUTELY NEVER`, `under any circumstances`, `You may not` and six other emphatic phrasings caught none of them (0 of 30), and every one of those files still graded A. Write the plain modal, and put the importance in an `@@` note and a `$TEST`. Somewhere in every claims prompt there is a rule a lawyer asked for, and you can tell which one, because it is the one in capitals with extra words around it. *NEVER, under any circumstances, tell the customer who was at fault.* The extra words are there to make the rule stronger for the model. This run measures what they do to the checker, which is the thing that stops the next person to edit the file from quietly reversing that rule. ## §1 The baseline A chat assistant for a motor insurer's claims line: one lookup tool, one length bound, two guarded obligations, and three prohibitions. The three `NEVER` lines are the ones that matter to the business: no liability calls, no settlement figures, no cancelling a policy mid-claim. base.tg - a motor-claims chat agent, three plain prohibitions ✓ A (99/100) ```typeglish $TOOL find_claim - description:: Find a motor claim by its claim reference. - input:: - claim_ref:: string: the claim reference. # Role @@ role: one chat assistant for a motor insurer's claims line You are Remy, the claims chat assistant for Oakmere Motor Insurance. # Constraints @@ brevity: three sentences fits a phone screen - MUST keep every reply to at most 3 sentences. @@ lookup: never answer about a claim from memory - WHEN the customer gives a claim reference THEN MUST call @[find_claim]. @@ fault: liability is decided by the claims handler, not the chat - NEVER tell the customer who was at fault. @@ figure: only the assessor can value a claim - NEVER quote a settlement figure. @@ cancel: cancelling mid-claim can void the cover, so a person does it - NEVER cancel the customer's policy. @@ injury: an injury claim needs a person on day one - WHEN the customer reports an injury THEN MUST escalate to a claims handler. ``` tg check, score and build - base.tg ``` $ npx typeglish check base.tg ✓ 1 file — 0 error, 0 warning, 0 info $ npx typeglish score base.tg base.tg — A (99/100) proven errors: none tiers: base+z3 planes runtime 98 (what the model reads) · hygiene 100 (source only) facets enforceability 95 x.21 · hardness 100 x.12 · directness 97 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 enforceability 95/100 (up to +1 overall) — 1 hard rule it cannot prove (L20): one action, one object, a catalog verb or a bound. The rules table below has the edit per line rules 6 of 6 rule-shaped lines read · 1 not provable L20 ~ unprovable NEVER cancel the customer's policy. "cancel" is not a verb the checker knows → use a verb from the catalog (redirect, escalate, ask, cite …) or add a numeric bound $ npx typeglish build base.tg ✓ built .typeglish/dist/base.txt ← base.tg (1c67ccdd7fa6, full) ``` The cancel rule is the one line the prover cannot hold, because *cancel* is not in the verb catalog. Keep an eye on it: in §2 its plain form still gets defended against a contradicting edit, because that check compares the action phrase, not the proof. ## §2 Fourteen ways to say never Each variant is `base.tg` with one of the three prohibitions rewritten in a different phrasing. Four are plain: `NEVER` itself, `You must never`, `Do not` and `Don't`. Ten are the phrasings people reach for when a rule really matters: an intensifier on the modal (`NEVER EVER`, `NEVER, ever,`, `ABSOLUTELY NEVER`), the legal-sounding clause in three positions (`NEVER under any circumstances`, set off with commas, and trailing at the end), and four ways of saying it as English rather than as a modal (`Under no circumstances`, `You may not`, `You are not allowed to`, `It is forbidden to`). Fourteen phrasings, three rules, forty-two files. Then each file gets the line that arrives later, from somebody who has not read the whole prompt: the guarded opposite of the rewritten rule, added at the top of the section. *WHEN the customer asks who was at fault THEN MUST tell the customer who was at fault* against the fault rule, *WHEN the customer asks what the claim is worth THEN MUST quote a settlement figure* against the figure rule, *WHEN the customer asks to cancel THEN MUST cancel the customer's policy* against the cancel rule. Against `base.tg`, each one is a blocking `logic/contradiction`. the results - each prohibition phrased fourteen ways, then contradicted ✗ 12 of 42 defended ``` # phrasing alone + contradicting edit caught NEVER A (99) logic/contradiction F (81-82) 3 of 3 You must never A (98-99) logic/contradiction F (81) 3 of 3 Do not A (99) logic/contradiction F (81-82) 3 of 3 Don't A (97-98) logic/contradiction F (80) 3 of 3 NEVER EVER A (98-99) passes A (98) 0 of 3 NEVER, ever, A (98-99) passes A (98) 0 of 3 ABSOLUTELY NEVER A (99) passes A (98-99) 0 of 3 NEVER under any circumstances A (98-99) passes A (98) 0 of 3 NEVER, under any circumstances, A (98-99) passes A (98) 0 of 3 NEVER ... under any circumstances. A (98-99) passes A (98-99) 0 of 3 Under no circumstances A (97-98) passes A (97) 0 of 3 You may not A (96-98) passes A (97) 0 of 3 You are not allowed to A (95-96) passes A (95) 0 of 3 It is forbidden to A (95-96) passes A (95) 0 of 3 ``` "Passes" means no error and no warning. Some variants drew one info line, never about the conflict: `prompt/unparsed-rule` on *Under no circumstances* (and on *Don't* before the edit), `prompt/agentless-passive` on *You are not allowed to*, `prompt/declared-later` on *It is forbidden to*. The emphatic files with the contradiction in them grade higher than the plain files do, because the plain files are capped at F for the proven conflict. No phrasing moved the grade by more than a few points on its own, so a rewrite like this passes any score floor you have set. The second column is where the experiment lives. Every plain prohibition, including the mixed-case `Do not` and the contracted `Don't`, defended its rule against all three edits: operators are case-insensitive and the contraction folds. Every emphatic one let all three edits through. The words added to make a rule stronger are the words that took it out of the check. ## §3 The edit that shipped Take the fault rule. Legal wanted it airtight, so it went in as *NEVER, under any circumstances, tell the customer who was at fault.* A quarter later the CSAT dashboard shows customers abandoning chats after asking about fault, and someone on the experience team adds a line to answer the question. The two files differ on one line: line 18. tg check and build - the same edit, two phrasings of line 18 ✗ one refused, one shipped ``` $ diff base-plus-edit.tg emphatic-plus-edit.tg 18c18 < - NEVER tell the customer who was at fault. --- > - NEVER, under any circumstances, tell the customer who was at fault. $ npx typeglish check base-plus-edit.tg base-plus-edit.tg:12:1 error logic/contradiction Conflicts with line 18. Logical conflict — "tell the customer who was at fault" is both required and forbidden. Keep one, or scope the two rules so they cannot both apply (IF THEN ...). ↳ line 18: - NEVER tell the customer who was at fault. ... ✗ 1 file — 2 error, 0 warning, 0 info $ npx typeglish build base-plus-edit.tg typeglish build: base-plus-edit.tg refused — nothing written $ npx typeglish check emphatic-plus-edit.tg --strict ✓ 1 file — 0 error, 0 warning, 0 info $ npx typeglish build emphatic-plus-edit.tg ✓ built .typeglish/dist/emphatic-plus-edit.txt ← emphatic-plus-edit.tg (71757121e721, full) $ grep -n "at fault" .typeglish/dist/emphatic-plus-edit.txt 5:- WHEN the customer asks who was at fault THEN MUST tell the customer who was at fault. 8:- NEVER, under any circumstances, tell the customer who was at fault. ``` The edit is guarded and the prohibition is not, so the two collide every time a customer asks about fault. In the plain file that is a refused build. In the emphatic file it is three lines apart in the artifact the model reads, and the model settles it one chat at a time: the failure in [Your prompt argues with itself](https://typeglish.dev/blog/prompt-contradictions), with `--strict` green. Stripped to the two rules, the pair is small enough to paste into the playground. pair-plain.tg - NEVER ✗ logic/contradiction ```typeglish # Role You are Remy, the claims chat assistant for Oakmere Motor Insurance. # Constraints - WHEN the customer asks who was at fault THEN MUST tell the customer who was at fault. - NEVER tell the customer who was at fault. ``` pair-absolutely.tg - ABSOLUTELY NEVER ✓ clean, B (87/100) ```typeglish # Role You are Remy, the claims chat assistant for Oakmere Motor Insurance. # Constraints - WHEN the customer asks who was at fault THEN MUST tell the customer who was at fault. - ABSOLUTELY NEVER tell the customer who was at fault. ``` The first grades F (70/100) and refuses to build. The second checks with 0 error, 0 warning, 0 info and grades B (87/100); the B is the missing `@@` notes, not the conflict. One word of emphasis is the whole difference. ## §4 What the other signals said If the contradiction check goes quiet, the next place to look is `typeglish review`, which ranks fixes and prints the rules table. It did notice something for most of the emphatic phrasings. It never noticed the conflict, and for one phrasing it noticed nothing at all. tg review - three emphatic phrasings, three different stories ``` $ npx typeglish review emphatic-plus-edit.tg emphatic-plus-edit.tg — A (98/100) → A (100) projected if every fix below lands check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +2 make L18 L22 provable — one verb the checker knows, one object, or a bound (the rules table names each edit) RULES 7 of 7 rule-shaped lines read · 2 not provable L18 ~ unprovable NEVER, under any circumstances, tell the customer who was at fault. "" is not a verb the checker knows → use a verb from the catalog (redirect, escalate, ask, cite …) or add a numeric bound ... $ npx typeglish review absolutely-plus-edit.tg absolutely-plus-edit.tg — A (99/100) → A (100) projected if every fix below lands check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +1 make L22 provable — one verb the checker knows, one object, or a bound (the rules table names each edit) RULES 7 of 7 rule-shaped lines read · 1 not provable L22 ~ unprovable NEVER cancel the customer's policy. ... $ npx typeglish review maynot.tg maynot.tg — A (96/100) → A (99) projected if every fix below lands check: 0 error, 0 warning, 0 info tiers: base+z3 FIXES ranked by projected gain +2 commit the 1 soft statement ("may" on L16) to MUST / NEVER / ALWAYS / REQUIRE / ENSURE — or keep the word if it is a permission by design — up to hardness 100 ... ``` `NEVER, under any circumstances,` leaves the rule with no verb the checker can find, so the rules table flags it as unprovable, worth +2. `ABSOLUTELY NEVER` is listed as read and provable, and the only fix offered is the unrelated cancel line. `You may not` is read as the permission `MAY`, and the fix asks whether it is "a permission by design". Those three are worth separating. The comma-and-clause forms break the parse, and the rules table says so, at the volume of a +2 suggestion. *ABSOLUTELY NEVER* is the quiet one: the rule is counted as a hard, provable prohibition, it does not even register as a duplicate of a plain `NEVER` on the same action, and nothing in the report points at it. *You may not* is the one that reads backwards. To an English speaker, and to the model, it is a prohibition. To the checker it is `MAY` with a `not` after it, a soft permission, and a soft side never meets a hard one in the contradiction check, which is the effect measured in [Soften a rule and it stops being graded](https://typeglish.dev/blog/deontic-force-ablation). None of these signals blocks a build, and none of them mentions the edit that contradicts the rule. A team that gates on `check` exit codes, or on `score --min B`, ships every emphatic file in this run. > Emphasis is for the model. The checker reads the modal, and a modal with company is a modal it stops comparing. ## §5 Put the weight where it holds The fix is not to stop caring which rules matter. It is to put that information somewhere the checker can use it, or at least somewhere it does no harm. Three places work. The modal stays bare, so the rule stays in the contradiction check. The reason goes in the `@@` note, which every editor sees and the model never does. And the behaviour you are most afraid of losing gets a `$TEST`, which is the only one of the three that says what the agent should actually produce. The same move for `IMPORTANT:` and `CRITICAL` labels is in [How to mark a rule as important in an agent prompt](https://typeglish.dev/blog/mark-rule-important). With the plain modal back, the experience team's edit is refused again, and the refusal forces the real decision: what should Remy do when a customer asks about fault? Not answer it, and not stonewall either. Send it to the person who decides. fixed.tg - plain prohibitions, the reason in the note, the fear in a test ✓ A (99/100) ```typeglish $TOOL find_claim - description:: Find a motor claim by its claim reference. - input:: - claim_ref:: string: the claim reference. # Role @@ role: one chat assistant for a motor insurer's claims line You are Remy, the claims chat assistant for Oakmere Motor Insurance. # Constraints @@ brevity: three sentences fits a phone screen - MUST keep every reply to at most 3 sentences. @@ lookup: never answer about a claim from memory - WHEN the customer gives a claim reference THEN MUST call @[find_claim]. @@ fault: the rule that matters most here; liability is decided by the claims handler, and one sentence from the chat can be quoted against the policyholder - NEVER tell the customer who was at fault. @@ fault_question: a question about fault goes to the person who decides it - WHEN the customer asks who was at fault THEN MUST escalate to a claims handler. @@ figure: only the assessor can value a claim - NEVER quote a settlement figure. @@ cancel: cancelling mid-claim can void the cover, so a person does it - NEVER cancel the customer's policy. @@ injury: an injury claim needs a person on day one - WHEN the customer reports an injury THEN MUST escalate to a claims handler. $TEST fault_question - input:: The other driver went into the back of me. That makes it their fault, right? - expect:: - escalates to a claims handler - matches /^(?!.*(your|their) fault)/i $TEST worth - input:: Roughly what will I get for the car? Ballpark is fine. - expect:: - does not quote a settlement figure - matches /^[^0-9]*$/ ``` tg score and test --dry - fixed.tg ``` $ npx typeglish score fixed.tg fixed.tg — A (99/100) proven errors: none tiers: base+z3 planes runtime 98 (what the model reads) · hygiene 100 (source only) rules 7 of 7 rule-shaped lines read · 1 not provable · 4/7 covered by $TEST ... $ npx typeglish test fixed.tg --dry ✓ fixed.tg coverage: 4/7 rules exercised uncovered (no case shares the rule's wording): L12 keep every reply to at most 3 sentences. L14 call @[find_claim]. L22 cancel the customer's policy. · fault_question — "The other driver went into the back of me. That makes it the" (not run) ✓ matches /^(?!.*(your|their) fault)/i · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) · worth — "Roughly what will I get for the car? Ballpark is fine." (not run) ✓ matches /^[^0-9]*$/ · rubric — 1 prose expectation, judged on a live run (needs ANTHROPIC_API_KEY) ✓ 1 prompt — 0 failed ``` The two deterministic asserts are the emphasis, made checkable: no reply to a fault question may say *your fault* or *their fault*, and no reply to a valuation question may contain a digit. A live run checks them on every model change, which an all-caps line never could. A useful habit falls out of the table in §2. Before a prompt ships, search it for the words that travel with emphasis: *ever*, *absolutely*, *under any circumstances*, *under no circumstances*, *may not*, *not allowed*, *forbidden*. Each hit is a rule the author cared about most and the checker is defending least. Rewrite it to the bare modal, move the feeling into the note, and add the test. It is the same audit as the one for [make sure to and remember to](https://typeglish.dev/blog/remember-to-ask), run on the other end of the rule. ## §6 Common questions **Does writing NEVER EVER or ABSOLUTELY NEVER make my AI agent follow a rule more strictly?** There is no guarantee it changes what the model does, and it does change what the checker does. In this run, NEVER EVER, NEVER, ever, and ABSOLUTELY NEVER each let a contradicting edit through on all three rules tested, with the file still graded A, while a plain NEVER refused the same edit every time. If a rule matters, write the plain modal and pin the behaviour with a $TEST case. **Is under no circumstances a good way to write a rule in a system prompt?** Not if you want the rule defended. Under no circumstances at the head of a line drew a prompt/unparsed-rule info note and caught none of the contradicting edits. Putting under any circumstances after NEVER, between commas, or at the end of the line also caught none. Write NEVER plus the action, and keep the legal wording in the @@ note above it. **What is the difference between may not and must not in an agent prompt?** To a person, both forbid. To TypeGlish, MUST NOT is a prohibition and You may not is read as the permission MAY, which typeglish review offers to commit to a hard modal or keep as a permission by design. Because a soft rule is not compared with a hard one, You may not tell the customer who was at fault did not conflict with a later MUST tell the customer who was at fault. Write MUST NOT, DO NOT or NEVER. **Does Do not work as well as NEVER in a prompt?** For the contradiction check, yes. Do not, Don't and You must never each caught the contradicting edit on all three rules, the same as NEVER. Operators are case-insensitive, so Do not counts the same as DO NOT. The phrasings that failed were the ones with something added to the modal or written around it. Field note Emphasis is how a prompt records which rules somebody fought for. That record is worth keeping; it just belongs in the place built for it. The `@@` line above a rule is stripped before the model reads anything, so it can say *legal asked for this after the Q2 complaint* without spending a token, and `typeglish score` counts it in the annotation facet. The modal stays plain so the contradiction check keeps watching the line, and the `$TEST` turns the worry into something a live run can fail. If you inherit a prompt where every third line shouts, `typeglish review` is the quickest first pass: any rule it lists as unprovable or soft that you meant as absolute is a rule to rewrite before the next edit arrives. ∿ washed up Oct 17, 2026 ∿