A non-conformance report records that something deviated from specification. Well-managed commissioning processes maintain the register as a live document: items raised, investigated, and closed with verifiable evidence. At the point of energisation review, what matters isn't the total count of open items — it's which items remain open, what they represent technically, and whether any of them sit on the load path.

The NCR register captures a wide range of deviations. Cable bent beyond minimum bending radius. Earth connection not installed to drawing. Test result outside specified tolerance. Equipment installed that doesn't match the approved submittal. These are different in kind, not just in severity. A register that treats all of them as equivalent items in a queue doesn't provide the analytical basis needed for an energisation readiness assessment.

Administrative items versus technical conditions

On larger projects, the majority of NCRs tend to be administrative in character. Late-arriving operation and maintenance manuals. Label designations not yet updated to reflect as-built changes. Minor contractor sign-off items where the physical work is complete. These represent genuine handover gaps, but they don't affect whether the equipment can safely receive load. They're loose ends, not blockers.

The risk is when a count-based view of the register — "twelve items open" — is used as a proxy for readiness status. The count isn't the signal. What those items are, and whether any of them sit on the main distribution, protection, earthing, or bonding path, is the signal. A register with three open items, one of which is an earth continuity failure awaiting re-test, may warrant more attention than a register with twenty open items, all administrative.

Technical NCRs that directly affect the load path

A distinct category requires closer examination: equipment installed outside specification in ways that affect function (cable tray fill beyond rated capacity, switchgear installed in an environment outside its ingress protection rating); test failures that were recorded and retested without documented explanation of the original failure; earth connections that failed continuity, recorded as remediated, but with no evidence of re-test following the remediation.

A specific pattern worth noting: test result fails, gets recorded in the NCR register, test is repeated and passes, and the item is closed. Where the closure narrative simply reads "re-tested — pass" without documenting the cause of the original failure, the closure may be procedurally complete but technically insufficient. Cause identification is part of closure — without it, the remediation path is unclear. Depending on the test type and the system involved, this may be acceptable or it may warrant investigation before energisation. The distinction can't be made from the register alone.

Register structure and what it tells you

Total count is context, not signal. An NCR register with 140 items and 12 open may represent a well-managed project with comprehensive recording. One with 30 items and 4 open may represent a project where deviations weren't consistently raised. Neither tells you directly whether load-path conditions are resolved.

Categorisation is the diagnostic tool. A register structured to distinguish blocking items, non-blocking items with close-out dates, and administrative items allows pre-energisation assessment without manual review of each entry. Without that structure, manual review of each open item is necessary — feasible at low volume, not at scale.

On anonymised data centre reviews, registers lacking category structure typically require 2–3 hours of manual triage to isolate load-path items that could be completed in under 30 minutes from a well-structured register. The cost is in review time, not in the register itself.

The conditional closure problem

A recurring risk pattern: NCRs closed with conditions attached. "Closed subject to verification during commissioning." "Closed pending receipt of manufacturer re-test certificate." "Closed subject to re-test following panel reinstallation." These closures appear as closed items in the register summary view. The headline count — X open, Y closed — looks clean. But the condition attached to the closure is still outstanding, dependent on a downstream action that may or may not be tracked in the NCR system.

Where no one is actively tracking the downstream action against the conditional closure, it can simply not happen. The system shows all NCRs closed; the technical condition the NCR was raised against has not actually been verified. This is particularly likely on projects where NCR management and commissioning test management sit in separate systems with no cross-reference between them.

The re-test without cause documentation pattern

Where a test fails and is retested to pass, the original failure record remains in the test pack. On review, the sequence looks like: fail result, pass result, NCR closed. That's a clean administrative path. The question worth asking is whether the pass result after a fail warrants a documented explanation of why the first attempt failed — instrument calibration drift, incorrect test procedure, a connection that was re-made — so that the re-test result can be assessed with appropriate confidence. In some cases the explanation is obvious from context. In others it isn't, and the absence of cause documentation means the re-test result can't be fully evaluated as remediation evidence.

At energisation decision: Filter the NCR register to load-path items — main distribution, protective device coordination, earthing and bonding arrangement. Separate blocking from non-blocking based on technical impact, not administrative status. Review re-tested items for documented cause of original failure. Check conditional closures for evidence that the stated condition was subsequently verified. The total count is context. Load-path items with unresolved or conditionally closed conditions are what affects the readiness assessment.

Zero open NCRs at energisation is rarely achieved on large projects and isn't the right threshold. The relevant question is whether open items are understood, categorised, and — for load-path items — either resolved with evidence or explicitly accepted with documented technical reasoning for why the condition doesn't affect energisation readiness. Both are defensible positions. The absence of that analysis is not.