If you are responsible for endpoint operations, the next caller to your management plane may be a person, a build job or a model. That changes the job: automating a person's steps is no longer enough. We built Smplify so non-human callers can act without moving authority, execution or the record outside the platform.

Reading Plate 000

Plate 000 maps the control boundary an endpoint team needs once callers are no longer exclusively human: what can be called, what governs the call and which devices the plane can reach.

The filled dot at the centre is the control plane. Everything radiates from it because everything goes through it.

Three wedges divide the dial, marked I, II and III on the drawing and named in the row beneath it. SECT I, HEADLESS, five arcs, the surfaces you can call. SECT II, GOVERNED, six arcs, the controls that decide whether a call proceeds. SECT III, PLATFORMS, three arcs, the systems the plane reaches. Each arc carries its number at the far end of its sweep, counted outward from the hub, so a wedge's numbers sit beside the next channel round rather than beside its own.

Three channels run outward from the hub, narrowing as they go, crossing the telemetry ring and ending in an arrowhead: CALL, GOVERN, REACH. They point outward because the plane acts on the world rather than waiting to be visited.

Partway along each channel the line breaks, and one or two heavy bars lie across the gap. That is a gate, labelled once so the mark has a name. The channel resumes on the far side, so a gate is something a change passes through rather than something it stops at. It is drawn inside every channel because governance belongs to the plane, not to one way of entering it. The number of bars is the tier, and the second caption names it so the count is not left to guesswork.

The ring of fine ticks is telemetry, continuous by design. The small dial outside the instrument, tethered by a bridge, is the reader: whatever consumes the stream once it has left. It sits outside the boundary because the plane does not own it, and the arrow on the bridge points away from the plane, because the plane emits and does not decide. Its centre is drawn open where the hub is filled. One of them is a source. The other is not.

The key

How to read the drawing:

• Filled centre dot and rings. The control plane. The one source everything leaves from.
• Wedge. One theme. Its label and count print below the drawing.
• Arc. One subsystem or surface, numbered by its position in the register. The heavy dot is where it meets the plane.
• Solid arc / dashed arc. Running and audited to the standard of this plate / built and running, not yet audited to that standard.
• Channel. A path a change travels along, running outward from the plane. The arrowhead is the direction of travel.
• Break in a channel, with bars across it. A gate. One solid bar is a single approval, two is two-person; a dashed bar is notify and a filled block is deny. The path continues on the far side.
• Tick ring. Telemetry, every eighth tick heavier the way a dial scale is. The stream does not stop.
• Rim band, and the triangle at twelve. Morse. The triangle is where a decoder starts, reading clockwise.
• Outer dial, open centre, bridge with an arrow. The reader. Outside the plane, pointed at, never asked.

The register

SECT I · HEADLESS

1. The API across every managed surface
2. Tenant API keys, which also enrol devices
3. Signed outbound webhooks
4. Command line and policy as code
5. The agent surface

SECT II · GOVERNED

1. Approval Gates on the execution path
2. Privilege-grade roles you compose yourself
3. Partner to customer hierarchy
4. Audit log
5. Break-glass tenant recovery
6. Audit egress in the OCSF schema

SECT III · PLATFORMS

1. Apple, across macOS, iOS, iPadOS, visionOS, tvOS and watchOS
2. Windows
3. Linux

What the rim reads

The heavy broken band around the edge is Morse. On this plate it reads NO CONSOLE.

NO CONSOLE does not mean no interface. It means no console required. The portal is one client among several, and nothing in the register above depends on a person having opened it.

Which rung this is

Device management has moved through four generations. Commands came first: install this, run that, wipe the other. Policies raised the abstraction to desired configuration. Declarative intent raised it again to desired state per device. The fourth generation is outcomes across a fleet, and it differs in kind from the three before it because it is the first designed for a caller that may not be a person.

For the endpoint team, the fourth generation changes the unit of work. The question moves from which command to issue toward which outcome to establish, which callers may pursue it and where human judgment must remain.

Smplify is built for that fourth generation. A human, script, build job or model can ask the plane to act. The caller may change; the authority it carries, the gate it meets and the record it leaves do not.

Every surface is a call before it is a screen

SECT I, arcs 1 to 5. The console is a client, not the product.

Every managed surface in Smplify lands on the API first. The console calls the same endpoints you can call, with no private channel behind it. New capability lands on the API and the console picks it up from there. What differs between callers is authorization, not reachability.

That is the difference between an API and an API tier. A tier is what remains after the interface has taken what it needs, which is why it is always the destructive actions and the bulk changes that turn out to be missing from it.

The test is cheap. Take the last five changes your team made to the fleet and count how many could have been made with a token, a terminal and no browser. The ones that fall out are usually the ones with consequences.

Around those five arcs sit the ordinary shapes of automated work. A key that enrols a device is a key an imaging pipeline can hold. A signed webhook is how a directory change, or policy drift on a Linux host, reaches a system that was not watching for it. A policy in a file can live in Git and be reviewed in a pull request before it applies. When CI, the CLI or a person applies it, the resulting call still meets the platform gate. An agent surface follows the same rule: the same plane, the same gate, the same record.

A credential that can request and cannot approve

SECT II, arcs 2 and 3. Authority is a property of the credential, not of the person holding it.

Roles are composed from a fixed catalogue of privileges, and reading and changing are separate privileges rather than two settings on one. So a role can hold the privilege to request an action and not hold the privilege to approve it, and the privilege check happens where the action executes, not in the client that asked for it.

The separation is literal. POST /api/v1/devices/lock requires DEVICE_COMMAND. The approver pool is resolved from a different privilege, DEVICE_COMMAND_APPROVE. A custom role can hold the first without the second, so possession of a credential can be enough to ask and still not be enough to act.

That is the whole trick behind unattended offboarding. Somebody leaves on a Tuesday, HR marks the record, and the job that runs carries a credential whose role can request a device lock and cannot approve one. It fires, and the lock does not happen yet. Nothing about that arrangement depends on the job being well written, which is what makes it worth relying on.

The hierarchy is the same idea one level up. If your team administers more than one customer, scope travels with the credential rather than with the page somebody happens to have open.

The gate belongs to the platform, not the pipeline

SECT II, arc 1. A gate enforced by Git governs only changes that arrive through Git.

Approval Gates sit on the execution path inside the platform. You set the tier per class of action, from five: automatic, notify, approve, two-person, deny.

The tier starts on the action rather than on the person, and from there it only tightens. An agent or connector identity raises it by a step. So does a blast radius above fifty devices, a compliance-bound tenant, or a call outside business hours. It never relaxes because of who is asking, and it holds the call inside the platform rather than telling somebody about it afterwards.

A pull request is a useful authoring control. It can show a diff, collect reviewers and decide whether a file may merge. It cannot govern a change made through the portal, a direct API call, an MCP tool or an agent, because none of those callers has to pass through that repository. Put approval in Git and you have governed one route into the product. The other doors remain different doors.

Smplify makes the Approval Gate a platform primitive. A device-changing request may begin in the portal, the CLI, an API client, an MCP tool, a Git-driven CI job or an AI agent. Once it reaches the plane, the entry point stops mattering. The platform evaluates the action class, principal type, blast radius and operating context, then applies the same tier model. If approval is required, every caller receives the same pending state and enters the same approval workflow before anything is dispatched to a device.

When a device-lock call resolves to approve, the endpoint returns 202 Accepted instead of dispatching the command. The caller receives the state of the gate, not a fiction that the device changed:

{
  "requestId": "<request-id>",
  "riskTier": "APPROVE",
  "status": "PENDING",
  "quorumRequired": 1,
  "approvalsCount": 0
}

The same receipt carries a quorum of two at the two-person tier. The request can be polled by its identifier, approved or denied, and only an approved request is replayed onto the execution path.

That is the difference between a platform primitive and a workflow attached to one client. Governance at the execution boundary cannot be routed around by changing tools. Git remains valuable for versioning and review, but it is a caller of the control plane, not the control plane's source of authority.

A gate is not the brake on unattended operation. It is what makes unattended operation possible. You can hand a credential to something that runs without supervision because the platform, not the caller, decides what happens next.

One policy object, three platform families

SECT III, arcs 1 to 3. You describe what should be true, and the plane carries it.

Apple, Windows and Linux each speak their own management protocol, and none of them agrees with the others about what a policy is. Within Apple, that support spans macOS, iOS, iPadOS, visionOS, tvOS and watchOS, while preserving the compatibility rules of each operating system. One policy object carries payloads for more than one platform family, assigned by the same tags and run through the same gate, so a mixed fleet is one object to review rather than three. Above that sits a small set of named cross-platform intents, camera off and passcode required, that expand into the payloads each platform uses to express them.

The expansion is concrete. disable_camera becomes allowCamera: false in Apple's application-access profile and allowCamera: 0 in the Windows Camera Policy CSP. require_passcode becomes an Apple passcode profile and a Windows DeviceLock policy, including the inverted Windows value where devicePasswordEnabled: 0 means a password is required. The intent stays readable; the compiled payload is allowed to be platform-shaped.

The third wedge deliberately draws one arc per platform because this plate maps reach rather than protocol depth. Counted by the same standard, Apple has sixteen capabilities with their own administrative surface, Windows ten and Linux eight.

The record answers why, not just when

SECT II, arcs 4 to 6. A session is not a reason.

Approver decisions are written to the audit log, denials included. A record carries the actor, the acting and target tenant, the privilege, the action, the target and the time. The tier that applied and the devices in scope ride on the approval request the decision resolves, so the two together reconstruct the event. That is a different artifact from a console session log, which can tell you a device was wiped in March and cannot tell you why anyone thought it should be.

Denials matter more than approvals here, and they are the part most systems throw away. An approval tells you a thing happened. A denial tells you a thing was attempted, by which credential, against which device, and that is the record you want in front of you when the question is whether something has been probing the edges of what it is allowed to do.

A tenant that has locked itself out has a recovery path of its own, run by a platform operator with a second operator approving inside fifteen minutes, and the recovery is itself an audited event rather than a favour done off the record.

Security-relevant events also leave the plane projected into OCSF 1.3.0, the open event schema security tools already parse, so the evidence is in a documented shape rather than a private one. Authentication, administrative changes, data modifications and high-severity events leave the plane. Routine reads such as DEVICE_VIEW stay in the audit log by default rather than flooding the stream; sensitive reads and deployments configured to stream reads can still include them.

Good governance should look unbalanced

The goal is not to maximize approvals. It is to make unattended work safe. Five tiers exist so that almost nothing has to wait; your job is to decide which short list does.

Good tiering is deliberately unbalanced: most actions at automatic, a narrow band at notify so somebody learns they happened, and a very short list at two-person for fleet-wide wipe, tenant deletion and anything that removes the ability to undo. A long approve list is not stronger governance. It is undecided policy turned into a queue.

A safe action repeated fast is a different risk

The next generation introduces a kind of risk that action-based controls were not built to see: persistence. At the authority layer, a caller that is a model looks like a caller that is a person unless the platform has decided otherwise. A person gets tired and stops. A retry loop does not.

So the grading that matters reads the caller and not only the action. That is why an agent or connector identity already tightens the tier by a step, and why a blast radius above fifty devices does the same. The next boundary is rate. Consider four thousand single-device locks issued in ninety seconds: each call may be unremarkable on its own, but together they are a different event from the same calls issued one an hour.

For an endpoint team, the valuable version of an agent is not one that performs one task well. It is an operating model in which an administrator stops writing every step, states what should be true of the fleet, and lets agents work out how to get there and keep it there. Enrolment, drift, an out-of-date version: stated once, then pursued continuously instead of re-issued every week.

This does not require trusting a swarm. It requires making authority explicit, which is why we built the gate first. The gate keeps a human in the loop without placing one in front of every action: you decide once which classes of work a machine may complete and which ones must come back to you. Set that boundary well and most of the work never reaches you.

This is why governance has to precede autonomy. The declaration layer is where fleet operations are going. The gate is what makes it safe to get there.

When something automated does the wrong thing overnight, the question you get asked is what happened. You can answer it without opening a console: what was asked and by which credential, what the gate decided including the denials, and what changed on the device afterwards. Three separate records rather than one session log, which is the difference between reconstructing an event and describing it.

That is the next generation we are building: Agentic Device Management. The reasoning may be probabilistic. The authority, execution, verification and record are not.