Remote Resolvability

The dominant operating cost of a deployed fleet is the field visit. Everything else — telemetry, connectivity, the platform — is small beside sending a person to a device.

Remote resolvability is the proportion of issues that can be diagnosed and fixed without one, and it is a direct function of what the device can report and what can be changed remotely.

Why it is a design-time property

A device that cannot report its logs, cannot have its configuration changed remotely, or has no per-device identity guarantees a field visit for every issue — and that is fixed at design time, not improvable by operational effort afterwards.

The decisions that determine it are made before the first unit ships, and they determine the cost structure for the device's entire deployed life.

Implementation patterns

• Retrievable diagnostics on request — state, logs, configuration — with a bandwidth and power cost that makes on-demand retrieval feasible.
• Remotely changeable configuration, validated and bounded, with a safe fallback.
• Per-device and per-cohort targeting, which requires per-device identity — a fleet with a shared credential cannot revoke, target or attribute.
• Health telemetry cheap enough to send continuously: a small periodic heartbeat plus event-driven detail, since a power- and bandwidth-limited device cannot stream.
• Version distribution visibility, since every server-side change must be compatible with a long tail that is longer than assumed.
• Staged rollout with halt on device-reported health, because a bad configuration reaching the whole fleet may require physical intervention on every unit — a company-ending cost at scale.

Industry example

Service marketplaces such as Urban Company with field devices, and connected-product companies such as Ather, both face the same arithmetic: a percentage point of remote resolvability is worth more than most software optimisations, because the alternative cost is a person travelling.

The capabilities that raise it are unglamorous — log retrieval, configuration change, cohort targeting — and they are the ones deferred in favour of features.

Failure scenarios

• No remote log retrieval, making every diagnosis a visit.
• Configuration baked into firmware, making every change an update.
• Shared credentials, making targeting impossible.
• Telemetry too expensive to send, so the device is silent between incidents.
• A bad rollout reaching the whole fleet, requiring physical intervention everywhere.

Trade-offs

Every remote capability is an attack surface: remote configuration change is a mechanism an attacker would want, and remote log retrieval may expose data.

They must be authenticated per device, authorised server-side, and audited — and the resulting complexity is the price of not sending people to devices. The alternative is a device that is safe and expensive to operate, which is a defensible choice only for a small fleet.

Interview question

"A customer reports their device is behaving oddly. Tell me everything you can learn and change without sending someone — and then tell me what you would have had to build to answer differently."