Depends on: OAII Base Model — Common Types v0.1; OAII Base Model — World v0.1.1; OAII Base Model — Event v0.1.1; OAII Base Model — Signal v0.1; OAII Base Model — Sensor v0.1
1. Purpose
The Knowledge object represents structured, retained, and interpretable information derived from Signals, Events, and Sensor Knowledge within a World. Knowledge enables continuity, learning, and comparison over time without collapsing into continuous surveillance or opaque global models.
In the OAII Base Model, Knowledge is explicit, scoped, revisable, and accountable.
2. Definition (Normative)
Knowledge is an abstract object that:
- MUST be scoped to a specific World;
- MUST be derived from Signals, Events, Sensor Knowledge, or combinations thereof;
- MUST be explicitly represented and referenceable;
- MUST support revision and versioning;
- MUST NOT imply diagnosis, intent, or psychological state by default.
Knowledge is not raw data, a live sensor feed, or an implicit model state.
3. Scope and Non‑Scope
In Scope:
- Baselines, norms, and learned patterns
- Aggregated or summarized Events
- Reference models used for comparison
- Sensor Knowledge promotion into durable form
- World‑scoped historical context
Out of Scope:
- Continuous surveillance archives
- Global or cross‑World learning without mediation
- Medical or clinical knowledge claims
- Undocumented or opaque internal model state
4. Core Responsibilities
The Knowledge object:
- Persists information beyond the lifetime of individual Signals or Events;
- Supports comparison between current observations and historical context;
- Maintains interpretability through explicit structure and metadata;
- Enables continuity across World evolution;
- Supports accountability via traceability and revision history.
5. Required Attributes (Abstract)
A conforming Knowledge object MUST expose the following attributes using shared types from Common Types v0.1.
5.1 Identity and Context
- knowledge_id : string
- world_ref : WorldId
5.2 Knowledge Classification
- knowledge_type : string
Describes the role (e.g., baseline, routine, threshold set, reference pattern, summary).
5.3 Source and Provenance
- source_refs : string[1..N]
References contributing Signals, Events, Sensors, or prior Knowledge objects. - creation_time : ParameterSet
5.4 Validity and Confidence
- confidence : Confidence
- validity_constraints : ParameterSet (optional)
5.5 Privacy and Access
- privacy_class : PrivacyClass
- access_class : AccessClass
6. Knowledge States (Normative)
A Knowledge object MUST support at least the following states:
- PROVISIONAL: recently created, subject to change
- ACTIVE: valid and in use
- REVISED: updated due to new evidence
- DEPRECATED: retained for continuity but no longer authoritative
- INVALIDATED: withdrawn due to error or context change
Knowledge state MUST be explicitly tracked and visible.
7. Knowledge Mechanism Bundle
Knowledge formation and update MUST be represented using a mechanism bundle:
- knowledge_mechanism_id : MechanismId
- knowledge_mechanism_params : ParameterSet
- knowledge_mechanism_result : ResultSet (optional)
This bundle documents how Knowledge was derived or updated.
8. Relationships to Other Objects
- Signals contribute raw evidence
- Sensor Knowledge may be promoted into Knowledge
- Events may be aggregated or summarized into Knowledge
- World scopes meaning and validity
- Policies may reference Knowledge for evaluation
- Agents may reason over Knowledge
- Logs record Knowledge lifecycle changes
Knowledge MUST NOT bypass Events to directly drive action without policy mediation.
9. Methods (Normative, Abstract)
To standardize behavior, a conforming Knowledge object SHOULD support the following abstract methods:
9.1 derive_knowledge
- method_params : ParameterSet (source references, derivation rules)
- method_result : ResultSet
9.2 revise_knowledge
- method_params : ParameterSet (new evidence or context)
- method_result : ResultSet
Requirements:
- MUST update knowledge state appropriately.
- SHOULD preserve revision history.
9.3 evaluate_validity
- method_params : ParameterSet
- method_result : ResultSet (validity assessment)
10. Edge‑Primary Constraints
In Edge‑primary systems, Knowledge:
- MUST be storable and usable locally;
- SHOULD support bounded retention and aging;
- MAY be selectively synchronized across Worlds or systems;
- MUST respect privacy and access constraints at all times.
11. Failure and Degradation Modes
Knowledge degradation may include:
- stale baselines
- overfitting to outdated routines
- insufficient evidence coverage
Systems MUST surface uncertainty rather than forcing false authority.
12. Notes for Implementers (Non‑Normative)
- Sensor Knowledge is a specialized, often transient form of Knowledge; promotion to durable Knowledge should be explicit.
- Knowledge objects should remain small, interpretable, and replaceable.
- Aggregation intervals and retention policies should be World‑specific.
- Knowledge exists to support Events and Policies, not to replace them.
Status: Draft v0.1 (Normative Object Definition)

Leave a comment