Research-Stack/0-Core-Formalism/otom/docs/gcl/MOIMConcepts.md

MOIM Concepts

Status: HOLD / workbench projection Authority: concept/system spec; not canonical proof Related: docs/gcl/GCLCompleteSurface.md, docs/gcl/ForestPathGoxelModel.md, docs/gcl/SuperorganismCollectiveBasinBridge.md, docs/gcl/NonEquilibriumTransitionRisk.md, docs/gcl/EquationForestActiveKernels.md

Canonical expansion

MOIM means Meta-Ontological Inversion Machine.

MOIM is a behavioral manifold router and lifecycle machine. It turns an object, formula, signal, route, or concept into a behavioral fingerprint, then searches for admissible routes, adapters, gates, receipts, and inheritance paths.

object
  -> behavioral fingerprint
  -> route / adapter search
  -> gate checks
  -> receipt writing
  -> inheritance or quarantine

One-sentence definition

MOIM is the machine layer that routes objects through behavioral manifolds by inverting ontology into behavior: what a thing is becomes what it does across gates, adapters, signals, and receipts.

Core doctrine

MOIM does not ask only:

What is this object called?

MOIM asks:

How does this object behave across domains, gates, projections, and failures?

This makes MOIM a behavior-first ontology engine.

Lifecycle manifesto

MOIM v3.0 turns computation into a lifecycle:

signal
  -> scalar
  -> confusion
  -> query
  -> gate
  -> receipt
  -> inheritance

Each stage is a transformation boundary.

Stage	Meaning
signal	raw input, event, perturbation, device state, language fragment, equation, or observation
scalar	normalized measurable quantity or compact field value
confusion	uncertainty, mismatch, unresolved route pressure, or adapter failure
query	structured request for resolution, routing, proof, or repair
gate	admissibility/safety/proof/routing check
receipt	evidence, audit trail, build result, benchmark, source, or refusal record
inheritance	admitted state becomes reusable structure, memory, basin, scar, or route prior

Keeper Law

The system may become useful.
It may not become authorized by usefulness alone.

This is the central anti-drift rule for MOIM.

Usefulness can trigger more attention, more search, or more tests. Usefulness cannot bypass gates.

Behavioral manifold

MOIM uses a behavioral manifold: a space where formulas, objects, routes, and concepts are placed by what they do.

Canonical behavioral axes from the graph surface:

IDENTITY
CONSERVATION
TRANSFORMATION
SCALING
DYNAMICS

A formula or object becomes a behavioral point:

BehavioralPoint(object) = fingerprint over behavior axes

Example:

equation
  -> conservation strength
  -> transformation behavior
  -> scaling response
  -> dynamic behavior
  -> identity preservation
  -> route candidates

Behavioral router role

MOIM is an equation type and routing primitive:

object -> behavioral fingerprint -> route/adaptor search

Use:

math behavior-space routing
adapter discovery
equation classification
semantic basin search
failure-to-route memory

Meta-ontological inversion

The inversion is the key move.

Classical ontology often starts with categories:

object -> class -> properties -> permitted behavior

MOIM inverts this:

object -> observed behavior -> manifold coordinate -> route/adaptor/gate -> provisional class

So category is not assumed first. Category is inferred, routed, and gated from behavior.

Relation to Mass-Number

Mass-Numbers sit under MOIM operationally but beside MOIM architecturally.

MOIM is the behavioral router. Mass-Number is the finite accounting profile that scores the routed object's weight, cost, inertia, density, or unresolved load.

MOIM asks:
  How does this object behave, and where can it route?

Mass-Number asks:
  How heavy/costly/dense/unresolved is this object under the declared regime?

Operationally:

object
  -> MOIM behavioral fingerprint
  -> Mass-Number / cost profile
  -> route candidates
  -> gate checks
  -> receipt or HOLD

Architecturally:

GCL
  contains MOIM routing profiles
  contains Mass-Number profiles
  contains gates, receipts, projections, and claim states

So Mass-Number is not above MOIM as the master controller. It is also not merely below MOIM as a passive variable. It is a sibling subsystem that MOIM consults when deciding whether a route, adapter, fusion, inheritance, or projection is affordable and admissible.

MOIM = route/search/inversion machine
Mass-Number = accounting/inertia/metabolic-cost scalar family
GCL = encoding container that holds both
OTOM gates = promotion/audit control

When Mass-Number is under MOIM

Mass-Number is under MOIM when MOIM is actively routing an object.

Example:

MOIM route attempt
  -> compute behavioral distance
  -> compute Mass-Number cost
  -> reject route if cost exceeds budget

Here Mass-Number is an input to MOIM route choice.

When Mass-Number is beside MOIM

Mass-Number is beside MOIM when both are profiles on the same GCL object.

Example:

GCL object
  -> MOIM profile: behavior / route candidates / adapters
  -> Mass profile: m_A / NaNMass / ClosedMass / budget
  -> Receipt profile: proof / benchmark / audit state

Here neither owns the other. They are coordinated profiles.

When Mass-Number can constrain MOIM

Mass-Number can gate MOIM inheritance.

if MassNumberCost(route) > Budget_R:
  MOIM may not promote inheritance
  route becomes HOLD, repair, split, or NaNMass

So Mass-Number is a constraint on MOIM's freedom, not the root ontology.

Relation to GCL

GCL is the Genetic Coding Language.

MOIM is one machine that operates on GCL objects.

GCL genotype
  -> encoded object / slots / claim state

MOIM behavior pass
  -> behavioral fingerprint / route search / gate query

GCL phenotype
  -> wiki page / graph node / simulator object / theorem target / receipt-backed state

MOIM does not replace GCL. It routes GCL objects through behavior-space.

Relation to FAMM

FAMM means frustration-aligned memory management / failure-attractor memory behavior in the broader stack.

MOIM feeds FAMM by turning object behavior into route outcomes.

MOIM route attempt
  -> success / failure / partial / confusion
  -> FAMM scar or basin
  -> future route bias

In short:

MOIM routes behavior.
FAMM remembers route pain and route success.

Relation to PIST

PIST is the perfectly-imperfect / stochastic search surface.

MOIM gives PIST a behavioral target. PIST explores imperfectly. FAMM stores the scars and basins.

MOIM: what behavior-space are we searching?
PIST: how do we search imperfectly without freezing?
FAMM: what did the search teach us?

Relation to Goxels and forest paths

Goxels make N-space geometry auditable as bounded scalar sub-manifolds. Forest paths make routes auditable as typed transitions through Goxel domains.

MOIM adds behavioral routing:

object / equation / concept
  -> behavioral fingerprint
  -> candidate forest path
  -> Goxel/domain transitions if geometric
  -> Sidon compatibility if interactions matter
  -> gate and receipt state

So MOIM is the route-finder across the forest.

Relation to Equation Forest

The Equation Forest contains active kernels.

MOIM classifies which kernels an object behaves like or routes through.

Examples:

object behaves like transport/shock
  -> candidate kernels: Burgers_Inviscid, Burgers_Viscous

object behaves like information compression
  -> candidate kernels: Shannon_Entropy, Landauer_Bound

object behaves like topology/admissibility
  -> candidate kernels: RGFlow_Admissibility, BettiAudit

object behaves like signal surprise
  -> candidate kernels: NII_Surprise, S3C_Codec

MOIM does not prove the object belongs to a kernel. It proposes routes for audit.

Relation to self-healing topology

MOIM is a repair participant in the self-healing topology model.

When a path breaks:

blocked route
  -> MOIM behavioral remap
  -> alternate adapter search
  -> gate pass/fail
  -> receipt or scar

This supports the transition from mainframe-style cognition to self-healing semantic topology:

central category authority
  -> distributed behavior routing
  -> gated route repair
  -> receipt-backed topology

Relation to non-equilibrium transition risk

In non-equilibrium transition periods, categories drift faster than institutions can stabilize them.

MOIM helps by routing by behavior instead of relying on stale labels.

label unstable
  -> behavior fingerprint
  -> route search
  -> gate
  -> receipt

This does not eliminate transition risk. It makes drift auditable.

Hardware / runtime surface

MOIM also has a hardware/runtime interpretation from the v3.0 expansion.

Representative modules:

moim_top.v
  top integration: host interface, signal inputs, controller FSM, module instantiation

morphic_nanokernel.v
  morph register file, fixed-point multiplier engine, neural coding encoder,
  replication limits, profile switcher, instruction decoder

all_device_signal_router.v
  signal aggregation over device categories

safety_valves.v
  unified hardware safety valves

oepi_processor.v
  fixed-point OEPI calculator and escalation thresholds

morphic_scalar_fsm.v
  lifecycle state machine over confusion/query/gate states

origin_protocol.v
  trait enforcement and hard refusal mechanism

delta_gcl_compressor.v
  delta + PTOS dictionary + GCL compression stack

This runtime surface should remain simulation_only or workbench_projection until build receipts, synthesis reports, and safety audits are attached.

Seven-valve safety surface

MOIM v3.0 uses seven safety-valve classes:

V1 data integrity
V2 performance / latency / throttle
V3 endurance / lifetime counter
V4 equation validation
V5 profile switching
V6 scalar behavior
V7 hardware signal boundary

These valves enforce the Keeper Law at runtime.

V7 Hardware Signal Boundary

V7 protects topology integrity for the device-signal surface.

Allowed use:

spoof detection
ghost detection
category count checks
topology lock
quarantine trigger

Boundary:

hardware signal boundary != proof of ontology
signal consistency != safety by itself

AngrySphinx relation

AngrySphinx is the hard refusal / veto layer.

MOIM may route, search, classify, or propose. AngrySphinx may still refuse execution or promotion.

MOIM proposes route.
AngrySphinx can veto route.
Gate receipts decide promotion.

OEPI placement

OEPI appears as a scalar escalation / pressure index in the MOIM runtime surface.

Use it as:

Operational / Ontological Escalation Pressure Index

until the exact acronym is locked by a stronger source.

OEPI should be treated as a finite scalar that helps decide whether a state escalates, throttles, routes to quiet hours, or requires human/gate intervention.

MOIM state object

type MOIMObjectState = {
  object_id: string;
  source_surface: string;
  behavioral_fingerprint: Record<string, number>;
  mass_profile?: {
    mass_number?: number;
    mass_state?: "FiniteMass" | "NaNMass" | "ClosedMass";
    budget_status?: "unknown" | "within_budget" | "over_budget" | "needs_closure";
  };
  active_route_candidates: string[];
  active_adapters: string[];
  confusion_state:
    | "none"
    | "low"
    | "moderate"
    | "high"
    | "quarantine";
  gate_state:
    | "ungated"
    | "pending"
    | "passed"
    | "failed"
    | "refused";
  receipts: string[];
  inheritance_status:
    | "none"
    | "scar"
    | "basin"
    | "admitted"
    | "quarantined";
};

MOIM route record

type MOIMRouteRecord = {
  route_id: string;
  object_id: string;
  start_domain: string;
  target_domain: string;
  adapter_chain: string[];
  behavioral_distance_before?: number;
  behavioral_distance_after?: number;
  mass_number_cost?: number;
  mass_budget_status?: "unknown" | "within_budget" | "over_budget" | "needs_closure";
  outcome:
    | "success"
    | "failure"
    | "partial"
    | "confusion"
    | "refused"
    | "quarantined";
  gate_receipts: string[];
  famm_write:
    | "scar"
    | "basin"
    | "none";
};

MOIM lifecycle record

type MOIMLifecycleRecord = {
  signal_id: string;
  scalar_value?: number;
  confusion_reason?: string;
  query: string;
  gate: string;
  receipt_refs: string[];
  inheritance_target?: string;
  claim_state: "U_scope" | "HOLD" | "V_scope" | "REVIEWED" | "CANONICAL_LEAN" | "QUARANTINE";
  authority_scope:
    | "workbench_projection"
    | "simulation_only"
    | "receipt_backed"
    | "canonical_lean"
    | "external_source"
    | "safety_policy";
};

Allowed claims

MOIM may claim:

this object has a behavioral fingerprint under declared axes
this route was attempted
this adapter chain reduced or increased distance under a declared metric
this route had a declared Mass-Number cost under a declared budget
this gate passed, failed, or refused
this route became a FAMM scar or basin
this state is eligible for further audit

MOIM may not claim by itself:

this object is true
this ontology is proven
this route is safe because it is useful
this route is valid because its Mass-Number is low
this hardware surface is safe because it synthesizes
this behavior class proves physical validity

Validator requirements

Every MOIM record must declare:

object_id
source surface
behavioral axes or metric
route candidate or lifecycle state
claim_state
authority_scope
gate state
receipt status
blocked usages

If Mass-Number is used, it must additionally declare:

mass profile
budget regime
closure state
Mass-Number receipt status

If any are missing, keep the MOIM record in HOLD.

Failure modes

MOIM should catch or preserve these states:

label drift
category error
behavioral mismatch
adapter failure
projection artifact
false route convergence
usefulness without authorization
missing receipt
unsafe inheritance
confusion loop
hardware signal spoof
origin protocol violation
Mass-Number budget overrun
NaNMass route contamination
AngrySphinx refusal

Operating sentence

MOIM is the Meta-Ontological Inversion Machine: it turns objects into behavioral fingerprints, searches for adapters through manifold routes, writes failures and successes into memory, and allows inheritance only through gates and receipts.

Mass-Number operating sentence

Mass-Number is not above MOIM as a sovereign controller; it is the finite accounting profile that constrains MOIM routing, inheritance, fusion, and projection under declared budgets and closure gates.