Bundles & compatibility
A heterogeneous fleet is the normal case: different system-on-chips, accelerators, runtime versions, and operating-system lineages, all in service at once. The platform is built so that an update targets a device's capabilities, not a single golden image - and so that a payload which does not fit a device is caught before it is sent, not after.
Compatibility metadata
The compatibility story starts on the artifact. A model artifact's manifest declares the hardware profile it is built for - for example a specific Jetson class
- alongside its framework and input specification. That metadata is what lets the platform reason about fit: a model compiled for one accelerator profile has no business landing on a device that cannot run it.
Because devices report their hardware profile when they enrol, fit is a comparison between what the artifact declares and what the device actually is. See Artifact kinds for what each manifest carries and Enroll a device for how a device's profile is established.
Targeting by capability
Rollouts are aimed at a target - a device group - and shipped with a health probe and a strategy. The design intent throughout is capability-based targeting: you describe the class of device an update is for, and the platform resolves that to the matching devices. This is what keeps a single rollout safe across mixed hardware instead of forcing one image per device type.
What a bundle is
A bundle is the unit you test and roll out: a versioned set of artifacts that belong together, with the compatibility constraints that say how they fit - for example, a model that requires a given runtime version and a particular hardware profile. Grouping artifacts this way is what makes pre-flight testing meaningful: you validate the set as a whole, then ship the set as a whole.
Direction
We are honest about what is shipped versus where this is going. Today, compatibility is expressed per artifact through manifest metadata, and rollouts ship a chosen artifact version to a target group with a health probe and automatic rollback.
On the roadmap:
- Bundle objects - first-class versioned sets of artifacts with declared compatibility constraints, as the thing you roll out.
- A compatibility solver - an explicit pre-rollout gate that refuses a rollout whose bundle constraints do not match a target device's hardware and runtime profile, rather than relying on the manifest as advisory metadata.
- Pre-flight testing of bundles against emulated and lab devices before any real fleet sees them.
When these land they will follow the same rule as everything else: signed, audited, and verified on the device before anything is applied - never a discount on trust.