Device-Side Refusal

A server orchestrating a fleet update knows what it intends and does not know whether the device is in motion, low on charge, in use, thermally constrained, or in a state where an interruption would be damaging.

The device is the only party that knows, which means the precondition check must be on the device and it must be able to say no.

Why it matters

The consequences of an unsafe update on a physical device are not recoverable remotely. A failed update on a vehicle is not a rollback — it is a recovery vehicle, physically inaccessible, in a customer's possession, and possibly unable to receive a corrective update at all.

A server-authoritative model puts the decision where the information is not, which is the general form of the mistake.

Implementation patterns

• Preconditions evaluated locally: charge level, motion state, in-use state, thermal state, available storage, time since last successful boot.
• The device reports the refusal with its reason, so a cohort that is systematically refusing is visible rather than appearing as a stalled rollout.
• An A/B partition scheme — write to the inactive partition, verify, activate on next start — so a boot failure falls back automatically with no network and no human involvement.
• Cryptographic verification before installation, so a corrupted or substituted image is not applied.
• Resumable download, since an intermittent metered connection will interrupt it and restarting from zero is unacceptable.
• A recovery path independent of the primary update mechanism, since the thing that broke may be the thing you would use to fix it.
• Staged rollout with halt on device-reported health, not on install success — a device that installed and is behaving badly reports success to a naive system.

Industry example

Connected-vehicle platforms such as Ather ship firmware to units that are in customers' hands and frequently in motion. The staging discipline — internal fleet, small cohort, progressive expansion, with a soak long enough for battery, thermal and usage-pattern effects to appear — is what prevents the failure mode that ends companies, and the soak is the part compressed under pressure.

Failure scenarios

• Server-decided update timing, applied while the device is in use or in motion.
• No A/B partitions, so a failed update is a bricked device.
• Halt conditions on install success, blind to post-update health.
• A recovery path depending on the broken component.
• Refusals invisible, so a systematically refusing cohort looks like a stalled rollout.

Trade-offs

Device-side refusal means the rollout is slower and less predictable — a cohort may take days rather than hours because devices are waiting for suitable conditions, and a fleet that is heavily used may lag substantially.

That unpredictability is the correct trade against the alternative, and the mitigation is visibility: a rollout dashboard showing what proportion is pending, applied, refused and why, so slow progress is understood rather than being an unexplained delay that invites overriding the safety.

Interview question

"Your update server instructs ten thousand vehicles to install tonight. Three thousand are in motion at the scheduled time. Describe what happens, and tell me who decided."