Chaos Engineering Steady-State Hypothesis Prompt

This prompt is for chaos engineers, SREs, and reliability engineers who need to define a formal, testable steady-state hypothesis before running a chaos experiment. The core job-to-be-done is translating a system's normal behavior into a structured, measurable definition that can be used as a control during fault injection. The ideal user has a specific target system in mind, a planned fault to inject, and access to monitoring dashboards that expose the system's key health metrics. The required context includes the system's architecture, its critical user journeys, and the specific metrics that indicate 'normal' operation. Without this context, the model cannot produce a hypothesis that is both specific and falsifiable.

The prompt forces the model to produce a structured output that includes key metrics with their normal operating bands, explicit blast radius boundaries, and clear abort conditions. It also validates that the hypothesis is falsifiable—meaning a deviation can be definitively detected—and that the available monitoring is sufficient to observe that deviation. For example, if you are preparing to inject a 500ms network latency fault into a payment service, the prompt will guide the model to define the steady state in terms of p99 latency, error rate, and transaction throughput, and then check whether your dashboards can actually measure a shift from a 200ms to a 700ms p99. This prevents the common anti-pattern of running an experiment without a clear definition of success or failure.

Do not use this prompt for general performance testing, load test scenario design, or incident postmortems. It is specifically scoped to the hypothesis-design phase of chaos engineering, before any fault is injected. If you need to design a load profile from SLA requirements, use the 'API Load Profile Design Prompt.' If you are analyzing a past incident, this prompt will not help you structure a timeline or identify root causes. Using this prompt outside its narrow window will produce a hypothesis that is either irrelevant or untethered from an actual planned experiment. After generating the hypothesis, your next step is to review it with the engineering team that owns the service to confirm the metrics and thresholds are correct before proceeding to experiment execution.

This prompt template produces a structured steady-state hypothesis that defines normal system behavior before fault injection. It forces the model to identify key metrics, establish operating bands, set blast radius boundaries, and define abort conditions. The output is designed to be directly usable in a chaos experiment plan, with enough specificity that an engineer can configure monitoring dashboards and automation rules from the hypothesis alone.

textCopy
You are a chaos engineering architect. Your task is to produce a falsifiable steady-state hypothesis for a chaos experiment.

## INPUTS
- System description: [SYSTEM_DESCRIPTION]
- Architecture diagram or component list: [ARCHITECTURE_CONTEXT]
- Known failure modes or prior incidents: [KNOWN_FAILURE_MODES]
- Monitoring stack and available metrics: [MONITORING_STACK]
- Experiment scope and constraints: [EXPERIMENT_SCOPE]
- Risk tolerance level: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a JSON object with these fields:
- hypothesis_statement: A single sentence declaring what steady state will persist during the experiment.
- key_metrics: Array of objects with metric_name, query_or_source, normal_band (min, max, unit), and aggregation_window.
- blast_radius: Object with affected_components, excluded_components, and justification for each exclusion.
- abort_conditions: Array of conditions that trigger immediate experiment termination, each with metric, threshold, and detection_latency.
- monitoring_gaps: Array of metrics or signals that are needed but currently unavailable.
- falsifiability_check: Explanation of how the hypothesis could be proven false by the experiment results.

## CONSTRAINTS
- Every metric must be observable with the stated monitoring stack.
- Normal operating bands must reference historical data ranges, not arbitrary thresholds.
- Blast radius must include justification for why excluded components are safe.
- Abort conditions must include detection latency so automation can be configured.
- If the hypothesis cannot be falsified with available monitoring, flag it and recommend instrumentation.
- Do not invent metric values. Use [PLACEHOLDER] where real data is needed.

## EXAMPLES
[EXAMPLES]

## TOOLS AVAILABLE
[TOOLS]

To adapt this template, replace each square-bracket placeholder with your system's specific context. The [SYSTEM_DESCRIPTION] should include the service topology, data flow, and user-facing behavior. The [MONITORING_STACK] must list the actual observability tools and metric names available, because the model will reference them directly in the key_metrics and abort_conditions fields. If you have prior experiment results or incident postmortems, include them in [KNOWN_FAILURE_MODES] to ground the hypothesis in real failure signatures. The [EXAMPLES] placeholder should contain one or two well-formed hypothesis objects that demonstrate your team's expected level of detail and terminology conventions. Before running the experiment, validate that every metric in the output is actually queryable and that abort condition thresholds are wired into your experiment controller. For high-risk production experiments, a human reliability engineer must review the blast radius boundaries and sign off on the abort conditions before fault injection begins.

This prompt is designed to be the first step in a chaos experiment pipeline, not a standalone artifact. The output should feed directly into your experiment execution system—whether that's a chaos platform like Gremlin, LitmusChaos, or a custom fault injection harness. The hypothesis JSON becomes the contract that the subsequent blast radius check, monitoring dashboard configuration, and automated abort logic all reference. Treat the prompt output as a machine-readable experiment definition, not just a planning document.

Wire the prompt into a pre-experiment approval workflow. After the model generates the hypothesis, run a validation layer that checks: (1) every metric in steady_state_metrics maps to an actual observable in your monitoring stack (Prometheus metric name, Datadog query, or log-based metric), (2) the normal_operating_band for each metric has both upper and lower bounds expressed in the same units your dashboards use, (3) the blast_radius explicitly lists affected services, and (4) the abort_conditions reference specific metric thresholds with comparison operators. If validation fails, route back to the prompt with the specific failure reason appended to [CONSTRAINTS] for a correction pass. For high-risk production experiments, require a human to approve the validated hypothesis before any fault injection begins.

Model choice matters here. Use a model with strong structured output capabilities and low hallucination rates on technical specifications—GPT-4o or Claude 3.5 Sonnet with strict JSON mode enabled. Set temperature to 0 or near-zero to maximize consistency across runs. If your chaos platform has an API for experiment creation, map the validated hypothesis fields directly to the platform's experiment schema. Store the full prompt input, raw model output, validation results, and human approval decision in an audit log. This trace is essential for incident reviews when a chaos experiment surfaces a real production issue. Avoid using this prompt without first confirming that your observability stack can actually measure every steady-state metric the model proposes.