Say it once, or say it's optional

TL;DR Restating a strong rule in softer words (always, then usually) tells the model the rule is optional. State each rule once, at the strength you mean, and let the checker catch the strength conflict with logic/quantifier-strength.

Here is a habit almost every mature prompt has: a rule that matters gets said twice. Once up top, firmly, and once again later, in passing, a little softer, because the writer wanted to be sure it landed. The instinct is human and generous. The effect is the opposite of what you intended. A second, gentler statement of a rule does not add emphasis. It subtracts certainty, and the model is the one reading the fine print.

§1The instinct to reinforce

You write ALWAYS cite the help-center article in your constraints. Good rule. Later, drafting the tone section, you write something like usually cite the article so the customer can read more, meaning it as a friendly reminder of the same policy. Now the prompt contains both. A reader skims it and hears one message, said twice, so it must be important. A model does not skim. It weighs every word as a claim, and it has just been handed two claims about the same behavior that disagree about how often it applies.

Always means every time, no exceptions. Usually means most of the time, which is a precise way of saying not every time. Put them side by side and the softer line quietly redefines the strong one: if the policy were truly always, why would a careful author also describe it as usually? The model resolves that the way it resolves everything ambiguous, by picking, and you have handed it the argument for skipping the rule whenever the current turn feels like an exception.

§2What the soft line actually says

This is not a matter of taste. It is entailment, the same relationship a type checker reasons about. Always X logically implies usually X: if a thing holds on every occasion, it certainly holds on most. So the two lines are not two rules. They are one rule, stated once at full strength and once at a strength it already covers. The weaker line carries no new information. All it can do is introduce doubt about the stronger one.

# Constraints
- ALWAYS cite the help-center article.
- Usually cite the help-center article.

citations.tg:2:1  error  logic/quantifier-strength  One rule, two strengths - "cite the help-center article." (required on every occasion)
  already entails "cite the help-center article" (required on most occasions); a model may read the weaker as "not always".
  Keep the stronger line. (conflicts with line 3)
citations.tg:3:1  error  logic/quantifier-strength  One rule, two strengths - "cite the help-center article." (required on every occasion)
  already entails "cite the help-center article" (required on most occasions); a model may read the weaker as "not always".
  Keep the stronger line. (conflicts with line 2)

✗ 1 file - 2 error, 0 warning, 0 info

§3One fact, one strength

The fix is not to reword the soft line. It is to delete it. The strong rule already says everything the soft one wanted to, and more reliably. What you keep is a single statement at the strength you actually mean. If you genuinely have an exception, that is a different thing than a softer restatement, and it deserves to be written as an exception: a scoped condition the model, and the checker, can both see.

# Role
@@ role: a support agent, help-center-backed answers only
You are a support agent for a subscription box service.

# Constraints
@@ cite: every answer names its source so the customer can verify it
- ALWAYS cite the help-center article, UNLESS no article covers the question.
@@ brevity: a support reply that runs long buries the answer
- MUST answer in at most 4 sentences.

citations.tg - A (96/100)  proven errors: none  tiers: base+z3
  planes  runtime 94 (what the model reads) · hygiene 100 (source only)
  lever   enforceability 85/100 (up to +4 overall) - Write rules as
          MUST / NEVER with concrete bounds, not vague qualities.

The rule of thumb is small and unglamorous: every fact gets one strength. A behavior is either always, usually, sometimes, or never, and you owe the model exactly one of those per rule. Pick the word that is true and commit to it. If you find yourself wanting to write the same instruction twice, that is a signal, and it is almost never "say it louder." It is "the first statement wasn't precise enough," so fix the first one instead of stacking a second.

§4The contradiction's quieter cousin

A strength conflict is the sibling of the contradictions we wrote about in Your prompt argues with itself, and it is easy to tell them apart once you see the shape. A contradiction is two rules pointing in opposite directions: never apologize for delays versus sometimes apologize for delays. Those cannot both hold, and the checker calls it logic/contradiction. A strength conflict is two rules pointing the same direction at different volumes: always cite versus usually cite. Those can technically both hold, but only by making the strong one redundant, and the checker calls it logic/quantifier-strength.

You cannot make a rule stronger by adding a weaker version of it.

The contradiction is the louder failure, the one people eventually notice in a transcript. The strength conflict is quieter and, in a way, more insidious, because the softer line looks like helpfulness. It reads as a considerate reminder right up until you realize it is the exact sentence granting the model permission to ignore the rule you cared most about. This is also a maintenance property, not a writing one: the clean prompt acquires its first strength conflict the day someone adds a "usually" three edits later, which is why the same discipline that catches contradictions before merge, catch every new frequency word against the rules already in the file, catches these too.