Claude's Corner: Constellation Space - The AI OS Running the Satellite Stack

Constellation Space (YC W2026) builds ConstellationOS, an ML-native satellite operations platform that processes 100,000 telemetry messages per second, predicts network failures five minutes out with 90%+ accuracy, and reroutes traffic in under two seconds. With ex-SpaceX, Blue Origin, and NASA founders and NVIDIA and OpenAI among their backers, they are positioning to be the default operating system for satellite constellations before 70,000 satellites hit orbit by 2030.

9 min read
Constellation Space homepage screenshot with Claude's Corner badge

TL;DR

Constellation Space builds ConstellationOS, an ML-native operating system that autonomously manages satellite constellations at megascale, predicting failures 5 minutes out with 90%+ accuracy and rerouting traffic in under 2 seconds. Founded by ex-SpaceX, Blue Origin, and NASA engineers and backed by NVIDIA and OpenAI, they are positioning to be the default operations platform before 70,000 satellites hit orbit by 2030. The federated learning architecture creates a data moat that compounds with every new operator signing on.

7.4
B

Build difficulty

The satellite industry has a dirty secret: most of its failures happen in software, not hardware. Panels deploy correctly, propulsion fires on cue, and payloads reach orbit intact. But somewhere in the seven-layer stack between a 40-node ground station and a constellation of 400 birds, a timing mismatch cascades into a link outage that takes an operator team six manual hours to diagnose. That is a $2.5 billion annual industry problem nobody wanted to talk about while SpaceX was still just launching rockets.

Constellation Space (YC W2026) is the bet that someone needs to build an actual operating system for that stack before 2030 drops another 60,000 satellites into orbit. Founded by engineers from SpaceX, Blue Origin, and NASA, the company's ConstellationOS is an ML-native platform that ingests telemetry at 100,000 messages per second, predicts link failures five minutes before they happen, and reroutes traffic autonomously in under two seconds. NVIDIA and OpenAI are among the investors. That is not an accident.

We are at the inflection point. There are about 10,000 satellites in orbit today. By 2030, that number hits 70,000, driven by Starlink Phase 2, Amazon Kuiper, and a dozen national broadband programs. Ground-based human operators who currently manage a 300-bird constellation will be completely overwhelmed at 3,000. The only path is autonomous orchestration, and nobody has built the infrastructure layer yet.

What They Do

ConstellationOS sits between the satellite and the operator. It ingests everything: ground telemetry, space weather feeds, weather radar data, IoT sensor streams from ground stations. It normalizes this chaos through a unified API so operators stop writing bespoke middleware scripts every time they add a new satellite to the constellation. Then it does something the industry has not had before: it predicts what is going to go wrong before it does.

The product has three layers, cleanly named Connect, Predict, and Act.

Connect is the data ingestion and normalization layer. Every satellite operator currently runs custom middleware to pull telemetry into something they can reason about. ConstellationOS replaces that with a standardized schema and single API endpoint. Unglamorous work, but it is the foundation that makes everything else possible. Without a clean, consistent data pipeline, prediction models are just modeling noise.

Predict is where the ML runs. The model forecasts signal-to-noise ratio degradation, traffic congestion patterns, weather interference windows, RF jamming events, and conjunction risks hours in advance. The 90%-plus accuracy figure applies at the five-minute prediction horizon, where there is still time to act before any data loss occurs. Beyond five minutes, the founders openly admit prediction quality degrades significantly. That is an honest acknowledgment that not everything in space is solvable with a bigger model.

Act is the orchestration layer. When Predict fires a warning, Act executes policy-based responses without waiting for a human: rerouting traffic around a failing link, isolating degraded data streams, handing off connections between ground stations. Every action is logged with full audit trails. That audit requirement is not bureaucratic overhead for Constellation. It is a product feature. Any operator selling services to the US government needs a complete, tamper-evident record of every autonomous decision the system makes.

Current customers are in the design-partner phase. The go-to-market uses a 30-day shadow pilot where ConstellationOS runs alongside existing operations in passive mode, observing without touching production. It is the right approach for a platform touching critical infrastructure: show the prediction accuracy on real traffic before asking for the orchestration keys.

How It Works

The technical architecture is what separates this from the dozens of satellite monitoring dashboards that exist already. This is not a transformer fine-tuned on telemetry logs. The founders built a hybrid physics-ML system that treats orbital mechanics and RF propagation physics as the ground-truth baseline and trains ML to learn the deviations from that baseline.

State management uses a Continuous Extended Kalman Filter. The physics model, including link budget equations, ITU atmospheric attenuation standards, and orbital propagation calculations, serves as the persistent prediction baseline. The ML layer learns residuals: the measurable differences between what physics says should happen and what the actual telemetry shows. A constellation link degrading faster than the physics model predicts is showing you something real. A deviation that matches the ITU atmospheric model for current weather conditions is just weather.

The data ingestion pipeline handles one of the most frustrating realities of satellite operations: intermittent connectivity. At low Earth orbit, a satellite has a ground station window of roughly 5 to 10 minutes per pass. Telemetry arrives in bursts, goes silent for 90 minutes, arrives again. Traditional monitoring systems designed for always-on cloud infrastructure fail badly here. ConstellationOS prioritizes data freshness, drops stale measurements before they can bias the model, scores sensor reliability at the edge before data reaches the central pipeline, and falls back to physics-only predictions when telemetry is unavailable rather than guessing based on stale state.

The architecture decision that will likely matter most long-term is federated learning. Satellite operators guard their telemetry jealously. It contains their orbital scheduling decisions, link capacity planning, and failure histories. Raw data sharing is not a conversation any serious operator will have. Constellation's federated approach runs local model training on each operator's private infrastructure, then aggregates only high-level pattern abstractions across the network. No raw telemetry ever leaves an operator's environment. The aggregate model improves with each new operator, enabling transfer learning across different orbit altitudes, frequency bands, and hardware generations.

That federated design has a network effect built into it. The first operator to join gets a model trained only on their own data. The tenth gets a model that has seen pattern abstractions from nine different constellations. The hundredth gets something that has seen enough edge-case failure modes to be genuinely robust. The data moat compounds automatically as adoption grows.

Deployment supports on-premises, AWS GovCloud, and standard commercial cloud. The GovCloud path is not optional for defense customers: FedRAMP authorization requirements mean classified ground station networks cannot touch commercial cloud environments without a dedicated secure deployment option.

The Technical Team

Four founders, all early in their careers. Kamran Majid (CEO) has direct SpaceX satellite software experience and NASA internships. Raaid Kabir (CTO) spent time as an embedded software engineer at Blue Origin. Laith Altarabishi brings an MS in electrical and computer engineering from UT Austin with ML and systems research. Omeed Tehrani built ML infrastructure at Capital One. The team distribution is deliberate: space domain expertise meets ML infrastructure production engineering.

The $6.5 million seed round, led by SGH Capital in March 2026, also brought in NVIDIA, OpenAI, Standard Capital, Samsung Next, Gladebrook Capital, and Fellows Fund. NVIDIA's presence signals that the training infrastructure Constellation will consume is significant. OpenAI's interest is worth noting: either they see satellite networks as a critical AI infrastructure dependency, or they see something in this team worth backing early. Neither explanation is boring.

Difficulty Score

Scoring by layer:

  • ML/AI (9/10): Physics-ML hybrid with a Continuous Extended Kalman Filter, federated learning across heterogeneous orbit types and frequency bands, real-time failure prediction on high-velocity streaming telemetry. The ML here is not decorative.
  • Data (8/10): Multi-orbit, multi-frequency telemetry with structural intermittency. Getting labeled failure data requires real operator partnerships and months of observation. The data moat cannot be purchased or scraped.
  • Backend (8/10): 100,000 messages per second ingestion with sub-2-second decision latency and FedRAMP-grade security requirements. Getting this wrong in production means dropped satellite links.
  • Frontend (4/10): Mission operations dashboards for specialists. Complex enough, but not where the differentiation lives.
  • DevOps (8/10): Multi-environment deployment, GovCloud compliance, on-premises support for classified networks, high-availability SLAs for infrastructure that cannot have scheduled maintenance windows.

The Moat

Three things compound here, and each gets harder to replicate as Constellation grows.

The data is the clearest moat. Predicting satellite network failures with 90% accuracy requires training data from actual satellite network failures. Getting that data means convincing operators to share telemetry access, even in a federated setup where raw data never leaves their systems. Those first operator relationships take months and require team credibility that comes from having actually operated these systems at SpaceX and Blue Origin. A well-funded competitor starting today cannot buy that credibility.

The physics expertise is the second layer. The hybrid physics-ML approach is not assembled from open-source libraries. The ITU atmospheric models, the link budget calculations, the orbital propagation math that feeds the Kalman filter baseline: these are public standards, but knowing which ones matter in practice and what failure signatures look like in real telemetry requires years of domain experience. The founders have it. A team that does not would spend a year building something that looks right in simulation and fails in production.

The defense relationships are the third moat layer and the slowest to build. Government satellite contracts run on multi-year procurement cycles. A single reference from a defense-adjacent operator unlocks multiple follow-on contracts. Constellation is building those references now, at the 10,000-satellite moment, before the market gets crowded with alternatives. The window for becoming the default platform is narrow.

StartupHub.ai tracks 967 companies in the space and satellite sector. The highest-scoring incumbents in that set are operators and launch providers, not software infrastructure companies. There is no pure-play satellite operations platform in our database targeting the specific prediction-and-orchestration layer Constellation is building. That gap is real and, for now, uncontested.

Replicability Score: 75 out of 100

Building a system that ingests satellite telemetry and shows trend dashboards takes a year of engineering work. Building one that predicts failures with 90% accuracy on a live constellation with hardware from five different manufacturers across three orbit regimes requires training data that cannot be synthesized, physics expertise that cannot be hired quickly, and operator trust that takes years. The federated learning design means the data moat grows automatically with each operator added. Score: 75 out of 100.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# Build ConstellationOS with Claude Code: 7-Step Developer Guide

## Step 1: Design the Telemetry Schema

Start with a TimescaleDB hypertable for time-series telemetry. Core fields: `satellite_id`, `timestamp`, `snr_db`, `ber`, `rssi_dbm`, `doppler_shift_hz`, `ground_station_id`, `orbital_elements_json`, `sensor_reliability_score`. Partition by satellite_id and time for efficient range queries. Add a `telemetry_gaps` materialized view to track intermittency patterns per satellite.

## Step 2: Build the Telemetry Ingestion API

FastAPI endpoint at `/v1/telemetry/ingest` accepting both real-time WebSocket streams and batch JSON uploads (for post-pass downlinks). Implement freshness scoring: reject telemetry older than the max_staleness_seconds threshold for the given orbit altitude class (LEO = 600s, MEO = 3600s, GEO = 7200s). Score sensor reliability using an exponential moving average of historical accuracy per sensor_id. Publish to a Kafka topic for downstream processing.

## Step 3: Implement the Physics Baseline

Code the link budget engine using ITU-R P.618 atmospheric attenuation models, Friis free-space path loss, and a Keplerian two-body propagation model (upgrade to SGP4 for production). Wrap this in a Continuous Extended Kalman Filter where the physics prediction serves as the state transition function. The KF produces expected telemetry values every 10 seconds; the difference between expected and actual is your anomaly signal.

## Step 4: Train the Anomaly Detection Models

Build LSTM models on the telemetry residuals (actual minus KF-predicted) for temporal anomaly detection. Label historical failures using operator-provided incident logs. Use active learning to prioritize labeling of rare edge cases. For federated training: implement FedAvg across operator-local models, sharing only gradient updates (not raw data). Use differential privacy (epsilon=0.1) on gradient uploads for defense customers.

## Step 5: Build the Orchestration Engine

Policy engine with a rules DSL: `IF predicted_snr_degradation > threshold AND time_to_failure < 300s THEN reroute_to(backup_link)`. Implement as a priority queue of pending actions with conflict resolution (two rules cannot both reroute the same stream). Every executed action writes an immutable audit log entry. Add a dry-run mode for the shadow-pilot onboarding flow.

## Step 6: API Gateway and Mission Ops Dashboard

GraphQL API over the orchestration engine. React dashboard with a 3D constellation map (CesiumJS for orbital visualization), link health heatmap, failure prediction timeline, and alert history. WebSocket push for real-time updates. Auth via SAML 2.0 SSO for enterprise customers. Export audit logs as signed PDFs for compliance.

## Step 7: Multi-Environment Deployment

Kubernetes with Helm charts parameterized for three deployment targets: commercial cloud (EKS/GKE), AWS GovCloud (US-West), and on-premises (bare-metal Kubernetes). FedRAMP-ready access control from day one: IAM roles, encryption at rest (AES-256), encryption in transit (TLS 1.3), and CloudTrail-equivalent audit logging. Set up operator-level data isolation at the namespace layer for the federated learning setup so no cross-operator data leakage is architecturally possible.
claude-code-skills.md