# 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.

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

## One-sentence definition

```text
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:

```text
What is this object called?
```

MOIM asks:

```text
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:

```text
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

```text
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:

```text
IDENTITY
CONSERVATION
TRANSFORMATION
SCALING
DYNAMICS
```

A formula or object becomes a behavioral point:

```text
BehavioralPoint(object) = fingerprint over behavior axes
```

Example:

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

## Behavioral router role

MOIM is an equation type and routing primitive:

```text
object -> behavioral fingerprint -> route/adaptor search
```

Use:

```text
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:

```text
object -> class -> properties -> permitted behavior
```

MOIM inverts this:

```text
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.

```text
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:

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

Architecturally:

```text
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.

```text
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:

```text
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:

```text
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.

```text
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.

```text
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.

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

In short:

```text
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.

```text
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:

```text
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:

```text
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:

```text
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:

```text
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.

```text
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:

```text
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:

```text
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:

```text
spoof detection
ghost detection
category count checks
topology lock
quarantine trigger
```

Boundary:

```text
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.

```text
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:

```text
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

```ts
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

```ts
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

```ts
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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

```text
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

```text
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.
```