Business rule

A business rule states what the organisation considers necessary, prohibited, or necessarily implied

Common types of business rule

A business rule is often imagined as an approval threshold. Real projects also use rules to define terms, determine when an object is valid, constrain who may act, and decide what happens when facts are missing. Distinguishing the types helps the team find the right authority and choose an appropriate implementation.

What to record for a governable rule

A sentence can sound sensible and still be unsafe to implement. The team needs to know where it came from, whom it applies to, which facts it requires, how exceptions work, and how an earlier decision can later be reconstructed. Together, the following details make a rule maintainable rather than merely plausible.

How to discover and confirm the real rules

Rules rarely sit neatly in one document. Policy may state the principle, a delegation table holds the threshold, experienced staff know the exceptions, and legacy code contains years of accumulated decisions. Discovery brings those clues together and asks the person with genuine authority to confirm their meaning.

1. Name decisions and business objects

   List eligibility, amount, status, routing, and restriction questions the project must answer consistently and identify accountability. Do not begin with database fields or legacy code.

2. Collect authoritative material

   Examine law, contract, policy, delegation tables, product terms, forms, procedures, and prior decisions, recording version, effective scope, and authorised interpreter.

3. Interview operators and control roles

   Ask caseworkers, approvers, compliance, finance, operations, and audit about normal judgement, exceptions, disputes, and remedies; distinguish formal rules from habit and system limitation.

4. Observe cases and records

   Sample approvals, refusals, returns, escalations, withdrawals, and exceptions. Different results for the same facts may expose a hidden rule, poor data, or unauthorised variation.

5. Normalise vocabulary

   Define request, valid authorisation, business day, amount, customer status, and other terms before writing rules, resolving synonyms and ambiguous terms.

6. Write atomic rules with evidence

   Split compound prose into individual judgements linked to authority and rationale. Mark uncertainty for owner decision rather than silently choosing in code.

7. Replay examples and boundaries

   Have authorised owners judge typical, threshold, missing, conflicting, and exceptional facts to prove a unique result or an explicit cannot-decide result.

8. Approve baseline and stewardship

   Identify the effective rule set, precedence, date, approver, and change route, separating accountability for business meaning, administration, and implementation.

Decision tables test logic but do not replace governance

As conditions multiply, prose makes gaps, overlaps, and conflicts difficult to see. A decision table exposes combinations of facts and conclusions, but it cannot prove that a threshold or precedence rule is authorised. It is a tool for finding logical problems, not a substitute for business accountability.

1. Are inputs stable facts?

   Each input has a name, type, allowed values, source, and time semantics; unconfirmed model output is not silently treated as fact.

   Check glossary and data definitions.

2. Are rows distinguishable?

   Analyse overlaps that may match contradictory conclusions and define an explicit hit policy.

   Check overlap analysis and hit policy.

3. Does every combination have an outcome?

   A gap yields an explicit default, insufficient-data, cannot-decide, or human-review result, not the first row or null by accident.

   Check completeness and no-hit tests.

4. Are boundaries and units exact?

   Greater than, at least, cutoff date, time zone, currency, rounding, and null handling must be explicit.

   Check boundary-value and unit tests.

5. Is the output a conclusion or action?

   A table may conclude countersignature required; task creation, notification, and write-back still need process, authority, and error handling.

   Check decision–process–action mapping.

6. Are source and version retained?

   Logic traces to rule IDs and authority, while each run records the rule-set version, inputs, and matched path.

   Check decision logs and version register.

A constructed procurement rule set

The customer-independent procurement rules below connect the earlier pieces. The point is not any particular threshold, but how definition, separation of duties, missing facts, and precedence combine into a decision—and why that decision still does not mean a system action succeeded.

How rules become an auditable, changeable baseline

Rules change with policy, products, and organisational responsibility. The important question is whether the team can still say which version governed each item. A baseline gives estimates, implementation, acceptance, and production one identifiable reference and lets historical decisions be reviewed under the conditions that applied at the time.

1. Maintain a register and glossary

   Keep ID, statement, type, terms, authority, owner, scope, version, status, dependency, tests, and implementations together rather than allowing policy, spreadsheet, configuration, and code to diverge.

2. Separate ownership from implementation

   Business or compliance authority approves meaning; technology implements it and discloses limitations. Permission to edit a platform does not confer policy authority.

3. Approve an identifiable rule set

   Estimates, design, acceptance, and production name a rule-set version and source snapshot, not unreproducible current online logic.

4. Keep implementations consistent

   Front-end guidance, back-end validation, batch, reporting, and AI tools should use one authoritative service or automated consistency controls.

5. Assess impact before change

   Evaluate historic and in-flight cases, interfaces, access, notification, training, tests, price, AI evaluation, rollback, and whether old work keeps the old version.

6. Release, monitor, and roll back

   Replay boundaries and history; record approval and effective time; monitor distribution, no-hits, conflict, and override; retain a path to an approved set.

7. Preserve explainability

   Subject to privacy and retention, retain facts, rule version, matched logic, override actor, and rationale for appeals, audit, and incident reproduction.

How rules connect scope, process, systems, and acceptance

A rule is not an appendix left behind after requirements. It affects required data, process branches, integration failure handling, acceptance boundaries, and operational ownership. If different parts of a project use different rule versions, individually working features can still produce inconsistent business outcomes.

In enterprise AI, rules cannot collapse into prompt instructions

It is useful for a model to read policy and explain a rule, but “the model generally understands it” is not reliable execution. Outputs vary with prompts, context, and model versions. For access, money, prohibitions, or irreversible actions, the project must separate helpful interpretation from final control.

Concepts commonly confused with business rules

Policies, processes, data validation, and code conditions can each carry part of a rule, so project conversations often treat them as interchangeable. The distinction matters: when an implementation is mistaken for the rule itself, the team may lose sight of who can approve its meaning and which constraints must survive a system replacement.