Open Autonomous Intelligence Initiative

Advocates for Open AI Models

OAII Base Model — Device v0.1

Depends on: OAII Base Model — Common Types v0.2; OAII Base Model — Sensor v0.2; OAII Base Model — Signal v0.2

1. Purpose

The Device object represents a physical or virtual computing substrate that hosts Sensors and performs local processing. 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

A Device is an abstract execution and containment unit that:

  • 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.

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
  • Cloud‑native control

4. Core Responsibilities

The Device object:

  • Hosts Sensors and manages their lifecycle;
  • Provides execution resources for local processing;
  • Manages power, connectivity, and failure modes;
  • Exposes capabilities without leaking internal state unnecessarily.

5. Required Attributes

A conforming Device MUST expose the following attributes using shared types from Common Types v0.1.

5.1 Identity and Context

  • device_id : DeviceId

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, 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)

7. Methods

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

  • A single Device may participate in multiple Events
  • Devices should be replaceable without invalidating Event semantics.

Status: Draft v0.2 (Normative Object Definition)

Leave a comment