The Decision ProductWork with me

The method

Method 18

Install the Rule

The specification that lets an organization run a decision repeatedly without the analyst in the room.

Agreement in principle with Tuesday unchanged is not a decision. It is a good meeting, which is the most seductive of the three failure modes because it feels like success.

The remedy is a specification. These items are all the same kind of thing, which is operating facts, and that is what makes them summarizable as one rule.

What has to be specified

Owner of the running rule. Not the sponsor of the study. The person who can change a parameter without convening a task force. If analytics retains the parameters, the rule dies when the analyst changes seats.

Cadence. When the rule fires, and separately when humans review it. “Ongoing” is not a cadence. Ongoing is how freeze dates pass.

The rule itself. Thresholds, classes, freeze logic, and what the system does when it is unsure. Unsure is a case. If you do not specify it, a planner will specify it with a pad, and the pad will be invisible.

Exception path. Who may break the rule, how that break is priced, and how it is recorded. An unpriced exception path is already a shadow rule.

Feedback. What you will look at to see whether the ranking is still right. A scoreboard for this rule, not a tour of last quarter.

Revisit triggers. Dates and flip conditions, not “ongoing monitoring.” The third of July, or sooner if bypass exceeds eight percent for four weeks. A date is a complete thought. Monitoring is a label.

What the rule can know when it fires

This is the constraint that most cleanly separates a rule that runs from a rule that was designed.

At the moment the rule executes, only some information exists. A stocking rule that requires next quarter’s demand cannot run, however well it performed in backtest, because backtests are computed with information the rule will not have.

Walk through a single firing, out loud, and ask of every input whether it is available at that instant, from a system, without a human deciding anything. Anything that fails that test is either an assumption to be made explicit or a dependency to be built.

How rules die

Four ways, and all of them are predictable.

The owner moves, and nobody inherits the parameters. The exception path widens until the rule is the exception. An input goes missing and the unsure case was never specified, so people improvise permanently. The revisit date passes without anyone noticing, because it was “ongoing.”

Each of these is addressed by one line in the specification above. That is the argument for writing all seven of them even when it feels bureaucratic.

Legibility is a feature

A rule a planner does not understand will be routed around, and the routing will not be reported.

This means the effective value of a rule is the value it delivers when followed multiplied by the probability that it is followed. A simpler rule with a higher compliance rate frequently beats a better rule with a lower one, and the comparison is rarely made because compliance is assumed.

Write the rule so the person running it can explain it to a colleague in one sentence. If they cannot, expect a workaround and plan for it rather than being surprised.

When you are not allowed to install

Sometimes the organization will not let you specify the operating process. It is not your remit, or the owner will not commit, or the change requires a system nobody will fund.

Say so in the write-up, explicitly, as a limitation of the decision rather than as a footnote. “This recommendation is not installable until Parts Planning owns the class parameters” is a finding. It names the actual blocker and it puts the cost of inaction where it belongs, rather than leaving the analyst to absorb it as a personal failure to influence.

Templates

The toolkit turns this into something you can open and fill in

Free worksheets for the choice sentence, the write-up, the working sequence, the complexity ladder, and the rule specification, each built on the method described here.