KESSLERSHIELD-LEO-Conjunction-Debris-Avoidance-Flight

Inspiration

More than 50,000 pieces of space junk are currently in low earth orbit, moving at 27,000 km/h. At that speed, something the size of a marble can destroy a $250 million satellite. Enough collisions and you get a runaway cascade Kessler Syndrome that could make orbit unusable for generations.

Right now, assessing these collision risks is mostly manual work buried in non-interactive scripts. We built KesslerShield LEO for the OpenAI WebMCP Challenge, taking inspiration from NASA's 1970s Houston Mission Control, to explore how a human operator and an AI agent could actually work together in the browser on something this high-stakes.

What it does

KesslerShield LEO is a mission control dashboard and physics engine for LEO satellite collision avoidance. It registers five tools directly onto document.modelContext inspect_conjunction_geometry, evaluate_avoidance_options, stage_avoidance_burn, commit_orbital_maneuver, and emergency_auto_deconflict so an AI agent can inspect a conjunction and work out avoidance options on its own.

The physics runs client-side: a relative-motion solver evaluates retrograde, prograde, and out-of-plane burns in under 10ms, entirely in browser memory. The AI can evaluate risk and stage a maneuver, but firing the thrusters needs explicit sign-off from a human operator — that split is the core safety design.

Operators can switch between three views: a 3D Earth globe with vector coastlines, a 2D Houston-style ground-track map, and a B-plane diagram showing the 5km safety corridor. The whole thing is styled after 1970s mission control amber CRT phosphor (#FFB000) throughout.

How we built it

React, TypeScript, and Tailwind for the frontend, Three.js for the 3D globe, custom HTML5 canvas for the 2D ground-track map and B-plane diagram. Tool registration goes through document.modelContext for WebMCP, with a window.kesslerShieldMCP fallback bridge for browsers that don't support it natively. A Zustand store runs a 180ms physics loop for orbital periods, miss distances, and risk scoring without blocking the UI. Satellite data comes live from CelesTrak's NORAD feed, with telemetry and event logs cached in localStorage across reloads.

Challenges we ran into

Getting the CRT console look right without it turning into visual noise took a lot of restraint amber stayed reserved for live telemetry only. Running the orbital motion math smoothly inside a 180ms loop without stalling the 60fps Three.js canvas took some tuning.

Accomplishments we're proud of

Getting the physics solver under 10ms in-browser. Landing on a two-phase design where the AI evaluates and stages maneuvers but a human has to actually commit them. Getting all five WebMCP tools working end to end.

What we learned

WebMCP lets a web app expose real, typed capabilities to an LLM instead of just chat intent — that's a genuinely different integration model than a chatbot bolted onto a UI. For anything high-stakes, a two-phase design (AI proposes, human commits) is the right shape. And a 2D B-plane view does more for understanding collision geometry than the 3D globe does — it makes the vectors legible in a way 3D just doesn't.

What's next

Extending the solver to handle multi-satellite, multi-burn avoidance for whole constellations. Moving the screening step to WebGPU compute shaders so it can handle 100,000+ catalog objects in real time. Eventually, agent-to-agent negotiation protocols for deconfliction across different operators.