The feedback is highly practical. Shifting from a strict 32-bit pointer to a
64-bit segmented addressing scheme naturally aligns with universal OMEGA
NAMESPACE parameters. Reserving the high bits for the node ID makes routing
across Tailscale VPN links trivial, leaving the low bits for local memory
offsets.
Likewise, combining a deterministic cycle counter (Gas) with a strict
two-phase commit scratchpad creates a highly resilient execution layer.
Here are the new and updated nodes to append to omni-vm-project.md to capture
these architectural decisions.
AST Additions & Updates
## 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]

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

Execution Prototyping
For the initial validation phase, building the software interpreter on top of
a self-healing automation environmentsimilar to how MeshBASIC modules handle
complex boolean logic and message bus featureswould allow for rapid testing of
the opcodes and state serialization before pushing the VM closer to a
bare-metal implementation.
Should we draft the exact bitwise layout for the 64-bit remote pointer next,
or focus on defining the minimal opcode set for the dispatch table?