One Language for RiskCompanion site · catalog 1.0

C3.3 Action Priority

Catalog 1.0Chapter 16 of the bookSources: [8]
What it requires
Severity, occurrence and detection are rated one to ten; priority is read from a table in which severity dominates; a severity of nine or ten requires action or a signed acceptance by someone with authority; the product survives only as a legacy figure; ratings are revisited after action with history kept.
Provenance

Failure mode and effects analysis, harmonized handbook [8]

Specification, origin and what it reconciles

What it requires. Where the decomposition of C2.3 is used, each mode is rated for severity, occurrence and detection on a scale of one to ten, and the priority for action is read from a table in which severity dominates: a severity of nine or ten demands action or a formal, signed acceptance by someone with authority, whatever occurrence and detection say; below that, occurrence is consulted next and detection last. The product of the three ratings survives only as a legacy figure. Ratings are revisited after an action and the previous values kept.

Where it comes from. The 2019 harmonized handbook [8] stopped multiplying. The risk priority number had a known flaw, that a catastrophic effect which is rare and easy to detect can score below a frequent nuisance, and the Action Priority table replaced the arithmetic with a lookup in which the worst consequence cannot be averaged away.

What it reconciles. This is the maximum rule of C3.2 applied to ordinal scales. The project literature says the worst objective sets the score; the quality tradition says the worst severity sets the priority; two communities reached the same conclusion from different failures, and the component states it once. It also explains why chapter 11 kept severity as a word distinct from consequence: Action Priority needs the score alone to be ordinal and dominant. The acceptance a nine or ten demands is the acceptance above appetite of C4.5, which goes to the board.

Status

Current in catalog 1.0. A component is never deleted, only marked retired, and every change is recorded in the changelog. Think it is wrong? Challenge it.