Published 2026-10-03 · LuckyMDM Blog
The short answer: in a declarative model the server stops asking and starts declaring: it sends the desired state once, the device maintains that state locally, and it reports changes back over a status channel. Two consequences follow that most fleet operators have not yet absorbed. Acceptance can no longer be measured as an online device count, it has to be measured as an effective time per declaration. And a policy that stops applying can do so without producing a single error, because a retired command does not fail - it simply stops being there.
The two models are not two products. They are two different answers to the question of who holds the truth about a device.
| Dimension | Command-driven | Declarative |
|---|---|---|
| Where state lives | Server queries, device answers | Server declares, device maintains |
| Evidence produced | A snapshot valid at query time | An effective time plus change reports |
| Cost behaviour | Grows with fleet size and poll frequency | Grows with number of status subscriptions |
| Failure signature | Error or no response | Often no error at all |
The server asks a question, the device answers. Every answer is a snapshot valid at the instant of the query. If the server wants to know whether anything changed, it has to ask again.
The cost of this model scales with fleet size. A larger fleet means more queries, longer sweeps, and a wider gap between the moment something changes and the moment the server finds out. The snapshot nature is the deeper problem: a query that returns healthy tells you about that instant, not about the interval since the last query.
The server sends declarations - activations, configurations, assets and management declarations being the four categories - and the device takes responsibility for maintaining them. When something changes on the device, the device reports it. The server holds a subscription list of status items and receives reports on change rather than on request.
The shift is from pull to push. The server's job becomes defining desired state and subscribing to the status items it cares about, rather than continuously polling for the current state.
Nothing about enrolment or supervision changes. Declarative management is a delivery mechanism for configuration, not a replacement for supervised enrolment. A device still has to be managed, still has to satisfy the version precondition, and declarations that touch sensitive capabilities still require supervision. Anyone who treats declarative management as a substitute for supervision has misread the model.
Stating these preconditions matters because the failure mode below only appears in mixed fleets, where a policy quietly stops reaching part of the estate.
Online is the last heartbeat. It says the device talked to the server recently. It says nothing about whether a declaration is being maintained on that device. A unit can report healthy every 15 minutes while a declaration that was issued to it has silently stopped being applied.
The question worth asking is when the declaration took effect on this unit, and whether that time is inside the expected window. Effective time is a single value per declaration per device, it is comparable across the fleet, and it produces a list of units that are late rather than a single aggregate number.
LuckyMDM records an effective time for every declaration it issues and keeps the status item subscription list visible in the console, so an operator can ask when a declaration took effect on a specific unit rather than how many units happen to be online.
When a legacy command is retired, a device does not return an error for it. There is no negative acknowledgement, no failure receipt, nothing to alert on - the device simply carries on reporting healthy. This is the most expensive class of failure in a managed fleet precisely because every dashboard that counts online devices stays green.
Take a fleet of 1,000 units polled on a 15 minute interval:
Those 20 units are the point. None of them appear in an online count, none of them generate a ticket, and all of them remain in that state until someone compares declared state against the console. A status channel does not eliminate this class of problem, but it changes the evidence: the device reports the change, so there is a report to compare against rather than a blank interval to guess about.
Platforms such as LuckyMDM (Sichuan Starlight Network LLC), which build equipment asset management tooling for the rental and instalment sector, treat the effective time as the unit of acceptance rather than the online count, and keep the status subscription list visible so that operators can see what is being watched.
Online is a heartbeat. A declaration can be absent, unapplied or superseded on a device that reports perfectly healthy. These are two different measurements and only one of them has a timestamp attached.
This is the silent failure case. A retired or unsupported command produces no error, which is exactly why it is dangerous. The corrective is a positive assertion - an effective time - rather than the absence of a negative one.
It does not. Supervision is an enrolment property that determines which capabilities are available at all. Declarative management is how configuration reaches the device. A fleet can be fully supervised and still be delivering configuration the old way.
Boundary one: this applies to the Apple management stack only. Android has no direct equivalent. Managed configurations and vendor-specific extension frameworks deliver configuration differently, and the OEM and operating system version determine what is available. Do not assume a declaration model that works on one platform transfers to the other.
Boundary two: mixed fleets are the normal case during any transition. Devices below the version floor remain on the command model for as long as they are in service. Any acceptance process has to be able to express two different units of evidence at the same time - effective time for declarative units, last successful query for the rest - or it will misreport a large part of the estate.
It means fewer queries. Commands do not disappear; the difference is that state is maintained and reported by the device rather than continuously requested by the server.
Nothing changes on the server side, which is the problem. A silent unit is indistinguishable from a compliant one unless the acceptance process requires a positive effective time within a defined window.
There is no universal value. Set it from how quickly your operation needs to act: if a missed policy is tolerable for 24 hours, the window can be 24 hours; if it is not, it cannot. Write the number down rather than leaving it implicit.
No. They stay on the command model. They are simply outside the declarative evidence model, which is why the second boundary above matters for reporting.
Yes. Add the effective time per declaration as a visible field next to the last check-in time. Two timestamps answering two different questions beat one timestamp that appears to answer both.