What a Repeating Rule Is Made Of

Leave one of these unnamed and the organization will name it for you, usually badly.

The state. What is visible at the moment the rule fires. On hand, on order, the item’s class, whether an exception is already open. Not what was true in the historical extract. What a person or a system can actually see on Tuesday morning.

The decision. What the rule is allowed to do now. Order this quantity, release this expedite, assign this class, refuse this exception. A decision is an action available in the current state, not a hope about an outcome.

The information that will arrive. What you do not control and do not yet know. Demand this week. A customer who goes around you. A supplier who misses. A date that moves. If the rule pretends this is empty, you have written a deterministic plan and called it a policy.

The transition. How the state, the decision, and the new information combine into the state the rule sees next time. This is the part analysts skip because it feels like plumbing. It is the reason a rule that looks good in a snapshot oscillates within a week.

The objective. What you are accumulating across those transitions, in units of consequence rather than in house metrics. A rule with no objective gets run against whoever’s scoreboard is loudest that month.

Most analysis specifies two of the five

Look at a typical notebook and you can name which two. The decision is whatever the model outputs. The objective is whatever it was trained or optimized on. The state is whatever happened to be in the extract. The incoming information is assumed away, or replaced by a point forecast treated as fact. The transition is a loop in a backtest that does not contain the people who will route around the rule.

That notebook can still be correct about last year. It cannot be a rule, because a rule is a function of a state it will actually be handed, using information that will actually be available, producing a next state the organization will actually occupy.

Rank alternatives on the notebook’s two parts and you will pick the one that fits history. Install it and you will discover the other three.

The state is not the database

A particularly expensive confusion is to treat the warehouse schema as the state. The schema is what you could query in week two, with permission and time. The state is what the rule can see in forty seconds, where the rule actually lives. Those overlap; they are not the same set.

If a quantity lives only in finance, it is not in the state, and a rule that consumes it will be run on a guess. If a quantity is known only after the month closes, it is not in the state during weeks two through four.

The unofficial spreadsheet is part of the state. Ignoring it does not make the rule cleaner, it makes the rule a description of a company that does not exist. Either the rule absorbs what the spreadsheet is doing, or the spreadsheet keeps running alongside it.

The practical consequence

Specifying all five frequently changes the alternative rather than merely documenting it. A classification rule that needs last year’s outcomes cannot run on a Tuesday that does not have them, so the rule becomes: classify on something visible now, and treat the behavior you cannot control as information the rule has to survive rather than as a footnote.

Write the five before you specify screens, dashboards, or thresholds. If a row is blank, you have a slogan about a rule rather than a rule.