We start with the bug. It's the kind of bug that gives you nightmares: nasty effects, just reproducible enough to be hard to track down, any fix is going to be pretty large and quite risky.
And then the hunt. Several weeks of finding it, missing it, finding it again, and narrowing it down and down. Finally, QA gets it. Granted, it takes two days to reproduce, but it reproduces every time.
By now we're getting close to the scheduled release date. There are a couple of ways to fix this, none of them nice - a new kernel, or writing a new NFS component.
And then... the hack. It's not pretty, no one likes it, but it's fast to implement, isolated, and doesn't change major components of the system. So management says, "let it be so" and the hack goes in. It works just fine. The problem is successfully worked around.
And then the fix. Better architecturally, more elegant, a much larger change, but The Right Thing To Do.
But wait.... a joke! Someone says, "We're going to forget to take out the hack!" General laughter, but what if we really do forget?
This is where we use negative acceptance criteria. Acceptance criteria are usually affirmative - "user can log in", or a lot of tests around writing files with certain ACLs. But you can also accept the absence or negative of something. In this case, we do not accept the fix unless the hack is gone. We can prove the hack is gone (in this case by checking that the package is not installed and that the process does not run on startup).
When you're working on accepting a story or a feature, don't forget to consider the acceptance of removals as well as of additions.