A model can recommend a sensible action without possessing authority to execute it. An executor can accept a command without completing it. A robot can move without satisfying a delivery objective. These distinctions motivate MissionOS: a mission control layer that treats proposals, approvals, command transmission, acknowledgements, observed effects, and completion as separate facts. Its governing sequence is explicit: LLM judges; Human approves; Rules constrain; Executor acts; Verifier checks; Repair loops. [1]
The research question is architectural: can useful AI judgment be connected to robotic execution while retaining an inspectable boundary at every transition? This article describes the implemented design and its published simulator evidence. It is a technical synthesis of a public research repository, rather than a claim of formal verification or peer-reviewed certification.
" }, { "id": "methods", "title": "2. Methods: Judgment, Authorization, and Evidence", "html": "Recovery proposes a concrete bounded response to an incident. Action Feasibility evaluates that candidate. MissionAssuranceAgent then receives the proposal, mission progress, observations, constraints, uncertainty, and source references in a backend-neutral MissionSituation. It recommends continue, hold, replan, return, abort, or operator escalation. A feasible maneuver may still be inappropriate for the mission; technical feasibility and mission alignment answer different questions. The Assurance agent cannot replace the Recovery action or invent new motor parameters. [2]
Judgment and continuation are linked but separate workflows. The judgment graph records what the agents actually considered. A declared downstream sequence is not evidence that execution followed. Continuation validates the frozen graph, observes authorization, performs fresh Rules checks, invokes the executor, verifies the outcome, and attempts to obtain a newer observation. Re-reading the same telemetry cursor cannot manufacture a new post-dispatch situation.
Individual approval remains one authorization mode. An alternative bounded policy binds an exact mission contract, simulator scope, permitted actions and parameters, preservation conditions, expiry, observation freshness, and cumulative action limits. The human approves the policy version; Assurance cannot amend or extend it. Human and shadow modes still require individual action approval. Bounded mode may omit that additional approval only after a successful reservation against the approved policy. [3]
Reservations count attempted dispatches, including failures. A crash does not refund authority, and replacing a policy does not reset a mission's accumulated budget. Exact judged parameters remain bound even when a different parameter value would also be inside the permitted range. Preservation predicates must be freshly observed, and current truth alone is insufficient: candidate feasibility and subsequent verification must also address preservation.
A stored record establishes that a record exists. Promoting its claims to runtime facts requires valid invocation evidence. MissionOS preserves an artifact-level claim separately from its runtime counterpart. The invocation kind, output material, and verifiable hashes matter; a digest with no readable preimage does not suffice. A loopback HTTP result cannot alone promote a dispatch-executed claim. Success additionally requires a zero process exit code where applicable. [4]
" }, { "id": "results", "title": "3. Results: A Bounded Policy Comparison", "html": "The published TurtleBot3 comparison used the same instruction and both fault-injection flags in individual-approval and bounded-policy modes. Each mode completed all seven route segments after two verified recovery cycles, involving obstacle avoidance and rerouting. Each recovery recorded acknowledgement, observed executor effect, outcome verification, and permission to resume. The study comprised one completed episode per mode. [3]
| Observed boundary | Individual approval | Bounded policy |
|---|---|---|
| Initial mission approval | 1 | 1 |
| Initial policy approval | 0 | 1 |
| Individual recovery approvals | 2 | 0 |
| Total approval boundaries | 3 | 2 |
| Verified recovery cycles | 2 | 2 |
| Completed route segments | 7/7 | 7/7 |
The bounded continuations explicitly recorded policy authorization and the absence of individual action approval. They did not manufacture a human click. These simulator results preceded the public port. Subsequent public-port checks included 2,517 tests, a 15-subprocess policy fixture smoke, and a real loopback Gateway smoke with fixture judgments and an executor queue. Those checks exercised software boundaries; they were not a new policy-driven Nav2 completion.
" }, { "id": "discussion", "title": "4. Discussion", "html": "The main contribution is an evidence structure that permits delegated judgment without merging authority and observation. A model can influence a mission decision while deterministic checks still refuse execution after state drift, expiry, or exhausted budget. The same structure makes negative outcomes legible: an invalid judgment, rejected dispatch, acknowledged command, and unsuccessful recovery can retain different explanations.
The small comparison shows one fewer required approval boundary in a repeated-recovery episode. It does not establish reduced operator workload. The individually approved episode paused while its comparison client was repaired, so elapsed-time comparison would be misleading. The most defensible interpretation is that bounded authorization operated through two recoveries while preserving distinct approval semantics.
" }, { "id": "limitations", "title": "5. Limitations", "html": "These are simulator and software-contract results. Physical execution, delivery completion, and safety certification remain outside the policy comparison. The local operator label relies on operating-system account trust rather than authenticated identity. Cancellation after a committed reservation does not necessarily cancel the action already in flight; an independent emergency-stop boundary remains necessary. The published policy integration covers TurtleBot3, while the documented PX4 path retains individual approval.
Evidence completeness is also bounded. Both recovery graph hashes and verified continuations were retained, but only the latest full raw Assurance proposal was preserved in the final policy artifact. This limits retrospective analysis of every model judgment. Future comparisons should archive each incident graph at creation and measure operator effort under matched, uninterrupted conditions.
" }, { "id": "conclusion", "title": "6. Conclusion", "html": "MissionOS demonstrates a concrete way to connect AI mission judgment to bounded simulator execution without treating a proposal, approval, acknowledgement, or observed motion as interchangeable with success. Its next evidential step is a matched evaluation of decision quality and operator burden, using the same disturbances and authorization envelope while retaining complete per-incident records.
" } ], "sources": [ { "id": "s1", "title": "Mission Assurance: concept", "url": "https://github.com/pome223/missionos/blob/7f0128491ac1e998c05580b50707ee8cab7543c6/docs/concepts/mission-assurance.md", "detail": "Human-facing responsibility split and observation-to-verification sequence." }, { "id": "s2", "title": "MissionAssuranceAgent implementation contract", "url": "https://github.com/pome223/missionos/blob/7f0128491ac1e998c05580b50707ee8cab7543c6/docs/agents/mission-assurance-agent-contract.md", "detail": "Judgment and continuation graphs, frozen inputs, semantic responses, and dispatch-time checks." }, { "id": "s3", "title": "Mission Assurance policy v1 contract", "url": "https://github.com/pome223/missionos/blob/7f0128491ac1e998c05580b50707ee8cab7543c6/docs/agents/assurance-policy.md", "detail": "Policy semantics and the September 5 comparison; simulator evidence and public-port fixture validation are separate." }, { "id": "s4", "title": "Claim semantics", "url": "https://github.com/pome223/missionos/blob/7f0128491ac1e998c05580b50707ee8cab7543c6/docs/agents/claim-semantics.md", "detail": "Artifact-versus-runtime claims, invocation evidence, and completion scopes." } ] }