How do you document business rules so people and AI tools can follow them?

Every organisation runs on rules, but many of them live only in people's heads. A discount limit, an approval threshold, a rule for which supplier gets a late delivery penalty: someone knows it, someone else guesses, and a new colleague learns it by making a mistake. Writing business rules down makes work more consistent, and it is the first step before asking any AI tool to follow them.

This guide explains a proposed documentation pattern. The examples are fictional, and no measured business results are claimed.

What is a business rule?

A business rule is a short statement that says what must, may, or must not happen under certain conditions. It is more specific than a policy and more stable than a task instruction.

For example, "Orders above a set value need manager approval" is a rule. "Be careful with large orders" is not, because nobody can tell whether it was followed.

Why write rules down?

• Consistency: two people facing the same case reach the same decision.
• Onboarding: new staff learn from a document instead of from mistakes.
• Change control: when a rule changes, you know what else is affected.
• Automation and AI: a tool can only follow a rule that is stated clearly. An unclear rule produces unclear results, whether the reader is a person or a model.

Step 1: Start with one process

Choose one process where decisions are repeated and mistakes are costly, such as approving refunds or accepting supplier deliveries. Do not try to document the whole organisation at once.

Step 2: Collect the rules where they already exist

Rules hide in several places: emails, spreadsheets, old contracts, system settings, and the habits of experienced staff. Ask the people who do the work to describe a recent case and explain each decision. Write down every "we always" and "we never" they mention.

Step 3: Write one rule per statement

Use a simple pattern: When a condition is true, then an action must, may, or must not happen.

A fictional example: When a refund request is above the agreed limit, then a manager must approve it before payment.

Keep each statement short enough to test. If a sentence contains "and" twice, it probably holds more than one rule.

Step 4: Define the terms

Words such as "customer", "large order", or "urgent" mean different things to different people. Add a short glossary and state the numbers, dates, or categories behind each term.

Step 5: Add an owner, an example, and an exception

For every rule, record:

• Owner: the person responsible for keeping it correct.
• Example: a short case that shows the rule being applied.
• Exceptions: when the rule does not apply, and who may approve an exception.
• Source: why the rule exists, such as a contract, a law, or a management decision.

A rule without an owner is one that quietly goes out of date.

Step 6: Test the rules on real cases

Take ten recent cases, remove the outcome, and ask someone to apply the written rules. Compare the result with what actually happened. Differences show a missing rule, an unclear term, or an exception nobody wrote down.

Step 7: Store the rules in one place and review them

Keep the rules in a shared location that people can search, with a version date and a review schedule. Review them when a contract, law, price, or process changes, and at least once a year.

Using documented rules with AI tools

Clear rules make AI use safer and easier to check.

• Give the tool only the rules relevant to its task, not the whole document.
• Ask it to name the rule it applied, so a person can check the reasoning.
• Keep a person responsible for decisions that affect customers, money, or personal data.
• When a rule changes, update the document first, then update any tool that depends on it.

An AI tool can misread or invent a rule, so review remains necessary even when the documentation is good.

Documentation checklist

• One process selected.
• Rules collected from people, files, and systems.
• Each rule written as one testable statement.
• Key terms defined with numbers or categories.
• Owner, example, exception, and source recorded for each rule.
• Rules tested against recent real cases.
• Rules stored in one searchable place with a review date.

Frequently asked questions

How detailed should a rule be?

Detailed enough that two people would reach the same decision, and short enough to test. If you cannot test it, it is probably too vague.

Who should write the rules?

The people who do the work, with the owner approving the final wording.

Do I need special software?

No. A shared document or spreadsheet is enough to start. Choose a dedicated tool later, if the number of rules grows.

Should every rule be automated?

No. Start by documenting. Automate only the rules that are stable, frequently used, and clearly tested.

The practical next step

Pick one process this week and write down its five most important rules using the "when, then" pattern. Test them on five recent cases and fix whatever does not match reality.

For wider context, read AI and Organizational Intelligence. Related reading: How can AI fill business forms from documents while keeping users in control? and How can businesses contain, report, and learn from AI errors?

Sources and review

This article contains editorial guidance and does not rely on external statistics or legal claims.

Factual review: 16 October 2026. Implementation steps are editorial recommendations.