Business Rule

While a product is small its rules live in someone's head. Ask whether two coupons can stack and the person who built it says no, and that settles it. The arrangement breaks down as people and features are added.

The breakdown shows up as one question collecting different answers. A customer asks whether two coupons can be used together, support says no, and the same week sales says yes while chasing a large deal. An engineer opens the code and reports that it currently works. None of the three is lying — nothing was ever decided, so each of them said what they knew.

With nothing decided, the code ends up being the rule. The trouble is that code is not a document of rules. A condition someone added in a hurry three years ago keeps running with nobody knowing why it's there, and when two coupons land on one order and it ships below cost, that isn't a bug. It's the result of a decision nobody made.

A business rule takes those conditions out of the code and states them as sentences. The whole character of the artifact is that it's a constraint from the business domain rather than a technical document. Nothing negotiable or a matter of taste belongs in it — only the conditions that, when broken, leave money unaccounted for or put the company in breach of a contract.

Writing a rule so that a stranger can read it and act on it takes five fields.

1. Scope — narrow down where the rule applies before anything else. One sentence does it: "applies to customers on a paid team plan billed monthly." Leave out whether it reaches the free plan, or whether contracted enterprise accounts are exempt, and the four fields below all turn vague.
2. Condition and outcome — the body of the rule. Put "if seats are reduced" on the left and "credit the prorated difference on the next invoice" on the right, laid out as a table. One condition per row. Bundle two together as "if seats are reduced and fewer than 15 days remain," and the moment the day threshold moves to 7 the seat rule shakes along with it.
3. Precedence — which rule wins when two apply at once. Write down that a contract beats a coupon when an enterprise agreement's negotiated discount arrives alongside one, and further combinations of the same kind stop producing different answers.
4. Effective date and retroactivity — when it starts, and whether it reaches people already in that state. This is the field most often left blank, and leaving it blank means someone who paid yesterday gets treated differently from someone who paid today.
5. Change history — one line per change, recording when and what. If the reasoning also needs to be preserved, keep a separate decision record for it. That document holds the circumstances at the time; this field carries only the date and the link.

Once a rule stands, the next job is finding the boundary situations that shake it. Reducing to eight seats when nine people are already invited is one of those, and situations like it are called edge cases. Deciding what the product does in that situation, down to the steps and deadlines, is an exception policy.

The writer is whoever owns the product. At Pagedeck that's Mia. She doesn't decide alone, though — the answers come from whoever holds them. Finance holds refund terms, sales holds the exceptions for contracted accounts, legal holds how long data may be kept, and the product owner's job is to assemble those answers into one set of sentences that don't contradict each other.

Four groups read it, and each one reads a different field.

1. Engineers translate field 2 straight into code. One condition per row is what keeps interpretation out of the translation.
2. Quality builds test cases from fields 2 and 3. A rule laid out as a table yields one test per row.
3. Support reads fields 1 and 4. That's where the answer to "why not for me?" comes from.
4. Designers take from field 2 what the screen has to prevent. A screen with a button that can be clicked and then refuses was built without reading that field.

Rules that have to reach customers as a promise move into the terms of service. Refund conditions and data retention periods are the usual ones. The two documents state the same facts for different readers, so changing only one leaves the product's behavior and its public promise out of sync.

"That's a business rule, so there's no exception. The contract terms would have to change."

This isn't something a product setting can solve.

"Where is that condition written down? If it only exists in code, it's an implementation, not a rule."

Drawing the line between what was agreed in a document and what simply got built that way.

"If a coupon and a contract discount both land, nothing says which wins."

A warning that field 3 is blank, so an engineer will decide it on the spot.

Pagedeck first needed this document after adding per-seat pricing. Seats cost $7 a month, an administrator tried to drop from twenty seats to eight, and nine people were already invited. Theo asked how to handle it and no answer came back, because blocking until invites are revoked, dropping the extra people to read-only, and simply allowing it and settling on the next invoice were all plausible.

What Mia wrote that day was one line: paid seat count cannot fall below the number of people invited, and reducing it requires revoking invites first. The same question came three more times afterward, and each answer took a minute.

The frequent assumption is that these belong inside a development spec. They end up as code, so writing them into the requirements document feels sufficient. But these conditions existed in the business domain before the product did. Limiting an order to one coupon isn't feature design; it's there because otherwise the money doesn't add up. Kept only inside a product requirements document (PRD), a rule gets read once while that feature is built, and six months later nobody finds it when a different feature touches the same condition.

The other misreading is that a rule, once set, never changes. "A condition that must be kept" sounds permanent. In practice rules change whenever pricing changes or the company enters a new country. That's what field 5 is for, and when it's empty nobody can be sure six months later whether the sentence in front of them is current.