An installer reports that about 1 in 200 smart water meters will not install. The firmware image is identical across the batch and the platform has no record of those units at all - no provisioning attempt and no failed authentication. Every failed unit works when bench-tested back at the depot, and the failures cluster in particular meter pits. Which cause should you look at first?

The mechanism

A failure with no telemetry is upstream of telemetry. That single sentence does most of the diagnosis, and it is the habit worth building.

Every other explanation on the list would leave a trace somewhere, because each of them happens after the device or the handset has successfully talked to something. The absence of any record - not a rejection, not a timeout logged at the gateway, nothing - bounds the failure to before the device's first successful network exchange. For a radio device in a concrete pit under a metal lid, the candidates in that window are almost all physical: signal strength at the mounting position, the lid, water ingress, antenna orientation, a pit that happens to sit in the shadow of a building.

The two clues in the stem confirm it. Clustering by pit is a geographic correlation, and firmware does not know where it is. Working on the bench is the same unit, same image, different physical environment, passing.

Why the other options fail

• A first-boot race. A real and common cause of intermittent provisioning failures, and it would reproduce at some rate on the bench, because a race depends on timing inside the device rather than on where the device is. It would also be distributed roughly evenly across the batch instead of clustering in particular pits.
• Rate-limiting at the provisioning service. This would be the right answer if the platform showed rejected enrolments, and the stem says there are none. A service that throttles still logs what it threw away; silence is not what throttling looks like.
• A bug in the installer's handset app. Plausible, and it would show as a missing step in the handset's own telemetry rather than as nothing anywhere. It would also not correlate with the pit, because the handset works wherever the installer stands.

What the architecture should have provided

This is the part that makes the question architectural rather than operational. At the moment of failure, the only instrument in existence is the installer's handset. The device cannot report, so the design must not depend on the device reporting.

• The handset records a local install result before any cloud call succeeds: measured signal strength at the mounting position, the unit's serial, a photograph of the installed position, and a pass or fail. It uploads later, when the installer has coverage, and the record exists whether or not the meter ever speaks.
• The expected population is known in advance. Reconcile units shipped to an installer against units heard from, so a unit that never reports is a visible open item rather than an absence nobody counts.
• The handset gets a local pass criterion - a minimum signal margin - so the installer can move the unit by 20 cm while they are still standing there, which costs nothing, rather than after a revisit, which costs everything.

When this reasoning is the wrong answer

When the platform's own record is incomplete rather than genuinely empty. Before concluding that a failure is upstream of telemetry, confirm that the telemetry would have captured it: a gateway that only logs successful handshakes, or a provisioning service whose rejection path writes no record, produces the same silence for a completely different reason. Check that your logging covers the rejection case before you let an absence of evidence become evidence.

Why the number matters

0.5% of a 200000-unit rollout is 1000 revisits. At a fully loaded cost of a site visit - travel, appointment, two people in some jurisdictions - that is routinely the largest single line in a rollout budget, and larger than the platform engineering. The install success rate is a design target, not a field-operations statistic.