Device identity and capabilities are tightly coupled in DeviceCapabilitiesManifest

[singhmj-1]

Description

The current DeviceCapabilitiesManifest schema forces static device identity information to live within the same document as dynamic hardware and runtime capability states. This creates three critical technical bottlenecks:

1. Coupled Lifecycles: Static fields (id, vendor, modelNumber, serialNumber) never change post-onboarding, while capability fields (cpu, memory, storage, networks) change frequently. Sending them together forces the system to payload immutable data on every state update.
2. Closed Enumerations: Complex subsystems like peripherals and interfaces are modeled using flat, closed lists. They cannot express granular, structured states such as GPU VRAM, device paths, interface baud rates, or allocation statuses.
3. Special-Cased Base Compute: Fields like cpu, memory, and storage are treated as scalar root properties instead of standardized capabilities. There is no uniform mechanism to extend their schemas or track their independent allocation states.

Motivation

We need to refactor the data model to decouple device identification from resource state reporting. The motivation behind this structural shift is to:

• Optimize Telemetry Pipelines: Enable edge nodes to post lightweight, highly frequent capability updates without redundant identity overhead.
• Enable Granular Control: Allow individual subsystems (like storage or a specific network interface) to update independently without triggering a full manifest rewrite.
• Future-Proof Extensibility: Transition to an open, structured architecture where base compute components and specialized peripherals use the same standardized capability framework.

Proposed Solution (optional)

No response