Special-Cause Detection Rules: Holding the Gain After the Project Team Moves On

Special-Cause Detection Rules sits in the Control phase of RDMAICS. It applies Nelson and Western Electric run rules to flag special-cause patterns such as trends, shifts, oscillation and stratification. In plain terms, it tells you which signals in your data count as a real change and which are just the normal noise of a stable process.

You reach for it at the point where a project is handing back to the line. The improvement has landed. The chart looks better. The team is about to be reassigned. That is the moment where gains quietly erode, because nobody has written down what a problem looks like or who responds to it.

The tool turns that vague worry into a worksheet. Each row is a rule. Each rule carries a pattern, an interpretation, an action and a record of where it triggered. A new owner can read the sheet and know exactly what to watch for without having sat in a single project workshop.

Use it after you have a control chart with established limits. Use it again whenever the process changes, because a rule set written for last year's process may not describe this year's behaviour.

Everything below works from the sample data that loads with the tool. It is a fictional case, included so you can see the mechanics before you put your own numbers in.

The worksheet holds five rules. Two of them triggered. Rule 1 triggered on 2025-05-04 against cycle time. Rule 5 triggered on 2025-05-06 against error rate. Rules 2, 3 and 4 did not trigger.

That picture is worth pausing on. Two signals, two days apart, on two different measures. Neither is a slow drift. Both are shift-type signals. One is large and sudden. One is medium and still developing. A control owner reading this sheet knows within a minute that something moved in the first week of May, and that it moved in more than one place.

The input side of the tool is a table. You add one row per rule you intend to monitor. Each row asks for the same four things, plus a field recording where the rule triggered.

The sample set uses the classic run rules. Rule 1 is one point beyond three sigma, interpreted as a large sudden shift, with the action to investigate the immediate cause. Rule 2 is nine points on the same side of centre, interpreted as a sustained shift in the mean, with the action to check for a process change. Rule 3 is six points trending up or down, interpreted as drift or trend, with the action to inspect tool wear or data drift. Rule 4 is fourteen points alternating up and down, interpreted as oscillation or two processes, with the action to check stratification. Rule 5 is two of three points beyond two sigma on the same side, interpreted as a medium shift, with the action to monitor closely.

Notice what the action column is doing. It is not a description. It is an instruction. The value of the worksheet comes from the fact that the response is decided in advance, while the project team still has the context to decide it well.

The result panel summarises the worksheet as a control output. It reports five rules, two triggered and three not triggered. It then names the triggers directly: Rule 1 on 2025-05-04 for cycle time, and Rule 5 on 2025-05-06 for error rate.

Below the summary, each rule is laid out as a numbered card carrying its pattern, interpretation, action and trigger status. The cards for Rules 2, 3 and 4 still appear, each marked not triggered. That matters. A rule that did not fire is evidence, not empty space. It tells you the process is not drifting and is not oscillating, which narrows the search considerably.

The tool also offers an AI review that explains the result in context. Treat that as a reading aid. The worksheet itself remains the record you hand over.

Read the result in this order. Count first. Then read the triggered list. Then read the not-triggered rules to see what you have ruled out. Then go to the action column for the rules that fired.

Rule 1 fired on cycle time on 2025-05-04. The action attached to it is to investigate the immediate cause. That is a same-day task for one person. A single point beyond three sigma is rarely subtle. Something specific happened on that date, and the record of what happened is usually still available.

Rule 5 fired on error rate on 2025-05-06. The action attached to it is to monitor closely. That is a different decision. You are not launching an investigation. You are raising the sampling attention on error rate and waiting to see whether the medium shift becomes a sustained one. If Rule 2 later fires on the same measure, you have your answer and you escalate.

Because Rule 3 did not trigger, you can set aside tool wear and data drift as the explanation for now. Because Rule 4 did not trigger, you can set aside stratification and the two-populations hypothesis. That leaves shift-type causes, which points the investigation at changes in input, method, staffing or setting rather than at slow degradation.

The practical output of this screen is a short list of owned tasks with dates attached. That is what holds a gain in place once the project team moves on.

The most frequent error is turning on every available run rule without thinking. More rules means more signals, and many of those signals will be false. The sample worksheet carries five rules, not fifteen. Five is a set a person can remember and act on.

The second error is writing a vague action. Compare investigate immediate cause with review as required. The first names a task. The second names nothing. Every action in the worksheet should be something a named person can finish.

The third error is leaving the triggered column blank instead of writing not triggered. A blank reads as unchecked. The explicit words not triggered read as checked and clear. Three of the five sample rows carry that entry for exactly this reason.

The fourth error is treating a trigger as a verdict. Rule 5 on error rate is a signal to watch, not proof of a failure. The interpretation column calls it a medium shift. The action column says monitor closely. Both of those were decided before anyone felt pressure to explain a bad number.

A control plan fails when it depends on memory. The worksheet removes that dependency because it states the rule, the meaning and the response in one place.

Put a name against each action before handover. Agree how often someone reviews the chart against the rule set. Agree where triggers get logged, which in this case is the triggered column itself, carrying the date and the measure.

Then review the worksheet on a schedule. Over time the pattern of triggers tells its own story. In the sample, two triggers appear in the same week on two measures. If that repeats month after month, the rule set is not the problem. The process is.

Special-Cause Detection Rules does not analyse your raw data. It does not calculate control limits, plot points or scan a series for patterns. It is a worksheet that records which rules you monitor and where they triggered. The detection work happens on your chart. The tool organises the response.

It also does not tell you the cause. Rule 1 on 2025-05-04 says a large sudden shift occurred in cycle time. It does not say why. The interpretation column offers the usual meaning of that pattern, and nothing more. Root cause work still belongs to the Analyse tools and to people who know the process.

It cannot judge whether your rule set is the right one. If you write a rule that does not suit your data, the tool will carry it forward faithfully. It cannot tell you that three not-triggered rules mean the process is stable in every respect, only that those three specific patterns were absent.

Finally, it holds nothing in place by itself. A worksheet with no owner and no review date is a document. The gain is held by the person who reads the chart, sees the pattern and takes the action already written in the row.