Most people approach negative prompting reactively: an output annoys them, they bolt on a "do not," and they hope. That works sometimes, but it does not scale and it does not teach. What is missing is a model, a small set of named stages you can run every time, that turns a vague instinct into a repeatable path. This article proposes one: Exclude-Replace-Verify, or ERV.
ERV is not magic. It is a deliberate organization of practices that already work, arranged so you always know what stage you are in and what to do next. The three stages are sequential, but the framework's real value is in the decision rules that tell you when each applies and when to skip ahead. Once internalized, ERV makes negative prompting feel less like guessing and more like following a procedure.
We will define each stage, give its decision rule, and show how the stages interlock. The hands-on, click-by-click version of running this model lives in Build a Working Exclusion in Six Concrete Steps; this article is the mental model behind it.
Stage One: Exclude
The first stage is identifying precisely what must not appear and deciding whether exclusion is even the right tool.
What happens here
You name the unwanted element in observable terms. Not "it feels wrong" but "it uses the word leverage," "it runs over 200 words," "it has extra fingers." The output of this stage is a concrete, gradeable description of the thing to remove.
The decision rule
Before committing to an exclusion, ask: does this have a clean positive equivalent? If yes, do not exclude; jump straight to Replace. Exclude is reserved for compliance boundaries, fabrication risks, and artifacts with no positive form. This gatekeeping is what keeps ERV from drowning in unnecessary negatives, a discipline argued in Opinionated Rules for Constraints That Hold.
Stage Two: Replace
The second stage supplies what should appear in place of what you removed. This is the stage most people skip, and skipping it is why their constraints disappoint.
What happens here
For every exclusion that can have one, you write a positive instruction naming the desired alternative. "Do not use bullet points" becomes "write flowing prose in full paragraphs." The replacement gives the model a target instead of a void.
The decision rule
If the excluded element has no sensible replacement, like a fabricated source or a watermark, leave it as a pure negative and move on. Otherwise, always pair. The pairing converts a fragile negative into a robust instruction. When the excluded thing is also a trigger word, the Replace stage doubles as your defense against the pink-elephant effect by describing the goal without naming the forbidden term.
Stage Three: Verify
The third stage proves the constraint did what you intended without collateral damage. A constraint is not done until it survives Verify.
What happens here
You generate output and compare it against a constraint-free baseline. You check three things: the excluded element is gone, nothing new broke, and the result is good on its own merits. Verify is holistic, not a pass-fail on the banned item alone.
The decision rule
If Verify fails because the constraint did nothing, return to Exclude and make it more gradeable. If it fails because something new broke, you have overcorrected; return to the offending constraint and scope or soften it, changing one variable. If it passes, proceed to closure. This loop is exactly what the Case Study: Negative Prompting in Practice traces across three rounds.
How the Stages Interlock
ERV is a loop, not a line. The stages feed back into each other, and knowing the return paths is what makes it a framework rather than a list.
The feedback paths
- Verify failing on non-compliance routes back to Exclude (sharpen the constraint).
- Verify failing on overcorrection routes back to Replace or to scoping the Exclude (soften or narrow).
- A successful pass exits the loop to closure.
Closure is part of the model
After a clean Verify, record the constraint, the model it was tested on, and any exception you found, then add it to your library. ERV does not end at a working output; it ends at a reusable asset. This makes each pass through the loop cheaper the next time you face a similar problem.
When to Apply the Whole Framework Versus a Shortcut
ERV scales down as well as up, and knowing when to abbreviate keeps it practical.
Full framework
Use all three stages with explicit baselines and library closure for anything going into production, a shared system prompt, or a reusable template. The cost of rigor is justified when the constraint will run many times.
Shortcut
For a quick one-off, you can compress: skip the formal baseline, run Exclude and Replace in your head, and do a light Verify by eye. The stages are still there; you are just spending less ceremony on a low-stakes task. The full checklist version that supports both modes is in A Working Checklist Before You Ship a Constraint.
Common Ways People Misuse the Framework
ERV is simple, which means it is easy to apply badly. Two misuses come up often enough to flag.
Treating Exclude as the whole job
The most frequent error is running Exclude, getting a passable result, and stopping. The output is free of the annoyance but the model was left to guess at the replacement, so a subtler problem creeps in. ERV deliberately makes Replace a named stage precisely so it is harder to skip. If you find yourself routinely jumping from Exclude straight to a finished output, that is the misuse to correct.
Treating Verify as a pass-fail on the banned item
The second misuse is a shallow Verify that only checks whether the forbidden element is gone. That check will pass even when the constraint has wrecked the tone or stripped necessary substance. Verify is holistic by design: the question is whether the output is better overall, not merely cleaner. A Verify that never sends you back to Replace is probably not looking hard enough.
Why naming the stages still helps
Even when misused, the named stages make the misuse visible. You can point at exactly where the process broke down, which is far more useful than a vague sense that the prompt is not working. That diagnosability is the whole reason to adopt a model rather than improvise.
Frequently Asked Questions
How is ERV different from just writing a good prompt?
ERV gives names and decision rules to steps people otherwise do implicitly and inconsistently. Naming the stages forces you to ask the right question at each point: is exclusion even needed, what replaces the excluded thing, and did it work without breaking anything. The decision rules and feedback paths turn ad hoc tweaking into a diagnosable loop you can teach and repeat.
Why is the Replace stage the one people skip, and why does it matter?
People skip Replace because removing the annoyance feels like the whole job. But a pure negative leaves the model guessing at what to do instead, which often produces a new problem. Supplying a positive alternative gives the model a target, dramatically improving reliability. Replace is also your defense against the pink-elephant effect, since describing the goal lets you avoid naming the forbidden term.
What do I do when Verify fails?
It depends on how it failed, and the framework tells you. If the constraint did nothing, return to Exclude and make it more gradeable. If something new broke, you overcorrected, so return to Replace or narrow the Exclude, changing only one variable. Then re-run Verify. The failure mode points you to the exact stage to revisit.
Can I use ERV for image generation?
Yes. Exclude becomes your terse negative keyword list, Replace is largely handled by your positive prompt describing the desired image, and Verify means comparing generated images and tuning the negative strength. The decision rules still apply: many image artifacts, like watermarks, are pure negatives with no replacement, so they stay in the Exclude stage.
Key Takeaways
- ERV organizes negative prompting into three named stages, Exclude, Replace, and Verify, each with a decision rule.
- Exclude gatekeeps whether a negative is even warranted, sending anything with a positive equivalent straight to Replace.
- Replace supplies the alternative the excluded element leaves behind and is the stage most people skip to their cost.
- Verify is a holistic comparison against a baseline, and its failure mode tells you which stage to revisit.
- ERV is a loop ending in closure, where you save the tested constraint as a reusable asset, and it scales down to a quick shortcut for low-stakes tasks.