Site Survey & Network Infrastructure Assurance · Technical White Paper
Site Survey & Network Infrastructure Assurance
An assurance method for multi-site network estates — reconciling four kinds of evidence about the same asset, testing fault data against itself, and defining closure so a fix can be proved rather than asserted.
11 · Asset census
An asset count is not a single number
The working tables showed differences between equipment charged, equipment physically observed, and equipment visible or registered on the network. Some of those schedules were themselves incomplete or internally inconsistent, which is precisely why they are not used as a final billing claim — they demonstrate the need for controlled reconciliation rather than providing its answer.
Each asset should resolve to one controlled status: contracted-and-present, contracted-but-missing, present-but-not-contracted, decommissioned-awaiting-removal, spare or loan, or disputed. That status then drives both the remediation and the billing position.
11.1 · Four evidence sets
What each one answers, and how each one fails
Scroll table sideways →
| Evidence set | What it answers | Typical failure mode |
|---|---|---|
| Commercial schedule | What the organisation is contracted or invoiced for. | Stale quantities, legacy assets, wrong model identifiers. |
| Physical census | What is actually present at each location. | Missing, moved, unplugged, damaged or substituted equipment. |
| Network discovery | What is powered, connected and visible. | Present but offline assets; unknown devices; duplicate or stale records. |
| Acceptance and change records | What was formally installed, moved or removed. | Records not updated after site changes. |
12 · Fault analytics
Reading 3,534 tickets without being misled by the average
The review covered 3,534 tickets and 141,667.8 cumulative incident-hours, at an average repair duration of about 40 hours. Cumulative incident-hours is an aggregate workload and impact measure across many tickets — not one continuous outage, and it should never be quoted as though it were.
The tail matters more than the average. 166 tickets exceeded the prolonged-downtime threshold and that group averaged more than 400 hours each — roughly 4.7% of tickets carrying a disproportionate share of the impact. Averages hide exactly this.
By category: 689 incidents under equipment failure, 178 resolved by replacement at about 42 hours; 262 lightning-related tickets at about 48 hours; 564 private-power tickets at about 34 hours; and an unknown-cause group averaging roughly 49 hours. Those categories are why infrastructure assurance has to consider environmental and power conditions, not only network design.
12.4 · When the cause code contradicts the fix
A repeated issue in the fault data was “corrosion” recorded as a cause even where the corrective action was a reset — an action that would not physically repair corrosion. Similar cause labels also produced very different resolution times.
That pattern does not prove every cause code was wrong. It does raise a data-quality and root-cause concern, and it is testable: symptom, cause, action, part replacement, closure code and recurrence should be internally consistent. Without reliable cause data, recurring technical debt cannot be eliminated because it cannot be identified.
16 · Triangulation
Why no single evidence type settles a contested finding
Scroll table sideways →
| Evidence | Primary use | Limitation alone |
|---|---|---|
| Site observation and photograph | Condition, presence, mounting, environment. | Does not establish contract entitlement or network operation. |
| Network scan | Visibility, addressing, live device classes. | Misses powered-off, filtered or unreachable equipment. |
| Functional test | Proves behaviour at the time of testing. | May not represent intermittent or load-related conditions. |
| Technical manual or standard | Defines expected environmental or installation conditions. | Describes what should be true, not what is. |
A supplier may dispute a physical count, a client record may be outdated, a scan may omit powered-off equipment, and an invoice may legitimately lag an approved move. Preserving multiple evidence types and reconciling them systematically is the only defence against each of those.
10 · Connectivity validation
Find where the loss occurs, not a speed-test screenshot
A user-side wireless test can be constrained by RF conditions, access-point loading, LAN switching, cabling, local congestion or the upstream circuit. Any one of those can produce a poor result that has nothing to do with the contracted service.
A defensible acceptance test therefore uses at least two test points: a controlled wired test at or near the service demarcation, and a representative user-path test across the LAN and WLAN, with latency, packet loss and jitter recorded where the application requires them.
19 · The closure standard
Every remediation item should carry a closure test, because a completed action without proof is still an open assurance issue.
“Replace cabinet” is an action. The closure standard is: new enclosure installed, ingress rating verified, cable entries sealed, temperature under load within design range, asset register updated, photographs retained.
No remediation is marked complete without objective acceptance evidence.