Skip to main content
Business rules are guardrails that prevent incorrect metrics (for example, excluding cancelled orders from revenue).
business_rules.yml is guidance. Hard runtime enforcement lives in policies/policy.yml and execution contracts.

​
Define rules

Create semantics/business_rules.yml: 
rules:
  - name: cancelled_orders_excluded
    category: metrics
    severity: critical
    applies_to: [orders.total_revenue, orders.avg_order_value]
    description: Revenue metrics must exclude cancelled orders
    guidance: Always filter status != 'cancelled' when computing revenue

  - name: test_customers
    category: data_quality
    severity: warning
    applies_to: [customers]
    description: Test customers exist in the data
    guidance: Filter out customer_id > 100 for production analysis

​
Rule fields that matter most

  • severity: critical, warning, info
  • applies_to: metric/model targets such as orders.total_revenue
  • guidance: explicit instruction the agent should reference

​
Best practices

  • Keep critical rules short and unambiguous.
  • Attach rules to specific metrics where possible.
  • Use warning for data quality caveats and info for guidance.
  • Keep additional narrative context in RULES.md.
  • Keep one canonical definition per metric across all files.

​
Enforcement boundary

  • Semantic model (semantic_model.yml): deterministic metric computation
  • Business rules (business_rules.yml): explanation and interpretation guidance
  • Policy (policy.yml): enforceable controls (PII, scope, execution rules)