Capability selectors
Real fleets are heterogeneous: an arm64 Jetson with a GPU, an x86 industrial PC, a small board with no accelerator at all. Capability selectors are the idea that you target a rollout by what a device can run, not by assuming every device is the same golden image. The raw material for that is the device facts each agent already reports.
The facts a selector can use
Every device reports a hardware profile on registration, detected from the running system rather than declared by hand. These are the dimensions a selector is built from:
| Dimension | Examples |
|---|---|
| Architecture | arm64, amd64 |
| SoC | nvidia-jetson-xavier-nx |
| Accelerators | nvidia-gpu, google-edgetpu |
| Memory / CPU | RAM bytes, core count |
| OS / kernel | OS pretty-name, kernel version |
| Tags | your own labels, e.g. site=plant-7, line=assembly-3 |
The hardware fields are observed facts the agent gathers; tags are labels you attach to carry your own grouping dimensions - site, line, environment, customer. Together they describe both what a device is and what role you've given it.
Why this matters for safety
Targeting by capability is a guardrail, not just convenience. An ONNX model built for a Jetson's GPU has no business landing on a board that lacks one; an arm64 artifact does not belong on an amd64 device. By matching a rollout to the devices that can actually run it, capability targeting keeps an incompatible artifact from ever reaching a device - failures you prevent are cheaper than rollbacks you trigger.
How targeting works
The device facts above are reported and stored for every device and visible per device. Identify the devices that match the required capabilities, build an explicit group from them, and review the resolved membership before publishing the signed release. The group snapshot is bound into the release authorization, so a later membership change requires a new authorization.