functional-designing-what-to-observelisted

# Designing What to Observe ## Overview Observability is a design decision, not an afterthought: it is choosing which questions a running system must be able to answer, and building the answers into the types before anything ships. Added afterwards, it becomes a scattering of log lines that record what was convenient rather than what anyone needs. A functional design has an advantage here that most do not. A workflow that returns events already produces a stream of business facts, in the domain's own words, at exactly the moments that matter. That stream is the observability primitive; logs, traces, and metrics are projections of it. ## When to use - Designing a workflow, and deciding what it must reveal - An incident where the recorded data could not answer the question - A log line is about to be added inside a domain function - Choosing what to alert on - Adding observability to a system that has none Not for: choosing what an interface exposes to callers, which is [functional-deciding-what-matters](../functional-deciding-what-matters/SKILL.md). ## Core rules 1. Default. **Write the questions first.** "Why did this booking fail?", "How many bookings are stuck?", "Is checkout slower than yesterday?" The fields follow from the questions; the reverse produces data nobody uses. 2. Default. **Emit domain events, not log lines.** The workflow already returns what happened. The shell projects those into whatever the platform wants. 3. Rule. **Log once, at the edg