The SRA steps

FIRSTRequirements catalog and defect history

Fundamentally, the risk study starts with the requirements catalog and the defect history, if it exists. Traditional risk studies follow a slow cycle since every failure mode must be analyzed and duration will be tied to the exhaustive data collection and if bypassing lengthy deliberation is possible in favor of rapid response.

Run the whole Risk Analysis for each requirement and scope, review relevant defect and near-miss history if available,

1. The requirement and its need. The requirement is anchored to the need it serves and to who stated it, and contains the fundamental function to be executed, described as a verb and a noun, with units and tolerance. Test conditions and most important: The Success Criteria. The need is a guide, not a gate: it is not scored, checked or audited, but every requirement is read against it — if it is met exactly, is the need met?
2. Why does this requirement exist? A need, a hazard, or a life-threatening hazard. A requirement exists either to create value or to protect it. A need creates value: the spindle must rotate at 12,000 rpm because the customer needs the cut. A hazard requires protection: the spindle seal must keep coolant out of the bearing only because the coolant is there; the hazard is the need. A life-threatening hazard is a hazard that can kill or seriously injure: the cabinet must insulate 13.8 kV because the operator opens its door. Every requirement records its origin, and both hazard origins name the hazard; neither can ever be a Won’t have, and a life-threatening hazard is a Must by its origin (Second step). The same hazard returns in the risk statement of the EIGHTH step, where the failure of that requirement exposes the target to it. So every hazard named in a risk statement must trace back to a requirement written to contain it; a hazard with no requirement guarding it is a finding: the requirement is missing.
3. Test conditions recreate the use. They reproduce the most common use of the product, in the way it really happens — the user's hands, eyes and attention, the hurry, the environment — and the most demanding moment of that use. A control tested on a bench by someone looking straight at it will pass; the same control used by feel, at speed, with the eyes on a hazard, may not. A success criterion met under the wrong conditions proves nothing about the product in use.
4. From the requirement to its failures. Starting from requirements helps anchor the exercise in what the system must do and what would count as a failure (not success). Defect history can then help identify recurring failure modes and estimate how often they occur. But a history-based approach can miss new or rare hazards simply because they haven’t happened yet. So the analysis should also ask prospectively, “How could this requirement fail, even if we’ve never seen it fail before?”. Then brainstorm plausible failure modes and assess them—including novel ones, new requirements will funnel these added studies. If history is absent, use expert judgment and available design or test evidence, and be clear that likelihood estimates are less grounded.

Operational and cognitive functions

A function either acts on matter and energy — move, hold, seal, cool — or it knows and decides: detect, recognize, warn, decide, inform. Both are functions, and both can fail, provided the result can be seen and tested: Detect leak, ml/min, min 5. Warn operator, s before harm, min 10. Inform approver, days from finding, max 1.

Cognitive functions fail in a family of their own: missed, false alarm, late, wrong, not passed on.

Verbs nobody can test — understand, know, be aware, consider — are not functions. Write the act they stand for: not “be aware of the hazard” but “recognize the hazard, s, max 2”.

Which is harder: defining requirements or finding the root cause?

As somebody asked: which is the more difficult task, defining the requirements or finding the root cause? We believe defining the requirements, and not by a small margin.

A root cause has an object. Something failed, or can fail, and physics is on your side: there is evidence to collect, hypotheses to test, and a check at the end — fix the cause and the failure stops, or it does not. Reality corrects a wrong branch of the 5 Whys.

A requirement has no object yet. It describes something that does not exist, for people who often cannot say what they need until they see what they did not want. Every hard part is judgment: writing the function as verb, noun, unit and tolerance; establishing the test conditions; choosing the success criterion against them; deciding what is out of scope; reconciling stakeholders who want different things. Nothing pushes back when it is wrong: a wrong requirement passes every review, because everyone checks the product against the requirement, never the requirement against the need.

Its errors also surface last and cost the most — at validation, at the customer, in the field — after the design has been built around them. And a root cause traced far enough very often ends at a requirement that was missing, vague or never tested. That is why every SRA study starts here: it is the hardest step, and every later step inherits its mistakes.

SECONDRank Requirement Importance

That makes the RIQ+ score more than a numeric recoding of MoSCoW: it combines the Requirement worthiness, effort, and team readiness to estimate how suitable it is to be pursued.

That can be useful for prioritization, but it’s a different question from risk importance. A requirement that’s highly worthy but difficult or not yet feasible may still be critical to safety or compliance. Keep RIQ+ as a delivery-priority or implementation-readiness measure, and avoid letting the RIQ+ score affect the consequence ranking assigned to failure in the risk analysis.

For the combined score to be meaningfully cardinal, the method should also explain how each factor is scaled and weighted, and how trade-offs work—for example, how much extra effort offsets greater worthiness. This is not possible with RIQ+. Effort cannot offset worthiness.

RIQ+ uses truth tables to assign the worthiness, effort, and readiness values, then combine them in the stated positional score. That makes the tables—not a simple tick count—the key to evaluating how the score works.

RIQ+ is faithful with Worthiness.

NOTE: There is not a ranking for Urgency. This is all about a date: Then specify it. It doesn't alter the RIQ+ Ranking.

The letter is derived, never chosen. RIQ+ is how importance is rated. The MoSCoW letter is read from its Worthiness digit — 4 Must, 3 Should, 2 Could, 1 Won’t — and kept because it is what people use, the way RPN is kept beside RPN+: familiar to read, no longer an input. A letter typed by hand in an older analysis is reported as importance not quantified until it is rated. Why the letter is no longer chosen, defect by defect: the Expert Corner, the defects nobody wrote down.

Two questions: the Worthiness fork. Before any worth is ticked, two questions are answered.

• Why does this requirement exist? A need, it creates value; a hazard; or a life-threatening hazard, one that can kill or seriously injure. Both hazard answers name the hazard, and neither can ever be a Won’t have. A life-threatening hazard is a Must by its origin: Worthiness 4.
• Is it imposed on you? No; or by law or regulation; or by contract — with the citation, “21 CFR 820.30” or “contract 4471, clause 7.3”, so anyone can look it up. Either answer makes it a Must: Worthiness 4.

When either question binds the requirement, the six worth ticks are not asked, and the form says why: Must — life-threatening hazard, or Must — imposed by 21 CFR 820.30. A requirement can be both, and the form says both. Otherwise its worth is ticked. Effort and Readiness are always ticked by the user, because what a requirement is worth to you says nothing about what it costs or whether the team can start. The bands are printed beside the ticks — 5 or 6 a Must, 3 or 4 a Should, 2 a Could, 1 or none a Won’t have — so a free choice left with no worth tick is a Won’t have in plain view, and the readout shows the W at once. A requirement that guards against a hazard can never be one. A life-threatening hazard whose worst failure is not rated catastrophic is questioned by the early sanity test.

The RIQ+ rating tables

Worthiness (Hundreds, the first digit)

What the requirement is worth, and how far that worth reaches.

* Exposure is the mirror of a failure's reach: wide exposure makes a failure hurt more, and a requirement worth more. Do not confuse Exposure Model that is Impact (Severity) × Likelihood (Probability).  ** Impact here is the upside, the opposite of impact in a risk (It is Opportunity, positive). Note: a requirement whose origin is a life-threatening hazard is a Must by its origin, and its worth is not ticked.

* The hundreds digit derives the MoSCoW letter, the letter is not guessed anymore. That is what makes RIQ+ an extension of MoSCoW rather than a replacement: the letter is that people already use and stays, it still governs inclusion and now it rests on what was counted rather than on who argued hardest.

Effort (Tens, the second digit)

What it will cost to get, inverted.

* Inverted on purpose: Of two requirements worthiness is the same, the cheaper comes first. This is the quick-win rule that RICE and WSJF get by dividing — without letting it overturn worthiness, because Effort is only the tens digit.

Readiness (Units, the third digit)

Whether the team can start now. Readiness is the combination of two factors: Know-how and Confidence.

The last tiebreaker: among requirements of equal worthiness and effort, the one that can start now goes first.

Why the digits descend in this order

RIQ+ is Ordinally faithful within a Worthiness level. When Worthiness is equal, Effort outranks Readiness because Effort represents the durable cost of satisfying the requirement, whereas Readiness reflects whether the current team can begin now.

Readiness may change through training, specialist support, or focused study. The digits therefore descend by persistence and consequence: Worthiness represents the requirement’s level, Effort represents its cost, and Readiness represents the team’s present ability to proceed.

Why the score is placed and not multiplied, and what MoSCoW cannot do: RIQ+ on the risk page.

RIQ+ also questions the impact. Its Worthiness digit is set against the impact of every failure mode of the requirement, twice: first at the gate of the Fifth step, where a Must screened out or a Could with a catastrophic failure raises a caveat that is settled on record; then across every scored mode in the Eleventh step’s Consistency Test.

THIRDThe Evidence Fork

The evidence fork is meant to handle that if there’s Defect History, it establishes two operational branches A and B:

Branch A: there is a defect history. This is the hard-data path: its decisions are empirical from what was witnessed, and data-driven from what was recorded. Therefore, you will be using the complete Ranking Tables with values from 1 to 10.

Branch B: there is no defect history. This is the Expert Judgment path, used rather than inventing a false history-based rate: its decisions are model-driven from theory, analogy and experience. It is subjective: likelihood without physical evidence, so it can only return a structured estimate; therefore, it will be enough using the simplified Ranking Tables with values from 1 to 5.

That makes sense as a scoring rule, as long as the “no history” branch still considers plausible failures using requirements, design knowledge, and expert judgment. The fork should change what evidence supports the score, not whether you look for risks at all.

Two kinds of evidence

A defect history exists only when four things are true:

1. The failure has had the chance to happen, enough times to count, and the record shows whether it did. Usually it did: the defects exist.
2. Somebody witnessed it.
3. Somebody recorded it.
4. The record comes from the conditions the item will now meet: the same design, process, duty and environment.

All four, Branch A. Any one missing, Branch B. A counted zero, a failure that never happened in a long record, is still a count: how it is ranked is in the Seventh step.

The fork reads the evidence on the failure: has this failure happened before, and are its defects on record?

• Yes, it has happened and is counted: Branch A. How often it happens comes from that count, the incidence. The risk is scored as RPN+.
• No, it has not happened yet, or nobody counted it: Branch B. The experts judge how likely it is, the likelihood: a structured estimate, not a measured rate. The risk is scored as RE+.

How each branch builds its score is shown in the TENTH step. A record of events with no failure behind it, such as floods or earthquakes, is not a defect count. Until the failure is found and its defects are counted, the mode stays in Branch B.

Mitigation follows the branch. Branch A: Correction, action to eliminate the root cause. Branch B: Prevention; there is not a physical object yet, and the only opportunity is planning and communicating.

The words behind the risk analysis, the reasoning of the fork and where each mitigation acts are set out in the Expert Corner: the basics behind the statement.

The fork chooses the decision method by the evidence available. Branch A decides from what happened; Branch B decides from what could happen. Impact is decided the same way in both. The fork never decides whether the analysis is done:

Why Defect History is so fundamental to establish a fork?

The perfect way to visualize it. Defect history is the "fork" that determines which branch of risk analysis you must follow.

Depending on whether that history exists, you move down two complementary logical paths: If you have defect history, you are performing Data-Driven Analysis.

Branch B: The Expert Judgment Path (No History)

If you have no defect history, you are performing Model-Driven Analysis.

Why this "Fork" matters for your project:

If you try to use the Empirical Path logic (Branch A) while you are actually on the Expert Judgment Path (Branch B), you will conclude that your Action Priority is "Zero" because there are no recorded defects.

This is a dangerous trap in engineering.

The absence of evidence (no defect history) is not evidence of absence (no defects). By recognizing the "fork," you realize that when history is missing, you must switch your toolset from statistics to risk estimation to determine your priorities.

Without that history, you are forced to rely on expert judgment, which estimates the likelihood from three factors:

A) Subjective Likelihood

Subjective likelihood is based on expert judgment, intuition, and experience rather than empirical data. It is used when an event is so rare (a "Black Swan" event) or so new (a zero-day exploit) that no historical data exists.

At the design, the logic, or the physics of the component. If the design is overly complex or uses a new, unproven technology, the likelihood of a defect is assumed to be higher, even if one hasn't occurred yet.

B) Comparative Likelihood

You look at similar components in other systems. If "Component A" has no history, but "Component B" (which is nearly identical) fails frequently in other projects, you assign a higher likelihood of failure to Component A based on that analogy.

C) Environmental Likelihood

You look at the conditions the system is operating in. If a part has no defect history but is now being moved into a high-heat or high-pressure environment, the likelihood of a defect increases because the operating conditions have changed.

Also, there are these techniques available: Brainstorming, Delphi, Nominal Group Technique, Analytic Hierarchy Process (AHP), among others to estimate a likelihood.

In short, "no defect history" doesn't mean the likelihood of failure is zero; it just means you have no evidence to prove it is high. You are essentially guessing based on the best available theory and comparison.

Other techniques: qualitative for Branch B, quantitative for Branch A, and the bridge

SRA does not prescribe the techniques around it. Users are free to use whatever they see necessary to improve the certainty of their decisions; those techniques are outside the scope of SRA. The fork only says which kind fits the evidence. The catalog of them is IEC 31010, Annex B.

• Branch B, qualitative: structure without numbers. Brainstorming, Delphi, the nominal group technique and AHP to estimate a likelihood; scenario analysis and the structured what-if (SWIFT) to find failures; the bow tie, and the fault tree and event tree drawn as logic only, AND and OR, to show how causes combine. A simulation run on ranges the experts estimate belongs here too, as a Likelihood basis: a thousand runs on guessed inputs is still a guess, with decimals.
• Branch A, quantitative: they need a record. The fault tree and event tree with the failure probability of each event, Markov analysis with its transition rates, layers of protection analysis (LOPA) with the failure frequency of each layer, human reliability analysis with error probabilities, and Monte Carlo on distributions fitted to the data.
• The bridge: Bayesian analysis. It incorporates “empirical data into prior judgements about probabilities” (IEC 31010, B.5.2). The experts’ Branch B likelihood is the prior; the item’s own record, as it gathers, updates it, until the record speaks for itself and the mode crosses to Branch A, with the date and the reason.

One rule holds whatever is used: a technique never moves a mode across the fork; only the evidence does. Numbers from a model do not make a defect history.

FOURTHRank Impact (Severity)

You must keep in mind that Catastrophic Impact must never be averaged, nor smoothed, neither hidden nor masked. These must be seen forward as legacy big time mistakes.

Both Branch A and Branch B Estimate Impact (Severity). the difference is only in the use of Complete or Simplified Ranking Impact Table.

An equivalence between the tables

Management can establish an equivalence between the Complete and the Simplified Impact Tables, so that an impact rated in one branch can be read in the other. It is possible for impact, and only for impact, because impact is rated from the consequence, never from the evidence: the history that splits the branches says how often a failure happens, not how badly it hurts. An injury is an injury in either branch.

The suggested equivalence pairs each simplified level with two complete levels, described by the same consequence words:

Why two for one. The Simplified Table is the Complete one at half the resolution, so each of its levels must cover a whole band of consequence, from the bottom of the scale to the top, with no gap and no overlap. The words carry the equivalence, not the numbers: a Branch B 4 and a Branch A 7 or 8 must describe the same harm.

What it is for. It is used where the branches meet: when the Risk Leader chooses between them in the mitigation phase, and when a failure mode crosses from one branch to the other, carrying its impact with it. It never makes RPN+ and RE+ comparable: only impact is correlated.

FIFTHThe First Gate and the Early Sanity Test

Management should establish the rules of the game: A Criteria. When to throw out risks with a minimum level of Impact that make sense to weed out from the study. But for compliance they must remain in the register. Also, the criteria must contain the Ranking Tables, without a uniform way to score, there is no game.

The Ranking Tables are part of these rules, meant to provide consistency, a set of Tables are provided for your reference, management must endorse them or change them to fit the particular business and then endorse them.

The gate comes before incidence is ranked, so only the modes that matter ever need their incidence proven.

Where SRA departs from IEC 31010. The standard asks that the lowest likelihood step be acceptable even for the highest consequence, so that any risk can be made tolerable by being rare enough (B.10.3.1). SRA’s gate refuses that at the critical level: a catastrophic impact is acted on whatever its likelihood. “Rare enough” is what the program believed the night before Challenger. More in the Expert Corner: the sin of the bottom row.

Harm that adds up. The gate rates the harm written in the risk statement. A failure that repeats is written with the harm of a period, a year of it, not of one occurrence, and its impact is rated on that. Otherwise a weekly nuisance is screened out on its first hour, while across a year it costs more than a mode the analysis works on in full. IEC 31010 warns of it: “a frequent but low impact risk can have large cumulative or long-term consequences” (B.10.3.2). Rated one occurrence at a time, the gate cannot take care of it.

Importance questions the gate, impact decides it

The gate has one rule: impact decides. The importance of the requirement, its RIQ+, is the gate’s cross-check, read on its first digit: Worthiness, the digit that sets the letter. Effort and Readiness never enter: they say what a requirement costs and whether the team can start, not what it is worth. A requirement with no RIQ+ is not compared. The cross-check never moves a mode in or out; when the two disagree, it raises a caveat:

• Low importance, high impact: what is going on? A requirement whose Worthiness makes it a Could, with a failure that rates above the impact that digit implies. The mode goes on, because impact decides. The question is whether the requirement is misclassified: something that can do this much harm is not a nice-to-have.
• A Must screened out on impact: is the impact under-rated? A failure of a requirement with Worthiness 4, a Must, that harms nothing is possible, but it is more often an impact rated from the record of getting away with it.

The early sanity test

The gate also runs the sanity test early. The test needs only two things: each requirement’s RIQ+ Worthiness and the impact of each of its failure modes, and both are known as soon as the Fourth step has written the requirement’s modes. Everything after this point is paid for mode by mode — the 6M, the 5 Whys, incidence or likelihood, detection — so the test is run here, requirement by requirement, before any of it is spent:

• Importance high, impact low: a Must or Should whose worst failure rates below the impact its Worthiness implies.
• Importance low, impact high: a Could with a failure above its band.
• Wide impact spread: one requirement whose failures run from trivial to severe is probably several requirements.
• Hazard not guarded: a hazard named in a risk statement that no requirement guards against.
• Life-threatening hazard, no catastrophic failure: a requirement that guards against a hazard that can kill, whose worst failure is not rated catastrophic. Either the hazard is not life-threatening here, the impact is under-rated, or the failure that reaches it has not been written yet.

Run it once a requirement’s modes are all written: its worst impact means nothing while one of them is still missing. By then the branch is known, impact is ranked, and importance can be argued against it.

Each mismatch works the way the Consistency Test does: a warning, never a decision. You decide; the register keeps it as a finding, answered in writing before sign-off. Where a finding stands, the analysis can stop here for a while. Once everything is clear, the study continues with good certainty, and the full test comes back in the Eleventh step, with every element in view.

Most often the Risk Leader calls engineering and has it settled before the study goes on. The settlement is recorded with the finding: who settled it, when, and what was decided — “Engineering, 8 November: impact confirmed, requirement raised to Must” — and the report prints it under the finding, so the auditor sees the trail.

SIXTHFind Root Cause

On every failure mode that passed the impact gate, in both branches. Each failure mode has its own causes.

You are behind the search of the fundamental trigger of the failure, and find a solution.

The first plausible cause arrives within about ninety seconds of a problem being described, and without a structure the room converges on it.

Start with the 6M and finish with the 5 whys Step Twelfth will propose the solution to the root cause. This step concentrates in finding it.

Two domains answer who fixes it

SRA splits the six Ms into two domains Knowhow and Physical to answer the question the categories alone do not. Physical — Hardware — Machinery, Materials, Mother Nature — has equipment owners, spare parts and capital behind it, and is closed with a work order. Knowhow — Software —Manpower, Methods, Measurements — is training, procedure, qualification.

Manpower has two faces

Manpower is a role and a person executing that role, and a cause can sit in either. The role is what the organization defines: the task, its authority, the qualification it requires, its workload, and who stands in when the holder is absent. The person is who holds it today: their training, their qualification, their experience. A badly defined role will fail whoever holds it; a well-defined role can still be held by someone not yet qualified for it.

The two are fixed by different owners. A cause in the role is closed by whoever owns the organization and its Methods: the role is rewritten, its workload or authority corrected, a back-up named. A cause in the person is closed by training, qualification or reassignment. Mixing them up is how organizations retrain good people for a broken role.

That is why both are controlled upfront, before anyone is put in the role. The role is written with the competence it requires; the person is verified against it; the record is kept in SRA Measurements; and a qualified back-up is named, because people change and the role stays.

Why Measurements. A qualification is a measurement: the person measured against what the role requires, with a result, a date and the evidence behind it. Like any measurement it ages and has to be repeated, and like any quality record it has to be produced when an auditor asks. SRA Measurements already holds everything about Quality Control, Quality Assurance and cGMP, and training and qualification records are quality records under all three. Keeping the record there also keeps the two faces apart: the role is written in Methods, the proof that the person meets it is kept in Measurements, and Manpower names who holds it.

When the 5 Whys reach Manpower, ask about the role first and the person second. "Operator error" is never a root cause: it is where the questions about the role begin.

Measurements is the one that gathers the other five

In SRA, Measurements is a very distinct spine, tied to Quality Control and Assurance, and cGMP activities, and it integrates the other five categories — which is what stops the same cause being argued over three times.

Ishikawa gave us the fishbone, and the six Ms that grew on it cover every resource a human adventure can draw on. SRA just arranged them a bit: two domains, Physical and Knowhow, answer who fixes a cause, and SRA Measurements holds everything about Quality Control, Quality Assurance and cGMP. Management and money are not missing. Money spent is a material the project consumes, while a decision about money, like management itself, is a Method. If your project needs anything outside these six, you will need extraterrestrial help to solve it.

6M and 5 Whys are a pair, not alternatives.

6M gives breadth, 5 Whys gives depth. 6M alone produces a wide, shallow list nobody can act on. 5 Whys alone produces one deep chain that may have started down the wrong branch — ask why a defective product reached a customer and you follow detection; ask why the defect exists and you follow creation. In SRA, both are legitimate readings of the same observation, and only the deeper levels reveal that they share a root and more than 5 causes is feasible not forbidden.

Two things 5 whys can do for you

It will tell you which cause dominates. That is what the scoring is for, and treating a long cause list as a priority list is the most common way the two get confused.

It can express interaction. Causes that only produce failure in combination appear as two independent entries. There is a way to write the AND between them (one after other), and that AND is often the whole mechanism.

SRA doesn't care about the modes quantity or complexity, always is beneficial to apply 6M and 5W. You may uncover bad outcomes.

SEVENTHRank Incidence (Occurrence) or Likelihood (Probability)

Branch A: Incidence (Occurrence or Frequency)
Branch B: Likelihood (Probability)

Branch A: Use Defect History as evidence to estimate Incidence. Use the Complete Ranking Table 1 to 10.

A counted zero

When the record shows no failure at all, the rate is not zero: it has not been seen yet. SRA ranks it by an application of the rule of three, the statistical rule for an event that has never occurred: zero failures in n recorded opportunities (units, cycles, hours, launches) proves, with 95 % confidence, a rate no worse than 3 in n. It applies at one point only: ranking incidence on the Complete Incidence Table, in Branch A, when the count is zero. The table states, rank by rank, the clean record each rank needs:

Below 30 opportunities a clean record proves nothing: the mode goes to Branch B, where the experts estimate it and say so.

Branch B: Is for cases without hard data; likelihood is judged qualitatively, rather than inventing a false history-based rate. Label the result as a structured estimate, not a measured probability, and scored on a simplified 1–5 scale. For example, in the concept design phase. Also, in one of a kind projects.

Since, there are not enough grounds to Rank Incidence then rank Likelihood. Use expert judgment, similar projects outcomes and studies, you are in the FAIRY TALES Realm be extremely cautious, big catastrophic tragedies are born right here. Think black swan and the hippo effect; for the black swan, see the black-swan provision in the Thirteenth step. More information in the Expert Corner: The HIPPO.

Branch B: the Likelihood Basis

With no record to count, the likelihood is a judgment, and a judgment is only as good as what it rests on. Two teams can both rate a likelihood 3: one from a sister plant’s ten-year record of the same seal, the other from a hunch. The number does not tell them apart.

So every Branch B failure mode records what its likelihood leans on, on the line where Branch A cites its defect history. It is not a rating: it never enters RE+. Choose one, and write one sentence beside it saying what exactly:

• Comparable items: similar components or systems elsewhere, and what their record shows.
• Changed conditions (design, process, duty, environment): a record exists, but the item has moved beyond it, so the record is no longer its own.
• Simulation or model: a calculation, a simulation or a physical model, and what it shows.
• Team experience, unrecorded: failures the team has seen but nobody wrote down: whose experience, and what they saw.
• Write-in: any other basis, described in a sentence. A write-in that recurs is proposed to the Risk Leader as a new option for the Criteria.

What the basis does

• It is kept with the rating. A re-rating carries its own basis, and the earlier basis stays with the earlier score, so the record shows what changed the team’s mind.
• It is printed under the RE+ score in the report, so the auditor sees why the likelihood is a 3 and not a 4 without having to ask.
• It is checked later. Once the item gathers its own record, the basis lets the team learn whether the experts’ judgment held, and which kinds of basis deserve trust next time. How: calibrate the experts, in the Fourteenth step.
• It is optional, except where it matters most. At or above the critical impact, a likelihood with no basis stated is a finding: that is where an unsupported guess costs the most. Below it, demanding a basis on every mode would be paperwork.

More information in the Expert Corner: What a Branch B likelihood leans on.

Likelihood of what, over what

The likelihood rated is the likelihood of the harm written in the risk statement, not of the failure alone. A seal can leak often and seize the bearing rarely; the statement names the seized bearing, so the rating is how often the bearing seizes. The unit and period are stated once, in the scope of the analysis: “per unit over its service life”, “per batch”, “per mission”. Without them, “likely” means a different thing to every rater. Both are what IEC 31010 asks: the event whose likelihood is stated “should be clearly and precisely defined”, and “the time period and population concerned should be explicit” (6.3.5.2).

EIGHTHThe Risk Statement

You have by now all the necessary information to describe the risk or failure mode. The risk statement puts everything together. It is a communication tool: a concise description of the risk that everyone can understand.

Five parts in a fixed order, one line. Where it comes from: the risk scenario, a reference for newcomers in the Expert Corner. If the failure, exposing the target to the hazard, it will result in the harm or damage, because of the root cause, with this incidence or likelihood.

Example: If the spindle seal leaks, exposing the bearing to coolant, it will result in a seized bearing and an unplanned rebuild, because seal lip wear is not caught between service intervals, with an incidence of 300 to 1,000 defects per million, rank 5.

Say it structured like that and you cannot skip the consequence, which is what impact is actually scored against — a mode written as a bare noun phrase gets ranked on a feeling.

NINTHRank Detectability

Detectability belongs to Branch A. It is rated on the Complete Ranking Table, against the failure mode and the controls that exist today, and it takes the units digit of RPN+. It can break a tie between two modes of equal impact and incidence; it can never outrank either of them.

It is rated against the failure mode and the controls that exist today.

Branch B: a soft glare, not a number

On the expert judgment side there is no product yet and no control to rate, so Detectability is not scored and stays out of RE+. RE+ is impact and likelihood only.

It is still a valuable resource, and the concept design phase is the best moment to start it. Ask early how each failure mode would announce itself, and write the answer down as its Detection Provision. It costs almost nothing on a drawing, and when the product exists and the failure mode crosses to Branch A, it is the control that will be rated.

The Detection Provision

Every Branch B failure mode carries one. It is not a rating: it is checked for presence, not size, and it never enters RE+. Choose one or more:

• Automated detection: a sensor, instrument or control system watches for the cause or the failure.
• Manual detection: an operator notices it in the course of the work — sight, sound, feel, smell, vibration. Unplanned: not a defined check.
• Test or inspection: a defined check catches it before it leaves the plant.
• Scheduled check: a periodic inspection or maintenance task finds it in service, before it does harm.
• Self-revealing design: the design makes the failure show itself harmlessly first — a wear indicator, a tell-tale hole, a leak before a break.
• Warning to the user: the failure announces itself to the user before it does harm.
• None possible: no practical way to see it coming. A legitimate answer and a finding in itself: prevention must carry the whole load, and on a high-impact mode it goes to the approver.
• Write-in: any other means, described in a sentence. A write-in that recurs is proposed to the Risk Leader as a new option for the Criteria.

The provision column on the detectability table

The provision is chosen in Branch B, where there is nothing to rate. It earns its rank later, when the mode crosses. So the detectability table carries a second column: for each rank, which provisions earn it, in the organization’s own words. The mapping is deliberately many to many. The same means of detecting is worth more at source than it is after commitment — automated detection correlated to actual operating conditions sits near the top of the table, while the same instrument measuring degradation after commitment sits in the middle. One provision can earn several ranks, and one rank can be earned by several provisions. Anything stricter would hand out a rank the evidence does not support.

An empty provision is visible to everybody, and it has a consequence: a mode that crosses to Branch A with no provision has no control to rate, and its Detection starts at the bad end of the table.

TENTHCreate Risk Model

This is where every failure mode receives its plus score: RPN+ in Branch A, RE+ in Branch B.

RPN+: impact decides, incidence orders, detection breaks ties. RE+: impact decides, likelihood breaks ties.

Every failure mode stays individual

Its score reads back as its own ratings, so it is judged on its own against the Criteria, never as a share of the others.

Nothing leaves the study here. A ranking orders, it does not remove. Screening is done on impact alone, at the gate, and never on incidence or likelihood.

To do that correctly, SRA introduced the RPN+ and RE+ that are injective mixed-radix encodings that induce a lexicographic order. This is the only time you will find a word soup in SRA. This is an important slogan, though. To cure once and for all the largest pain points in traditional Risk Management.

• Injective means there are not repeated scores.
• Mixed radix means each digit represent a different base, like a clock.
• Lexicographic means with a built in dictionary. You can go either way, back and forth.

This explanation also applies to RIQ+.

Branch A: Create the RPN+ Risk Priority Number Plus

RPN+ is 100 x Impact + 10 x Incidence + 1 x Detection.

RPN+ is faithful with Impact (First digit).

Branch B: Create the RE+ Risk Exposure Plus

RE+ is 10 x Impact + 1 x Likelihood

RE+ is faithful with Impact (First digit).

The score is most sensitive to impact, its leading digit: one step of impact outweighs any incidence, likelihood or detection. That is why impact gets the gate, the sanity test and the auditor’s first look, and why it is the rating to question first (IEC 31010, 6.4.2, uncertainty and sensitivity).

An RPN+ is never compared with an RE+

They are built on different evidence. RPN+ runs from 111 to 1110, RE+ from 11 to 55: different scales, so an RPN+ is never compared with an RE+. Comparing them would place a mode partly because of the branch it came from, which is exactly the distortion the fork exists to avoid. The classical RPN and RE are printed in brackets beside each plus score, because customers still ask for them; decisions are always made on the plus score.

These new structured scoring systems make prioritization faster and the record clear enough to avoid repeated debates, the time saved can go toward investigating important risks, improving designs, or delivering customer value. The key is to keep the process proportionate: use the tables to support judgment, not add paperwork that costs more than it saves.

This method aims to avoid generating bulky, preformatted paperwork and spreadsheets that gets filed away without influencing decisions. A compact, maintained risk register can keep the analysis tied to actual requirements, evidence, and decisions, while making it easier to revisit when things change.

Team Voting is recorded in the Register.

Independent member's initial ratings before discussion can reduce groupthink and control peer pressure, mitigates the "First-Speaker" bias, exposes underlying variance, and eliminates false unanimity.

One rating per person, written before anybody speaks. Every vote is kept. A rank is a whole number, so the score is always a whole rank: the safer of the median and the average rounded up. Votes of 4 and 5 average 4.5, rounded up to 5; the report prints the average, its rounding and the median beside the score. On every SRA table the higher rank is the worse case — the more severe impact, the more frequent failure, the harder detection — so the safer is always the higher. The safer the better. A wide spread on impact is flagged as disputed, because that is where the misunderstanding is: two people looking at the same mode and seeing two different consequences.

As any other subjective ranking method, all depends on the quality of the team members. The voting is part of the record so they must do their best or they could be found accountable with the written proof on the risk register. RPN+ and RE+ rank a single magnitude, RIQ+ ranks 3 complex variables, making each selection unit small, so ranking reliability grows. And recording each vote and its rationale in the risk register makes the decision traceable and encourages care.

It is framed as accountability for a reasoned process, rather than blame for an estimate that later proves wrong. To make the record useful, capture the assumptions and evidence behind ratings, record dissent where it matters, and revisit scores when new information appears.

ELEVENTHThe Consistency or Sanity Test

The full sanity test, with every element in view. The Fifth step ran it early, on importance and impact alone. Here it runs on everything the analysis now holds: the plus scores of the Tenth step, the committee medians, the crossings of the fork, every rating that moved since the gate and every mode added since, with the Auto-Audit’s findings beside it. It is the OK to go on: the Twelfth step proposes the correction or prevention on the best understanding and information the analysis has.

RIQ+ against RPN+ or RE+

The same judgment is made twice, at two levels, by people looking at different things. Where the two disagree, one of them is wrong — and that is worth knowing before the register is signed.

Two judgments, one object

RIQ+ ranks the requirement: how much it is worth and how far that worth reaches. RPN+ and RE+ rank what happens when it fails. Nobody sets out to contradict themselves, but the two are usually rated in different sessions, from different evidence, and often by different audience. Comparing them costs nothing — the numbers are already there.

What can go wrong, and what the test does about it

The usual failure of an FMEA was not bad arithmetic; it was an input nobody questioned. A requirement is called a Must because it was written by the customer, while its modes are rated by someone who has never seen a failure. Or the modes are rated honestly, and the importance was inherited from an old document. Neither error shows up in any score, because both sides are internally consistent. The test catches them by crossing the two.

The bands

A Must is expected to carry a worst failure mode of impact 7 to 10, a Should 4 to 8, a Could 2 to 6. The ranges overlap on purpose: the test is meant to catch the contradiction, not to police every judgment. The letter is the one RIQ+’s Worthiness digit sets; Effort and Readiness never enter, and a requirement with no RIQ+ is not compared. A Branch B impact is read through the table of equivalences, at the top of its band. The first two mismatches are raised earlier too, at the gate, as its caveat. A Won't with any scored failure mode at all is flagged outright: a requirement nobody will do should have no failure modes attached to it.

The two shapes of a mismatch

• Importance high, impact low. The requirement is called a Must, yet nothing that fails about it does much harm. Either it is not really a Must, or the consequences are being under-rated.
• Importance low, impact high. A Could carries a mode that can hurt someone. Something that dangerous is not a nice-to-have: the requirement is misclassified.

One more check rides along. When one requirement carries both a catastrophic mode and a trivial one, the requirement is probably two requirements, and only an engineer can split it.

Read the pair, never blend it

RIQ+ and RPN+ or RE+ are read side by side, as a pair. No formula combines them, and none ever should: the moment worth and consequence are blended into one number, a high worth can buy down a catastrophic impact, and that trade is exactly how launches that should never have flown were approved. Worth decides what we pursue; impact decides what we must protect. Neither pays for the other.

What the test deliberately does not do

It changes no ranking, moves no number and blocks no sign-off. It produces findings — the requirement, the mismatch, and why it matters — and a person decides. The test cannot know which of the two ratings is the wrong one, and guessing would replace a visible disagreement with an invisible one. Every finding is answered in writing before the register is signed: rating corrected, requirement reclassified, or the contradiction explained.

Here is where the risk auditor comes in: the auditor's role shifts from "checking boxes" to finding contradictions. The operational playbook, the audit questions and the auditor's job description are published in the Expert Corner: The SRA Auditor.

TWELFTHCorrect or Prevent

By now, the brain is aligned with the previous information it can do an effective Brainstorming, and joined with data from similar cases.

Aim every action at a digit

The plus scores read back as their own ratings, so every action can say which rating it is meant to move. An action that names no digit is an activity, not a correction.

• Impact moves only when the design or the plan changes: avoid the function, redesign it, add a safeguard or a redundancy. Effort spent elsewhere leaves the first digit where it was.
• Incidence or Likelihood moves when the root cause found in the SIXTH step is prevented.
• Detection moves when a control catches the cause, or the failure, before it reaches the customer. In Branch B it is not scored: a detection provision is part of the design.

Branch A:

Defects already exist on this branch, some of them may already be out of the door. Contain first what has escaped, then correct the root cause so it cannot come back. Detection controls are legitimate here: they guard while the correction is being built.

Branch B

Since you have no physical product or final code yet, you have no defects to fix.

On this branch the cheapest action ever available is a line changed on a drawing. Spend it now; the same decision taken after the tooling is cut costs a recall.

Who does it

The two 6M domains already answer it. A Physical cause is closed with a work order by the owner of the equipment, the material or the environment. A Knowhow cause is closed with training, a procedure or a qualification by the owner of the method. Every action carries the failure mode and the cause it answers, an owner and a due date. An action with no owner belongs to nobody, and nobody does it.

Treat the root cause, not the symptom. Every action names the root cause from the SIXTH step that it removes. Containment and detection guard while the correction is built, but they do not close the cause: a sorted batch, an extra inspection or a warning label leaves the root cause where it was. A Manpower cause follows its face: a cause in the role goes to the owner of the Methods, a cause in the person goes to training or qualification. The action is closed only when the FOURTEENTH step shows the cause is gone — the targeted digit moved, the defect stopped recurring. An action that cannot name its root cause is treating a symptom.

THIRTEENTHMitigation Phase, What We Will Do About It

Every remaining candidate is worked out. This is the management decision on every failure mode still in the study after the impact gate. Each one with merit is worked out to be mitigated: a strategy is chosen for it from the list below, on its own merits — its digits, its cause, the cost of the action and the value it protects.

The decision is individual; the sum needs a budget. Each failure mode is decided one at a time, but the actions all draw on the same resources: money, people, equipment and time. Management sets a budget in resources for the mitigation as a whole. When the budget cannot cover every action, within its branch, the failure mode with the higher plus score is funded first.

One budget, two branches. Within a branch, the higher plus score is funded first. Between branches no score can decide, because RPN+ and RE+ are different scales: when the budget cannot cover every action, the Risk Leader chooses between them, mode by mode, at their discretion, and records the reasons in the Budget notes. A mode that crosses branches, in either direction, is decided again in its new branch.

Impact is the common ground. RPN+ and RE+ cannot be compared, but impact can: it is rated from the consequence, not the evidence, and an injury is an injury in either branch. Between branches, compare impact band by band — Branch B 5, 4, 3, 2, 1 equal Branch A 9–10, 7–8, 5–6, 3–4, 1–2 — and fund the higher consequence first. Within a band the choice is the Risk Leader's, recorded in the Budget notes. Columbia is the warning: no consequence is read lower because its history looks reassuring.

Impact comes before the budget. Any failure mode at or above the critical impact threshold written in the Criteria is mitigated, or accepted with a signature at the authority its impact requires, whatever the budget allows. When the budget runs out, the candidates left are not dropped: they are accepted in writing, or the budget is raised.

The budget is not a gate: nothing leaves the study at it. A failure mode beyond the budget still gets a strategy, and the one it most often gets is a signed Acceptance.

Risk mitigation strategies are planned actions taken to reduce Incidence or likelihood and/or impact of a potential or real threat to a project, business, or system. Rather than trying to eliminate all risks—which is usually impossible—these strategies focus on managing threats to an acceptable level.

The four primary strategies for handling risk are often categorized as follow:

a) Avoidance

Avoidance involves changing a plan or strategy to eliminate the risk entirely. This is the most drastic approach and is typically used for high-impact risks where the cost of the risk outweighs the benefit of the activity. For example, a company might decide not to launch a product in a specific country to avoid the risk of navigating unstable or hostile local regulations.
—Another example, don’t use an untested supplier for a critical component

On the score: the failure mode leaves the analysis. The record keeps it, with the change that removed it and who approved the change.

b) Reduction (or Mitigation)

Reduction focuses on lowering the likelihood that a risk will occur or minimizing the severity of its impact if it does. This is the most common strategy and involves implementing safeguards or redundancies. Examples include conducting extra quality assurance, testing, training to reduce the risk of software bugs or installing fire sprinklers (Safeguards) in a warehouse to reduce the impact of a fire. Redundancy: Devising Backup(s) systems.

Reduction acts through four approaches:

• Prevention: closes the root cause, so the failure happens less often or not at all.
• Safeguard: the failure still happens; the harm is smaller when it does.
• Redundancy: a backup, so a single failure does not carry through.
• Detection control: shortens the time before you know; it does not stop the cause. Automated or manual, as set out in the NINTH step.

On the score: prevention moves the Incidence or Likelihood digit, a detection control moves the Detection digit, and only a safeguard or a redundancy can move Impact. The action plan says in advance which digit it targets, so the FOURTEENTH step can tell whether it moved.

In this order, where people can be hurt: first remove the hazard or the failure by design; then guard against it with a safeguard or a redundancy; and only last, tell the user about what remains. A warning label is never the first answer to a high-impact mode: it is the residual risk, handed to the people who carry it (FOURTEENTH step).

c) Acceptance

Acceptance occurs when a risk is deemed low-impact, unlikely, or too expensive to mitigate. The organization acknowledges the risk and decides to deal with it if and when it happens.

Acknowledge the risk and prepare a contingency plan when reducing it would cost more than the likely loss.

Acceptance can be passive, where no action is taken, or active, where a contingency fund (a "rainy day" budget) is set aside specifically to cover the cost of the risk should it materialize.

On the score: no digit moves. Acceptance is a signature, not a silence: the person who accepts must hold the authority the Criteria assign to that impact level, and the higher the first digit, the higher the signature.

d) Transfer (or Sharing)

Transfer shifts the financial or operational burden of the risk to a third party. The risk still exists, but the responsibility for managing the consequences is moved elsewhere. The most common form of risk transfer is purchasing insurance. Other examples include outsourcing a specialized task to a vendor who is better equipped to handle the associated risks or using a fixed-price contract to transfer the risk of cost overruns to a contractor

On the score: no digit moves. The failure still happens and the impact stays on the record; what changes is who pays for it. An insurance policy has never repaired a reputation or brought anyone back.

And, if no solution was devised:

e) Reconsider Objectives

Go back to the SECOND step: the requirement may be worth less than its risk, or its worth may be reachable another way.

f) Further analysis

Go back to the step where the information ran out. Most often it is the fork: a Branch B mode that needs a test, a prototype or a field trial to gather the history that would move it to Branch A.

The black-swan provision

Every life-threatening hazard has at least one action that limits the harm whatever the cause: a safeguard, a redundancy, or avoiding the exposure altogether. A black swan is the failure nobody wrote down, so no method can list it. But it still has to reach the same target through the same hazard, and that is where it can be met. Prevention is aimed at the causes on the list and cannot stop one that is not there; a safeguard acts on the harm, not on the cause, so it holds against the unlisted path too. That is why the hazard is named in every risk statement: the protection is designed on the exposure, not only on the failure.

A requirement whose origin is a life-threatening hazard, with no such action on any of its modes, is a finding: life-threatening hazard protected only against its listed causes. It is answered with the action, or in writing, signed, with why none is possible.

Final steps:

• Propose the Solution and Development of Action Plan
  Who, what, how, why, where, when, with what. And which digit it targets.
• Answer every consistency finding and every audit finding in writing.
• Sign off: the approver signs the decision on the residual risk, with a name and a date, and the analysis is frozen as a numbered revision that can never change. Work continues on the working copy. This is the residual risk planned; the FOURTEENTH step decides the residual risk achieved.
• Write the Risk Analysis Report
• Implement Solutions
• Update Corporate Risk Register Database

FOURTEENTHWas the Solution Proposal Effective or Have We to Start Again?

Follow Up. Monitor Effectiveness

Re-rate, and compare

Once the action is done, the failure mode is rated again. Scores are kept as a history, so the report shows the risk before and after the action. The digit the action targeted is the first thing to look at: if it did not move, the action did not work, whatever the action report says. An action marked done and never re-rated is a finding.

The residual risk

The rating after the action is the residual risk: the risk that remains once the action is in place. Every failure mode that passed the gate ends the study with one. For a mode that was reduced, it is the re-rating; for a mode that was accepted or transferred, it is the rating it already had, because no digit moved. A mode avoided leaves the analysis and leaves no residual risk behind, only the change that removed it.

Critical usually stays critical. Prevention moves Incidence or Likelihood, a detection control moves Detection, and only a safeguard or a redundancy moves Impact (THIRTEENTH step). So a mode at or above the critical impact is still there after most actions, and that is by design: its residual risk is not decided by a better score, it is decided by a signature.

Decide each residual risk, one mode at a time:

• Re-rate on the evidence, not on the plan. The number the action plan hoped for is not the residual risk. The rating made after the action is done, with its evidence, is.
• A corrected Branch A mode has no history of its own yet. Its defect history describes the item before the correction: the conditions have changed, and the count no longer applies. Until the corrected item has its own record, at least 30 opportunities ranked by the counted-zero table, its residual likelihood is an estimate. It crosses to Branch B, with the correction and its verification as its Likelihood basis, and crosses back when the count is made.
• Ask what the action brought in. A guard can make a pinch point, a sensor a false trip, a new supplier a new defect. Any failure mode the action creates goes to the FOURTH step as a mode of its own, and the record names the action it came from.
• Accept it by name. Every residual risk is accepted at the authority the Criteria assign to its impact level: the higher the first digit, the higher the signature. At or above the critical impact, and for any high-impact mode whose Detection Provision is “None possible”, the acceptance carries a name, a reason and a date. A residual risk nobody can accept goes back to the THIRTEENTH step.
• Tell whoever lives with it. What remains is written into the information for use: the warning, the instruction, the training, the maintenance task. A residual risk the operator was never told about has not been accepted by anyone who carries it.

Then the whole. The overall residual risk is judged last, across all the modes: the approver signs it, with the individual acceptances listed beneath. The sign-off in the Thirteenth step is made on the residual risk planned; this is the residual risk achieved. When the two differ, the analysis is signed again, as a new revision.

More information in the Expert Corner: Residual risk, as the standards read it.

Evidence of effectiveness

Branch A: the recurrence count over the review interval. A correction is effective when the defect stops appearing in the same history that ranked it.

Branch B: verification evidence — the test, the prototype, the design review that shows the prevention holds. Until then, the rating is still a claim.

The fork is revisited

History accumulates. When a Branch B failure mode collects real defect or test data, it crosses to Branch A: Incidence is counted, Detectability is rated against the provisions written in concept design, the complete 1 to 10 tables replace the simplified ones, and RPN+ replaces RE+. A failure mode is never scored on both branches at once, and the record keeps the date it crossed.

Calibrate the experts

When a mode crosses to Branch A, compare the likelihood the team estimated with the incidence now counted. Kept over many modes, the comparison shows how good the team's judgment really is.

Record each comparison in three words: held, under-estimated, or over-estimated. The counted incidence is read against the words of the likelihood that was given: a mode estimated Rare that is now recorded every few batches was under-estimated. Each comparison is filed with what the estimate rested on, its Likelihood basis, and with the votes behind it.

• By basis. Over many modes the record shows which kinds of basis deserve trust: comparable items may hold, unrecorded team experience may run optimistic. The Criteria can then ask for more evidence where a basis has failed before.
• By rater. Each voter’s estimate is kept, so the record shows whose judgment held. That is not blame: an estimate made honestly on the evidence of its day is not a fault. It is how the next committee knows whose 2 means 2.
• Against the bias the consistency test cannot see. The sanity test catches two judgments that disagree; it cannot catch a team that is optimistic about everything. Calibration can, because it compares the judgment with what happened.

This is what IEC 31010 asks of expert opinion: that it “be informed by evidence and data wherever possible”, and that biases such as over-confidence be addressed (6.1.5).

It works the other way too. History only counts inside the conditions it was gathered in. When a Branch A mode meets conditions outside its history — a heavier load, a hotter environment, a debris piece far larger than the test data — its incidence count no longer applies. It crosses back to Branch B: likelihood is estimated on the simplified tables, and RE+ replaces RPN+. The record keeps the date and the reason. Columbia is the case that proves it; see the Columbia case file in the Expert Corner.

Controls are evidence, and evidence ages

Every control carries the date it was last verified. Every review sets the next review date. A control nobody has verified, a review overdue, a critical mode with no action: each one is a finding, and the register search lists them on demand.

Or start again

• The targeted digit did not move: the cause was wrong or incomplete. Back to the SIXTH step.
• A new failure mode appeared: back to the FOURTH step for that mode.
• The requirement or its circumstances changed: back to the FIRST step. The fourteen steps are made to be revisited.

Close the loop on value

The last question is not whether the paperwork is complete. It is what value the action protected or created, and what it cost. That answer, and the reasoning behind it, goes into the Corporate Risk Register, so the next study starts from it instead of arguing the same failure mode from scratch.

Back to Risk

AUTO-AUDITThe Rule Tester and Its Findings

The Auto-Audit is a rule tester, and it reports FINDINGS. Every time the analysis is printed, it checks the record against the rules of each step and reports each breach as a finding: printed on its failure mode, and listed under FINDINGS in the report. Every finding is answered in writing before sign-off. A finding that has been settled stays in the report, with who settled it, when, and what was decided, so the auditor sees the question and its answer together.

It does not replace the auditor’s judgment. A rule can test that a field is filled in, that two inputs agree, that a date has not passed. It cannot test whether the ratings were independent, or whether the history comes from the conditions the item will meet. The auditor reads the findings first, then judges what no rule can test.

The 36 findings, by the step whose rule each one tests:

The Eleventh step’s Consistency Test is a step in its own right: judgment against judgment, decided by a person. The Auto-Audit only points at the mismatch.