Choose where business rules should live
Choose rule placement by deciding where the authoritative truth belongs, what other layers may mirror or guard, and how the team will prevent behavior drift across boundaries.
- Situation
- A business rule is duplicated or inconsistently implemented across layers.
- Goal
- Reduce inconsistency, coordination cost, and ambiguity by giving business rules a clear home and explicit supporting copies where needed.
- Do not use when
- the issue is only technical validation and not a real business rule
- Primary owner
- tech lead
- Roles involved
tech leaddomain-aware engineerarchitect if multiple boundaries are affectedfrontend and backend owners when both implement the rule
Context
The situation
Deciding whether to reach for this playbook: when it fits, and when it doesn't.
Use when
Conditions where this playbook is the right tool.
- The same rule exists in UI, API, batch jobs, or database logic differently
- Bugs appear because two layers disagree on policy or validation
- Teams argue over where a rule should live
- Business behavior is hard to change consistently
Stakes
Why this matters
What this playbook protects against, and why skipping or half-running it tends to be expensive.
Business rules spread by convenience. Once the same rule exists in several layers without an explicit authority model, every change gets slower and every inconsistency becomes harder to trust and debug.
Quality bar
What good looks like
The observable qualities of a team or system that is actually doing this well. Not just going through the motions.
Signs of the playbook done well
- The team can name the authoritative home of the rule
- Other copies are clearly classified as mirror, cache, guardrail, or presentation convenience
- Rule change triggers are easier to reason about
- Behavior stays consistent across channels and workflows
Preparation
Before you start
What you need available and true before running the procedure. Skipping this is the most common reason playbooks fail.
Inputs
Material you'll want to gather first.
- Rule examples and recent bugs
- Affected layers or services
- Runtime paths where the rule applies
- Latency, UX, and operational constraints
- Ownership map
Prerequisites
Conditions that should be true for this to work.
- The rule can be stated clearly in business terms
- The layers currently applying it are known
- The team can distinguish authority from convenience duplication
Procedure
The procedure
Each step carries its purpose (why it exists), its actions (what you do), and its outputs (what you produce). Read the purpose. It's what keeps the step from degenerating into checklist theatre.
State the rule in plain domain language
Reduce debate caused by implementation-specific framing.
Actions
- Write the rule as a business statement
- List where the rule currently exists in code or workflow
- Identify where behavior disagrees today
Outputs
- Rule statement
- Current placement map
Choose the authoritative home
Give the rule one source of truth.
Actions
- Decide where the rule must be authoritative to preserve consistency and ownership
- Test whether that layer actually owns the required context and decision rights
- Record what other layers may only mirror or guard
Outputs
- Authority model
Define allowed secondary copies
Avoid fake purity while preventing drift.
Actions
- Identify where UX, latency, or safety justify a secondary check
- Label each secondary copy as advisory, guardrail, or projection
- Make sure those copies do not silently redefine the rule
Outputs
- Secondary copy policy
Align tests and change flow to the authority model
Keep the rule consistent under change.
Actions
- Add tests at the authoritative layer
- Verify supporting layers reflect but do not redefine the behavior
- Make future rule changes start from the source of truth
Outputs
- Rule validation plan
Review drift over time
Prevent convenience from rebuilding duplication.
Actions
- Watch for new implementations of the same rule elsewhere
- Review recurring bugs or exceptions as placement failures or clarity failures
- Teach the team the authority model in code review
Outputs
- Rule drift review
Judgment
Judgment calls and pitfalls
The places where execution actually diverges: decisions that need thought, questions worth asking, and mistakes that recur regardless of good intent.
Decision points
Moments where judgment and trade-offs matter more than procedure.
- Where does the rule have enough context and ownership to be authoritative?
- What secondary copies are justified?
- Is the duplication defensive, advisory, or accidental?
- Would moving the rule expose a deeper boundary problem?
Questions worth asking
Prompts to use on yourself, the team, or an AI assistant while running the procedure.
- Where should this rule be authoritative and why?
- Which copies are justified and which are accidental?
- What would stop this rule from drifting again six months from now?
Common mistakes
Patterns that surface across teams running this playbook.
- Arguing from layers like frontend or backend instead of from ownership and context
- Pursuing purity that hurts user experience or safety with no real gain
- Keeping all copies as equal truth sources
- Changing the rule in one place and trusting others to catch up
Warning signs you are doing it wrong
Signals that the playbook is being executed but not landing.
- Different teams still disagree on which behavior is correct
- Bugs keep appearing as layer disagreement rather than obvious failure
- The team says the rule lives everywhere because it needs to
- Secondary copies keep growing extra semantics
Outcomes
Outcomes and signals
What should exist after the playbook runs, how you'll know it worked, and what to watch for over time.
Artifacts to produce
Durable outputs the playbook should leave behind.
- Rule statement
- Current placement map
- Authority model
- Secondary copy policy
- Rule validation plan
Success signals
Observable changes that mean the playbook landed.
- Rule changes start from the authoritative layer
- Inconsistency bugs decline
- Teams use more consistent language about the rule
- Supporting copies remain visibly subordinate
Follow-up actions
Moves that keep the playbook's effects compounding after it finishes.
- Review other duplicated rules using the same model
- Update service and layer ownership guidance
- Turn repeated placement confusion into architecture heuristics for the team
Metrics or signals to watch
Longer-horizon indicators that the underlying problem is receding.
- Rule inconsistency bug count
- Number of layers implementing the rule
- Time to apply a rule change consistently
- Review findings about duplicate rule introduction
AI impact
AI effects on this playbook
How AI-assisted and AI-driven workflows help execution, and the ways they can make it worse.
AI can help with
Where AI tooling genuinely reduces the cost of running this playbook well.
- Finding where similar rule logic exists across codebases
- Summarizing inconsistent validations and conditions
- Drafting rule placement options and authority models
AI can make worse by
Distortions AI introduces that make the underlying problem harder to see.
- Copying the same rule into more places faster
- Making supporting copies look consistent while semantics drift
- Masking source-of-truth ambiguity behind tidy code generation
Relationships
Connected playbooks
Failure modes this playbook tends to address, decisions behind the situation, red flags that motivate running it, and neighboring playbooks.