On this page
What is it?
The Business Rules Document defines the rules and decision logic that determine how the product should behave under specific conditions.
Business rules can define:
- Conditions
- Constraints
- Decisions
- Exceptions
PRD
Product intent
FSD
Functionality
BRD
Rules and constraints
UFD
User behavior
Why do we need it?
A feature description tells us what a product can do, but it does not necessarily tell us what conditions govern that behavior. Without explicit rules, different people or AI agents may make different assumptions about the same scenario.
Without explicit rules
With explicit rules
When do we create it?
The BRD is created after the product functionality is understood well enough to identify the rules that govern it.
This is an information relationship, not a rigid waterfall. Rules may evolve as flows and design reveal new scenarios.
Who benefits from it?
Product
Uses it to make business decisions explicit.
Design
Uses it to understand states, constraints, validation, and exceptional scenarios that affect the experience.
Engineering
Uses it as the source of defined conditions and expected behavior.
AI agent
Uses it as explicit constraints instead of inventing behavior that was never specified.
What does it contain?
These are the fields a business rule can define.
- 01
Rule ID
A unique identifier for the rule.
- 02
Rule Name
A concise name that identifies the rule.
- 03
Applies To
The feature, module, or capability affected by the rule.
- 04
Trigger
The action or event that causes the rule to be evaluated.
- 05
Condition
The condition under which the rule applies.
- 06
Expected Behavior
What the system should do when the rule condition is met.
- 07
Exceptions
Defined situations where the normal behavior does not apply.
- 08
Constraints
Limits or restrictions the rule imposes.
- 09
Priority
The importance of the rule when relevant.
- 10
Dependencies
Other rules, features, or conditions that affect the rule.
Not every rule needs every field — the exact fields used can vary depending on the type of rule.
What does it NOT contain?
- Product vision
- Product goals
- Feature inventory
- Complete user journeys
- Screen layouts
- Visual design
- Database schema
- API contracts
- Technical architecture
- Implementation code
FSD
What the feature does.
BRD
What rules govern the feature.
UFD
How the user moves through it.
DSD
How the experience behaves and looks.
DDD / ASD / TAD
How it is technically implemented.
What does a rule look like?
Rule
- Rule ID
- RULE-001
- Rule name
- Project Name Required
- Applies to
- Create Project
Trigger
User submits the Create Project form.
Condition
Project name is empty.
Expected behavior
Prevent project creation and request a project name.
Exceptions
None defined.
- Priority
- High
Common rule types
- 01
Validation
Determines whether input or a condition is acceptable.
- 02
Eligibility
Determines whether a user or entity is allowed to perform an action.
- 03
State
Defines behavior based on the current state of something.
- 04
Limit
Defines a boundary such as quantity, time, or frequency.
- 05
Calculation
Defines how a value should be derived.
- 06
Access
Defines who can perform or access something.
- 07
Exception
Defines behavior for an exceptional scenario.
How does AI use it?
The BRD gives the AI agent explicit behavioral constraints. It tells the agent what conditions matter and what behavior has already been decided.
AI understands
- What conditions matter
- What behavior is expected
- What constraints apply
- What exceptions are defined
- What decisions have already been made
The BRD does not tell the AI exactly how to write the code. It tells the AI what behavior the implementation must satisfy.
Context
PRD
Functionality
FSD
Constraints
BRD
Implementation behavior
AI Instructions
Specification Gaps
If a scenario is important enough to affect implementation but the documentation does not define the expected behavior, the specification contains a gap.
Specification gap
Feature
Create Project
Scenario
The project name already exists.
Expected behavior
Not defined.
Decision required
- A. Prevent creation
- B. Allow duplicate names
- C. Define another behavior
Paused until the decision is documented.
AI should implement decisions, not silently make important product decisions.
How does it connect to other documents?
FSD
“What can the feature do?”
BRD
“What rules must it follow?”
UFD
“How does the user move through it?”
DSD
“How should that behavior be experienced?”
DDD / ASD / TAD
“How is it implemented?”
A business rule can affect multiple downstream documents. For example:
RULE-001
Project name is required.
This may influence
UFD
What happens when the user submits without a name?
DSD
How is the invalid state represented?
ASD
What response is returned if validation fails?
TAD
Where should the rule be enforced?
Example
Users can create a project.
Project name is required.
RULE-001
Project name is required.
RULE-002
Project name cannot exceed the defined limit.
RULE-003
Only eligible users can create projects.
RULE-004
Duplicate project names follow a defined policy.
FSD
Create Project
BRD
RULE-001
UFD
User submits without project name
DSD
Validation state
Implementation
Rule enforcement
BRD Template
brd-template.md
# Business Rules Document
## 01. Rule
### Rule ID
RULE-001
### Rule Name
### Applies To
### Trigger
### Condition
### Expected Behavior
### Exceptions
### Constraints
### Priority
### Dependencies
---
## Specification Gap
### Feature
### Scenario
### Expected Behavior
### Decision Required
### Implementation Status
Common mistakes
- Writing rules as vague statements.
- Mixing UI decisions into business rules.
- Putting complete user flows inside the BRD.
- Defining technical implementation instead of behavior.
- Leaving important exceptions undocumented.
- Creating contradictory rules.
- Using rules to compensate for unclear product scope.
- Letting AI choose behavior for undocumented scenarios.