# Business Rules Catalogue: [Business domain]

> Catalogue of the business rules for one domain: each rule's ID,
> statement, type, source, owner and the points where it is enforced.
> The rule types follow the Business Rules Analysis technique of IIBA's
> BABOK Guide version 3 (technique 10.9: definitional and behavioural
> rules) and the rule categories of the OMG *Semantics of Business
> Vocabulary and Business Rules* (SBVR) version 1.5 (December 2019).
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- A business rule is a statement the business owns that defines a term
  or guides behaviour. It exists whether or not there is software; keep
  it independent of any screen, table or process step.
- Write each rule once, here, and reference its ID from requirements,
  process models, decision tables and acceptance tests.
- Give every rule an owner in the business who can change it. A rule
  owned by IT is usually a design decision, not a business rule.
- Mark the enforcement points (section 4) so that a change to the rule
  can be traced to every place that must change with it.
-->

## Document control

<!-- Guidance: Identify the catalogue and record who approves rule changes. -->

| Field | Value |
|---|---|
| Document ID | [BRC-DOMAIN-001] |
| Domain | [Business domain, for example Home claims] |
| Version | [0.1] |
| Status | [Draft / Approved / Superseded] |
| Owner | [@business-rules-owner] |
| Rule change approver | [Role or board] |
| Last updated | YYYY-MM-DD |
| Related documents | [Business requirements], [Process models], [Decision tables], [Glossary] |

## 1. Rule types and writing conventions

<!-- Guidance: Agree the types and the sentence style before cataloguing. Questions: does the team need SBVR's formal wording, or controlled natural language is enough? Pitfall: mixing rules with requirements ("the system shall check the policy status") so the rule disappears when the system changes. -->

| Type | What it does | Example wording |
|---|---|---|
| Definitional (SBVR: definitional rule) | Defines a term or how something is classified or computed; cannot be broken, only applied wrongly | "A policy is active if today is between its start date and end date and the premium is not overdue by more than 30 days." |
| Behavioural (SBVR: behavioral business rule) | Guides conduct; people or systems can break it, so it needs an enforcement level | "A claim with an estimated value above 5,000 must be referred to a handler before any payment." |

Writing conventions:

1. One rule per statement, in the business's terms from the glossary.
2. Use "must", "must not" or "may only" for behavioural rules, and "is"
   or "is defined as" for definitional rules.
3. Name the subject explicitly; avoid "the system", "it" and "they".
4. Put thresholds in the rule, not in a footnote.
5. State exceptions as separate rules with their own IDs.

## 2. Rule catalogue

<!-- Guidance: One row per rule. Source is where the rule comes from (law, policy, contract, management decision). Owner is the business role that can change it. Pitfall: copying policy paragraphs as rules; break them into atomic statements. -->

| Rule ID | Statement | Type | Source | Owner | Enforcement level | Status |
|---|---|---|---|---|---|---|
| BR-CLM-001 *(Example)* | A first notice of loss is the first report of an incident by or for the policyholder | Definitional | Claims manual 2.1 | Head of claims | n/a | Approved |
| BR-CLM-002 *(Example)* | A policy is active if today is between its start date and end date and no premium is overdue by more than 30 days | Definitional | Policy terms, section 4 | Head of underwriting | n/a | Approved |
| BR-CLM-004 *(Example)* | A claim may only be notified online for an active policy | Behavioural | Digital channel policy | Head of claims | Strictly enforced | Approved |
| BR-CLM-007 *(Example)* | A claim with an estimated value above 5,000 must be referred to a handler before any payment | Behavioural | Claims authority matrix | Head of claims | Strictly enforced | Approved |
| BR-CLM-008 *(Example)* | A handler must contact the policyholder within 2 working days of a referral | Behavioural | Service standard | Claims operations manager | Monitored, breach reported | Approved |
| BR-CLM-009 *(Example)* | Each claim photo must be 10 MB or smaller, and a claim may have at most 10 photos | Behavioural | Upload policy | Digital product owner | Strictly enforced | Approved |
| BR-CLM-012 *(Example)* | A claim must be referred to the fraud team if two or more fraud indicators from the indicator list apply | Behavioural | Fraud policy | Head of fraud | Strictly enforced | In review |
| [BR-XXX-nnn] | [Statement] | [Definitional / Behavioural] | [Source] | [Role] | [Level] | [Proposed / In review / Approved / Retired] |

Enforcement levels used: **Strictly enforced** (cannot be broken),
**Override allowed** (can be broken by an authorised role, with a
reason recorded), **Monitored** (breaches are allowed but reported),
**Guideline** (advice only).

## 3. Rule details

<!-- Guidance: Add a detail block for rules that need more than one row: rationale, exceptions, examples, the decision table that implements them, and history. -->

### BR-CLM-007 *(Example)*

| Field | Value |
|---|---|
| Statement | A claim with an estimated value above 5,000 must be referred to a handler before any payment |
| Rationale | Large losses need a human check of cover and value |
| Terms used | Claim, estimated value, handler, payment (glossary) |
| Exceptions | [None. If an exception is needed, write it as a separate rule with its own ID and link it here] |
| Examples | 7,500: referred. 5,000: not referred (the rule says "above") |
| Related rules | BR-CLM-004, BR-CLM-012 |
| Acceptance scenarios | SC-04, SC-05 in `requirements/acceptance-criteria-bdd` |
| Effective from | YYYY-MM-DD |

## 4. Enforcement points

<!-- Guidance: List every place where each behavioural rule is applied: system components, manual steps, controls. Questions: if the threshold changes tomorrow, which places must change? Pitfall: a rule hard-coded in three services and a call script, with only one updated. -->

| Rule ID | Enforcement point | Mechanism | Owner of the point |
|---|---|---|---|
| BR-CLM-004 *(Example)* | Claims portal, notification start | Policy status check through the policy service | Digital product owner |
| BR-CLM-007 *(Example)* | Claims service, payment step | Referral decision from the rules engine | Claims IT lead |
| BR-CLM-007 *(Example)* | Contact centre script | Agent refers manually for phone claims | Claims operations manager |
| BR-CLM-009 *(Example)* | Claims portal and mobile app upload | Client and server size checks | Digital product owner |
| BR-CLM-012 *(Example)* | Fraud scoring service | Indicator count from the fraud indicator list | Head of fraud |

## 5. Change log and governance

<!-- Guidance: Record each change to a rule with the reason and the approver, so that past decisions can be explained. Changes follow the governance in the business analysis plan. -->

| Date | Rule ID | Change | Reason | Approved by |
|---|---|---|---|---|
| YYYY-MM-DD | BR-CLM-007 *(Example)* | Threshold raised from 3,000 to 5,000 | Referral volume too high for handler capacity | Head of claims |
| YYYY-MM-DD | [BR-ID] | [Change] | [Reason] | [@approver] |

Review the catalogue at least [yearly] and whenever a source policy,
contract or law changes.

## Standard and licence note

Structure aligned with the Business Rules Analysis technique (10.9) of
*A Guide to the Business Analysis Body of Knowledge* (BABOK Guide)
version 3, International Institute of Business Analysis (IIBA), 2015,
and with the distinction between definitional rules and behavioral business
rules in the Object Management Group specification *Semantics of
Business Vocabulary and Business Rules* (SBVR), version 1.5, December
2019. Both are cited by name and number only; this template is original
text written for this collection. Check the current editions before
use. Official text: IIBA, purchase or member access at
https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/;
OMG specification at https://www.omg.org/spec/SBVR/. Related templates:
`requirements/business-requirements`, `requirements/business-analysis-plan`,
`requirements/traceability-matrix`. Template licence: MIT.