Observability: Three Layers, One Graph
This is the implementation guide for unified observability in regulated enterprises. Principles live in G.A.I.N Observability. This blueprint explains what to build: three layers, one observability graph, four capability planes, and a maturity path from reactive logs to business-aware operations.
A production observability stack connects business KPIs to service traces and infrastructure signals through correlation IDs and journey mapping. Dashboards consume the graph; they do not replace it.
What you are building
A unified observability framework is three layers plus a graph, a capability platform, and an operating model:
- Layer ① Business: KPIs and SLAs tied to named workflows, not orphan metrics
- Layer ② Service: golden signals, distributed traces, dependency graph, SLIs/SLOs
- Layer ③ Infrastructure: resource and platform health linked to service identities
- Observability graph: correlation from KPI → transaction → resource
- Capability platform: collection, correlation, intelligence, action
- Operating model: shared ownership across product, engineering, platform, SRE, architecture
Read the top row left to right: Business → Service → Infrastructure, then down through the observability graph and capability platform.
| Layer | Component | Decides | When |
|---|---|---|---|
| ① Business | Journey map + outcome SLOs | Why the customer or obligation moved | Per named workflow |
| ② Service | Golden signals + traces | What failed in the request path | Per service hop |
| ③ Infrastructure | Resource telemetry | Where saturation or faults live | Per resource bound to a service |
Layer ①: Business
The why: journeys, KPIs, outcome SLOs. Playbook: Business journey mapping.
Product and business operations own this layer. Platform teams support emission and storage; they do not define what success means for a regulated journey.
Five capabilities
- Name the journeys: revenue, risk, or regulation, not every screen
- KPIs per journey: payment success, first-touch resolution, verification completion
- Business events:
checkout.payment.failedwith principal and step - Outcome SLOs: customer-completing-the-workflow, not host CPU
- Drop-off visibility: which step drives degradation
Playbook: Business journey mapping.
Layer ②: Service
The what: golden signals, traces, SLIs/SLOs. Playbook: Service golden signals.
Engineering and SRE own this layer. Every production service exposes mechanism-level truth: what failed, where latency entered, which dependencies broke.
Five capabilities
- Golden signals: latency, traffic, errors, saturation
- Distributed traces: one failed business event across all hops
- SLIs / SLOs: error budgets tied to the journey
- Dependency graph: which upstream caused the burn
- AI hop set: gateway, policy, retrieval, model, tool, and validation spans on agent paths
Playbook: Service golden signals. Related: G.A.I.N Observability.
Layer ③: Infrastructure
The where: resources bound to service identity. Playbook: Infrastructure telemetry.
The goal is not more host graphs. It is binding resource stress to the services and journeys that consume those resources.
Five capabilities
- Service identity labels: every resource tagged to an owning service
- Compute: CPU throttle, memory pressure, OOM
- Orchestration: pod restarts, pending, eviction
- Network and storage: latency, loss, I/O wait, replication lag
- Data plane: connection pools, replica lag, lock waits
Playbook: Infrastructure telemetry.
The observability graph
The graph is the unifying artifact. It answers: when this KPI moved, which service transactions and which infra resources moved with it?
| Node | Carries | Example |
|---|---|---|
| Business event | Journey step, outcome, principal | checkout.payment.failed |
| Service span | Operation, dependency, latency, error | POST /payments → fraud.check |
| Infra signal | Resource binding | db-primary.cpu, pool.connections |
Example flow: payment success drop
| Layer | Observation |
|---|---|
| Business | Payment success rate 98% → 85% on checkout journey |
| Service | Payment API p95 latency up; fraud service timeouts; retry storms |
| Infrastructure | Database CPU 95%; connection pool exhaustion |
One incident narrative. No manual portal hopping.
For agent and RAG paths, service spans must include gateway, policy, retrieval, model, tool, and validation hops. See G.A.I.N Observability. The graph shape is the same; the span set is richer.
Capability model
Think in capabilities, not tools.
| Capability | Owns | Does not own |
|---|---|---|
| ① Data collection | Metrics, logs, traces, business events at source | Dashboard layout |
| ② Correlation | Trace IDs, journey mapping, dependency graph | Alert routing rules alone |
| ③ Intelligence | Anomaly detection, SLO burn, trend analysis | Runbook content |
| ④ Action | Runbooks, incident automation, remediation hooks (mature) | Business KPI definitions |
Reference architecture (conceptual)
| Stage | Regulated-enterprise default |
|---|---|
| Sources | Structured logs, OTel traces, business event bus, infra agents |
| Pipeline | Enrichment with service identity, tenant, journey ID; redaction before persistence |
| Platform | Separate tiers for ops, quality, and audit retention |
| Intelligence | SLO burn-rate alerts, dependency-aware anomaly, business KPI thresholds |
| Consumption | SRE dashboards, product journey views, regulator replay exports |
Maturity model
Observability is not binary. Use this ladder to plan investment.
Most firms should reach L3 broadly (business-aware, correlated graph) and L4 on tier-1 journeys before attempting L5. Autonomous remediation needs governance, audit trails, and blast-radius controls first.
| Level | Name | Characteristics | Typical gap |
|---|---|---|---|
| 0 | Reactive | Logs only, manual debugging | No correlation |
| 1 | Monitoring | Dashboards, static alerts | Siloed layers |
| 2 | Observability | Metrics + logs + traces | Layers still disconnected |
| 3 | Business-aware | KPIs mapped to services, journey visibility | Limited prediction |
| 4 | Predictive | Anomaly detection, proactive alerts | Manual remediation |
| 5 | Autonomous ops | Automated remediation, self-healing (select paths) | Requires strong governance |
Assessment playbook: Maturity assessment.
Design principles (governance rules)
| Rule | Rationale |
|---|---|
| Every service emits structured logs | Parsing cost and alert quality |
| Every request carries a correlation ID | Graph integrity |
| Every business KPI maps to system signals | Business-aware prioritization |
| Every alert has an owner and action | No orphan pages |
| Every dashboard answers a decision question | Prevents sprawl |
| No telemetry without purpose | Cost and compliance |
Playbook: Governance rules.
Operating model (summary)
| Role | Owns |
|---|---|
| Product | Business KPIs, journey definitions, outcome SLOs |
| Engineering | Service instrumentation, SLIs, dependency accuracy |
| Platform | Observability infrastructure, pipelines, retention tiers |
| SRE / reliability | Alerting, incident response, error budgets |
| Architecture | Standards, correlation model, maturity roadmap |
Playbook: Operating model.
Playbook map
| Layer / topic | Playbook |
|---|---|
| ① Business journeys | Business journey mapping |
| ② Service golden signals | Service golden signals |
| ③ Infrastructure | Infrastructure telemetry |
| Correlation graph | Correlation graph |
| Governance | Governance rules |
| Maturity | Maturity assessment |
| Ownership | Operating model |
Start at Observability playbooks overview.
Related G.A.I.N domains
| Domain | Relationship |
|---|---|
| G.A.I.N Observability | AI service-layer depth: capture, retention, audit |
| G.A.I.N Evaluation | Quality and drift consumers of telemetry |
| PGAR audit and replay | Policy verdict chain as audit-tier signal |