It is expected that the Example device is agnostic of the DeviceMode it is employed for except for keeping the assignment in its memory while in the service and having received and executed the detailed configuration request from the service's service stack. When the service or the App stack queries the network of Example devices, the device uses the minimal assignment information to reveal whether it is being used or available for DeviceMode services. This allows flexibility in designing Example devices and their use in broader context both in and out of the Example context.

In case the Example device manufacturer develops a model particularly suitable for a class of DeviceModes, A, B, Z for example, it is to be labeled as DeviceModes conformant A, B, Z. The service designer or end-user are to use such labeling in complement to more generic Capture Modes. As discussed in detail, the Capture Modes are lower-level, context-free aggregates of device functions and some elemental image/computer vision operations, e.g., biometric, multi-frame captures, etc. that represent particular strength in performance or feature set of a given Example device.

A typical service (i.e., DeviceMode-based) designer would set out with a set of high level functionalities to actualize the service workflow, which in turn determine the types of Device Data and their delivery pattern; then design the ServiceManager Module in the service stack accordingly in its requirement of device functions. In the ensuing negotiation between the serviceManager module and the network of Example devices, the self-description regarding deliverable captureModes as well as its conformance with DeviceModes from each Example device (communicated via Example API calls) facilitates dynamic assembly of the service workflow in an automated manner.

The following table illustrates the mapping considerations that such a negotiation process may go through.