A complete test pack and a correct test pack are not the same thing. Completeness is a page-count check — every schedule present, every certificate signed off. Correctness requires that the data inside those documents is technically plausible and internally consistent.

A package can pass a completeness review without difficulty and still carry data that doesn't hold up to scrutiny. Those errors tend to persist — through handover, through sign-off, surfacing only when something behaves unexpectedly under load. The patterns that produce them are fairly consistent, and most are detectable from a desk review without site access.

Recurring patterns in submitted packages

Insulation resistance recorded as pass without a measured value. The pass/fail checkbox is marked, but the megohm reading at test voltage isn't recorded. A pass indicates the result cleared the minimum threshold — it doesn't indicate by how much, whether the result was borderline, or what the insulation condition was at the time of test. The measured value, the test voltage, and the circuit configuration at the point of test are what make the record usable for future reference or dispute resolution.

Instrument calibration absent or out of period. Each instrument used in the test campaign should have a current calibration certificate traceable to a national standard. Where calibration records are missing, or where the expiry date has passed, the traceability chain is broken. Results recorded by an instrument that was outside its calibration period carry no formal evidential weight — and multifunction testers operating outside calibration have been observed producing readings with sufficient drift to affect interpretation of marginal results.

Circuit reference misalignment

Test records referencing a superseded design schedule. This one is easy to miss on a summary review. Test sheets may reference circuit designations from a design revision that predates the as-built condition. Panels renamed, circuits renumbered, equipment changed during build — if the test record references "Panel 3, Circuit 12" and that designation doesn't appear on the current as-built schedule, the record can't be positively traced to the installed circuit without additional investigation.

Spot-checking test records against the as-built schedule typically surfaces this pattern quickly. Where circuit references don't reconcile and revision notes don't explain the discrepancy, the record should be treated as unmatched — nominally present but not attributable to a specific installed circuit.

Technical plausibility review

A document audit confirms presence and signature. Technical review asks whether the recorded values are consistent with the installation they describe. IR readings reasonable for the cable types and lengths involved? Zs values consistent with the expected supply impedance plus circuit conductor contribution? RCD operating times within specification at both rated and half-rated current? Test dates plausible against the commissioning programme — not clustered on a single day where the volume of work would have taken several?

Internal inconsistencies tend to become visible when reading the data as a dataset rather than as individual certificates. IR readings at exactly 999 MΩ across every circuit may indicate the tester reached its display ceiling rather than a measured value. Zs values identical across circuits of materially different length warrant closer attention. A section that should have required several days to commission, with all records dated the same day, suggests the records may not reflect the actual test sequence.

What the review is looking for: Completeness establishes that everything is present. Technical review looks at whether the data is internally consistent, values are within plausible ranges for the installation, equipment references match the as-built, dates align with a credible programme, and calibration is traceable. A package that satisfies the completeness check but fails technical plausibility doesn't provide the assurance that energisation decisions should be based on.

Documentation problems arise for various reasons — compressed schedules, records compiled from field notes after the fact, instrument limitations not captured at the time of test, schedule changes that didn't propagate into the test sheets. The origin matters less than whether the package, as it stands, supports the claim that the installation was tested and found acceptable. Where it doesn't, the gap needs to be resolved before the energisation decision is made.