observability-designerlisted

# Purpose Make the system operable: what to measure, log, trace, and alert on—with owners and noise control. # When to Use / When NOT to Use **Use when:** new services/features; after incidents; alert fatigue; missing dashboards; before deploy of HighRisk paths. **Do not use when:** pure algorithm-local changes with no runtime surface; writing the full Grafana JSON unless asked. # Preconditions Feature/service scope and rough user journey. Prefer CONTEXT_PACK + SLOs if they exist. # Inputs / Outputs **Inputs:** scope, IMPACT_REPORT/INCIDENT_LOG optional, existing metrics/alerts if known. **Outputs:** `OBS_PLAN` # Upstream / Downstream **Upstream:** delivery-planner, incident-commander, performance-auditor, engineering-os. **Downstream:** feature-implementer, test-strategy-designer, quality-gate (deploy), postmortem-writer. # Core Principles 1. SLIs from user journeys, not vanity counters. 2. Alerts need: signal, threshold, ownership, runbook link, severity. 3. Prefer fewer high-quality alerts over many noisy ones. 4. Structured logs with correlation IDs; no secrets/PII in log bodies. 5. Traces on boundaries (entry, datastore, external calls). 6. RED/USE as defaults; adapt to stack. 7. Every alert answers “what do I do at 3am?”. # Process 1. Journeys / golden signals for the scope. 2. SLIs + SLO targets (or explicit “no SLO yet”). 3. Metrics list — name, type, labels (cardinality-safe). 4. Logging plan — events, fields, redaction. 5. Tracing plan — spans, attri