Documentation

Appearance

Provision and claim ​

Provisioning establishes device identity and its initial organisation and class context. Claiming is a separate handoff workflow for supported OEM inventory.

Provision securely ​

An organisation provisioning key authorises agent provisioning. The organisation can define a default device class, and supported install flows can select an explicit class.

  1. Create or select an organisation provisioning key.
  2. Set the intended default class or include the explicit supported class selection.
  3. Run preflight against the target operating system and network.
  4. Provision one staging device and verify its organisation, class, architecture, and first connection.
  5. Add the key to a controlled manufacturing or image-build process.

Treat provisioning keys as secrets. Do not commit them to source control, bake a reusable plaintext key into a customer-readable image, print them in support logs, or reuse them across untrusted manufacturers. Rotate after exposure or supplier change and validate the replacement before revoking the old path.

Use organisation keys with explicit or default class assignment. Migrate any class-scoped keys into this model.

Create and redeem claim bundles ​

Where claim bundles are enabled, an OEM can group eligible inventory for customer redemption.

  1. Select the intended device class and eligible devices.
  2. Create the smallest bundle that matches the shipment.
  3. Record the bundle against the shipment without exposing redemption material publicly.
  4. Have the intended customer redeem through the supported claim flow.
  5. Verify ownership, organisation, class, licensing, warranty, and customer or site context after redemption.

Do not treat bundle creation as proof of customer ownership. Redemption is the transition that must be verified.

Licensing, warranty, and returns ​

Licensing and warranty are independent records. When those modules are enabled, check the class license policy, organisation license state, bundle redemption history, warranty plan and dates, and RMA status separately.

An RMA request can be pending, approved, or denied and carries update history. Confirm warranty eligibility and device identity before changing status. Keep replacement identifiers and customer communication in the supported record rather than informal tags.