Separate proposal from action
An AI policy proposes a move or recovery. Deterministic rules validate it, and sensitive interventions wait for an operator decision.
05 / Deterministic autonomy simulation
See what an autonomous rover proposed, what the rules allowed, and what a person approved.
An interactive Unreal dispatch simulation with four recorded AI missions, deterministic replay, and a public showcase that keeps proposals, validation, and operator decisions separate.
Product brief
- Product
- Lunar Dispatch
- Status
- In progress
- Target user
- A person comparing software dispatch policies, fault recovery, and operator authority in a constrained lunar depot simulation.
- My role
- Product boundary, deterministic simulation design, Unreal implementation, command validation, replay evidence, operator interaction, and public showcase direction.
The problem
A policy can appear successful while hiding illegal commands, silent state changes, or approvals that never happened. The simulation needs to show what was proposed, what its rules accepted, and what the operator decided.
01 / Workflow
The product, end to end.
Follow the product from first input to a reviewable outcome.
- 01Choose one of four missions
- 02Run an offline policy or an approved live AI assessment
- 03Validate the proposal against simulation rules
- 04Hold sensitive recovery for operator approval
- 05Show the outcome
- 06Replay the exact recorded run
02 / Product surface
The interface carries the evidence.
Owned, locally generated product assets—no client screenshots or borrowed logos.
03 / Decisions
Architecture with a reason.
Unreal Engine 5.8 · C++ · Automation Specs · Seeded simulation · Next.js static showcase
Keep old and new evidence distinct
The showcase separates four live mission replays, baseline comparisons, and the earlier negative five-seed experiment instead of pooling incompatible runs.
Show the simulation boundary
The public site presents curated screenshots and replay evidence; it does not run the Unreal build or imply physical rover readiness.
Failure paths
What can go wrong is part of the product.
- A rover fails while carrying a job
- Communications are lost before a dispatch decision
- A policy proposes an illegal command
- An approval is rejected and the mission must hold safely
Verification
What supports the claim.
- 78 offline Unreal tests and four approved live missions with exact replay
- Corrected 22/22 mission batch with audited calls and cost
- Owner walkthrough of the packaged recovery flow
- Public static showcase with 14 tests and zero findings in its locked dependency audits
Portfolio boundary
Complete enough to review. Honest enough to trust.
- Public website is an evidence showcase, not a playable Unreal or live AI demo
- The four live missions are authored tests, not a broad reliability estimate
- Historical and current experiments use different timing and cannot be pooled
- No physical rover, sensor, radio, or hardware-in-the-loop validation
- No claim about real lunar operations or safety certification