Business rule register template: rule, source, rationale and owner

Rule, source, rationale, owner and the event that would make it wrong. Why a rule is not a requirement, and what breaks without the register.

Nothing enters this register without a tag. The seven-tag provenance legend is at the top of template 1 and it governs the four templates that hold claims about the business (the stakeholder map, the process, the requirements register and this one): [POLICY], [HELP], [THREADS n=10], [WALKTHROUGH], [LAW], [MINE], [OPEN]. A register is the one artifact whose entries get quoted years later by people who never met you, so every statement, every rationale and every owner in it says where it came from. An untagged rule is a rumour with a number.

First: a rule is not a requirement

This is the most confused pair in the job, and the confusion is expensive, because a register full of requirements gives you nothing to trace back to.

A business rule is true whether or not you build anything. It constrains how the business behaves. Cancel the project, fire the vendor, go back to paper, and the rule still holds. Someone decided it, on a date, for a reason, and someone can change it.

A requirement is what the solution has to do about a rule or a need. It only exists because you are building something. Kill the project and the requirement dies with it.

The test that settles most arguments: say the statement out loud with the words "with no software at all" on the end. If it still makes sense, it is a rule. If it stops making sense, it is a requirement.

The pair to watch. In the worked case in this pack, BR-12 says a case that misses the decision window is assigned to a named person rather than to a queue, and REQ-015 says the system assigns it. They read almost the same and they are not the same. The rule holds even if a duty manager does the assignment by hand on a Post-it. The requirement is the system doing it. If you cannot say what your rule would mean with no software at all, you have written the requirement twice and traced it to itself.

How to fill the register

One row per rule, and one rule per row, so that a reviewer's comment lands on a line instead of a paragraph. Chase the reason behind every rule until you either find it or can say precisely who would know - the statement is the cheap half of the row, and the rationale is what makes the register worth having. Mark your own inferences as inferences, every time, because an unmarked guess in a register is the thing that gets quoted back at you in eighteen months as though it were policy.

Column conventions

• Rule ID. BR-nn, permanent. Never reuse a number after a rule is retired; strike it through and leave it in place.
• Statement. One sentence, no conjunctions hiding a second rule. Write the boundary condition explicitly: "above 40 EUR" leaves 40 EUR itself undecided, which is exactly the case that will arrive on day one.
• Source. Start the cell with Established: or Inferred:, add the tag saying where it came from, then who set it and when if you can find that out. A rule with a name and a date can be renegotiated. An anonymous rule can only be worked around, which is what teams do to rules they cannot argue with. When no source names an owner, leave the slot open with the role in it rather than closing it with a plausible job title, and give the gap an open question id.
• Status. Established and inferred is a binary, and rules are not. Close the source cell with Status: Observed, Status: Inferred or Status: Proposed. Observed means you found the rule stated somewhere and nobody has confirmed that it is enforced. Proposed means you wrote it yourself because a requirement needed something to trace to, which is honest, and hiding it is not. Leaving this field out is how a rule that somebody proposed on a Tuesday becomes a rule that has always been there.
• Rationale. Why the rule exists, in the owner's terms, not yours. Where the reasoning is yours, say so in the cell. Close the cell with Review trigger: and the event that should make somebody look at this rule again.
• What breaks if we ignore it. The concrete consequence, on a named person's desk. "Non-compliance" is not a consequence, it is a category.
• Related requirements. The REQ ids that exist because of this rule. Empty cell means either an orphan rule or a missing requirement, and both are worth an hour.

What a source cell looks like when you have access, and why the example rows below do not. With a client, a seat in the returns session and permission to quote it, the cell reads: Established [INTERVIEW 2026-03-12]: set by the Head of Customer Care on 12 March in the returns session, replacing the informal "as soon as possible" in use until then. Status: Established. That is the strongest cell in this template, and it is available only to somebody who was in the room.

The worked case that the example rows come from was built from public sources. Nobody inside that company was asked anything. So its rules are Observed rather than Established, its owners are open rather than named, and the register says so, because a register that borrows the authority of a meeting that never happened is worth less than an empty one. Write the version your access actually supports.

The register

The italic rows are an example, from the worked case in this pack: returns handling at a mid-size online retailer, built from public sources. Both rules are Observed and both owners are open, because a published sentence tells you that a rule exists and tells you nothing about who can change it. Neither row is weaker for saying so; a reviewer trusts the register that admits which half it has. Delete the rows before you send yours.

Rules I could not source

Anything you believe is a rule but cannot attribute goes here rather than into the register. A rule in the register carries the register's authority, and a guess promoted into it quietly poisons everything that traces to it later.

Before you call this done

1. Which of these rules could you get changed? Pick one and name the person you would ask and the argument you would make. Rules where the honest answer is "nobody knows who owns this" are the ones that will survive your redesign untouched and unexplained, because changing them feels riskier than keeping them.
2. Which rationale is yours rather than theirs, and is it tagged? Read your own rationale column looking only for unmarked inference, and put [MINE] on every sentence that turns out to be your reasoning wearing the owner's voice. Marking your inference as inference is not weakness; it is the whole difference between an analyst and someone who fills gaps with confident guesses.
3. Take one requirement from your register at random. Can you name the rule it traces to, and does that rule exist here? If the trace lands nowhere, you have either an undocumented rule or a requirement somebody invented, and both need a name against them before anyone builds anything.

How long this takes. Twenty to thirty minutes per rule, and most of that is chasing the why. The statement itself takes two minutes, which is why most registers contain only statements.

The one mistake. Accepting "that is our policy" as a rationale and writing it down as though it were one.

Scorecard checks that apply to this artifact: 15 The rule states its condition and its outcome in one sentence 16 The rule names the person or role who set it, and the date it was set 17 The reasoning is written down, and anything you inferred rather than found is labelled as an inference 18 The rule names the event that would make it wrong and should trigger a review

Template 4 of the Proof Pack, from analify.com. Use it in your own applications and at work, including commercially. Do not resell it as your own product.

In the worked case

Section 5 of the worked case shows this artifact filled to the standard the template asks for: returns and refunds at a mid-size online retailer, built from public sources only, with every number tagged. Read it there, then come back to the blank.

The scorecard checks for this artifact

One rule, stated precisely, with the reason behind it and the person who owns it.

All twenty-five checks, with the scoring scale: the scorecard.

Notes that work on this artifact

Next template

All six templates · The worked case · The scorecard