PROFILE · ROUTE
Route the request
Classify the request and choose the smallest suitable execution path. A known result or a direct procedure can avoid a worker mission entirely.
CONTROL PLANE · MISSION ORCHESTRATION
Coordinate the work.
Keep the receipts.
The GenOS orchestrator plans and supervises backend missions: it applies a strategy and budget, dispatches bounded workers, and checks evidence before closure. It makes execution inspectable; it does not turn a successful dispatch into proof of a correct result.
PARTIAL IMPLEMENTATION · NODE.JS MISSION CONTROL
THE MISSION PATH
From request
to verified close.
The path branches according to the request and its contract. Some work can be served directly; missions that need workers move through planning, dispatch, evidence and a completion gate.
STRATEGY · BUDGET
Set the mission contract
Define the strategy, available work, budgets and constraints before planning workers. Permissions and capacity can narrow or stop a proposed plan.
PLAN · DISPATCH
Plan and reconcile
Build bounded phases and assignments, then compare the selected assignments with the workers actually created. A mismatch blocks the mission from proceeding as if dispatch had succeeded.
WORKERS · ISOLATION
Execute in bounded workspaces
Workers operate under declared leases, isolated workspaces, and token/time ceilings. Narrow native methods cover ten kinds, including LPT, subset-sum, Lean arithmetic and sourced observation; unsupported methods fail closed.
EVIDENCE · GATE
Check evidence and close
Wait for expected work to reach a stable state, collect evidence and check mission invariants. Missing evidence or failed checks can leave a mission incomplete, blocked or ready for bounded recovery. For Trinity, only worlds created by the current invocation count; its agents and all current worlds must be terminal before the mission closes.
WHAT THE CONTROL PLANE ENFORCES
Every decision
has a boundary.
Mission status and topology labels are not substitutes for the contracts and evidence attached to a run.
A completed worker is not proof
Transport and worker status are observations. A result needs the worker-specific typed artifact, sourced claims and provenance references, plus the applicable checks before the mission can be considered complete.
Plans meet real limits
Budgets, permissions, fan-out, workspace isolation and available capacity constrain the work that can actually run.
Topology names carry no blanket guarantee
A registered topology or capability profile does not prove that every capability is active or that a proposed plan was dispatched.
IMPLEMENTATION BOUNDARY
Two runtimes,
different jobs.
The backend Node.js control plane plans and supervises missions and their workers. The Rust genos-orchestrator crate runs a local ecosystem simulation; it does not launch those backend workers or certify a Node mission’s deliverable.
The main mission path still uses the historical morphology preparer. A mission can opt in to executing its planned graph with executeMorphogenesisGraph: true after worker evidence validation; the output remains unverified and does not apply or commit a transition. A distinct explicit transition may persist a version commit when configured. Morphogenesis V2 remains an opt-in shadow preflight.
Read the operational orchestration contract ↗