-
-
The mission begins with an AI-orchestrated mobile flood metabolism system designed to process, separate, reroute, and recover floodwater.
-
AI evaluates flood depth, contamination, priority targets, and network conditions to select routes, configure modules, and deploy the fleet.
-
Floodwater moves through debris, mud, contamination, and reusable-water stages while module saturation and mission metrics update live.
-
A support carrier removes the saturated pod, inserts a fresh module, and keeps the main vehicle processing without mission interruption.
-
Users select where recovered water should go while the AI updates routing paths, allocation logic, and non-potable quality constraints.
-
The final mission view compares severe flooding with restored hospital access, isolated contamination, and zero simulated interruption.
-
MFMS connects data inputs, AI mission planning, fleet operations, modular treatment, support logistics, and recovered-water reuse.
Inspiration## Inspiration
Cities usually respond to flooding by moving water somewhere else.
MFMS began with a different question:
What if a city could process floodwater while the disaster is still happening?
Instead of treating floodwater as one undifferentiated mass, MFMS imagines a mobile system that can intake water, separate debris, isolate mud and contamination, exchange full treatment modules, and redirect recovered water according to operational priorities.
The central idea is simple:
Do not just pump floodwater away. Metabolize it.
What it does
MFMS Mission Simulator Lite is an interactive operational concept prototype for AI-orchestrated urban flood response.
The user configures four disaster conditions:
- Water depth
- Contamination type
- Priority target
- Network condition
The AI Orchestration Layer then updates:
- Mission priority
- Route selection
- Blocked-road logic
- AI operating mode
- Intake power
- Safety radius
- Module configuration
- Support-vehicle deployment
During the mission, users can observe water-level reduction, processed-water volume, module saturation, and predicted time to capacity.
When the mud module approaches saturation, the AI dispatches a support carrier and coordinates a seven-stage hot-swap sequence:
- Saturation warning
- Support dispatch
- Vehicle arrival
- Full-pod removal
- Empty-pod insertion
- Integrity check
- Mission continuation
The main vehicle continues operating during the exchange.
After processing, recovered water can be routed toward:
- Emergency cooling
- Street cleaning
- Temporary storage
- Landscape irrigation
- Safe discharge
The final results page summarizes the route, AI mode, mission outcome, module exchange, water destination, and interruption time.
How we built it
The prototype was built with React, Vite, TypeScript, Tailwind CSS, React Router, Framer Motion, and local deterministic simulation rules.
A shared mission state connects the complete experience across multiple pages:
- Mission Command
- Vehicle Anatomy
- Live Metabolism
- Hot-Swap Logistics
- Recovered Water Routing
- Mission Results
- System Architecture
The current prototype does not call a live GPT model at runtime.
Instead, it uses a deterministic rule engine to demonstrate how AI orchestration could coordinate routes, vehicles, modular treatment pods, communications fallback, saturation prediction, and recovered-water allocation.
AI contribution
This project was created through an iterative collaboration between Alex, GPT-5.6, and Codex.
Alex
Alex originated the MFMS concept, system boundaries, visual direction, feature priorities, ethical limitations, and final product decisions.
GPT-5.6
GPT-5.6 translated the concept into the product architecture, mission flow, interaction logic, AI orchestration rules, visual specifications, safety boundaries, Codex implementation instructions, Demo review, README, and submission language.
Codex
Codex implemented the React, Vite, and TypeScript prototype in VS Code, including state synchronization, interactive mission logic, route updates, simulation controls, hot-swap sequencing, testing, debugging, responsive fixes, GitHub preparation, and deployment support.
This project was not produced through a single prompt. It emerged through an iterative loop of human direction, GPT-5.6 product reasoning, Codex implementation, testing, visual review, and correction.
GPT-5.6 is not embedded as a live runtime model inside the deployed prototype unless a real API is explicitly connected.
Challenges we ran into
The largest challenge was not creating individual screens.
It was making the entire mission behave as one connected system.
A change in water depth, contamination, priority target, or network condition had to remain consistent across route planning, vehicle deployment, module saturation, hot-swap logistics, water routing, and final results.
Another challenge was compressing a complex infrastructure concept into a short interactive Demo without presenting simulated values as validated engineering performance.
The final prototype therefore focuses on system behavior, decision flow, and orchestration rather than physical accuracy.
Accomplishments that we are proud of
- Built a complete end-to-end flood mission flow
- Connected disaster conditions to AI route and module decisions
- Implemented live module saturation and water-processing updates
- Created a seven-stage hot-swap sequence
- Preserved zero simulated mission interruption during module exchange
- Added recovered-water routing with dynamic allocation logic
- Maintained cross-page mission-state consistency
- Added 1×, 2×, 4×, 8×, and 16× simulation speeds
- Deployed a working prototype through GitHub and Vercel
What we learned
AI infrastructure concepts become easier to understand when people can change a condition and immediately see the system reorganize.
The most important part of the experience is not the vehicle itself.
It is the orchestration layer connecting:
- City conditions
- Mission priorities
- Vehicle routes
- Modular processing
- Support logistics
- Communications modes
- Water-resource destinations
Without AI, the vehicle is machinery.
With AI, the fleet becomes a coordinated urban organ.
What is next
Future development could explore:
- Real GIS integration
- Live weather and water-level feeds
- More detailed fleet coordination
- Engineering consultation
- Hydraulic and mechanical validation
- Environmental-treatment constraints
- Maintenance and pod-lifecycle planning
- Multi-district deployment simulation
These are future directions only and are not claimed by the current prototype.
Honest disclosure
MFMS Mission Simulator Lite is an operational concept prototype.
It demonstrates:
- System architecture
- AI mission orchestration
- Modular logistics
- Simulated decision flows
- Cross-page interaction
- Mission visualization
It is not:
- A validated hydraulic simulation
- A mechanical engineering model
- A CFD simulation
- A manufacturing-ready vehicle
- A certified environmental-treatment system
- A real GIS deployment
- A live emergency-response platform
- A drinking-water treatment system
- A government deployment
- A real-time sensor integration
All mission values are simulated and rule-driven.
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for MFMS — Mobile Flood Metabolism System
Built With
- framer-motion
- github
- gpt-5.6
- lucide-react
- react
- react-router
- tailwind-css
- typescript
- vercel
- vite
Log in or sign up for Devpost to join the conversation.