Purpose of This Series
This post introduces a series of specifications defining the Open Simulated General Intelligence (Open SGI/SimGenie) Minimum Viable Model (MVM) for edge‑primary Personal Event Recognition (PER) in the context of aging in place.
The initial and primary goal of the MVM is not to deliver a product. Its purpose is to demonstrate the technical feasibility and value of open, object‑oriented autonomous intelligence models, grounded in the OAII Base Model and extended through Simgenie as an optional interpretive layer. That said, it is my intention to use the MVM to construct a Minimum Viable Product – a PER kit for AI hobbyists.
This series will specify what I believe is a minimal, coherent set of OAII object subclasses that together form an end‑to‑end, implementable PER system operating entirely at the edge.
Design Objectives
The MVM is designed to satisfy the following independent objectives:
- Demonstrate implementability of the Base Model in a real‑world, safety‑critical domain
- Demonstrate edge‑primary operation, without reliance on cloud inference
- Demonstrate governance by construction, including privacy, policy mediation, and logging
- Demonstrate the feasibility of open, object‑oriented AI models that are interoperable and auditable
Domain Scope: Aging in Place
The domain of interest is Personal Event Recognition for a single human aging in place (the Primary User).
Key constraints:
- The Primary User is a known individual residing in a known environment
- The system operates continuously but conservatively
- No diagnostic or medical claims are made
- All evaluation is contextual, policy‑mediated, and revisable
- The system favors non‑action unless policies permit escalation
The MVM focuses on interpretation and governance, not surveillance or behavioral scoring.
Edge‑Primary Processing Assumption
All processing in the MVM is edge‑primary:
- Sensor data is processed locally
- Event recognition occurs locally
- Policy evaluation occurs locally
- Logging occurs locally
External connectivity, if present, is treated as an Interface, not as a dependency.
World Model for PER
Worlds are a Simgenie concept that support a unity of opposites ontology and epistemology. Worlds are not required for OAII compliance.
The Open SGI MVM employs three interpretive Worlds, each providing a distinct contextual frame for processing the same underlying sensor data.
1. Subject–Object Context World
This World contains data and programs that:
- identify objects within sensor data
- assign generic, non‑personal meaning to those objects
Example interpretation:
“Something came through the door.”
This World establishes semantic grounding without personalization or evaluation.
2. PrimaryUser–Environment Context World
This World contains PER data and programs that:
- identify the Primary User within sensor data
- interpret events specifically in relation to the Primary User and the environment
Example interpretation:
“The Primary User came home.”
This World introduces personal meaning while remaining descriptive rather than judgmental.
3. Beneficial–Detrimental Context World
This World contains PER data and programs that:
- interpret events in terms of their contextual impact on the Primary User
- evaluate outcomes relative to configured policies
Example interpretation:
“Nothing abnormal detected in the user’s appearance or act of entering.”
Outcomes in this World are policy evaluations, not events. They are logged and revisable.
Single Pipeline, World‑Specific Interpretation
The MVM assumes a single processing pipeline:
- Signals are captured from Devices and Sensors
- Events are recognized from Signals
- Events are interpreted separately within each World
- Policies evaluate interpretations and propose outcomes
- Outcomes are logged and optionally delivered via Interfaces
Worlds do not duplicate pipelines; they provide distinct interpretive lenses over the same causal flow.
Levels in the Open SGI MVM
Within each World, Levels are used as optional indexing and coordination structures.
Key constraints:
- Levels are not ontological
- Levels are world‑specific
- Levels may contain distinct or intersecting processing areas
- Not all regions of a Level are required to contain data or programs
Like Worlds, Levels are a Simgenie concept that support transparency, testing, reintegration, and controlled innovation. Levels are not required for OAII compliance.
Minimal OAII Subclasses Defined by the MVM
This series will define eight OAII object subclasses, each specified in sufficient detail to demonstrate technical feasibility:
- EdgePERDevice (Device subclass)
- EdgePERSensor (Sensor subclass)
- PERSignal (Signal subclass)
- SubjectObjectEvent (Event subclass)
- PrimaryUserEvent (Event subclass)
- PERPolicy (Policy subclass)
- PERAgent (Agent subclass)
- PERInterface (Interface subclass)
A minimal PERLog specialization will be included where required to demonstrate auditability.
What This Series Will and Will Not Do
This series will:
- show how OAII objects compose into a real PER system
- demonstrate policy‑mediated interpretation
- remain edge‑primary and privacy‑preserving
- show how Simgenie concepts integrate without redefining OAII
This series will not:
- define a product or deployment
- prescribe implementation technologies
Why This Matters
This MVM demonstrates that:
- autonomous intelligence can be structured, governable, and open
- personalization does not require opacity
- innovation can be introduced without destabilization
- edge‑primary systems can remain accountable by design
The following posts in this series will intermix advocacy with the specifications of the eight OAII subclasses, starting with the EdgePERDevice.
OAII defines the foundation. Open SGI explores what can be built on top of it — carefully, transparently, and responsibly.
Open Autonomous Intelligence Initiative 
Leave a comment