LLMs are bad at ‘no.’ Give them a rule like ‘no adjectives’ and they’ll quietly ignore it half the time. A Redditor in r/PromptEngineering found a fix: reframe your constraints as binary logic gates, and the compliance rate changes significantly.
The author, u/Glass-War-2768, calls the approach ‘Chain of Density’ but the real mechanism is something more specific. The author built in a concept called a ‘Hard Failure’ that forces the model to self-audit before finishing its response. It’s a small structural change that produces a noticeably different result.
Why AI Breaks Your Rules in the First Place
Standard instructions get processed once at the input stage. The model reads your rule, acknowledges it, then generates anyway based on its training distribution. Your preference competes with billions of parameters pulling in another direction.
The instruction usually loses. Especially with strict constraints like tone, word choice, or format. This is not the model being defiant. It’s the model being statistical. It defaults to what it has seen most often in training data, and most training data doesn’t follow your specific rule.
Think of it this way: telling a model “no adjectives” is like telling someone to not think of a pink elephant. The instruction draws attention to the thing you’re trying to suppress. The model has to actively work against its defaults with nothing structural holding it accountable.
The fix isn’t to repeat yourself louder. The fix is to change the frame entirely.
How the Failure Condition Technique Works
Instead of stating a rule as a preference, you define a rule as a logic gate with two outcomes: Pass or Fail. No gradient. No partial credit.
If the model detects a violation in its own draft, it doesn’t just flag it. It deletes the entire response and starts over. That’s the key move. You’re not giving feedback after the fact. You’re building an internal checkpoint into the generation process itself.
This matters because most prompting advice targets the input side of the equation. You write a better instruction, and hope the output changes. The Failure Condition technique targets the output side directly. The model is now responsible for verifying its own work before it hands anything back to you.
📋 Prompt of the Day
Here’s the exact template the author shared. Reproduce it as written:
Task: [Task]. Critical Rule: [Rule, e.g., No Adjectives]. If you detect a violation of this rule in your draft, you must delete the entire response and regenerate. A violation is a “Hard Failure.” Treat this as a logic-gate.
Slot in your task. Slot in your rule. That’s the whole thing. No complex syntax required. The power is in the framing, not the length of the prompt.
Why It Works
Three things make this effective:
- Binary framing removes ambiguity. There’s no ‘sort of followed the rule.’
- The self-check happens during generation, not after. The model evaluates its draft before surfacing it.
- ✔️ Labeling it a “Hard Failure” gives the model a semantic anchor it recognizes as non-negotiable. Those words carry weight in training data contexts where failure means restart, not revision.
It’s the difference between a sign that says ‘watch your step’ and a physical bump that forces you to stop. One is advisory. The other is structural.
The phrase ‘logic-gate’ does additional work here too. It invokes a binary computing concept the model has seen thousands of times in technical writing: input is either valid or it isn’t. No room for interpretation. That context shapes how the model weighs the constraint against its other defaults.
Use Cases Worth Trying
Any constraint you’ve been repeating in follow-up messages is a candidate for this treatment:
- Writing that must avoid specific filler phrases or hedging language
- Code generation that cannot use a particular library or pattern
- Summaries that must stay under a strict word count
- Responses that must always follow a specific output format
- Translations or rewrites that cannot introduce certain brand terms or competitor names
The more specific your Critical Rule, the better this works. Vague rules give the model wiggle room. Binary rules don’t. “Be concise” is vague. “No sentence may exceed 20 words” is binary. One of those works with this technique. The other doesn’t.
If you find yourself editing AI output for the same issue two or three times in a row, that’s your signal. Turn that recurring correction into a Hard Failure condition and stop babysitting it.
One Variation Worth Testing
The author’s template uses a single rule. You can stack two Critical Rules if you need to, but test one at a time first. Multiple hard gates can sometimes cause the model to get stuck in a loop trying to satisfy conflicting constraints. When two rules pull in opposite directions, the model can’t regenerate its way out.
A useful way to diagnose this: if your output gets noticeably shorter or more generic after stacking rules, the model is hedging to avoid triggering either failure condition. That’s a sign to simplify. Remove one rule, nail the baseline, then reintroduce the second rule in a separate pass if needed.
Keep it simple: one task, one critical rule, one failure condition. Then layer from there once you see the baseline behavior.
Check the Full Discussion
Head over to the original r/PromptEngineering thread to see the full post and any follow-up discussion from the community. There are a handful of replies testing variations of the template on different use cases. Worth reading before you run your own tests. And worth bookmarking the template above before you go.
The ‘Chain of Density’ (CoD) for Maximum Information Extraction
by u/Glass-War-2768 in PromptEngineering