A mixed fleet should not force an endpoint team to operate three management systems. Apple, Windows and Linux each have native protocols, policy models and status semantics. Those differences matter at the device, but they should not become three authoring languages and three separate versions of operational truth.

Plate 001 maps the fifteen mechanisms that let an endpoint team declare one outcome, preserve each platform's native implementation and verify the resulting state through one governed operating model.

One outcome becomes three native changes

The abstraction belongs above the platform, not in place of it.

Plate 001 is built around three verbs. DECLARE is the contract an operator authors. COMPILE is the platform work Smplify performs. VERIFY is the evidence that comes back after the policy reaches a device. The three channels leave the control plane, cross the same gate grammar introduced in Plate 000 and end at the instrument edge.

The arcs are not platform payload counts. They are the mechanisms required to make one operating model credible. A solid line marks an operating production path. A dashed line marks a mechanism outside the plate's current production claim. Implementation alone is not enough to turn an arc solid; the complete path must be operating.

The rim carries a second claim in Morse. The start mark is at twelve and the ring reads clockwise. The numbered version here lets each line be matched to the register.

The register names fifteen mechanisms

SECT I · DECLARE

1. Discoverable canonical intent vocabulary
2. Name and alias canonicalization
3. Typed intent parameters
4. Schema validation before compilation
5. Preview by default; explicit commit to write

SECT II · COMPILE

1. Native compiler path for each platform family
2. Apple native configuration-profile compilation
3. Windows native Policy CSP compilation
4. Linux declarative payload and signed-bundle compilation
5. One governed policy object and tag assignment

SECT III · VERIFY

1. Per-platform applicability summary
2. FULL, PARTIAL and UNSUPPORTED coverage with reasons
3. Normalized policy lifecycle with native status retained
4. Shared cross-platform drift evidence
5. Platform-specific report or remediation decision with loop protection

Mixed-fleet intent is the next operating layer

Device management has moved through four generations. Commands say what to do now. Policies raise the abstraction to configuration. Declarative management states what should remain true on one platform. For an endpoint team, the fourth generation is an outcome operating across a mixed fleet, with its authority, native implementation and evidence kept together. Plate 000 established who may call that control plane and where the gate sits. Plate 001 shows the object that travels through it.

The declaration is a contract, not a shortcut

An intent must be precise enough to reject an ambiguous request.

The distinction becomes concrete with intents such as disable_camera and require_passcode. A payload describes a platform object. An intent promises an outcome, and that promise is useful when every parameter has a defined meaning, every applicable platform has an implementation and every limitation can be reported before a device changes.

The authoring path makes that contract visible:

smplify intents list

smplify intents apply \
  --name "Workforce baseline" \
  --intent require_passcode=minLength:10,numericOnly:true \
  --tags workforce

The second command is a preview. It discovers the canonical intent, parses minLength as a number and numericOnly as a boolean, asks the server to compile the request and prints what each platform will receive. Nothing is written until the caller adds --commit. A quoted value with the wrong type is rejected rather than quietly coerced into something the operator did not ask for.

That preview-first model matters because an intent can expand. The operator writes one outcome, but the review surface must show the native objects, coverage and affected tags before approval. Concision at authoring time cannot mean opacity at review time.

Smplify accepts aliases at the authoring edge, then resolves every request to a canonical name before validation. The policy record, audit trail and native compilers therefore refer to one stable identifier. Endpoint teams can make the vocabulary easier to use without creating several internal names for the same desired state.

The result is still one governed policy object. It is assigned through the same tag model and enters the same Approval Gate whether the request came from the portal, CLI, API, MCP, Git-driven automation or an agent. Intent changes what the caller has to describe. It does not create a route around governance.

Native compilation preserves platform truth

One operating model should not force three platforms into one payload shape.

Smplify does not emit a generic document and hope every device understands it. The canonical intent passes through a native compiler for each platform, which returns the objects that platform expects. For the endpoint team, another platform expands the same operating model; it does not add another authoring workflow.

disable_camera makes the distinction concrete. On Apple, the compiler emits the application-access restriction with allowCamera: false where that restriction is available. On Windows, it emits the Camera Policy CSP value the OMA-DM channel expects. On Linux, it emits the curated camera payload that enforces a V4L2 udev rule on supported devices. The declaration is shared. The implementation is not.

Apple support spans iOS, iPadOS, macOS, tvOS, visionOS and watchOS, but not every control applies to every operating system. Smplify preserves Apple's compatibility metadata so an intent applies only where the operating system and enrollment conditions support the resulting native payload.

Windows receives Policy CSP and DeviceLock objects through its own SyncML lifecycle. Linux receives a declarative payload that becomes a signed bundle for the enrolled agent. Each path keeps the protocol state needed to diagnose it. A common policy does not erase native status or turn protocol-specific failure into a generic red light.

Direct platform payloads remain important. An Apple-specific declaration, a Windows ADMX-backed setting or a Linux hardening control does not become less legitimate because it lacks a cross-platform equivalent. The unified policy can carry platform-shaped content alongside named intents, and the preview reports which parts are explicit and which platforms are not involved. The goal is one operating model, not a lowest-common-denominator catalog.

Coverage is part of the answer

Silence is not cross-platform support.

Many systems accept a broad request, emit what they understand and omit the rest. That makes the request look successful while transferring the most important question to the endpoint team: what did not happen? Smplify returns a platform summary with applicability, emitted payload identifiers and coverage for every platform involved.

The current coverage vocabulary is FULL, PARTIAL and UNSUPPORTED. disable_camera is FULL on supported V4L2 Linux devices and compiles to the native camera controls on Apple and Windows. require_passcode is FULL on Apple and Windows but PARTIAL on Linux. Linux can require the requested minimum length for future account password changes through pwquality and login.defs; it does not rewrite existing credentials, numericOnly does not describe a Linux account-password control, and unassignment cannot reconstruct values that existed before Smplify managed those keys.

That explanation appears beside PARTIAL in the plan. It is not hidden behind a second diagnostic request. An operator deciding whether a policy satisfies a requirement needs the reason before commit, not after an audit.

A short answer that cannot distinguish partial enforcement from complete enforcement is not a useful abstraction.

Coverage is part of the contract

The plan is intentionally more detailed than a single green checkmark. It keeps platform complexity where coverage is known instead of handing unresolved gaps to the endpoint team after deployment.

An endpoint leader should therefore judge an intent by more than its name. It is complete when its parameters, native mappings, applicability and evidence are defined together.

Linux belongs in the same sentence

Linux is a managed platform, not a script target attached to the end of a workflow.

Scripts are useful implementation tools, but a script alone does not create a policy contract. It does not state which inputs are valid, what files or services it owns, what should be removed on unassignment, how the artifact is signed, what state can be verified or how a failure appears beside Apple and Windows.

Smplify produces curated Linux payloads. The Smplify manager composes those payloads into a signed Ansible bundle, and the enrolled agent verifies the bundle before reconciliation. Managed keys are removed deliberately during unassignment rather than treating a successful process exit as proof that the policy disappeared.

Camera restriction and passcode requirements exercise different parts of that model. Camera restriction becomes a V4L2 device rule. Passcode intent becomes password-quality and login policy settings. The camera intent can be FULL on the supported hardware path. The passcode intent remains PARTIAL for the reasons the preview prints. Giving Linux equal architectural standing does not require giving it a false equivalence.

This is what makes Linux first-class in the operating model. It receives the same canonical request and must return the same kind of coverage answer while its payload and verification mechanics remain Linux-native. Endpoint teams can govern Linux alongside Apple and Windows without reducing it to scripts or pretending the implementations are identical.

Verification completes the declaration

Desired state without observed state is a dispatch record.

The third sector returns evidence to the control plane. Smplify normalizes lifecycle terms such as queued, dispatched, applied and failed while retaining the native status underneath. An endpoint team can read one fleet view without losing the Apple MDM acknowledgement, Windows CSP result or Linux reconciliation result needed for diagnosis.

Policy status answers whether the delivery path completed. Drift answers whether the resulting state still matches the declaration. Those are different questions, and they need different evidence.

Windows can read managed values back through Policy CSP and compare the observed value with the compiled policy. Apple Declarative Device Management reports status items and continues to own enforcement on the device. Linux carries an expectations contract in the signed bundle so a verifier can name the path, setting or service it was able to inspect. The shared drift surface records the platform, configuration, evidence and reconciliation state in one fleet query.

The correct remediation remains platform-specific. Windows can requeue the affected profile for the affected device. Linux can render and deliver a fresh signed bundle. On Apple, Smplify should not repeatedly send an identical declaration after the device has attempted to enforce it, because that turns a persistent failure into a loop. One drift event can therefore lead to different correct actions while keeping the operator-facing contract consistent.

Automatic remediation is opt-in. A tenant can keep the system in reporting mode, and loop protection leaves a repeatedly drifting configuration open for a person rather than applying forever. This is the same principle introduced by Approval Gates: automation should run inside an explicit authority boundary.

Verification coverage is another necessary signal. An empty drift list may mean nothing differs, or it may mean nothing could be checked. Linux reports what was verifiable separately from what drifted, and the same distinction belongs in the Apple and Windows views. No drift and verified state are not synonyms.

Compliance packs belong above the intent layer

A benchmark is a versioned set of outcomes, checks and exceptions, not a new policy language.

The macOS Security Compliance Project is valuable source material because it connects technical rules to frameworks such as NIST, CIS and DISA STIG and can generate native Apple artifacts. It also demonstrates why importing every benchmark row as an intent would be a mistake. Some rows express durable outcomes, some describe one macOS implementation, some are checks, and some require organizational evidence rather than a device setting.

For an endpoint team, a compliance pack belongs above the canonical vocabulary. A versioned pack selects intents with parameters, adds platform-specific controls where no durable cross-platform intent exists and carries evidence-only requirements separately. require_disk_encryption, for example, can be one outcome with FileVault, BitLocker and a Linux encryption control underneath. A requirement that applies to a supervised Apple device should remain explicitly Apple-specific rather than acquiring empty Windows and Linux mappings for the sake of symmetry.

That structure lets an administrator-authored baseline and a published compliance pack use the same compiler, Approval Gate, assignment model and verification loop. The difference is provenance. One begins with the operator's desired outcome. The other begins with a version-pinned framework mapping.

The applicability model must distinguish UNSUPPORTED, not applicable and evidence-only. A platform may understand an outcome but be unable to enforce it, may enforce it but be unable to verify it, or may have no corresponding concept. Treating those states as the same answer would make a compliance result look simpler while making it less trustworthy.

A shared vocabulary should remove work, not platform truth

Endpoint teams should be able to declare an outcome once without hiding how each platform enforces it.

An endpoint team should not have to translate the same requirement into an Apple configuration, a Windows CSP policy and Linux enforcement logic. Smplify's intent vocabulary gives that team one place to describe the outcome while preserving each platform's native implementation.

Every intent makes its parameters, platform coverage, enforcement behavior and verification evidence visible before a device changes. When an outcome differs by platform or operating-system family, the plan says so explicitly. Native catalogs remain available when a requirement has no meaningful cross-platform equivalent.

For the endpoint leader, the value is not a longer list of intent names. It is fewer policy languages to reconcile, fewer coverage gaps to discover after deployment and one governed path from declaration to verified state.

Payload breadth is the raw material. The operating model is the product.