# The Rule Specification

> From *The Decision Product* (Chapter 18). Use this before you call a decision done.
>
> Agreement in principle with Tuesday unchanged is not a decision. It is a good
> meeting, which is the most seductive failure mode because it feels like
> success.
>
> These seven items are all the same kind of thing, which is operating facts.
> That is what lets them be summarized as one rule.

---

### 1. 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.

**Owner:** ____________________

---

### 2. Cadence

When the rule fires, and separately when humans review it.

"Ongoing" is not a cadence. Ongoing is how freeze dates pass.

**Rule fires:** ____________________
**Humans review:** ____________________

---

### 3. 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.

**Specification:** ____________________
**The unsure case:** ____________________

---

### 4. 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.

**Who:** ____________________
**Price:** ____________________
**Recorded where:** ____________________

---

### 5. 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.

**Watching:** ____________________

---

### 6. Revisit triggers

Dates and flip conditions. Not "ongoing monitoring."

"3 July, or sooner if bypass exceeds 8 percent for four weeks" is a complete
thought. "Monitoring" is a label.

**Date:** ____________________
**Or sooner if:** ____________________

---

### 7. What the rule can know when it fires

Walk through a single firing, out loud. For every input, ask: is this available
at that instant, from a system, without a human deciding anything?

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.

| Input | Available at fire time? | If not: assumption or dependency? |
|---|---|---|
|  |  |  |
|  |  |  |

---

## How rules die

Four ways, all predictable, each addressed by one line above:

1. The owner moves and nobody inherits the parameters.
2. The exception path widens until the rule *is* the exception.
3. An input goes missing and the unsure case was never specified, so people improvise permanently.
4. The revisit date passes unnoticed, because it was "ongoing."

---

## Legibility is a feature

Effective value = value when followed × probability it is followed.

A simpler rule with a higher compliance rate frequently beats a better rule
with a lower one. The comparison is rarely made, because compliance is assumed.

**Test:** can the person running it explain the rule to a colleague in one
sentence? If not, expect a workaround and plan for it.

---

## When you are not allowed to install

Say so in the write-up, explicitly, as a limitation of the decision rather than
a footnote.

"This recommendation is not installable until Parts Planning owns the class
parameters" is a finding. It names the blocker and puts the cost of inaction
where it belongs.

---

The Decision Product  ·  thedecisionproduct.com