This is Part 2 of a three-part series on the architectural shift to Declarative Device Management. Part 1 established the legacy MDM baseline: the server wakes the device, waits for check-in, interprets status, calculates drift, and queues the next command.

This article focuses exclusively on the internal mechanics of the Declarative Device Management model on macOS: Declarations, Configurations, Assets, Activations, and autonomous client-side enforcement. Part 3 covers the Status Channel and Delta Reporting.

From Command Executor to Desired-State Engine

Traditional MDM treats the endpoint primarily as a command executor. The server decides what needs to happen, sends a command, waits for status, and decides the next action.

Declarative Device Management changes that relationship.

With DDM, the MDM server gives the device structured declarations that describe the desired management state. The device then evaluates those declarations locally. The server is no longer responsible for calculating every small compliance decision during every check-in. Instead, the operating system receives a set of rules, resources, and activation conditions, then applies them as local state changes.

For a Windows administrator, this is closer to a client-side desired-state engine than a traditional MDM command queue. It has conceptual overlap with Group Policy processing, SCCM/MECM compliance settings, and PowerShell Desired State Configuration, but with one critical difference: the logic is part of Apple’s management framework rather than a separate enterprise agent bolted onto the OS.

The Mac does not need the server to repeatedly say, “Check this. Now apply that. Now check again.” The Mac can evaluate the declared state itself.

What a Declaration Is

A declaration is a JSON object that tells the device something about management intent.

Most declarations share a common outer shape:

{
  "Type": "com.apple.example.declaration-type",
  "Identifier": "com.example.unique.identifier",
  "ServerToken": "opaque-server-version-token",
  "Payload": {}
}

The outer fields tell the device what kind of declaration it is, how to identify it, and which server-side version it represents.

The Payload contains the actual declaration-specific data. That payload is different for each declaration type. A configuration declaration does not have the same payload shape as an activation declaration. An asset declaration does not have the same payload shape as either of those.

This is where DDM becomes more precise than “a JSON profile.” A declaration is not one universal object. It is a typed management object with a specific role.

The three declaration families that matter most for understanding the client-side architecture are:

• Configurations
• Assets
• Activations

Configurations: The Desired State

A Configuration describes what the device should apply.

This is the closest DDM concept to a configuration profile, a Group Policy setting, or an SCCM/MECM configuration item. The Configuration defines the desired state, but it does not necessarily decide when that desired state becomes active. That decision is handled by Activations.

One practical example is a legacy profile declaration. This allows DDM to reference an existing MDM-style configuration profile hosted by the MDM server.

{
  "Type": "com.apple.configuration.legacy",
  "Identifier": "com.admincrossover.configuration.loginwindow-baseline",
  "ServerToken": "loginwindow-baseline-v1",
  "Payload": {
    "ProfileURL": "https://mdm.example.com/ddm/profiles/loginwindow-baseline.mobileconfig"
  }
}

In this example, the Configuration says, “This profile is part of the desired management state.” The device knows where to retrieve the profile, and it knows which declaration identifier represents that configuration.

For a Windows administrator, this is similar to defining a GPO or configuration baseline, but not yet linking it to a site, domain, OU, collection, or filter. The Configuration defines the managed object. It does not, by itself, explain all of the conditions under which the object applies.

Assets: The Supporting Resources

An Asset is a resource that other declarations can use.

Assets are not the same as Configurations. A Configuration describes management state. An Asset describes data, credentials, identity material, or another supporting resource needed by the managed state.

A simple example is a data asset. The payload points to externally hosted data and can include metadata the device can validate, such as content type, size, or SHA-256 hash.

{
  "Type": "com.apple.asset.data",
  "Identifier": "com.admincrossover.asset.corporate-wallpaper",
  "ServerToken": "corporate-wallpaper-v1",
  "Payload": {
    "Reference": {
      "DataURL": "https://mdm.example.com/ddm/assets/corporate-wallpaper.png",
      "ContentType": "image/png",
      "Size": 184221,
      "Hash-SHA-256": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
    },
    "Authentication": {
      "Type": "MDM"
    }
  }
}

This does not mean the wallpaper is automatically applied merely because the Asset exists. The Asset is available to be consumed by a configuration that needs it.

For a Windows administrator, think of an Asset as closer to content in an MECM distribution point or a file referenced by a GPO preference. The asset is necessary, versioned, and validated, but it is not the policy decision by itself.

That separation is important. It allows the MDM server to update a resource without redefining every configuration that depends on it. It also allows the device to reason about which supporting resources belong to the active desired state.

Activations: The Local Applicability Logic

An Activation determines which Configurations are active.

This is the “when” and “under what conditions” layer. An Activation references one or more Configuration identifiers and can include a predicate. If the predicate evaluates to true, the referenced Configurations become active. If no predicate is present, the activation applies without an additional condition.

A simple Activation might look like this:

{
  "Type": "com.apple.activation.simple",
  "Identifier": "com.admincrossover.activation.standard-mac",
  "ServerToken": "standard-mac-v1",
  "Payload": {
    "StandardConfigurations": [
      "com.admincrossover.configuration.loginwindow-baseline"
    ],
    "Predicate": "@status(device.model.family) == 'Mac'"
  }
}

This declaration says, in effect:

When this device evaluates as a Mac,
activate the standard Mac configuration set.

Predicates use Apple predicate syntax and can reference DDM data such as status items by using extension terms like @status(...). Do not think of the predicate as JavaScript, PowerShell, or Jamf Smart Group syntax. It is an Apple predicate expression evaluated by the device as part of the declaration model.

For a Windows administrator, this is similar to the combination of GPO link, security filtering, WMI filtering, and collection targeting. The major architectural difference is where the evaluation happens. In legacy models, the server frequently calculates scope and tells the endpoint what to do next. In DDM, the endpoint receives the activation logic and evaluates it locally.

The MDM server still defines the desired management model. The Mac decides whether the local conditions match that model.

Predicate Reevaluation Timing

Predicates are not server-side polling jobs.

The macOS DDM client evaluates predicates when declarations are processed and when relevant local state used by the predicate changes. For example, if an Activation depends on a status item such as device model family, the device can evaluate that predicate from local status information. If the relevant local input changes, the client can reevaluate which Activations apply and apply or remove the referenced Configurations accordingly.

This is more responsive than waiting for the MDM server to recalculate scope during a later inventory cycle, but it should not be described as a constant busy-loop. Predicate behavior is tied to observable device state and declaration processing, not to an administrator-defined script schedule.

A useful mental model is:

Declaration received or changed
        ↓
Device parses Activation
        ↓
Device evaluates Predicate
        ↓
Activation becomes active or inactive
        ↓
Referenced Configurations are applied or removed as appropriate
        ↓
Relevant local state changes later
        ↓
Device reevaluates affected Activation logic

If a predicate references unsupported or unavailable state, the Activation may not evaluate as expected. For production use, validate predicate syntax and status item availability against Apple’s current DDM schema and the OS versions in scope.

How the macOS Client Evaluates Declarations

The DDM-capable management client on macOS receives declarations from the MDM service and stores the resulting desired-state model locally. Apple does not expose every internal implementation detail, but the mechanical behavior is straightforward:

1. The device receives a declaration manifest.
2. The device determines which declarations are new, changed, or removed.
3. The device retrieves needed declaration payloads.
4. The device parses each JSON declaration by type.
5. The device builds a local model of available Configurations, Assets, and Activations.
6. The device evaluates activation predicates.
7. The device applies active Configurations.
8. The device maintains that desired state as local conditions change.

The key change is that the client now has enough local context to make management decisions without waiting for the server to send a new imperative command for every transition.

Autonomous Enforcement

Autonomous enforcement does not mean the Mac ignores the MDM server. It means the Mac no longer needs the server to micromanage every step after the desired state has been declared.

Once declarations are present, the device can independently evaluate whether the current state matches the active desired state. If a condition changes, the device can re-evaluate the relevant Activations. If an active Configuration must be applied, the device can apply it as part of its local management behavior.

For example, assume the device has these declarations:

Configuration:
  com.admincrossover.configuration.loginwindow-baseline

Activation:
  com.admincrossover.activation.standard-mac
  Predicate: @status(device.model.family) == 'Mac'
  StandardConfigurations:
    - com.admincrossover.configuration.loginwindow-baseline

The server does not need to ask the same scoping question every time the device checks in. The device has the predicate. The device knows the configuration identifier. The device can evaluate whether the activation applies.

This is the architectural shift: the server defines the desired state, but the client performs the ongoing evaluation.

Why Configurations, Assets, and Activations Are Separate

The separation is not cosmetic. It is what makes the model scalable.

A Configuration can change without changing every Activation.

An Asset can be replaced or versioned without rewriting the entire management model.

An Activation can target a different condition without redefining the underlying configuration.

That gives the device a composable model:

Activation
  └── references Configuration
        └── may reference Asset

This model is cleaner than a server repeatedly calculating every device’s state and sending one command at a time. The device receives structured management intent and can maintain it locally.

What DDM Does Not Replace

DDM does not mean every management action becomes declarative overnight. Traditional MDM commands, vendor agents, scripts, and inventory mechanisms still matter. Some actions remain command-oriented, some are vendor-specific, and some administrative workflows still require the existing MDM protocol.

The architectural shift is narrower and more precise: when Apple exposes a management capability through DDM, the server can express desired state as declarations, and the device can evaluate more of that state locally.

For a Windows administrator, this distinction matters. DDM is not “run any arbitrary script as desired state.” It is a structured Apple management model with specific declaration types, payloads, assets, activations, predicates, and supported status items.

What This Means for Windows Administrators

The closest Windows comparison is not a single technology. It is a blend of several ideas:

• GPOs define desired configuration.
• WMI filters and security filtering define applicability.
• MECM collections define deployment targeting.
• Configuration baselines define compliance rules.
• DSC defines local desired-state enforcement.

DDM combines similar concepts into a client-side management model for Apple devices.

The MDM server still matters. It authors declarations, versions them, signs or protects the management relationship, and provides the payloads. But once the Mac has the declarations, the endpoint becomes more than a command recipient. It becomes an active participant in maintaining its own managed state.

Conclusion

Declarative Device Management moves Apple device management from a server-driven command loop toward a client-side desired-state model.

Configurations define what should exist. Assets provide supporting resources. Activations decide when configurations apply. The macOS management framework parses these declarations, evaluates them locally, and enforces the resulting desired state without requiring the server to issue a new command for every small decision.

That client-side autonomy is the architectural center of DDM. The server declares. The endpoint evaluates. The endpoint enforces.

Part 3 will cover how the device reports meaningful state changes back to the MDM server without returning to the legacy polling model.