Open Autonomous Intelligence Initiative

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

1. Purpose

The Event object represents a semantically meaningful occurrence recognized within a World. It is the primary unit of interpretation for autonomy, assistance, logging, and policy evaluation. In Edge‑primary systems, Events enable actionable understanding without dependence on continuous connectivity or centralized inference.

2. Definition (Normative)

An Event is an abstract, bounded, and contextualized occurrence that:

• MUST be recognized relative to a specific World;
• MUST arise from one or more Signals produced by Sensors/Devices;
• MUST be derived by comparing current observations to Sensor Knowledge (baseline, learned patterns, calibration, and/or reference models);
• MUST possess semantic meaning beyond raw observation;
• MUST be temporally delimited or characterizable;
• MUST NOT imply diagnosis, intent, or clinical assessment by default.

An Event is neither a raw Signal nor a continuous state; it is an interpreted occurrence deemed relevant within a World.

3. Scope and Non‑Scope

In Scope:

• Recognition of occurrences (e.g., entry/exit, interaction, anomaly, absence, transition)
• Local interpretation and relevance assessment
• Triggering downstream reasoning, logging, or policy evaluation
• Event lifecycle and revision under new evidence

Out of Scope:

• Medical diagnosis or health condition inference
• Attribution of motive, causality, or responsibility
• Cross‑World truth arbitration

Events may be provisional, revised, or superseded as context evolves.

4. Core Responsibilities

The Event object:

• Encapsulates meaning derived from one or more Signals;
• Defines temporal extent (instant, interval, or ongoing-with-checkpoints);
• Associates context from the containing World;
• Supports uncertainty and confidence representation;
• Supports revision when new Signals arrive or World evolves;
• Enables interoperability by standardizing occurrence semantics.

5. Required Attributes (Abstract)

A conforming Event MUST expose the following abstract attributes, using shared types and conventions in Common Types v0.1.

5.1 Identity and Context

• event_id : EventId
• world_ref : WorldId

5.2 Type (World‑Scoped)

Event types are typically World‑specific.

• event_type_id : string
  MUST be uniquely identifiable within the referenced World.

Requirement: When exported beyond the originating system or beyond the World boundary, event_type_id SHOULD be namespaced (e.g., world_id + local_type).

5.3 Evidence and Timing

• temporal_extent : ParameterSet
  MUST characterize occurrence time, duration, or interval bounds.
• source_signals : SignalId[1..N]
• confidence : Confidence

5.4 Lifecycle State

• event_state : string (see Section 6)
• revision_state : string
  Indicates whether the Event is provisional, confirmed, revised, or superseded.

5.5 Recognition Mechanism Bundle

Event recognition is represented as a mechanism bundle:

• recognition_mechanism_id : MechanismId
• recognition_mechanism_params : ParameterSet
• recognition_mechanism_result : ResultSet (optional)

The recognition mechanism bundle MUST be sufficient to explain how an Event was recognized at an abstract level (e.g., rule-set id, model id, threshold set, feature family), subject to privacy constraints.

6. Event Lifecycle and States (Normative)

A conforming implementation MUST support at least the following Event states:

• CANDIDATE: evidence accumulating; not yet declared as an Event
• ACTIVE: declared and currently ongoing (for interval/ongoing Events)
• COMPLETED: ended / bounded interval finalized
• REVISED: materially updated due to new evidence or context
• SUPERSEDED: replaced by a later Event representation
• INVALIDATED: withdrawn due to error, corruption, or misrecognition

State constraints:

• Events MUST NOT jump directly from CANDIDATE to COMPLETED without either ACTIVE or an explicit instantaneous characterization in temporal_extent.
• REVISED and SUPERSEDED MAY apply to both ACTIVE and COMPLETED Events.

7. Relationships to Other Objects

• Signals provide evidence for Events
• Sensors generate Signals that may participate in Events
• Devices host Sensors and recognizers
• Sensor Knowledge provides baseline and learned context used in recognition
• World provides contextual axes and policy context for relevance
• Agents reason about and act upon Events
• Knowledge may be derived from aggregated Events
• Policies are evaluated in response to Events
• Logs record Event lifecycle, evidence, and outcomes

Events MUST NOT exist independently of a World context.

8. Methods (Normative, Abstract)

Events may be implemented without explicit callable methods; however, to standardize behavior, a conforming Event SHOULD support the following abstract methods (using ParameterSet / ResultSet):

8.1 evaluate_event_candidate

Evaluates current Sensor data (e.g., GPS, motion, sound, image) against Sensor Knowledge to update candidacy.

• method_params : ParameterSet (references incoming signals, relevant sensor knowledge ids, and evaluation window)
• method_result : ResultSet (may include updated confidence, suggested event_type_id, and explanatory_trace)

Postconditions:

• MUST update confidence and event_state appropriately.
• MAY create a new Event in CANDIDATE state or update an existing candidate.

8.2 declare_event

Declares an Event from candidate evidence.

• method_params : ParameterSet (candidate reference, declaration thresholds, policy gates)
• method_result : ResultSet (SUCCESS/PARTIAL/FAIL)

Requirements:

• MUST set event_state to ACTIVE or COMPLETED as appropriate.
• MUST record source_signals used for declaration.

8.3 revise_event

Updates an Event due to new evidence or context.

• method_params : ParameterSet (new signals, updated sensor knowledge, or world evolution notices)
• method_result : ResultSet

Requirements:

• MUST set event_state to REVISED (or SUPERSEDED if replacement occurs).
• SHOULD preserve prior representation via revision_state history (implementation-specific).

8.4 close_event

Closes an ongoing Event.

• method_params : ParameterSet (closing criteria, final signals)
• method_result : ResultSet

Requirements:

• MUST set event_state to COMPLETED on success.

9. Edge‑Primary Constraints

In Edge‑primary systems, Events:

• MUST be recognizable with locally available data;
• SHOULD tolerate partial, missing, or noisy Signals;
• MAY be recognized incrementally;
• MUST support deferred synchronization with other systems or Worlds.

Event recognition MUST prioritize safety, privacy, and local autonomy.

10. Failure and Degradation Modes

Event degradation may include:

• Missed or delayed recognition
• Reduced confidence or specificity
• Misclassification among similar event types
• Sensor drift causing baseline mismatch

Systems MUST allow uncertainty rather than forcing false certainty.

11. Notes for Implementers (Non‑Normative)

• Treat “Sensor Knowledge” as the bridge between raw data and stable interpretation: calibration, baselines, learned routines, acoustic/visual embeddings, geofences, etc.
• Events may be instantaneous (e.g., door opened) or extended (e.g., absence over time).
• Event vocabularies should remain extensible and World-scoped; different Worlds may define different event types for the same raw patterns.
• For aging‑in‑place, emphasize observability over inference (e.g., “no motion detected in kitchen for 3 hours” rather than “fell”).

---

Status: Draft v0.1.1 (Normative Object Definition)