Fault-Injection Composition Probe¶
Resilience probe — instantiates Composability Testing and Validation
Deliberately breaks components and their shared context to expose the hidden coupling and unsafe degradation that only appear when a composition is under stress.
A composition can look perfectly healthy right up until one of its parts stumbles — and then the way the others respond reveals couplings nobody declared. Fault-Injection Composition Probe is the mechanism that provokes exactly that: it deliberately degrades or fails a component, or corrupts the context the parts share (latency, packet loss, a stuck sensor, a resource starved), and watches how the failure propagates through the combination. Its defining move is perturbation to reveal coupling: healthy-path testing shows that parts cooperate when all is well; fault injection shows whether the composition degrades safely or amplifies a single fault into a cascade. It does not check correctness against an oracle and it does not sample the combination space — it stresses one live combination and reads the emergent response, turning "we assume these parts are loosely coupled" into evidence one way or the other.
Example¶
An automotive team has composed a driver-assistance stack from three modules: a perception module (cameras and radar), a planning module, and a control module. Each passes its own tests, and on the healthy path they cooperate smoothly. The open question is what happens when one part falters. So the team injects faults on a test track and in simulation: they blind one camera with simulated glare, they delay the radar feed by 200ms, they feed the planner a briefly corrupted object list.
The revealing case is the delayed radar. Perception, missing fresh radar, keeps publishing its last fused estimate without flagging it stale; planning trusts the stale estimate as current; control acts on a phantom object that has already moved. None of the modules is "wrong" by its own contract — but the composition has a hidden coupling: planning silently assumed perception's timestamps were always fresh, an assumption written nowhere. The fault injection exposes it, and the fix is a contract change — perception must mark stale outputs, planning must reject them — that no healthy-path test would ever have demanded.
How it works¶
- Pick the fault and the injection point. Choose a realistic degradation — component crash, slow response, corrupted output, resource starvation, context perturbation — and where in the composition to introduce it.
- Inject into the live combination. Apply the fault while the composed system runs, so the other components must respond to it in real interaction, not in isolation.
- Trace the propagation. Instrument how the fault travels — does it stay contained, degrade gracefully, or cascade? — reading the emergent response across all parts.
- Attribute the coupling. Where a fault propagates further than any contract predicted, name the undeclared dependency it exploited and route it to the contract inventory.
Tuning parameters¶
- Fault severity — from a brief hiccup to total component loss. Mild faults probe graceful degradation; severe faults probe worst-case cascades but can obscure subtler coupling.
- Blast scope — inject into one component versus the shared context (network, resource pool) that many touch. Context faults reveal wide couplings; component faults localize.
- Injection timing — steady-state versus during a transition or under peak load. Faults injected under contention surface interactions that a quiet-system injection misses entirely.
- Steadiness of the steady state — how confidently "normal" is established before injecting. A well-characterized baseline makes the fault's effect legible; a noisy baseline muddies attribution.
When it helps, and when it misleads¶
Its strength is that it finds the couplings nobody wrote down — the implicit "the other part will always be fast / fresh / available" assumptions that healthy-path testing can never violate, and that only a real degradation exposes. It is the mechanism that converts a hopeful "these parts are loosely coupled" into demonstrated resilience or a named, fixable dependency, and it is the empirical heart of chaos engineering.[n1]
Its failure mode is that injected faults are a chosen menu: the probe reveals coupling only for the failures someone thought to inject, so an unimagined fault mode stays hidden, and surviving the tested faults can breed overconfidence about untested ones. Run carelessly, it is also genuinely dangerous — a fault injected in the wrong environment can cause the very outage it was meant to prevent. The classic misuse is injecting only convenient, mild faults, declaring the system "resilient," and never probing the ugly correlated failures that actually take systems down. The guarding discipline is to derive the fault menu from real incident history and contract assumptions, expand it as new failure modes are discovered, and always bound the blast radius so the probe cannot become the disaster.
How it implements the components¶
adversarial_combination_probe— it is the perturbation itself: injecting hostile conditions (failures, delays, corruption) into a live composition to provoke worst-case interaction.emergent_behavior_observability— it traces how an injected fault propagates across components, reading the cascade or containment that only emerges under stress.component_contract_inventory— it surfaces undeclared couplings and implicit assumptions, feeding them back as new or revised contract terms.
It provokes and observes but does not judge correctness against a formal property — that oracle belongs to Property-Based Composition Testing — nor does it diagnose the full root cause of a revealed coupling, which belongs to Incompatibility Root-Cause Analysis.
Related¶
- Instantiates: Composability Testing and Validation — the fault probe is how the archetype exposes hidden coupling and unsafe degradation that healthy-path testing cannot reach.
- Sibling mechanisms: Pairwise Interaction Probe · Combinatorial Sampling Strategy · Property-Based Composition Testing · Staged Integration Sandbox · Invariant Monitoring Dashboard · Incompatibility Root-Cause Analysis · Metamorphic Composition Test
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Fault-Injection Composition Probe operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it deliberately breaks components and their shared context to expose the hidden coupling and unsafe degradation that only appear when a composition is under stress.
Independent corroboration: The frozen evidence defines Fault-Injection Composition Probe as 'Deliberately breaks components and their shared context to expose the hidden coupling and unsafe degradation that only appear when a composition is under stress', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Deliberate fault injection became a characteristic software and distributed-systems testing practice.
Related originating lineages:
- Engineering & Design — Reliability engineering supplied failure testing and common-context stress analysis that shape the probe.
Review resolution: Both reviewers agree that computer_science is primary. I retain engineering_design only as formative origin lineage(s), without treating every later application as an origin. cross_disciplinary_synthesis is appropriate because the exact artifact combines contributions from multiple professional lineages. Reach is multi_domain as a separate applicability judgment: it does not widen or narrow the recorded provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. The secondary differences are reconciled with no unresolved primary-provenance ambiguity.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Chaos engineering is the practice of deliberately injecting failures into a running system to build confidence in its resilience — popularized by Netflix's Chaos Monkey, which randomly terminates production instances so that hidden coupling and unsafe degradation are discovered by design rather than by outage. ↩