# OMNI_VM_ROOT {ovm-root-0001}
> description: Root node for the Omni-Processor distributed virtual machine
concept, a system that routes bounded execution state across a mesh network
rather than fetching remote data.

## CORE_ARCHITECTURE {ovm-core-0001}
> description: The foundational 128-bit instruction set environment. Each
instruction consists of a 32-bit macro-opcode, two 32-bit mesh-routable
pointers, N-registers for local scratchpad math, and an n-depth stack for
retaining exact context during remote execution and suspension.
> type: specification
> status: conceptual
> tags: [isa, bytecode, opcode, registers, stack]

## DATA_GRAVITY_ROUTER {ovm-mesh-0001}
> description: The dynamic execution layer responsible for evaluating whether
to fetch data or teleport the bytecode. It weighs payload mass, topology
latency, compute asymmetry, reference locality, and quarantine egress rules to
route the serialized program state directly to the target node.
> type: routing-engine
> status: conceptual
> tags: [teleportation, heuristics, data-gravity, mobile-agents]
> depends_on: [ovm-core-0001]

## TRANSACTIONAL_MEMORY {ovm-sync-0001}
> description: The resilience layer preventing data corruption during node
failures mid-teleportation. It implements a caller-retained ghost copy of the
execution state, a timeout epoch monitor, temporary scratchpad memory for a
two-phase commit, and a poison pill protocol to discard stale results from
reconnecting zombie nodes.
> type: module'
> status: conceptual
> tags: [two-phase-commit, fault-tolerance, state-recovery, ghost-copy]
> depends_on: [ovm-mesh-0001]

## RESEARCH_INFINITE_LOOPS {ovm-res-0001}
> description: Investigate mechanisms to prevent runaway bytecode on remote
nodes. Options to explore include embedding a strict cycle-limit quota during
state serialization or attaching a TTL (Time-To-Live) counter to the
teleported payload.
> type: research-question
> status: open
> tags: [security, resource-exhaustion, quotas, limits]
> depends_on: [ovm-mesh-0001]

## RESEARCH_SCRATCHPAD_MEMORY {ovm-res-0002}
> description: Define the exact implementation of the temporary scratchpad
overlay required for the two-phase commit. Needs analysis on whether this
should be a virtualized heap within the software VM instance or mapped to a
specific namespace constraint.
> type: research-question
> status: open
> tags: [memory-management, two-phase-commit, isolation, state]
> depends_on: [ovm-sync-0001]

## RESEARCH_PING_PONG_ROUTING {ovm-res-0003}
> description: Determine heuristics to prevent infinite routing loops where
two nodes constantly bounce the execution state back and forth due to
conflicting cost-function evaluations.
> type: research-question
> status: open
> tags: [routing-loops, cost-function, heuristics, mesh-logic]
> depends_on: [ovm-mesh-0001]

## TODO_DISPATCH_MINIMAL {ovm-todo-0001}
> description: Draft the minimal opcode index for the software VM dispatch
table. Must include Data Movement (LOAD, STORE), Logic (CMP, JNZ), Mesh Ops
(TELEPORT, SUSPEND), and Transaction Control (BEGIN_TX, COMMIT_TX).
> type: task
> status: pending
> tags: [software-vm, interpreter, macro-instructions]
> depends_on: [ovm-core-0001]
## TODO_ISA_SPEC {ovm-todo-0002}
> description: Define the 64-bit segmented addressing scheme (OMEGA NAMESPACE
compatibility) where high bits represent the mesh Node ID and low bits
represent the local offset. Specify the minimal instruction set architecture,
including unary operations and explicit SUSPEND/RESUME opcodes.
> type: task
> status: pending
> tags: [isa, 64-bit, addressing, opcodes]
> depends_on: [ovm-core-0001]

## RESEARCH_GAS_METERING {ovm-res-0004}
> description: Evaluate deterministic cycle-limit quotas (Gas) combined with
hard node-level resource caps to prevent runaway bytecode, superseding
standard time-to-live (TTL) monitors.
> type: research-question
> status: open
> tags: [security, resource-limits, cycle-counter]
> depends_on: [ovm-res-0001]

## RESEARCH_ROUTING_HYSTERESIS {ovm-res-0005}
> description: Formulate a monotonically increasing route cost or a
visited-node list mechanism to prevent ping-pong routing loops caused by
conflicting data gravity heuristics across the mesh.
> type: research-question
> status: open
> tags: [routing-loops, mesh-logic, hysteresis]
> depends_on: [ovm-mesh-0001]

## CUSTODY_CHAIN_PROTOCOL {ovm-sync-0002}
> description: Defines the state retention lifecycle during teleportation.
Sending node keeps a serialized snapshot until receiving node acknowledges
custody. Snapshots are pruned on transaction completion or periodic
checkpointing.
> type: specification
> status: conceptual
> tags: [chain-of-custody, state-retention, resurrection]
> depends_on: [ovm-sync-0001]

## RESEARCH_REVIVAL_RULES {ovm-res-0006}
> description: Determine dynamic timeout thresholds, heartbeat frequencies,
and cascade epochs to prevent both false revivals and split-brain execution.
Include fencing token mechanism for epoch generation.
> type: research-question
> status: open
> tags: [timeouts, heartbeats, split-brain, fencing]
> depends_on: [ovm-sync-0002]

## RESEARCH_CHECKPOINT_PRUNING {ovm-res-0007}
> description: Define how often a process should emit a stable checkpoint to
truncate the custody chain and prevent unbounded memory growth on intermediate
nodes.
> type: research-question
> status: open
> tags: [garbage-collection, checkpoints, chain-pruning]
> depends_on: [ovm-sync-0002]