The verification sequence isn't arbitrary. Each test in the chain exists because its predecessor created the conditions under which the next measurement is valid. When a test pack shows results without their documented prerequisites, the question isn't whether the numbers look reasonable — it's whether the configuration was correct when the measurements were taken.

The sequence is established for a reason: continuity (dead circuit), insulation resistance, polarity, earth fault loop impedance, RCD functional, live checks. Continuity confirms conductor integrity before voltage is applied. Insulation resistance verifies the dielectric condition before impedance is introduced. Polarity confirms phase-neutral orientation before Zs is interpreted against protection characteristics. Reordering those steps, or presenting results without the preceding records, produces data that may be technically present but cannot be reliably interpreted.

How chain gaps present in test pack review

Incomplete verification chains rarely appear as missing test types. More commonly, the pattern is a result present without its documented prerequisite. An IR record signed and dated, but no corresponding continuity check in the pack — or continuity records post-dating the IR by several weeks. That sequence gap doesn't necessarily mean continuity wasn't checked. It means the documentation doesn't demonstrate the circuit was in the correct configuration when IR ran. A disconnected protective conductor wouldn't cause an IR test to fail; it would mean the IR result was obtained on a configuration that doesn't represent the installed circuit.

The same issue arises with Zs recorded before polarity verification appears in the pack. If phase and neutral orientation was unconfirmed at the time of measurement, the impedance figure is real — but it's the impedance of an unverified configuration. Whether or not the circuit ultimately passed polarity, the Zs value isn't reliable evidence of loop impedance in the as-built condition until polarity was confirmed first.

Sequence indicators to review

Date order across test types. Continuity records dated after Zs measurements suggest the sequence wasn't followed or documentation was retrospective. Either warrants a query before energisation sign-off.

IR and live functional tests on the same date. Where these appear together without intervening records, it may indicate compressed testing — or documentation assembled after the fact. The gap between dead-circuit and live-circuit work should be visible in the dates.

RCD functional results without Zs records for the protected circuits. RCD disconnection-time assessment depends on the available fault current, which depends on Zs. An RCD result without a Zs record for its downstream circuits is incomplete regardless of what the RCD test shows.

Dates out of sequence don't demonstrate tests weren't performed — they demonstrate the documentation doesn't show they were performed in the correct order, on the correct configuration. That's the distinction that matters for an independent review.

Tests performed vs tests evidenced

There's a distinction between tests that were carried out and tests that are documented in a way that supports an energisation decision. An engineer who completed the sequence correctly but assembled records in a way that obscures the order has produced documentation that can't be relied upon as verification evidence — not because the testing was inadequate, but because the record doesn't demonstrate what it needs to demonstrate. For pre-energisation review purposes, the distinction between "done but undocumented" and "not done" is practically narrow: neither supports a sign-off.

What a complete chain requires: every step in the verification sequence has a dated record; dates are consistent with the prescribed order; each result references a specific circuit or assembly; no prerequisite is absent for any test that's present. A pack that satisfies those conditions provides a defensible basis for energisation. One that doesn't — regardless of whether individual results look acceptable — may indicate system-level gaps requiring resolution.

A pattern from review

On an anonymised data centre pre-energisation review, test packs for a medium-voltage distribution section contained Zs records for all circuits, with values within limits and protective device coordination appearing satisfactory. Polarity verification records were present for approximately half the circuits; the remainder had no polarity entry. When the issue was raised, the response was that polarity had been checked verbally on-site and wasn't considered to require a separate record. The Zs values for the undocumented circuits couldn't be accepted as valid verification because the configuration at the time of measurement was unconfirmed. Retesting after documented polarity verification produced Zs results consistent with the original figures — which is the most common outcome. But the original test pack, as submitted, represented an incomplete verification chain that couldn't support an energisation recommendation without that resolution step.

Verification approach when chains are incomplete

Where a chain gap is identified during review, the appropriate path depends on what's missing and whether conditions have changed since testing. A documentation gap — where testing appears to have been performed correctly but prerequisites aren't recorded — typically warrants retest with full documentation rather than retrospective sign-off. The retest serves a dual purpose: it produces the required record, and it confirms the configuration hasn't been disturbed in the interim.

Where a gap indicates a genuine sequence issue — IR or Zs results that may have been obtained on an unverified or incorrect configuration — those circuits should be treated as requiring full reverification from the appropriate point in the sequence. Design margins in critical infrastructure rarely accommodate the assumption that an out-of-sequence result happens to be valid. The verification chain exists precisely because that assumption isn't safe to make at this stage.