Open Autonomous Intelligence Initiative

Depends on: OAII Base Model — Common Types v0.1; OAII Base Model — World v0.1.1; OAII Base Model — Policy v0.1; OAII Base Model — Agent v0.1; OAII Base Model — Event v0.1.1

1. Purpose

The Interface object represents a controlled interaction surface through which Agents and systems communicate with humans or other systems. Interfaces enable assistance, notifications, consent, and configuration while enforcing Policy constraints and privacy boundaries.

---

2. Definition (Normative)

An Interface is an abstract interaction channel that:

• MUST support inputs and/or outputs between the system and a human or external system;
• MUST support confirmation flows when required;

---

3. Scope and Non‑Scope

In Scope:

• Voice, text, display, audio cues, lights, tactile signals
• Caregiver notifications and escalation channels
• Configuration and consent workflows
• System-to-system APIs for interoperability

Out of Scope:

• Hidden background data export
• Undocumented communication channels
• Surveillance-oriented streaming interfaces
• Legal or medical advisories

---

4. Core Responsibilities

The Interface object:

• Delivers outputs (messages, prompts, notifications) from Agents;
• Receives inputs (confirmations, preferences, commands) from humans/systems;
• Supports accountability via logging of significant interactions;

---

5. Required Attributes (Abstract)

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

5.1 Identity and Context

• interface_id : InterfaceId

5.2 Interface Classification

• interface_type : string
  Examples: voice, text, display, audible_alert, light_signal, caregiver_api, local_ui.

5.3 Capabilities

• capabilities : ParameterSet
  Supported modalities, languages, accessibility features, confirmation support.

5.4 Audience and Routing

• audience_descriptor : ParameterSet
  Describes intended recipients (resident, caregiver, maintenance, emergency contact) and routing rules.

5.5 Privacy and Access

• privacy_class : PrivacyClass
• access_class : AccessClass

5.6 Operating State

• interface_state : string (see Section 6)

---

6. Interface States (Normative)

An Interface MUST support at least the following states:

• AVAILABLE: can send/receive
• UNAVAILABLE: temporarily offline
• DEGRADED: reduced capability (e.g., no audio)
• SUSPENDED: intentionally disabled

State transitions that affect safety or user experience MUST be logged.

---

7. Interface Mechanism Bundle

Interface rendering, routing, and confirmation handling MUST be represented using a mechanism bundle:

• interface_mechanism_id : MechanismId
• interface_mechanism_params : ParameterSet
• interface_mechanism_result : ResultSet (optional)

This bundle documents how the Interface behaves without mandating a UI framework or protocol.

---

8. Relationships to Other Objects

• Agents emit outputs through Interfaces
• Events may trigger notifications
• Logs record interactions and confirmations

---

9. Methods (Normative, Abstract)

To standardize behavior, a conforming Interface SHOULD support the following abstract methods:

9.1 present_output

Presents an Agent output to an audience.

• method_params : ParameterSet (message content, object refs, urgency)
• method_result : ResultSet

Requirements:

• MUST enforce applicable Policies (privacy, quiet hours, routing, redaction).

9.2 request_confirmation

Requests explicit confirmation when required by Policy.

• method_params : ParameterSet (prompt, proposed action, rationale)
• method_result : ResultSet (confirmation outcome)

9.3 receive_input

Receives input from a human or system.

• method_params : ParameterSet (input content, source)
• method_result : ResultSet

9.4 configure_interface

Configures Interface behavior.

• method_params : ParameterSet (preferences, accessibility settings)
• method_result : ResultSet

Configuration changes SHOULD be logged.

---

10. Edge‑Primary Constraints

In Edge‑primary systems, Interfaces:

• MUST function locally without continuous cloud dependency;
• SHOULD support offline operation for local prompts and confirmations;
• MAY defer outbound notifications when connectivity is absent;
• MUST degrade safely (e.g., switch to local alerts) per Policy.

---

11. Failure and Degradation Modes

Interface degradation may include:

• delivery failures
• misrouting due to stale configuration
• unavailable confirmation channels

Systems MUST handle such failures by:

• retrying within policy limits,
• falling back to alternate interfaces,
• or requesting local confirmation where possible.

---

12. Notes for Implementers (Non‑Normative)

• Interfaces should separate content from routing and authorization.
• For aging-in-place, escalation interfaces should be explicit and policy-governed.
• System-to-system interfaces should prioritize interoperable, open protocols.

---

Status: Draft v0.1 (Normative Object Definition)