Skip to content

Integration Test Plan

Verification protocol — instantiates Inventory-Bounded Resource Recomposition

Exercises the recombined configuration as a whole under representative load, environment, duration, and failure — to confirm its required invariants still hold and that it is genuinely good enough for the mission.

A make-do system can pass every part-by-part check and still fail as a whole — the pieces interact, the improvised seams sag under real load, the substitute that tested fine at the bench behaves differently after six hours in the cold. An Integration Test Plan is the protocol that exercises the assembled configuration under conditions representative of its actual use — real load, real environment, sustained duration, and injected failures — to establish two things: that the invariants the design must never violate still hold, and that the recomposition is genuinely sufficient for the mission. Its defining move is testing the whole under stress rather than the parts at rest: it is the difference between "each component works" and "the thing we built actually does the job when it matters." It judges the finished whole; it does not assemble it, nor screen the parts before assembly.

Example

An off-grid clinic recomposes a power system from what it has: mixed-vintage solar panels, a salvaged inverter, and a repurposed EV battery module, wired together to keep a vaccine fridge and lights running. Every part checked out individually — but that says nothing about the whole under real conditions, so the team writes an integration test plan. Load: run the full evening draw — fridge compressor cycling, lights, a charging bench — not a token bulb. Environment: through a cold night, when battery chemistry and inverter efficiency both shift. Duration: a 72-hour autonomy run with no sun on day two. Failure: deliberately drop one panel string to confirm the system rides through. Against these, two things are checked: the invariant that the battery never discharges below its safe floor, and the sufficiency criterion that the fridge stays in its required temperature band throughout.

The run surfaces what no bench check could: the salvaged inverter's cold-night efficiency dips enough that, combined with the compressor's startup surge, the battery grazes its floor near dawn on day two. The invariant is at risk — so they add a low-battery load-shed that protects the floor by dropping the bench first. The recomposition ships not because the parts worked, but because the system was shown to hold and suffice under the conditions it will actually meet.

How it works

What distinguishes this from a bench check or a parts screen is that it stresses the integrated whole against representative conditions and named invariants:

  • Test the assembly, not the parts. The unit under test is the recombined configuration, so the interactions and emergent behaviours that only appear once everything is connected are what get exercised.
  • Representative conditions, deliberately. Load, environment, duration, and failure modes are set to mirror real use — including the sustained and adverse cases where improvised systems fail — not a convenient best case.
  • Check invariants and sufficiency separately. One axis asks did anything cross a line it must never cross (the preserved invariants); the other asks is the result actually good enough for the mission (the sufficiency criterion). Passing one does not imply the other.
  • Inject failure on purpose. Faults are induced, not awaited, so the configuration's behaviour under the failures it will eventually meet is known before it is relied upon.

Tuning parameters

  • Condition realism — how faithfully load, environment, and duration mirror real use. Higher realism catches failures a bench check misses but costs setup, time, and sometimes risk to the hardware.
  • Failure coverage — how many fault modes are deliberately injected. Broader coverage builds confidence but lengthens the campaign and can stress improvised parts to destruction.
  • Invariant strictness — how hard the never-cross lines are drawn and how much margin is demanded. Tight invariants are safe but may reject a workable make-do; loose ones ship faster but closer to the edge.
  • Sufficiency bar — how good "good enough" must be. A high bar rejects marginal recompositions; a low one accepts them but may under-serve the mission when conditions turn.

When it helps, and when it misleads

Its strength is that it catches the failures unique to recomposition — emergent interactions, seams that hold at rest but not under load, substitutes that drift in the real environment — and it separates "won't break the rules" from "will do the job", so a make-do build is relied upon on evidence rather than hope. It is the gate that stands between an improvisation that looks finished and one that has been shown to hold. What it cannot do is prove the configuration is flawless: a test can reveal a problem but never certify the absence of all of them, so a clean run means "no failure found under these conditions", not "will never fail".[1]

Its failure mode is a plan that tests the easy conditions and skips the ones that actually break improvised systems — the sustained run, the cold, the simultaneous fault — so it certifies a fragility it never provoked. It can also mislead by measuring the wrong invariant, passing a system that holds the line you checked while crossing the one that mattered. The classic misuse is running it to bless a configuration already committed — a token test staged to produce a green check for a decision made on schedule pressure. The discipline is to derive the conditions and invariants from real mission demands before testing, to include the adverse and sustained cases by default, and to treat a pass as bounded evidence, not a guarantee.

How it implements the components

This protocol realises the verification slice of the archetype — proving the assembled whole holds and suffices — and neither builds it nor screens its parts:

  • preserved_invariant_set — it defines the lines the recomposition must never cross and checks, under stress, that none is violated.
  • sufficiency_test — it establishes whether the integrated result actually meets the mission's good-enough criterion under representative conditions.

It proves the assembled whole holds and suffices but does not perform the up-front, per-item compatibility screen — that belongs to the Affordance Inventory Walkthrough — it does not assemble the configuration, which the System Integration Workflow does, and it does not record the outcome, which the Configuration Change Log captures.

References

[1] A well-known observation in software engineering (Dijkstra) holds that testing can reveal the presence of defects but never prove their absence. An integration test therefore bounds risk under the conditions exercised; it does not certify the recomposition will hold under conditions it never met. ↩