# 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_VM_DISPATCH_TABLE {ovm-todo-0001}
> description: Draft the initial 32-bit opcode index and define the
software-level dispatch table that acts as the interpreter for fixed-width
macro instructions.
> type: task
> status: pending
> tags: [software-vm, interpreter, macro-instructions]
> depends_on: [ovm-core-0001]