Every waiver policy fails the same four ways. The anti-patterns below are worth learning by name because naming them in a review is faster than re-deriving the objection each time — and because each has a mechanical catch the review process can enforce.
Anti-pattern | Symptom | How reviews catch it |
|---|---|---|
Blanket waiver | One waiver covers a class, a module, or a bus “and similar” | Scope rule: one waiver, one instance, one finding — anything broader is rejected at intake |
Waiving to go green | Waiver count spikes just before a milestone with thin evidence | Dashboard rule: waivers in the final week need the full template plus a second reviewer |
Undocumented waiver | A finding disappears between runs with no record | Run-to-run reconciliation: every closed finding traces to a fix or a waiver reference |
Copy-forward waiver | Last project's waivers applied to this project by default | Revision rule: no waiver survives a project change without fresh joint approval |
All four share one root cause: schedule pressure meets a green dashboard. The waiver count is the easiest number to move, so it moves first. The defence is structural, not moral — intake rules, reconciliation, and expiry that work when everyone is tired and the milestone is Friday. A policy that only works when the team has spare time is not a policy.
Copy-forward deserves a special note because it feels efficient. The previous project's waivers were correct for the previous project's clocks, constraints, and protocols. None of those transfer for free; each needs its argument re-confirmed against the new design. Import the old waivers as candidates for review, never as approvals.
Waiving to go green. The response is to reject the batch at intake, demand the full template per finding, and escalate the schedule impact honestly rather than borrowing green.
Because findings that vanish without a record are undocumented waivers by another name. The trace is the mechanical catch that makes silent closure impossible.