Business Rules in Semantic Layers: Encoding Logic Where It Belongs
Business rules in semantic layers define how data should be filtered, calculated, and interpreted - ensuring consistent application across all analytics tools and users. Learn to encode business logic in your semantic layer.
Business rules in semantic layers are the encoded logic that determines how data should be interpreted, filtered, calculated, and aggregated for analytics purposes. These rules translate business policies into computational instructions - ensuring that when someone asks for "revenue," they get the exact calculation the business has defined, regardless of which tool they use or how they phrase the question.
Business rules are where business decisions meet data reality.
Why Business Rules Belong in Semantic Layers
The Scattering Problem
Without a semantic layer, business rules scatter across:
- SQL queries (different versions in different reports)
- Dashboard calculations (definitions embedded in visuals)
- Spreadsheet formulas (manual implementations)
- Application code (hardcoded in systems)
- People's heads (tribal knowledge)
Each location can drift. A rule updated in one place stays stale in others. Inconsistency becomes inevitable.
Centralization Benefits
When rules live in the semantic layer:
- Single source of truth: One authoritative definition
- Consistent application: Every tool uses the same logic
- Simplified maintenance: Update once, propagate everywhere
- Auditability: Clear record of what rules exist
- AI grounding: AI systems can query and apply rules
The Codd Semantic Layer provides this centralization - encoding business rules that all downstream tools and AI systems automatically respect.
Types of Business Rules
Definitional Rules
What terms mean:
Active Customer = customer with purchase in last 90 days
AND customer status != 'suspended'
AND customer type IN ('standard', 'premium')
Calculation Rules
How metrics are computed:
Net Revenue = Gross Revenue - Returns - Discounts - Credits
Filtering Rules
What data to include or exclude:
EXCLUDE WHERE order_type = 'internal'
EXCLUDE WHERE customer_id IN (test_accounts)
EXCLUDE WHERE transaction_date < company_founding_date
Aggregation Rules
How data combines:
Revenue aggregates: SUM (not average, not count)
NPS aggregates: AVERAGE (not sum, not count)
Headcount aggregates: LATEST (not sum, not average)
Temporal Rules
How time affects calculations:
Monthly Revenue = SUM(revenue) WHERE date WITHIN calendar_month
Trailing 12 Month Revenue = SUM(revenue) WHERE date WITHIN last_365_days
Access Rules
Who can see what:
Regional managers see only their region
Executives see all regions
External users see only approved metrics
Implementing Business Rules
Rule Structure
Well-structured rules include:
- Name: Human-readable identifier
- Description: What the rule does and why
- Logic: The actual implementation
- Scope: Where the rule applies
- Owner: Who maintains the rule
- Effective date: When the rule took effect
Expressing Logic
Semantic layers use various syntaxes for rule expression:
SQL-like:
DEFINE METRIC active_customers AS
COUNT(DISTINCT customer_id)
WHERE last_purchase_date >= DATEADD(day, -90, CURRENT_DATE)
AND status != 'suspended'
YAML configuration:
metrics:
active_customers:
type: count_distinct
column: customer_id
filters:
- last_purchase_date >= today() - 90
- status != 'suspended'
Declarative definitions:
active_customers = count_distinct(customers.id)
where customers.last_purchase >= relative_date(-90)
and customers.status not in ['suspended']
Rule Composition
Complex rules build from simpler ones:
Gross Revenue = SUM(order_total)
Returns = SUM(refund_amount)
Discounts = SUM(discount_applied)
Net Revenue = Gross Revenue - Returns - Discounts
Net Margin = Net Revenue / Gross Revenue
Each component is independently defined and testable. Complex metrics compose from verified building blocks.
Business Rule Patterns
Conditional Logic
Rules that vary by context:
Revenue =
CASE
WHEN region = 'Europe' THEN order_total * exchange_rate
WHEN product_type = 'subscription' THEN recognized_revenue
ELSE order_total
END
Time Intelligence
Rules involving time-based logic:
Revenue Growth =
(Current Period Revenue - Previous Period Revenue) / Previous Period Revenue
Year-over-Year =
Compare current period to same period last year
Hierarchical Aggregation
Rules for rolling up through hierarchies:
Regional Revenue = SUM(Store Revenue) for stores in region
National Revenue = SUM(Regional Revenue) for all regions
Global Revenue = SUM(National Revenue) for all countries
Exception Handling
Rules for edge cases:
Average Order Value =
IF COUNT(orders) > 0
THEN SUM(order_total) / COUNT(orders)
ELSE NULL // Not zero - no orders means no average
Governance of Business Rules
Change Management
Treat rule changes seriously:
- Proposed change with business justification
- Impact analysis on existing reports and dashboards
- Stakeholder review and approval
- Testing in non-production environment
- Staged rollout with monitoring
- Communication to affected users
Version Control
Maintain rule history:
- What changed
- When it changed
- Who approved the change
- Why it changed
This enables understanding of historical reports that used previous rule versions.
Documentation
Every rule should be documented:
- Business rationale
- Technical implementation
- Known limitations
- Related rules
- Usage examples
Access Control
Not everyone should modify rules:
- Viewers can see rule definitions
- Analysts can use rules in queries
- Data stewards can propose changes
- Governance board approves changes
- Administrators implement changes
Testing Business Rules
Unit Tests
Test individual rules in isolation:
- Known inputs produce expected outputs
- Edge cases handled correctly
- Null values managed appropriately
Integration Tests
Test rules working together:
- Composed metrics calculate correctly
- Filters interact as expected
- Aggregations roll up properly
Regression Tests
Ensure changes don't break existing behavior:
- Compare outputs before and after changes
- Verify known-good reports still match
- Catch unintended consequences
User Acceptance
Business stakeholders validate:
- Rules match business intent
- Outputs make sense in context
- Edge cases handled appropriately
Common Pitfalls
Over-Complexity
Rules that try to handle every case become unmaintainable. Sometimes separate metrics are clearer than one complex rule.
Under-Documentation
Rules without explanation become tribal knowledge. Document the why, not just the what.
Scope Creep
Rules that start simple and accumulate exceptions need periodic review. Sometimes it's better to refactor than continue patching.
Testing Gaps
Rules deployed without testing cause production issues. Invest in test coverage before deployment.
The Foundation of Trustworthy Analytics
Business rules in the semantic layer are the contract between business intent and data reality. They ensure that analytics reflect actual business definitions - not analyst interpretations, not tool defaults, not historical accidents.
When rules are centralized, governed, and tested, analytics becomes trustworthy. Everyone gets the same answer to the same question. AI systems apply the same logic humans would. And when business definitions change, they change everywhere at once.
This is the foundation upon which reliable, scalable analytics is built.
Questions
Rules that define business concepts (what counts as revenue, who is an active customer) belong in the semantic layer. Rules that ensure data quality (null handling, deduplication) belong in the warehouse. The test is whether the rule affects interpretation vs. just data correctness.