The Orbital Zoning Framework has undergone a complete architectural rebuild. The original version — the one visualized elsewhere on this site — used RAAN (Right Ascension of the Ascending Node) as one of its classification axes. That approach worked as a proof of concept, but it had a fundamental flaw that I couldn't ignore once I understood it.
This post explains what was wrong, what replaced it, and how AI-assisted development made it possible for someone with a geography background to push into orbital mechanics territory.
The Flaw: RAAN Precession
In the original OZF, orbital space was divided using altitude, inclination, and RAAN bands. A zone ID looked like LEO-A550-I53-RAAN0_30. The problem is that RAAN isn't stable. Due to Earth's equatorial bulge (the J2 effect), RAAN precesses continuously:
- The ISS: -4.95°/day, completing a full 360° rotation every 72.7 days
- Starlink satellites: -4.49°/day, full rotation every 80 days
- GPS: -0.04°/day, full rotation every 25 years
For anything in LEO, a RAAN-based zone assignment is outdated within days. A satellite assigned to RAAN0_30 this week will be in RAAN30_60 next week. It's the equivalent of assigning a street address based on which direction the wind is blowing.
I realized this as I dug deeper into the orbital mechanics. The original architecture demonstrated the concept of spatial zoning for orbit, but the underlying parameter choice made it impractical for real-world use. Zones need to be stable.
The Fix: Proper Orbital Elements
The new OZF classifies orbits using proper orbital elements — quantities derived from the physics of orbital motion that remain nearly constant for decades. These are the true fingerprint of an orbit.
Every satellite has six parameters describing its orbit at any moment (osculating elements). These change constantly due to gravitational perturbations. Proper elements are computed by mathematically filtering out all the oscillations, leaving only the stable secular component. They represent what the orbit fundamentally is, not where it happens to be at this instant.
The Three Classification Axes
- Proper Semi-Major Axis (Altitude) — The mean orbital size. Nearly constant over a satellite's lifetime unless actively maneuvered.
- Proper Inclination — The mean tilt of the orbital plane. Starlink operates at ~53°. Sun-synchronous orbits at ~97°. Polar orbits near 90°.
- Proper Eccentricity — The mean shape of the orbit. Near zero means circular (most operational satellites). Higher values mean elliptical (Molniya, transfer orbits, debris).
A zone ID now looks like LEO-A550_600-I50_55-E0 — LEO region, 550–600 km altitude, 50–55° inclination, near-circular orbit. That's the Starlink operational shell, and that classification remains valid for the satellite's entire operational life.
AI-Assisted Development: Being Honest About the Process
I want to be direct about something. I'm a geographer by training. My degrees are in geography, geology, and environmental science. I am not an astrodynamicist. The mathematics behind Brouwer's J2 secular theory — the analytical method used to compute proper elements — is not something I could have implemented from my base knowledge alone.
Getting here took a combination of things: AI-assisted development tools, reaching out to researchers in the orbital mechanics and space sustainability field for guidance, and a lot of iteration.
The concept was mine. The problem identification was mine. Understanding why RAAN fails as a classification parameter came from working with the data and thinking spatially about what orbital zoning actually requires. But translating that understanding into working code that correctly implements Brouwer's 1959 theory, validates precession rates against known values, and processes 31,000+ satellites through the computation pipeline — that happened through iterative collaboration with AI development tools and conversations with people who know this domain far better than I do.
I don't think that diminishes the work. If anything, it's the point. The barrier to building something like this used to be a PhD in celestial mechanics. Now it's having the right question, the persistence to iterate, the willingness to reach out to experts, and the ability to validate results against known physics. The AI handles the mathematical implementation. I handle the architecture, the validation, and the decision-making about what the system should be.
The validation matters: our computed RAAN precession rates match observed values. The system correctly reproduces the critical inclination behavior at 63.4° (where argument of perigee stops precessing — the reason Molniya orbits exist). These aren't black-box outputs. They're testable predictions that match reality.
Current System
The system generates Situation Reports (SITREPs) for any satellite in the catalog — proper elements, zone assignment, congestion analysis, precession rates, and automated policy advisories. It processes the entire US Space Force catalog from Space-Track.org.
What's Next
The visualization on this site still shows the original RAAN-based model. Updating the 3D shells to reflect proper-element zones is a significant undertaking — the geometry is different when you remove RAAN as an axis. That work is ongoing.
The underlying system is live and processing real data. The science is sound, validated against known orbital behavior. The concept of zoning orbital space into stable, governable regions hasn't changed. The math underneath it just got a lot more rigorous.
Earlier posts on this blog describe the original RAAN-based architecture. They represent where the framework started. This is where it is now.