Depends on: OAII Base Model — Common Types v0.1; OAII Base Model — World v0.1.1; OAII Base Model — Sensor v0.1; OAII Base Model — Signal v0.1
1. Purpose
The Device object represents a physical or virtual computing substrate that hosts Sensors, performs local processing, and participates in one or more Worlds. Devices are responsible for execution, containment, and lifecycle control, not interpretation.
In the OAII Base Model, Devices are the anchor point for edge‑primary autonomy, power management, and trust boundaries.
2. Definition (Normative)
A Device is an abstract execution and containment unit that:
- MUST operate within one or more Worlds;
- MUST host one or more Sensors;
- MAY host local processing for Signal summarization and Event recognition;
- MUST enforce privacy, access, and isolation boundaries;
- MUST NOT implicitly centralize data beyond its defined scope.
A Device is not an Agent, Policy authority, or World by itself.
3. Scope and Non‑Scope
In Scope:
- Physical edge devices (e.g., embedded systems, hubs)
- Virtual or containerized execution environments
- Sensor hosting and orchestration
- Local compute, storage, and power constraints
Out of Scope:
- Global coordination or orchestration
- Cross‑World arbitration
- Medical device certification
- Cloud‑native control planes
4. Core Responsibilities
The Device object:
- Hosts Sensors and manages their lifecycle;
- Provides execution resources for local processing;
- Enforces privacy and access policies at runtime;
- Manages power, connectivity, and failure modes;
- Exposes capabilities without leaking internal state unnecessarily.
5. Required Attributes (Abstract)
A conforming Device MUST expose the following attributes using shared types from Common Types v0.1.
5.1 Identity and Context
- device_id : DeviceId
- world_refs : WorldId[1..N]
5.2 Device Classification
- device_type : string
Describes the general class (e.g., edge hub, wearable, camera node, virtual node).
5.3 Capabilities
- capabilities : ParameterSet
Describes compute, memory, storage, accelerator availability, and supported modalities.
5.4 Privacy and Access
- privacy_class : PrivacyClass
- access_class : AccessClass
6. Hosted Objects
A Device MUST explicitly enumerate hosted objects:
- sensors : SensorId[1..N]
- signal_processors : MechanismId[0..N] (optional)
- event_recognizers : MechanismId[0..N] (optional)
Hosted mechanisms MUST be explicitly declared; implicit behavior is not permitted.
7. Methods (Normative, Abstract)
To standardize behavior, a conforming Device SHOULD support the following abstract methods:
7.1 register_sensor
- method_params : ParameterSet (sensor metadata)
- method_result : ResultSet
7.2 unregister_sensor
- method_params : ParameterSet (sensor_id)
- method_result : ResultSet
7.3 report_capabilities
- method_params : ParameterSet (optional filters)
- method_result : ResultSet (capability description)
7.4 enforce_privacy_policy
- method_params : ParameterSet (policy reference)
- method_result : ResultSet
8. Edge‑Primary Constraints
In Edge‑primary systems, Devices:
- MUST function under intermittent or absent connectivity;
- SHOULD prioritize local processing over data export;
- MUST support bounded storage and data retention;
- MAY degrade gracefully by disabling non‑essential Sensors or processing.
9. Failure and Degradation Modes
Device degradation may include:
- power loss or throttling
- connectivity loss
- partial hardware failure
- thermal or resource exhaustion
Devices MUST surface degradation explicitly and avoid silent data loss.
10. Notes for Implementers (Non‑Normative)
- A single Device may participate in multiple Worlds (e.g., physical home world and maintenance world).
- Devices should be replaceable without invalidating World or Event semantics.
- Containerization or sandboxing is encouraged but not required.
- Devices define the trust boundary for Sensors and Signals in edge deployments.
Status: Draft v0.1 (Normative Object Definition)

Leave a comment