A unified class and containment framework for implementing world-indexed data, belief, and knowledge flows in Simulated General Intelligence.

Open SGI v2 — Base Inheritance & Containment Classes

Canonical inheritance hierarchies and containment/aggregation patterns for the UPA‑aligned Base Model. Language‑neutral; suitable for JSON Schema, ASN.1, UML, and TypeScript/Python implementations.

1) Core Abstract Bases & Mixins

Intro — what & why: Establishes minimal, reusable contracts so every stateful thing in SGI is world/time/context anchored and traceable. This guarantees interpretability and audit trails across worlds and time.

package open_sgi.base

abstract class Identified { id: UUID }
abstract class WorldBound { world: WorldID }
abstract class TimeBound { time: TimeIndex }
abstract class ContextBound { context: Context }
abstract class Provenanced { provenance: Provenance }
interface AxisAware { signature(): WorldSignature }

// Root base for domain objects
abstract class BaseObject extends Identified {}

// Common situated base: world + time + context + provenance
abstract class Situated extends BaseObject implements WorldBound, TimeBound, ContextBound, Provenanced {}

Intent: Ensure every stateful object can be anchored to world/time/context and traced.

Conclusion — how & where (Service–Object–Application):

• Object layer: BaseObject, Situated, mixins.
• Service layer: IdentityService (UUID), ContextService (resolve/merge), ProvenanceService (lineage).
• Application layer: Any flow (monitoring, simulation) can rely on these guarantees for logging, RBAC, and certification.

2) Epistemic Inheritance Tree (D → I → B → K)

Intro — what & why: Encodes the epistemic ladder as first-class types so systems can separate raw signal, interpretation, stance, and justification — the core of UPA-aligned reasoning.

package open_sgi.epistate

enum EpistemicType { DATA, INFORMATION, BELIEF, KNOWLEDGE }

abstract class EpistemicState extends Situated {
  type: EpistemicType
}

class Data extends EpistemicState {
  signal: Any,
  source: EntityID
}

class Information extends EpistemicState {
  data: Data,
  schema: SchemaRef,
  interpretation: Any
}

class Belief extends EpistemicState {
  info: Information,
  agent: AgentID,
  distribution: ProbabilityModel,
  update: UpdateRule
}

class Knowledge extends EpistemicState {
  belief: Belief,
  justification: Justification,
  harmony: HarmonyScore,
  world_consistency: ConsistencyScore
}

Containment semantics (composition): Knowledge ▸contains▸ Belief ▸contains▸ Information ▸contains▸ Data.
Deleting a parent removes its contained children inside the same aggregate.

Conclusion — how & where (Service–Object–Application):

• Object: the four classes + composition chain.
• Service: EpistemicService (promote/demote), BeliefUpdateService, KnowledgeValidationService.
• Application: monitoring (D→I), forecasting (I→B), governance/ops (B→K) with auditable promotions.

3) Rule Inheritance

Intro — what & why: Externalizes how things change and are judged into pluggable rules so worlds remain configurable and testable.

package open_sgi.evaluation

abstract class Rule extends BaseObject {}
abstract class WorldRule extends Rule { appliesTo: WorldID }

class UpdateRule extends WorldRule {
  apply(x: EpistemicState, Δc: Context, Δw: World): EpistemicState′
}

class HarmonyRule extends WorldRule {
  evaluate(x: EpistemicState, w: World): HarmonyScore
}

class JustificationRule extends WorldRule {
  evaluate(b: Belief, w: World): Justification
}

Conclusion — how & where (Service–Object–Application):

• Object: rule types & evaluators.
• Service: RuleRegistry, HarmonyService, JustificationService, UpdateEngine.
• Application: switch rule sets per tenant/world; A/B test policies; certify via fixed rule bundles.

4) World & Mapping Inheritance

Intro — what & why: Makes worlds first-class and defines cross-world mappings (Φ) so SGI can compare, translate, and transfer safely.

package open_sgi.world

class PolarityAxis extends BaseObject { name: String, description?: String }
class SigmaPair extends BaseObject { axis: PolarityAxis, positive_label: String, negative_label: String }

abstract class MappingLike extends BaseObject { source: WorldID, target: WorldID }
class Mapping extends MappingLike { functor: MappingFunctor, loss_model?: MappingLoss }

abstract class FunctorLike extends BaseObject {}
class MappingFunctor extends FunctorLike {
  mapEntity(e: Entity): Entity′
  mapEpistemic(x: EpistemicState): EpistemicState′
  mapAxis(a: PolarityAxis): PolarityAxis′
}

class World extends BaseObject implements AxisAware {
  id: WorldID,
  name: String,
  axes: List<PolarityAxis>,          // contained
  sigma: List<SigmaPair>,             // contained
  entities: List<Entity>,             // aggregated (or contained in test worlds)
  epistore: EpistemicStore,           // contained
  rules: WorldRules,                  // contained
  context: Context,
  time: TimeIndex,
  signature(): WorldSignature
}

class WorldRules extends BaseObject {
  update: UpdateRule,
  harmony: HarmonyRule,
  justification: JustificationRule
}

Conclusion — how & where (Service–Object–Application):

• Object: World, Mapping, MappingFunctor.
• Service: WorldService (create/clone), MappingService (Φ apply/verify), SignatureService (axis activations).
• Application: simulators, counterfactual planners, multilingual/cultural adapters via Φ pipelines.

5) Entities & Agency

Intro — what & why: Defines the actors and peripherals of a world so observation and action are first-class and auditable.

package open_sgi.agency

enum Role { AGENT, SENSOR, ACTUATOR, ENVIRONMENT, OTHER }

type EntityID = String

abstract class Entity extends Situated { role: Role, attributes: Map<String,Any> }
class Agent extends Entity { belief_state: List<Belief>, knowledge_base: List<Knowledge>, policy: Policy }
class Sensor extends Entity { observe(): Data }
class Actuator extends Entity { act(a: Action): Outcome }

Conclusion — how & where (Service–Object–Application):

• Object: Agent, Sensor, Actuator.
• Service: ObservationService (ingest to Data), PolicyService (select actions), ActionService (execute/rollback).
• Application: closed-loop apps (monitor→decide→act), safety rails via knowledge/harmony checks.

6) Epistemic Store & Timelines (Containment)

Intro — what & why: Provides durable, typed storage and temporal chains so every epistemic transition is queryable and replayable.

class EpistemicStore extends BaseObject {
  data:      Repository<Data>,
  info:      Repository<Information>,
  beliefs:   Repository<Belief>,
  knowledge: Repository<Knowledge>,
  timelines: Map<EntityID, Timeline>
}

class Repository<T extends EpistemicState> { items: Map<UUID,T> }
class Timeline extends BaseObject { states: List<EpistemicState> } // ordered by time

World containment: World ▸contains▸ one EpistemicStore and one WorldRules.

Conclusion — how & where (Service–Object–Application):

• Object: repositories & timelines.
• Service: EpistemicRepoService (CRUD + versioning), TimelineService (append/replay), ProvenanceService.
• Application: audits, incident post-mortems, learning replays, certification.

7) Aggregates (DDD)

Intro — what & why: Defines transaction boundaries to keep invariants consistent under concurrency and failure.

class WorldAggregate { root: World }
class EpistemicAggregate { root: Knowledge, chain: { belief → information → data } }

Guideline: Use World and Knowledge as aggregate roots for transactional boundaries.

Conclusion — how & where (Service–Object–Application):

• Object: aggregate root classes.
• Service: UnitOfWork / TransactionService enforcing aggregate rules.
• Application: consistent promotions/demotions; snapshot & rollback at aggregate scope.

8) Validation Invariants

Intro — what & why: Encodes non-negotiable truths (e.g., world coherence for the D→I→B→K chain) so errors are caught early and explainably.

• Every EpistemicState extends Situated (world + time + context required).
• Information.data.world == Information.world.
• Belief.info.world == Belief.world and Belief.agent.world == Belief.world.
• Knowledge.belief.world == Knowledge.world.
• Mapping.source != Mapping.target unless identity mapping explicitly declared.

Conclusion — how & where (Service–Object–Application):

• Object: invariant declarations (annotations/contracts).
• Service: ValidationService (pre/postconditions), CI/CD schema checks.
• Application: gate deployments; reject malformed events; produce human-readable errors.

9) UML Containment Snapshot (textual)

Intro — what & why: A compact, human-parsable view of containment to keep architects, devs, and auditors aligned.

[World] 1 ──contains──> * [PolarityAxis]
[World] 1 ──contains──> * [SigmaPair]
[World] 1 ──contains──> 1 [WorldRules]
[World] 1 ──contains──> 1 [EpistemicStore]
[World] 1 ──aggregates──> * [Entity]
[EpistemicStore] ──contains──> * [Repository<Data|Information|Belief|Knowledge>]
[Information] ──contains──> 1 [Data]
[Belief] ──contains──> 1 [Information]
[Knowledge] ──contains──> 1 [Belief]

Conclusion — how & where (Service–Object–Application):

• Object: diagram reflects classes/associations.
• Service: use as source for codegen/docs (PlantUML/Mermaid pipelines).
• Application: onboarding, design reviews, external audits.

10) JSON Schema / ASN.1 Hints

Intro — what & why: Shows how to realize inheritance/containment in machine-readable contracts for validation and interop.
JSON Schema discriminator for inheritance

{
  "$id": "https://schema.open-sgi.org/v2/EpistemicState.json",
  "oneOf": [
    { "$ref": "#/definitions/Data" },
    { "$ref": "#/definitions/Information" },
    { "$ref": "#/definitions/Belief" },
    { "$ref": "#/definitions/Knowledge" }
  ],
  "discriminator": { "propertyName": "type" }
}

ASN.1 sketch

EpistemicState ::= CHOICE {
  data        Data,
  information Information,
  belief      Belief,
  knowledge   Knowledge
}

Conclusion — how & where (Service–Object–Application):

• Object: schemas as single source of truth.
• Service: schema-driven codegen; runtime validators in gateways/ETL.
• Application: cross-team interop (REST/gRPC/Kafka), versioning with backward compatibility.

11) Lifecycle Semantics (Delete/Copy)

Intro — what & why: Defines what happens to contained objects under destructive or cloning operations to avoid orphaned or inconsistent chains.

• Deleting Knowledge removes its contained Belief → Information → Data chain within the same aggregate.
• Copying World deep‑copies WorldRules, EpistemicStore, and σ‑structures; Entity references may be shallow unless flagged for composition.

Conclusion — how & where (Service–Object–Application):

• Object: cascade rules annotated per class.
• Service: LifecycleService (cascade delete/clone), snapshotting & deep-copy utilities.
• Application: safe archival, tenant copy, sandboxing, redaction.

12) Next Steps

Intro — what & why: Prioritized path to operationalize the model and prove conformance.

• Generate full JSON Schema + ASN.1 modules from these definitions
• Add sequence diagrams for observe→interpret→believe→know→act
• Provide TypeScript/Python interface packages with runtime validators
• Create Test Worlds (Wᵢ) and a conformance suite enforcing invariants

Conclusion — how & where (Service–Object–Application):

• Object: finalize classes & schemas.
• Service: stand up WorldService, EpistemicService, ValidationService, MappingService behind REST/gRPC.
• Application: integrate into two pilots — (1) Monitoring & Alerts, (2) Counterfactual Planner — to exercise end-to-end D→I→B→K and Φ mapping.