The chaos engineering decision record: why the experiment authorization model you chose determines your production reliability confidence ceiling and your blast radius control surface

The founding failure

A developer tools startup experiences a Redis outage in production. The cache layer becomes unavailable for 47 minutes. The circuit breaker that was supposed to trip and serve fallback cached data does not trip because its error threshold is configured as a percentage of total requests — and the startup's traffic is low enough that the absolute count of Redis connection failures never crosses the bucket-based algorithm's minimum request threshold within the observation window. The on-call engineer eventually traces the failure to a configuration parameter that appears nowhere in any ADR, runbook, or architectural discussion: the minimum request threshold below which the circuit breaker percentage calculation is ignored.

The incident post-mortem produces two outputs. First: a runbook update documenting the correct circuit breaker configuration. Second: the decision to adopt chaos engineering. The team spends two weeks instrumenting LitmusChaos experiments targeting the Redis dependency. The Redis unavailability scenario is tested. The circuit breaker trips. Services fail open. The fallback serves cached data. The team publishes an engineering blog post: "How we run chaos engineering to validate our resilience mechanisms." The post-mortem action items are closed.

Fourteen months later, the database primary fails in production at 2:17 AM. The PostgreSQL primary becomes unavailable for 94 seconds during automated failover to the read replica. The 94-second failover window is well within the three-minute tolerance the team estimated during the original database selection discussion. Recovery should be transparent to users.

Instead, the payment service makes 180 sequential database connection attempts at one-second intervals during the failover window rather than failing open to a retry queue. The connection pool exhausts the PostgreSQL max_connections ceiling. The exhausted connection pool blocks all subsequent connection requests, including the connections needed by the primary recovery check. The payment service stops accepting new requests entirely. Recovery requires a manual database restart. The incident lasts three hours and twenty-two minutes.

The Redis experiment had been run only in staging, where max_connections was 50 — lower than production's 200 to reduce cost — and where the ORM connection pool default of 5 connections per application instance across 8 instances produced a total of 40 connections, safely under the staging ceiling. Production ran the same ORM connection pool default of 5 per instance across 24 instances at peak, producing 120 connections — plus 180 sequential retry connections from the payment service's blocking reconnect logic, totaling 300 connection attempts against a 200-connection ceiling.

The circuit breaker the team had validated in staging — and had correctly configured after the Redis incident — did not exist in the payment service's production-scale connection pool code path. The payment service team had added a dedicated connection pool implementation eight months earlier to support the payment provider's connection requirements, using a pool library that did not integrate with the application's existing circuit breaker layer. This implementation detail was documented in a PR description. It was not in any ADR.

The chaos experiment authorization model had said "staging only" for the database failover scenario. The staging experiment had produced a passing result. The team had closed the chaos engineering checklist item. The confidence the experiment produced was confidence in staging behavior at staging scale, not in production behavior at production scale.

The pass rate that didn't measure what mattered

A B2B SaaS company hires a senior reliability engineer two years after founding. The previous reliability approach had been reactive: incidents triggered runbooks, runbooks triggered post-mortem action items, action items triggered code changes. The new hire implements a structured quarterly GameDay cadence using AWS Fault Injection Simulator with explicit steady-state hypotheses for each experiment.

The first year's GameDay results are documented. Eight experiments across four quarterly GameDays: EC2 instance termination, RDS failover, Elasticache primary failure, network latency injection on the payments service, CPU stress on the API servers, memory pressure on the background job workers, disk I/O saturation on the log aggregation tier, and Availability Zone outage simulation. Every experiment specifies a steady-state hypothesis. Every experiment produces a result. Of eight experiments across four GameDays, seven pass on the first run — the Elasticache experiment reveals a secondary connection pool issue that the team resolves before the next GameDay. The reliability engineer presents "99.7% chaos experiment pass rate" (seven of eight, with the eighth passing after remediation) at the quarterly board meeting.

The board member asks: "What does this number tell us about what breaks next?" The reliability engineer answers that it means the team has validated all critical failure modes.

Six weeks after the board presentation, an engineer adds a synchronous third-party analytics SDK to the user registration flow to enable detailed funnel tracking. The SDK is a well-maintained library from a reputable analytics provider. The provider's documented P95 response time is 12 milliseconds. The documented P99 is 800 milliseconds. The documented P99.99 is a configurable timeout value that the library defaults to 8 seconds. The SDK call is made synchronously in the registration endpoint handler, before the response is returned to the user — a standard pattern for analytics that the engineer follows without discussion because analytics calls appear in dozens of other places in the codebase.

At normal registration traffic — 40 to 80 registrations per hour — the analytics call adds an imperceptible latency overhead. Registration endpoint P99 response time increases from 340ms to 380ms. No alert threshold is breached. No monitoring is added for the analytics SDK call specifically.

Eleven weeks after the SDK integration, a co-marketing campaign with a partner company drives a 40× surge in registration traffic. At this traffic level, 0.1% of registrations encounter the 8-second analytics SDK timeout — consistent with the provider's documented P99.99 behavior under their own load conditions, which the campaign was also affecting. Eight-second blocked threads consume thread pool capacity faster than they drain. Within four minutes, the thread pool is exhausted. The registration endpoint stops accepting new connections. The deployment pipeline triggers a health check failure. The auto-scaling group launches new instances. New instances also hit the thread pool exhaustion within four minutes of first receiving traffic.

The registration service is unavailable to all users for twenty-two minutes. Recovery requires disabling the analytics SDK call, which requires a deployment — and the deployment pipeline's CI pipeline is itself under elevated load from the campaign's traffic-driven health check alerts, adding twelve minutes to the deployment time.

The GameDay experiment catalog had never targeted the registration endpoint's external dependency call — not because anyone had consciously decided it was out of scope, but because the analytics SDK integration was added after the last GameDay was scheduled and before the next one was planned. The blast radius scope document listed the systems tested as of the last GameDay: EC2 instances, the RDS primary, Elasticache. The registration endpoint's synchronous external dependency was not on the list because it had not existed when the list was written.

The 99.7% pass rate was an accurate statement about the system topology at the time of the experiments. It was not a statement about the system topology at the time of the incident. The blast radius scope was a point-in-time list, not a living policy. The confidence boundary it defined expired the moment a new external dependency was added.

Three structural properties the chaos engineering decision determines

1. The experiment authorization model and the production reliability confidence surface

The experiment authorization model specifies who has authority to run chaos experiments in which environments, under what pre-conditions, and with what abort criteria. It is the decision that determines whether chaos experiments actually produce production reliability evidence or only staging evidence.

The authorization model has four components that must be specified independently, because each captures a different failure mode.

The environment tiering specifies which experiment types run in which environments and what the promotion criteria are from staging to production. Staging experiments validate that the resilience mechanism exists and functions correctly in isolation. Production experiments validate that the mechanism functions correctly at production scale, with production configuration, under production dependency state. These are different validations. An authorization model that permits staging experiments for all failure modes and production experiments for "proven" failure modes produces the connection pool failure described in the first story: the mechanism was proven correct in staging, incorrectly generalizing that proof to production.

The production promotion criteria should specify what changes between staging and production that are relevant to the failure mode: configuration parameters, traffic multipliers, connection pool sizes, replica counts, external dependency behavior. An experiment promoted from staging to production without analyzing those differences produces staging confidence labeled as production confidence.

The minimum monitoring readiness requirement specifies what observability must be in place before production experiment injection begins. The minimum set is: the SLO metrics targeted in the steady-state hypothesis are instrumented and confirmed accurate on a recent test; alert rules are configured for the blast radius systems so that unrelated production incidents during the experiment window are flagged separately; the on-call engineer for the blast radius is confirmed available for the experiment duration plus thirty minutes; and a runbook exists for the failure mode being injected, describing how to manually abort and recover if the automated abort criteria are not triggered before user impact exceeds the tolerance threshold.

Experiments run without monitoring readiness produce the most dangerous outcome: a "passing" result produced because the failure mode impacted users in a way that did not register on any monitored metric. The team reports "experiment passed" and increases its reliability confidence. The metric that user impact would have registered on was not monitored.

The abort criteria specification requires specifying the measurement, threshold, and responsible party before injection begins — not during. "Abort if something looks bad" is not an abort criterion. "Abort if error rate on /api/registration exceeds 1% for 30 consecutive seconds as measured by the Datadog APM error rate metric — engineer on call for the blast radius has authority and responsibility to trigger manual abort if this threshold is breached" is an abort criterion. The distinction matters because injection decisions made mid-experiment under time pressure and incomplete information systematically produce over-optimistic assessments of how bad the impact currently is. Pre-specified thresholds remove that pressure.

The authorization decision tree maps experiment types to authorization requirements. Low-blast-radius experiments targeting a single stateless service with redundant instances might require only an asynchronous Slack notification to the team channel thirty minutes before injection. High-blast-radius experiments targeting the primary payment service, authentication layer, or database primary require synchronous war-room presence with a named incident commander, separate communication channel open for blast radius monitoring, and a confirmed recovery runbook with the relevant team on standby.

The two default failure modes the authorization model prevents are opposite in character. Without an explicit authorization model, some teams never run production experiments because no one wants to be the person who caused an incident by intentionally injecting failure — the authorization responsibility is diffuse and the downside risk is borne by the individual who initiated the experiment. Other teams run production experiments whenever an engineer feels like it, during convenient business hours without confirming on-call coverage, with no pre-specified abort criteria and no monitoring readiness check. Both failure modes produce the same outcome: chaos engineering that does not produce production reliability evidence.

2. The blast radius scope and the failure assumption confidence ceiling

The blast radius scope is not a list of systems — it is a policy for how systems enter and remain in the in-scope category. The distinction between a list and a policy is what determines whether the confidence boundary remains current as the system evolves.

A list becomes stale at the moment of the next system addition. A policy describes the process that keeps the list current: how new services enter scope, when external dependency integrations trigger scope updates, what the cadence for reviewing the scope against the current system topology is, and who is responsible for each of those processes.

The in-scope system catalog enumerates the current systems within the experiment boundary with the failure modes that have been validated for each (experiment type, environment, last validated date, result) and the failure modes that are in the backlog for next experimentation. The failure mode backlog is as important as the validated list: it makes explicit what has been tested and what has not, preventing the "we do chaos engineering" claim from being misread as "we have validated all relevant failure modes."

The out-of-bounds systems requires documentation for two reasons. First, the list of out-of-bounds systems names the systems that are too critical or too costly to target directly — payment processors, identity providers, multi-region database primaries — along with the technical reason for their exclusion and the mechanism protecting them from blast-radius spillover from in-scope experiments. A system that is out-of-bounds for direct targeting but is unprotected from cascading failure originating in in-scope systems is not actually out-of-bounds — it is just not being directly targeted, while still being exposed to the same failure modes through indirect paths.

Second, the out-of-bounds list makes explicit what resilience claims cannot be validated through chaos experiments. "We do chaos engineering" followed by a list of out-of-bounds systems that includes the database primary, the payment processor integration, and the third-party authentication provider is a statement about what has been validated and, implicitly, about what has not. Stakeholders reading only the "we do chaos engineering" claim without reading the out-of-bounds list have a different understanding of the confidence level than stakeholders who read both.

The scope entry policy for new components is the most operationally critical section because it determines whether the confidence boundary remains current. Three questions the policy must answer:

When does a new service become in-scope? Options include: on first production deployment, at the next scheduled GameDay, after a minimum production runtime period (ensuring the service is stable before experimenting on it), or after a staging experiment has validated the failure modes. The answer determines the gap between when a service is added and when it is covered by chaos validation.

When does a new external dependency trigger a scope update? A new SDK added to a request path is not a new service, but it introduces failure modes that the current experiment catalog does not cover — the analytics SDK timeout that is not in any experiment. The policy must specify whether an external dependency integration automatically triggers a new experiment or whether it waits for the next scheduled GameDay scope review.

What is the scope audit cadence? The GameDay frequency and the scope review cadence are different processes. A quarterly GameDay runs experiments against the current scope. A monthly scope audit reviews whether the current scope still matches the production system topology and flags additions that have occurred since the last audit. Without a separate scope audit cadence, the scope definition drifts from the production topology in the interval between GameDays.

The infrastructure architecture constrains which systems can be targeted and what the maximum blast radius of an experiment can be. A single-region architecture has a higher maximum blast radius per experiment than a multi-region architecture because a regional failure has no failover path. The blast radius scope document must account for infrastructure topology when defining experiment boundaries.

3. The steady-state hypothesis framework and the resilience theater risk

Resilience theater is chaos engineering that produces passing experiment results without producing evidence of resilience. The mechanism is simple: an experiment designed without a falsifiable steady-state hypothesis can only produce a "pass" result, because "pass" is defined as "the engineer watching the monitoring during the experiment did not see something alarming." This is not a null result — it is a result that actively inflates confidence in systems that may not be resilient.

The steady-state hypothesis framework determines whether experiments can produce falsifiable results. A falsifiable hypothesis has four required components:

The measurement specifies which metric is being observed. Internal metrics (Redis hit rate, database connection pool utilization, Kubernetes pod restart count) measure the behavior of infrastructure components. User-facing metrics (request success rate, response latency percentiles at the API boundary, business-level transaction success rate) measure the behavior users experience. Both types have a role in chaos experiments, but the hypothesis must include at least one user-facing metric — or an explicit proxy metric with a documented rationale for why the proxy accurately represents user impact. An experiment that passes all internal metric thresholds while degrading user-facing metrics has produced a passing result that does not reflect the user's actual experience of the system.

The threshold specifies what value of the measurement constitutes healthy behavior. Thresholds grounded in SLO targets inherit the organization's prior deliberation about what level of degradation is acceptable to users. Thresholds invented by the engineer writing the experiment inherit whatever that engineer's intuition about acceptable degradation is — which may or may not match the organization's SLO commitments, and which varies across engineers writing different experiments. Experiments with SLO-grounded thresholds produce results that are directly comparable to the organization's reliability commitments. Experiments with intuition-based thresholds produce results that are comparable only to each other, within the variation of individual engineers' thresholds.

The scope specifies which service, endpoint, or user segment the measurement applies to. A hypothesis that says "API response latency remains below 800ms" is ambiguous: which API endpoints are included? Does the /api/admin endpoint count, or only the /api/v2 endpoints that production users call? Does the measurement exclude health check endpoints, which typically respond faster than real API endpoints and will improve the aggregate P99 if included? Precise scope definitions prevent ambiguity about what "passing" means and ensure that the measurement covers the user-facing surface the experiment is intended to validate.

The recovery criterion specifies how long after experiment termination the system must remain within threshold to count as a clean recovery. An experiment that returns to baseline within 30 seconds of termination has demonstrated faster recovery than an experiment that returns to baseline within 10 minutes. Both may "pass" against a threshold check taken at the moment of termination — missing the 9-minute recovery tail that would have exceeded the SLO error budget for the measurement window. The recovery criterion makes the recovery tail a part of the hypothesis, requiring the system to stabilize within a defined window rather than merely returning to baseline at some unspecified time after termination.

A hypothesis meeting all four criteria — measurement, threshold, scope, recovery criterion — is falsifiable. The experiment can produce a clear pass or fail result. A "fail" result produces evidence that a resilience gap exists. A "pass" result produces evidence — not assurance, but evidence — that the system behavior matches the hypothesis under the injected failure condition.

The missing counterpart to a well-formed hypothesis is what the experiment does not validate. Every chaos experiment tests one failure mode, under one traffic condition, at one time. A database primary failover experiment run at 2 PM on a Tuesday tests failover at Tuesday-afternoon traffic levels with Tuesday-afternoon connection pool state, not at 2 AM during a backup job or at peak business hours during a traffic campaign. The hypothesis makes explicit what was tested. The experiment record should also make explicit what was not tested — the traffic conditions, configuration states, and concurrent operations that were not present during the experiment and that could produce different results.

This is the information a new technical leader inheriting a team with a "we do chaos engineering" claim needs. The claim without the experiment records, hypothesis specifications, and out-of-scope conditions gives the new leader a confidence score with no denominator. The experiment records with hypotheses and explicit scope statements give the new leader a bounded confidence claim: "we have validated that the system behaves as specified under these failure modes, at these traffic conditions, with these experiment dates."

Five ADR sections the chaos engineering decision record needs

1. Experiment authorization model

Document the environment tiering with specific experiment types assigned to each tier and the promotion criteria between tiers. Distinguish the authorization requirements for experiments by blast radius magnitude: specify whether low-blast-radius experiments (single stateless service, redundant instances, no user-facing SLO impact at the P99 failure rate) require only asynchronous notification, while medium-blast-radius experiments require the on-call engineer to be actively monitoring, and high-blast-radius experiments require a named incident commander, pre-experiment communication to the team, and confirmed runbook availability.

Specify the minimum monitoring readiness checklist that must be satisfied before production injection: which SLO metrics must be verified as accurately instrumented, which alert rules must be confirmed active for the blast radius, which team members must be confirmed available, and what communication channel is opened for the experiment window. Document the abort criteria format requirement — every production experiment must specify the measurement, threshold, monitoring source, and named individual responsible for triggering manual abort before injection begins.

Document what happens after an experiment, whether it passes or fails. A passing result is logged in the failure mode catalog with the date, environment, traffic conditions, and hypothesis specification. A failing result triggers a remediation process with a defined owner and completion criterion before the experiment is re-run. A failing result that reveals a configuration gap between staging and production triggers a scope review for other experiments that may have the same staging/production configuration difference.

2. Blast radius scope definition and scope maintenance protocol

Document the in-scope system catalog in the format: service name, failure modes in scope (each with last validated date and environment), failure modes in backlog (not yet tested), and out-of-scope failure modes (intentionally excluded with reasons). The failure mode backlog makes the confidence gap explicit: "we have validated failover but not connection pool exhaustion under production-scale reconnection storms."

Document out-of-bounds systems with the technical reason for exclusion and the cascading failure protection mechanism. A payment processor that is out-of-bounds for direct targeting should have a documented circuit breaker or bulkhead pattern protecting it from in-scope experiment blast radius — or the reason why no such protection exists and what the risk acceptance decision was. The load balancer's health check model and connection draining policy is one of the first things to validate through chaos: a health check that detects process failure but not application-layer failure will route users to broken backends during experiments that produce application failures without killing the process.

Document the scope entry policy with answers to the three questions: when new services enter scope, what triggers a scope update for new external dependencies, and the scope audit cadence. Specify the trigger for an unscheduled scope review: a production incident revealing a failure mode not in the experiment catalog should trigger both a new experiment targeting that failure mode and a scope review to identify similar gaps.

3. Steady-state hypothesis framework

Document the required hypothesis format: measurement name and monitoring source, threshold value and direction, scope specification (services, endpoints, user segments), measurement duration during experiment, and recovery criterion (time window and threshold after termination). Specify that at least one user-facing metric or explicit user-impact proxy must appear in every hypothesis — internal system metrics are permitted as additional measurements but not as the sole hypothesis.

Document the SLO grounding requirement: where a published SLO exists for the measurement being used in the hypothesis, the hypothesis threshold must be at most as permissive as the SLO target. Hypotheses more permissive than the SLO target — "latency remains below 2,000ms" when the SLO target is "latency P99 below 800ms" — validate resilience at a lower standard than the organization has committed to users and produce "passing" results that are compatible with SLO violations.

Document the experiment result record format: hypothesis specification, experiment start and end timestamps, traffic conditions at experiment time, injection parameters, measurement samples during experiment, recovery time, pass/fail verdict, and explicit statement of what was not tested. The "not tested" section prevents passing results from being interpreted as validation of conditions that were not present.

4. Failure mode catalog and experiment cadence

The failure mode catalog is the living record of what has been tested, what has passed, what has failed and been remediated, and what has not been tested. Format each entry: failure mode name, affected system, last experiment date, environment, result (pass/fail/remediated-retest-pass), hypothesis specification link, and gap notes (conditions not covered by the experiment). The catalog should be readable as a confidence statement: "here is what we have verified, when we verified it, and what conditions we did not test."

Document the GameDay cadence: frequency, scope per GameDay (all experiments in the catalog versus rotating subsets), the scheduling process, and the lead time for each pre-experiment preparation step. The cadence should also specify the maximum allowable gap between experiments for high-priority failure modes. A database failover experiment run once eighteen months ago may have been valid at the time and may no longer be valid if connection pool configuration, traffic levels, or replica count have changed since.

Document the new failure mode intake process: how does a production incident that reveals a gap in the experiment catalog trigger a new experiment? The intake process should specify the gap analysis required (what conditions in production were not present in any existing experiment), the experiment design steps, the staging experiment requirement before production, and the timeline for closing the gap. The founding decisions in the initial chaos engineering adoption session — which failure modes to prioritize, what the minimum experiment cadence is, whether the team targets a continuous experiment model or periodic GameDays — determine this intake process and are almost never documented in the initial enthusiastic installation of the chaos platform.

5. Observability requirement for chaos experiments

Document the monitoring readiness gate as a checklist with named verification steps, not as a policy statement. "All SLO metrics must be instrumented" is a policy statement. "Verify the following before production experiment injection: (1) confirm the Datadog p99 latency monitor for /api/checkout has fired at least once in the past 14 days, confirming instrumentation is active; (2) confirm the payment success rate monitor is returning non-null data in the current hour; (3) confirm that the on-call PagerDuty rotation for the payment service blast radius has a named current primary who has confirmed availability via Slack thread created at minimum 30 minutes before injection" is a readiness gate.

Document the experiment result storage model. Experiment results stored only in a team wiki or a shared document degrade differently than experiment results stored alongside the experiment definition in a version-controlled repository. The version-controlled model produces an auditable history of when experiments were run, what the results were, and how the experiment definitions have evolved — enabling the new technical leader to read the chaos engineering history and understand how the team's resilience posture has evolved, rather than receiving only a summary prepared by the team.

The database failover experiment in particular must document the production-specific conditions that staging cannot reproduce: the production max_connections parameter, the production connection pool configuration per service, the production traffic rate at which reconnection storms can exhaust the connection pool, and the production replica count and failover timing. Without this documentation, a staging-validated experiment is only staging confidence, and the staging confidence is accurately labeled as such only when the experiment authorization model enforces that distinction.

Document the correlation tracking process between experiment results and production incidents. A chaos engineering program that passes all its experiments in periods that also produce a high rate of production incidents is revealing either a scope gap (the incidents are in areas not covered by experiments) or a hypothesis gap (the experiments pass at a standard lower than the actual production failure threshold). Correlating experiment results with incident reports at a quarterly cadence is the check that prevents a high pass rate from becoming a confidence illusion.

The three AI session types that make chaos engineering decisions

The initial chaos engineering adoption session is triggered by a production incident or a reliability-focused hire. The session installs a chaos platform, runs a "hello world" experiment (typically pod kill or instance termination on a non-critical stateless service), verifies that auto-healing works, and declares chaos engineering adopted. The platform choice (LitmusChaos, Gremlin, AWS Fault Injection Simulator, Chaos Mesh) is made based on a combination of team familiarity, deployment environment, and available documentation. What the session does not produce is the experiment authorization model, the blast radius scope policy, the steady-state hypothesis format requirement, or the failure mode catalog. It produces a running chaos platform and a first passing experiment. The deployment strategy determines whether experiments that reveal failures can be quickly rolled back or require a full deployment cycle — a constraint on experiment design that the initial session rarely considers.

The tool configuration session adds more experiments to the catalog and schedules a first production experiment. This session is where the blast radius scope is implicitly defined — by the set of experiments added — without being explicitly documented as a scope boundary. If the session adds experiments for Redis, the database primary, and the primary API service, those three systems become the implicit scope. New systems added to the product after this session exist outside the implicit scope without anyone deciding that they are outside scope. The session may also configure scheduled experiments, which is where the experiment cadence is implicitly defined — "run the database failover experiment every 90 days" — without a cadence policy that specifies what triggers an out-of-cycle experiment or how the 90-day cadence is reviewed as the system evolves.

The incident-triggered session adds a new experiment in response to a production incident that exposed a failure mode not covered by the existing catalog. This session is the most honest chaos engineering session because it is responding to evidence of an actual gap. It is also the session that most clearly reveals the absence of a scope maintenance policy: the incident exposed a failure mode not in the catalog because the catalog was never designed as a policy for keeping the failure mode coverage current. The session adds one new experiment targeting the specific failure mode that caused the incident, without reviewing whether other similar gaps exist in the current catalog or whether the scope definition process needs to be updated to catch similar gaps in the future. The on-call rotation model determines who is paged during incidents that reveal chaos engineering scope gaps — and the rotation's handoff quality determines how completely the incident knowledge is captured before the next session, where a new engineer may not know the full context of what the previous incident revealed.

Finding these decisions in your AI chat history

The chaos engineering adoption session has a distinctive signature: "I want to set up chaos engineering for our platform. We use Kubernetes / AWS / GCP. What's the best tool to start with?" followed by installation commands, a first experiment configuration, and a verification of the experiment result. The session produces the platform selection, the first experiment definition, and often the first passing result. It rarely produces authorization model, scope policy, or hypothesis format decisions — those questions don't appear in the getting-started guides that the session is following.

The blast radius scope decisions are often most visible in the sessions where experiments were explicitly not run: "I want to chaos test our database, but that feels too risky. Let's stick to the Redis experiment for now." The "too risky" judgment is the out-of-bounds decision being made without being documented. The reason the database feels too risky is information about the blast radius, the on-call readiness, the monitoring coverage, or the recovery confidence — exactly the information the blast radius scope document should capture as a basis for the out-of-bounds classification.

The steady-state hypothesis decisions are often in sessions where the engineer describes the experiment result in retrospective terms: "I ran the Redis experiment and everything stayed up." The session produced a passing result without a pre-specified hypothesis, meaning the engineer's post-hoc assessment ("everything stayed up") is the "hypothesis" being evaluated against the experiment result. Searching for sessions that describe what the engineer observed during or after an experiment — rather than sessions that specify what metrics must hold during the experiment — surfaces the implicit hypothesis decisions that were never recorded as explicit commitments.

WhyChose's extractor identifies chaos engineering decisions by looking for the session-type signals in your export: initial adoption sessions (platform comparison and installation), incident-triggered sessions (session starts with an incident description and ends with an experiment addition), and configuration sessions (steady-state hypothesis discussions, authorization model discussions, or — most commonly — the absence of those discussions in sessions that otherwise configure experiments). The decisions found in those sessions are what the chaos engineering ADR sections above are asking to capture: not what the tool does, but what the team decided about who can inject failure, in what scope, under what conditions, and with what evidence standard for pass and fail.