Business Rules - Observability

This document lists the fundamental business rules of the Observability domain, each identified by a unique BR-NNN code. Every rule is technology-independent (valid on Prometheus, OpenTelemetry, any backend) and describes an invariant constraint on the behavior of the observability system.

---

BR-001 - Mandatory instrumentation of critical signals

Code: BR-001 Name: Every service exposes the Golden Signals Description: Every instrumented Service must emit at least the Golden Signals (latency, traffic, errors, saturation) - or RED (Rate, Errors, Duration) / USE (Utilization, Saturation, Errors) equivalents. An uninstrumented service is a blind spot. Rationale: Without signals there is no observability; the Golden Signals are the minimum to diagnose health. Priority: HIGH Actors: Service Owner, Instrumentation Layer Traceability: Golden Signals, RED method, USE method (glossary); instrument-service.md.

---

BR-002 - End-to-end context propagation

Code: BR-002 Name: Every request propagates the trace context across services Description: Every Span generated in a distributed request must propagate the TraceContext (W3C Trace Context) to downstream services, so all spans belong to the same Trace. Broken propagation breaks the trace. Rationale: Correlate the whole request across service boundaries. Priority: HIGH Actors: Instrumentation Layer, Service Owner Violation: orphan traces (spans without a parent), impossible cross-service diagnosis. Traceability: Context propagation, W3C Trace Context (glossary); instrument-service.md.

---

BR-003 - Metric cardinality under control

Code: BR-003 Name: Metric labels do not have unbounded cardinality Description: No Metric may use as a label high-cardinality unbounded values (e.g. user ID, request ID, timestamp). Cardinality explosion grows the time series until it saturates the backend. Rationale: Prevent the metrics backend from crashing and contain costs. Priority: HIGH Actors: Service Owner, Telemetry Backend Violation: cardinality explosion → backend degradation or crash. Traceability: Cardinality, Cardinality explosion (glossary); domain-faq.md.

---

BR-004 - SLOs with explicit error budgets

Code: BR-004 Name: Every critical service has defined SLIs, SLOs and error budgets Description: Every critical Service must have measurable SLIs, stated SLO targets and a derived ErrorBudget. Operational decisions (releases, alerting) are based on error budget consumption, not arbitrary thresholds. Rationale: Balance reliability and development speed in a measurable way. Priority: HIGH Actors: SRE, Service Owner Traceability: SLI, SLO, Error Budget (glossary); define-slo.md.

---

BR-005 - Actionable, symptom-based alerts

Code: BR-005 Name: An alert fires on a symptom requiring human action Description: Every Alert must signal a user-relevant symptom (e.g. high error-budget burn rate) and require an action. Alerts on impactless causes or those requiring no intervention (noise) are forbidden. Rationale: Avoid alert fatigue; every notification must deserve attention. Priority: HIGH Actors: SRE, Alerting Engine Traceability: Alerting, Burn Rate (glossary); evaluate-alert.md.

---

BR-006 - The three signals are correlatable

Code: BR-006 Name: Metrics, logs and traces share correlation identifiers Description: The three pillars (Metric, Log, Trace) must be correlatable through common identifiers (trace_id, service.name, exemplars). From a metric alert one must be able to reach the relevant traces and logs. Rationale: Reduce MTTR by navigating between signals during an incident. Priority: HIGH Actors: Instrumentation Layer, SRE Traceability: Correlation, Exemplar (glossary); domain-faq.md.

---

BR-007 - Semantic conventions and structured logging

Code: BR-007 Name: Telemetry with standard semantic attributes and structured logs Description: Telemetry must use Semantic Conventions (standard Resource attributes like service.name, service.version) and logs must be structured (JSON with typed fields), not free text. This makes signals queryable and correlatable. Rationale: Interoperability between tools and reliable queries. Priority: MEDIUM Actors: Instrumentation Layer, Service Owner Traceability: Semantic Conventions, Structured logging, Resource (glossary).

---

BR-008 - Cost-governed sampling and retention

Code: BR-008 Name: Sampling and retention are sized to the signal's value Description: Signal Sampling (head or tail-based) and Retention must balance observability and cost: high-fidelity retention for what has diagnostic value (errors, latency tails) and sampling or reduced retention for the rest. Rationale: Keep observability economically sustainable. Priority: MEDIUM Actors: SRE, Telemetry Backend Traceability: Head/tail-based sampling, Retention (glossary); domain-faq.md.