observability_driven_development

Observability driven development treats tracing as a design artifact where you define the span tree before coding, then run locally against an OpenTelemetry stack so every change yields a readable trace that guides implementation decisions.

Design OpenTelemetry traces before coding by writing a narrative spec that guides instrumentation, then defining proper span design and attributes to ensure end-to-end observability across async boundaries and external API calls.

Validate telemetry against a narrative spec by running the /validate_telemetry workflow, which compares observed traces from your local OTel stack against the spec and iterates until the trace matches the defined behavior.

Yes, a local OpenTelemetry stack is required. You need to stand up the Aspire dashboard and local OTel collector to observe traces in real time and validate instrument behavior against your narrative specification.

Use observability driven development for features that cross async boundaries or external API calls, where designing the trace first ensures proper instrumentation and validation rather than retroactively adding telemetry to existing code.

A telemetry narrative spec contains the expected span tree structure, span attributes, and behavioral flow that guides instrument design and serves as the validation target for comparing observed traces during the development loop.