One label cannot carry every decision
Severity describes consequence, while priority describes ordering in a specific context. Teams often blend both into one urgent word.
If every finding receives the highest label, the queue stops communicating tradeoffs. Work then follows volume, confidence, or the loudest requester.
Define each field and who can change it. Keep the number of levels small enough for consistent use.
Describe the risk components
State which users are affected, how many might encounter the condition, and what harm follows. Include workaround and recovery cost.
Add likelihood and detectability when they change the decision. A rare silent corruption can deserve action before a common cosmetic fault.
Note timing constraints such as a release, contract, campaign, or regulatory deadline. Urgency can change while severity stays constant.
Run triage as a decision meeting
Bring reproducible evidence and product context. Ask what must happen next, who owns it, and when the team will review the choice.
A fix is not the only response. The team can remove scope, add monitoring, communicate a limitation, or accept risk for a defined period.
Do not spend the entire meeting debating labels. Record the rationale and move toward an accountable action.
Audit the system with real outcomes
Compare past labels with production incidents, customer reports, fix time, and escaped consequences. Look for patterns of inflation or neglect.
If different groups use critical differently, publish examples from your own product. Train with ambiguous cases instead of perfect textbook defects.
A useful priority system makes disagreement visible. It does not eliminate judgment, but it gives judgment shared language and evidence.