OrbitCall

OrbitCall’s architecture highlights sponsor roles in orbital analysis, AI coordination, multilingual communication, and infrastructure.

Inspiration

Thousands of satellites pass overhead every day. As orbit becomes more crowded, we wondered: when two satellites approach dangerously close, who decides which one should move?
The challenge is growing. ESA's 2025 report describes increasing collision-avoidance activity as orbital traffic and debris grow.
Coordination still involves directories, calls, and emails. Starlink's operator guide directs operators to a contact directory, a 24/7 phone, and urgent email. ESA also documented email-based coordination during the 2019 Aeolus–Starlink encounter.
Avoiding one encounter can create another. ISRO's report for 2025 records 82 LEO maneuver plans revised to avoid post-maneuver close approaches.
That inspired OrbitCall: a shared workspace to understand evidence, compare options, and coordinate across languages—with AI assistance and humans in control.

What it does

OrbitCall is designed around five steps:

Detect risks: Visualize assigned satellites against the real public catalog and screen for potential close approaches.
Compare options: AI explains incidents and evaluates maneuver proposals against each operator's private constraints.
Coordinate across languages: Operators discuss options through text or voice, with AI translation and summaries.
Approve and schedule: Humans approve the same proposal revision, then re-screen it before recording an authorized schedule.
Verify outcomes: Compare the plan with later observations and preserve the evidence and decision record.

How we built it

Cursor: We built OrbitCall in Cursor, using it to write, refactor, and debug code across the stack—from the Python orbital services to the Three.js globe and Convex backend.
Grok Bot for team coordination: We used Grok Bot to plan the project, divide work among teammates, and keep independently built components on track for integration.
Real space data: Every input is a public source, pinned to timestamped snapshots with source URLs and checksums for reproducibility:
- CelesTrak GP: Orbital elements for the full active group plus the Cosmos 2251, Iridium 33, and Fengyun-1C debris clouds, propagated with SGP4.
- CelesTrak SATCAT: Owner, launch, object type, and radar cross-section for each object.
- CelesTrak SOCRATES: A pinned conjunction list we use as an independent reference to validate our own screening.
- NASA ISS ephemeris (OEM): Real ISS trajectory data for our maneuver-verification replay.
- Earth context layers: NASA GIBS and Esri imagery, plus live space-weather and storm data from NOAA, GDACS, and EUMETSAT.
Interface and orbital calculations: Next.js, React, and Three.js power the globe; Python, FastAPI, and SGP4 handle screening and maneuver calculations.
Convex + Auth0: Convex manages shared state and backend jobs; Auth0 integration supports operator identity and access checks.
Anthropic Claude: Supports incident explanations, private-policy evaluation, and translation with critical-value checks.
Google Gemini: Provides coordination clarifications and summaries tied to shared evidence.
LiveKit + xAI + Cartesia: Inside the product, our voice pipeline combines LiveKit rooms, Grok speech recognition, Claude translation, Cartesia English/Mandarin speech, and Grok Russian speech.
Factory: Our scheduling design uses Droid to prepare file changes and record authorized artifacts after approval and re-screening.
Backboard + Tiger Data: We built company-scoped memory components and a historical-observation adapter with source and simulation labels.
DigitalOcean: Docker Compose and Caddy configurations support hosting orbital and voice services.

We are integrating these components into one shared operator workflow.

Challenges we ran into

Numerical edge cases: Rounding near distance thresholds and incomplete orbital propagation could produce misleading screening results.
Reliable AI output: Numbers, references, and evidence versions needed validation before accepting agent explanations.
Privacy and authority: Agents needed useful context without exposing private policies or gaining approval authority.
Service integration: API contracts, job states, deployment settings, and health checks had to match across independently developed components.
Coordinating our own team: Like satellite operators, we built components in parallel. Grok Bot helped us plan the work and keep integration on track.
Consistent history: Observation keys, timestamps, and retries needed careful handling to prevent duplicates and separate real from simulated data.

Accomplishments that we're proud of

Making real orbital data explorable: Built an interactive globe with a pinned CelesTrak catalog of 19,468 space objects.
Building calculation services: Implemented screening, maneuver candidates, re-screening, and verification, with successful service smoke tests.
Checking ourselves against a reference: Built a validation endpoint that measures our screening against CelesTrak's SOCRATES conjunction list.
Giving AI distinct roles: Built Claude analysis and private-policy evaluation, plus Gemini coordination and Grok checking demonstrated through live API calls.
Protecting operator privacy: Added company-scoped policies, assignment checks, and safeguards against stale agent results.
Strengthening reliability: Added automated tests and fixed numerical edge cases that could otherwise produce misleading screening results.

What we learned

AI needs clear boundaries: Deterministic code handles orbital calculations; models explain evidence and support discussion.
Details matter: Rounding, missing data, and stale results can change a screening verdict.
Coordination requires privacy: Operators need shared evidence without exposing private operational constraints.
Integration needs its own validation: Passing component tests does not prove the complete workflow works.

What's next for OrbitCall

We see OrbitCall growing into an international coordination network for satellite safety. Operators of a few spacecraft and teams managing large constellations should be able to work through a shared encounter without needing the same software, language, or internal policies.

Build with satellite operators. Run pilots around real decision workflows and measure the time needed to reach agreement, the effort spent reviewing alerts, and operators' confidence in the evidence.
Connect to operational data. Bring in operator-supplied trajectory predictions and Conjunction Data Messages, standardized reports describing close approaches and their uncertainty. Preserve source history so teams can see why their assessments differ.
Coordinate across fleets. Evaluate linked encounters together, so an avoidance maneuver is considered alongside its consequences for neighboring spacecraft and other operators.
Make cooperation easier across borders. Expand language support and help teams find the responsible operator, share their reasoning, and keep a record of the agreement. Company constraints stay private and approvals stay explicit.

The long-term goal is fewer avoidable maneuvers, less fuel spent resolving orbital conflicts, and a lower risk of creating more debris. That helps protect the communications, navigation, and Earth-observation services people rely on. Operators who have never worked together before should still be able to agree on a checked plan in time to act.