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

1. Purpose

The World object provides the foundational contextual container within which OAII objects operate. It establishes the structural, semantic, and interpretive boundaries that make Signals, Events, Agents, Knowledge, Policies, and Interfaces intelligible and interoperable. In Edge‑primary systems, the World object enables local coherence without dependence on centralized or global state.

2. Definition (Normative)

A World is an abstract, persistent, and internally coherent interpretive space that:

• MUST define the contextual frame in which observations are interpreted;
• MUST provide a basis for distinguishing Signals, Events, and entities;
• MUST support temporal continuity and versioned evolution;
• MUST be locally instantiable on edge devices.

A World is not a physical location, dataset, or simulation by default, but a structural context within which such representations may exist.

3. Scope and Non‑Scope

In Scope:

• Context definition (temporal, spatial, semantic, policy)
• Event intelligibility and relevance
• Edge‑resident autonomy and coherence
• World evolution with continuity guarantees

Out of Scope:

• Global ontology enforcement
• Medical or clinical interpretation
• Cross‑World truth arbitration

Multiple Worlds may coexist, overlap, or partially align, but no single World is assumed to be authoritative.

4. Core Responsibilities

The World object:

• Provides context for interpreting Signals as Events;
• Defines boundaries of relevance and attention;
• Maintains continuity across time and state changes;
• Hosts relationships among Devices, Agents, Events, Knowledge, Policies, and Interfaces;
• Supports evolution without invalidating prior interpretations.

5. Required Attributes (Abstract)

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

5.1 Identity and Versioning

• world_id : WorldId
• version_state : string (or other version identifier)

5.2 Temporal Frame

• temporal_frame : ParameterSet
  MUST define time reference and granularity (e.g., monotonic clock reference, wall-clock mapping, sampling epochs).

5.3 Contextual Axes (Typed)

• contextual_axes : ContextualAxis[1..N]
  Each axis MUST include axis_id, axis_type, label, and value_domain. (See ContextualAxis in Common Types v0.1.)

5.4 Continuity Mechanism Bundle

World continuity is represented as a mechanism bundle:

• continuity_mechanism_id : MechanismId
• continuity_mechanism_params : ParameterSet
• continuity_mechanism_result : ResultSet (optional)

The continuity mechanism bundle MUST support interpretation of prior World states under World evolution.

6. Relationships to Other Objects

• Devices and Sensors operate within a World
• Signals are observed relative to a World
• Events are recognized in a World
• Agents reason and act with respect to a World
• Knowledge is scoped to a World
• Policies are evaluated within a World’s context

Objects MUST NOT assume shared meaning across Worlds without explicit mediation.

7. Methods (Normative, Abstract)

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

7.1 apply_continuity_mechanism

• method_params : ParameterSet (may be empty)
• method_result : ResultSet

Preconditions: World has a defined continuity mechanism bundle.

Postconditions: World state remains interpretable across version_state transitions; method_result reports SUCCESS / PARTIAL / FAIL and any diagnostics.

7.2 evolve_world

• method_params : ParameterSet (proposed changes to axes, frames, or context)
• method_result : ResultSet

Requirements:

• MUST update version_state on success.
• MUST preserve continuity according to the continuity mechanism bundle.
• MUST NOT silently invalidate previously recorded Events; instead, it MAY mark them as “requires_reinterpretation” via revision_state on those Events (see Event v0.1).

8. Edge‑Primary Constraints

In Edge‑primary systems, a World:

• MUST be instantiable without network connectivity;
• MUST degrade gracefully under partial data loss;
• SHOULD support local persistence and recovery;
• MAY synchronize with other Worlds opportunistically.

9. Failure and Degradation Modes

World degradation may include:

• Loss of contextual fidelity (e.g., missing axes, stale frames)
• Temporal discontinuity (e.g., clock reset)
• Reduced Event recognition accuracy

Systems MUST continue operating in a degraded but safe mode rather than failing catastrophically.

10. Notes for Implementers (Non‑Normative)

• A World may be implemented as a graph, object space, scene model, contextual runtime, or “digital twin” fragment.
• Lightweight Worlds are appropriate for constrained edge devices.
• Worlds may be nested or layered (e.g., Physical World, Home World, Interaction World).
• For the MVP, AxisType values will typically include: TEMPORAL, SPATIAL, ACTIVITY, DEVICE_STATE, and POLICY_CONTEXT; SOCIAL is useful but should be privacy-gated.

---

Status: Draft v0.1.1 (Normative Object Definition)