🛰️ Orbital Computation · 2026-04-25
🛰️ Orbital Computation Watcher — 2026-04-25
🛰️ Orbital Computation Watcher — 2026-04-25
Table of Contents
- 🚀 SpaceX Files for 1 Million AI Satellites and Acquires xAI to Close the Orbital Compute Stack
- ⚡ SpaceNews April 30 Summit Brings FCC Chief, Power Startups, and Compute Architects Under One Roof
- 🎯 Operation Epic Fury: The Kill Chain That Ran on Orbital Infrastructure While AI Got All the Credit
- 🏗️ Commercial Station Developers Defend Their Market at Space Symposium as NASA CLD Pivot Threatens Timeline
- 🏛️ AI-Routed Constellations Are Making Political Triage on Brittle Commercial Balance Sheets
- ☀️ The Orbital Compute Power Problem: Solar Advantage, Thermal Ceiling, and the Carbon Cost of Launching Racks
🚀 SpaceX Files for 1 Million AI Satellites and Acquires xAI to Close the Orbital Compute Stack
SpaceX's FCC application for a one-million-satellite orbital data center constellation—filed in early February 2026, covering 500 to 2,000 kilometers in both sun-synchronous and mid-inclination orbits—is the first major constellation filing that treats compute, not connectivity, as the primary service. Sun-synchronous satellites would orient toward near-constant solar illumination to sustain AI inference workloads continuously; mid-inclination satellites would absorb demand peaks. Neither technical architecture nor power budgets appeared in the application. The Kardashev II framing ("a first step toward becoming a Kardashev Type II civilization") was plentiful; engineering specifics were not. That ambiguity became structurally less relevant weeks later when Musk announced that SpaceX would acquire xAI, converting the FCC filing into the orbital compute layer of a vertically integrated AI company: launch infrastructure, connectivity (Starlink), orbital compute nodes, and—post-close—the AI inference workloads running on them. Vertical integration removes the commercial gap that confronts pure-play orbital compute startups, who must convince enterprise customers that space-based inference beats terrestrial alternatives before either latency advantage or cost competitiveness has been demonstrated at scale.
Deloitte's 2026 AI data center power analysis projects US AI data center consumption growing from 4 GW in 2024 to 123 GW by 2035—a 30× increase driven by inference at scale. Musk's memo claim—"My estimate is that within 2 to 3 years, the lowest cost way to generate AI compute will be in space"—targets that demand directly, arguing that perpetual solar illumination in sun-synchronous orbit eliminates the grid constraint, land-use costs, and permitting delays that limit terrestrial data center siting. The "always sunny" framing is accurate as far as it goes. What it elides is thermal rejection: in vacuum, radiator panels are the only heat transfer mechanism, and current orbital thermal budgets constrain AI accelerator deployments to power envelopes an order of magnitude below terrestrial rack density. Solving compute density in orbit requires solving thermal rejection first. No announced program is primarily attacking that constraint.
In the xAI all-hands session, Musk described a lunar manufacturing scenario: a mass driver launching AI data center satellites into deep space from the Moon's surface, reaching 500–1,000 TW/year of orbital compute. Mars advocate Robert Zubrin called the lunar city claim "nonsense", arguing Moon resources are insufficient for self-sustaining manufacturing and the financial model against terrestrial data centers hasn't closed.
Musk's lunar pivot announcement caps a structural reversal: for a decade, Starlink was the revenue engine funding Mars. The new thesis makes orbital AI data centers the revenue engine. Whether this becomes infrastructure or a funding narrative will become legible within 18 months as the xAI acquisition closes and the FCC filing enters technical review.
Sources:
- The Space Review: Musk's Moon mania
- SpaceX xAI acquisition memo
- Deloitte: AI Data Centers Jolt Power Demand
⚡ SpaceNews April 30 Summit Brings FCC Chief, Power Startups, and Compute Architects Under One Roof
SpaceNews convenes an in-person summit on orbital computing in Washington, D.C. this Wednesday, April 30—the second event in its Orbital Data Centers series—and the speaker lineup diagrams exactly where the field stands. Jay Schwarz, Chief of the FCC's Space Bureau, shares the agenda with Marc Berte, founder of Overview Energy, a startup working on space power architectures, and Andrew Rush, co-founder of Star Catcher, whose Suncatcher mission—conducted jointly with Planet—will test wireless optical power transfer between satellites in orbit. The pairing is not accidental. On-orbit computing has moved from technology demonstration into the zone where regulatory frameworks and power infrastructure get designed simultaneously, and the presence of the FCC's top space official alongside power and compute entrepreneurs signals that institutional engagement has begun in earnest.
The summit's panel architecture exposes the actual constraint stack of the field. "Powering compute in space: solar ambitions and nuclear realities" (with Berte and additional confirmed speakers) maps the energy problem: solar provides continuous power in sun-synchronous orbit but tops out at mass-constrained watt-per-kilogram ratios that limit compute density; nuclear offers higher power density but requires regulatory pathways—specifically, nuclear launch approval procedures managed across multiple federal agencies—that remain incomplete for commercial applications. The Star Catcher / Planet Suncatcher session represents a third path: beaming power wirelessly between satellites to enable cooperative compute nodes that don't each need to carry their own full power infrastructure.
"Processing in orbit: how much compute stays in space?" (Kelsey Litzner, Aerospace Corporation; Paul Tilghman, CTO of Voyager Technologies; Michael Pierce, Technology Strategy Partners) addresses the architectural partition question that will define the market structure for the next five years. The decision about which workloads benefit from orbital placement—latency-sensitive inference, intermittent-connectivity environments, Earth observation processing that avoids downlinking raw data—versus which pay a latency penalty for no advantage is not yet analytically settled. Tilghman's presence as Voyager's CTO is significant: Voyager is simultaneously developing the Starlab commercial space station, operating defense satellite services, and now speaking on orbital compute architecture. That vertical span is the pattern SpaceX is attempting at much larger scale.
Delian Asparouhov's fireside chat brings the commercial thesis into sharpest focus. Varda Space Industries demonstrated that microgravity manufacturing of pharmaceuticals—specifically ritonavir crystal production in orbit with pharmaceutical-grade purity—is commercially viable. The orbital compute question is whether the same logic applies to inference: do specific AI workloads have properties—continuous power access, sovereign data routing, latency advantages for regional inference—that make orbital placement genuinely superior rather than merely novel? Asparouhov's Founders Fund background means this is not an academic question. Whether Varda's answer for pharmaceuticals translates to compute is what the summit convenes to examine. The most consequential output won't be any single announcement but the convergence of regulatory, power, and compute expertise in a single room five days before SpaceX's FCC filing enters heightened scrutiny.
Sources:
---🎯 Operation Epic Fury: The Kill Chain That Ran on Orbital Infrastructure While AI Got All the Credit
Operation Epic Fury, which began February 28, 2026, produced the most analytically significant demonstration in the history of orbital compute infrastructure: a targeting architecture in which artificial intelligence was the least interesting component. When Pentagon Chief Digital and AI Officer Cameron Stanley demonstrated Maven publicly in March, he described the process with deliberate simplicity—three clicks, left-right-left, and a detection became a formal strike package. What the demonstration obscured was the full orbital architecture running underneath it: imaging satellites providing the visual picture, SATCOM carrying the data, signals intelligence satellites intercepting the electronic environment, GPS timing synchronizing the system. Remove the satellites and Maven processes nothing. The drones navigate blind. Precision munitions revert to ballistic trajectories. The targeting cycle is not "an AI system enabled by some satellites"—it is a space architecture with an AI processing layer on top of it.
What Bharath Gopalaswamy's analysis in The Space Review identifies as the genuinely new development in Epic Fury is not that space proved decisive—that was anticipated—but the speed at which the orbital and terrestrial layers fused into a single operational system with no meaningful seam. In previous conflicts, space enabled the fight. In Epic Fury, the sensor, the processor, and the weapon operated as a continuous cycle refreshing and executing at speeds human deliberation cannot match.
Iran's positioning illuminates the geopolitical depth of the orbital compute stack. Iran's military completed a decade-long transition to BeiDou as its primary navigation system—a strategic calculation made after the 1996 Taiwan Strait Crisis, when Beijing concluded that dependence on American GPS was an existential vulnerability rather than a manageable risk. By the time Epic Fury began, Iranian precision strike capability ran on Chinese timing and positioning data. China's Jilin-1 commercial constellation—officially an Earth observation service—simultaneously documented US and allied strike patterns, aircraft deployments, and logistics cycles throughout the conflict, feeding a surveillance architecture that amplified Iranian targeting precision. Chinese satellites enabled both sides of the battlefield while Beijing bore no legal accountability for the strikes those satellites made possible. This is the model China has now validated: proxy warfare conducted entirely through the space domain, with no formal involvement that would trigger alliance obligations or escalation thresholds.
The next-order consequence is the confrontation scenario Western analysts are least prepared for: an orbital layer that is genuinely contested rather than merely disrupted at the margins. The three-click kill chain that ran above Iran required specific orbital conditions—an imaging constellation that could see the target, a communications architecture that could carry the data, a positioning system that could synchronize the weapon. Each condition is something China has invested specifically in being able to deny. An AI navigating without orbital data produces catastrophic error at machine speed—not three clicks.
Sources:
- The Space Review: When the orbital layer is the kill chain
- BeiDou Navigation Satellite System
- Jilin-1 / Chang Guang Satellite Technology
🏗️ Commercial Station Developers Defend Their Market at Space Symposium as NASA CLD Pivot Threatens Timeline
Last week's Space Symposium in Colorado Springs (April 14-17, 2026) placed commercial space station developers in an unusual position: defending the existence of their market to NASA rather than pitching for contracts. The backdrop was a NASA request for information issued last month proposing major changes to the Commercial Low Earth Orbit Destinations program, citing agency concerns that commercial markets for orbital stations had not emerged as anticipated. Three primary developers—Starlab Space, Axiom Space, and Vast—arrived at the conference not with vision decks but with market evidence.
Starlab Space CEO Marshall Smith disclosed that his company submitted 390 pages of independent analysis, research, data, and contract evidence in response to the RFI. Joint venture partners—Airbus, Mitsubishi, MDA Space, and Voyager Technologies—have committed investment based on a business case that closes without revenue from in-space manufacturing, tourism, or media, the hypothetical markets NASA was skeptical of. Voyager separately announced that Starlab's commercial payload capacity is "fully reserved" three years before the station's scheduled launch—a booking depth that implies either genuine commercial demand or extraordinary speculative positioning.
Vast CEO Max Haot offered the most precise financial characterization at the conference. Haven-1—a single-module station targeting first-quarter 2027 launch—needs 40% to 60% of NASA CLD development funding and one six-month NASA mission per year, plus a 30-day mission from another customer, to reach profitability. "With that alone, and with zero dollars from in-space manufacturing, sponsorship, and tourism, Vast can be profitable," Haot said. The $1.5 billion CLD budget included in NASA's FY2027 proposal for FY2031—a $1 billion transfer from retiring ISS operations—validates the revenue premise if NASA allocates it. Axiom CEO Jonathan Cirtain, whose company has flown four private astronaut missions to ISS with a fifth PAM scheduled for early 2027, anchored his case on the sovereign astronaut market: nations that want to maintain astronaut programs and Artemis access regardless of tourism or manufacturing revenue.
The orbital compute implication cuts across all three stations. Commercial stations are, in their mature form, the residential infrastructure of the orbital economy—the nodes where humans service equipment, perform maintenance, and anchor manufacturing and compute operations that cannot be robustly managed autonomously from Earth. NASA's proposed alternative—a government-built "core module" to which commercial modules would dock—would take 7-10 years by Haot's estimate, pushing the residential infrastructure layer out to the mid-2030s and displacing the timeline for Western orbital economy development while Chinese commercial orbital infrastructure continues development independently. The CLD decision is not a NASA human spaceflight choice in isolation. It is a decision about whether the Western orbital economy gets anchored infrastructure in the early 2030s or the late 2030s—and whether orbital compute development inherits a serviceable residential layer or has to wait.
Sources:
- The Space Review: Commercial space station developers make their business case
- Starlab Space
- Vast Space
🏛️ AI-Routed Constellations Are Making Political Triage on Brittle Commercial Balance Sheets
Gopalaswamy and Col. Daniel Dant's analysis names the governance failure at the center of the orbital AI economy with precision: commercial satellite operators providing broadband, imagery, and radiofrequency sensing have become "golden domes"—AI-enabled strategic infrastructure that sits above national economies and militaries—while their owners still run them as growth-stage technology companies on venture capital, quarterly revenue targets, and brittle balance sheets. Operation Epic Fury tested this mismatch in real time: as traffic spiked across commercial constellation platforms and jamming, cyber interference, and regulatory pressure simultaneously constrained capacity, AI-driven routing systems decided within milliseconds whose data moved, whose images were refreshed, and whose connections degraded. No minister or general was manually allocating satellites. The optimization model made the choices, and the choices had geopolitical consequences that the model was not designed to anticipate.
The structural problem is that AI makes these constellations economically viable while also making them opaque. The same AI "brain" that enables a single constellation to serve defense, enterprise, and consumer markets concurrently also encodes triage priorities that, under crisis conditions, produce outcomes that look like political choices: one set of users preserved, another effectively cut off. The failure mode is not deliberate political choice—it is that an operator's throughput-optimizing model makes triage choices automatically, faster than any governance mechanism can intervene.
Board-level oversight at commercial space operators runs on ARPU, churn, and launch cadence metrics that capture none of the relevant variables: geopolitical exposure, sanctions risk, the reputational cost of routing decisions made under fire. When a constellation's AI policy denies service to a contested region, it satisfies one regulator and enrages another. When a company prioritizes a state's military traffic, it invites cyber retaliation from that state's adversaries. The decisions encoding those outcomes are in optimization models, not manual procedures, and they execute before consequences can be reviewed. Deloitte's 123 GW AI demand projection means orbital constellations are being pulled into the power-grid governance category before frameworks for that role exist.
Capital structure compounds the fragility. Commercial constellation operators are highly leveraged and asset-intensive; a single geopolitical shock can threaten not just the income statement but the infrastructure multiple governments quietly assume will be available in the next crisis. Gopalaswamy and Dant's four structural responses—crisis stress-testing against revenue projections, explicit resilience product tiers, AI/geopolitics board competence, and political risk as investment metric—are none of them technically difficult. All require operators to acknowledge they are running sovereign infrastructure on a commercial balance sheet, and that the gap between those two identities is where the next governance failure will occur.
Sources:
---☀️ The Orbital Compute Power Problem: Solar Advantage, Thermal Ceiling, and the Carbon Cost of Launching Racks
The power case for orbital compute is structurally sound and structurally misleading in the same sentence. Structurally sound: sun-synchronous LEO satellites receive near-continuous solar illumination, escaping the grid connection costs, land-use permitting delays, and renewable energy intermittency that increasingly constrain terrestrial data center siting. Deloitte's projection of 123 GW of US AI data center demand by 2035, versus 4 GW in 2024, makes the terrestrial constraint real enough that any architecture that sidesteps it has genuine structural appeal. Structurally misleading: the power advantage in orbit runs directly into a harder constraint that the "always sunny" framing consistently elides—thermal rejection. Terrestrial data centers dump heat into air or water at scale. In vacuum, radiation is the only heat transfer mechanism, and radiator panels operate at temperatures and efficiencies that impose a binding ceiling on compute density per kilogram of spacecraft mass. The SpaceNews April 30 summit panel on "powering compute in space: solar ambitions and nuclear realities" is framed exactly right: both solutions are real, and both are still years from resolving the thermal-compute-density problem at commercial scale.
KubeSpace (arXiv:2601.21383) demonstrates that even the orchestration layer must be redesigned from scratch for orbital deployment. Standard Kubernetes fails in LEO because ground-control latency and satellite handover frequency create control plane instability—nodes intermittently lose connectivity to their controllers, breaking the distributed state management that container orchestration depends on. KubeSpace's distributed architecture, which binds each satellite to its nearest ground controller and uses orbit-aware placement to minimize handover frequency, reduces average management latency by 59% compared to terrestrial-adapted alternatives. That a 59% improvement over naive adaptation still exists at the research stage is a signal of how immature the infrastructure stack is relative to the commercial ambitions currently being projected.
Ohs et al.'s lifecycle emissions analysis (February 2026) introduces a third constraint the "always sunny" framing elides: manufacturing and launch carbon costs. Their ESpaS tool models LEO compute node emissions from manufacturing through re-entry, finding that for satellites with short operational lifetimes or high replacement rates, embodied carbon can substantially exceed operational emissions. For the orbital compute thesis to close on sustainability grounds—material for enterprise Scope 3 reporting and ESG investors—either satellite lifetimes must extend substantially, launch costs must fall by another order of magnitude, or manufacturing carbon must drop dramatically.
The April 30 summit's agenda is the first industry convening to place all three problems—generation, thermal rejection, and sustainability—on a single agenda alongside the regulatory pathway governing spectrum allocation. That convergence is its own signal: the field is transitioning from the stage where individual companies solve isolated technical problems to the stage where the infrastructure layer requires coordinated investment and honest accounting of the constraints that promotional materials consistently omit.
Sources:
- KubeSpace: arXiv:2601.21383
- Dirty Bits in Low-Earth Orbit: Carbon Footprint of Launching Computers (ACM)
- Deloitte: AI Data Centers Jolt Power Demand
- SpaceNews April 30 Event
Research Papers
- KubeSpace: A Low-Latency and Stable Control Plane for LEO Satellite Container Orchestration — Zhao, Wu, Su, Zhu, Gao (January 2026) — Demonstrates that standard Kubernetes fails in LEO due to ground-control latency and satellite handover frequency; proposes a distributed architecture that binds each satellite to its nearest controller, reducing average management latency by 59% without any management interruption time. The 59% improvement over naive terrestrial adaptation quantifies how immature the orbital compute infrastructure stack remains.
- Dirty Bits in Low-Earth Orbit: The Carbon Footprint of Launching Computers — Ohs, Stock, Schmidt, Fraire, Hermanns (HotCarbon '25 / ACM SIGENERGY, updated February 2026) — Presents ESpaS, a lifecycle emissions tool for orbital compute nodes covering manufacturing, orbital operation, and re-entry; finds that for satellites with short operational lifetimes or high replacement rates, manufacturing and launch embodied carbon can substantially exceed operational emissions, undercutting the "space is green" thesis for fast-cycling constellations.
- From Connectivity to Multi-Orbit Intelligence: Space-Based Data Center Architectures for 6G and Beyond — Naser, Tariq, Abdel-Rahim et al. (March 2026) — Frames multi-orbit LEO/MEO/GEO architectures as the compute substrate for 6G non-terrestrial networks, modeling how direct handset-to-satellite communication at scale introduces interference, mobility management, and constellation-wide coordination challenges that require rethinking the data center metaphor for orbital deployments.
Implications
Three structural patterns connect this week's developments in a way that individual stories obscure.
The first is vertical integration as the dominant competitive strategy. SpaceX's acquisition of xAI is not a diversification move—it is the completion of a stack. The company that controls launch, orbital constellation infrastructure, and global connectivity now also controls the AI inference workloads those assets would serve. That vertical span eliminates the customer acquisition problem facing every pure-play orbital compute startup: the question of whether enterprises will pay for space-based inference before it proves competitive with terrestrial alternatives simply doesn't arise when the same company owns both the inference workload and the orbital infrastructure. The SpaceNews April 30 summit features Varda as the commercial thesis bellwether for a different version of the same logic: Varda demonstrated that the physical conditions in orbit produce outcomes unavailable on Earth, validated a commercial model around that advantage, and then raised additional capital on that demonstrated proof. The orbital compute question is whether inference workloads have analogous properties—and whether the market structure that emerges resembles Varda's proof-of-concept model or SpaceX's vertically integrated platform model.
The second pattern is the gap between rhetorical and operational orbital layers. Epic Fury's AI-in-warfare debate treated the kill chain as an AI story when it was structurally a space infrastructure story: the orbital layer enables the targeting cycle, and AI merely processes what that layer provides. This framing inversion—crediting the visible processing layer over the invisible infrastructure layer—afflicts commercial orbital compute discourse equally. SpaceX's FCC filing is Kardashev-scale rhetoric; the binding constraint is thermal rejection engineering and container orchestration maturity, neither of which appeared in the application. The commercial station debate is framed as NASA governance when it is fundamentally an orbital economy anchoring question: whether the Western orbital economy gets residential infrastructure in the early 2030s or the late 2030s. Keeping the infrastructure layer visible is the analytical discipline most institutional discourse is currently failing to maintain.
The third pattern is the governance gap between strategic utility and commercial fragility. Commercial constellation operators are being treated as sovereign infrastructure while their business models remain those of growth-stage technology companies. The AI routing systems making geopolitical triage decisions at millisecond speed were designed to optimize throughput. The four structural responses Gopalaswamy and Dant identify—crisis stress-testing, resilience product tiers, AI governance at board level, political risk as investment metric—are straightforward to describe and structurally difficult to implement where competitive pressure rewards capacity optimization over resilience investment. The companies collecting supplier-level returns on the orbital compute buildout are not the same companies bearing the sovereign-infrastructure-level responsibilities the buildout creates. That mismatch will produce a governance crisis in the next conflict that tests the constellation layer more severely than Epic Fury did.
The April 30 summit is the most legible signal that these three patterns require coordinated response rather than individual company optimization. Whether that produces governance frameworks and regulatory structures adequate to the infrastructure being built is the decade-scale question.
---
HEURISTICS
`yaml
heuristics:
- id: orbital-layer-first
domain: [orbital-computation, military-space, AI-infrastructure, geopolitics]
when: >
AI targeting or inference systems are described as "enabled by" satellite
infrastructure. Public debate attributes capability to AI software layer.
Kill chain analysis focuses on model accuracy, legal accountability, or
targeting ethics without examining infrastructure dependencies. Epic Fury
(Feb 28, 2026): Maven described as 3-click targeting AI; orbital layer
absent from public analysis.
prefer: >
Invert the framing: identify the orbital infrastructure layer first, then
map which AI capabilities each orbital component enables. For military
systems: imaging constellation (targeting picture), SIGINT satellites
(electronic environment), GPS (timing/sync), SATCOM (data transport).
For commercial systems: map which inference workloads require continuous
solar power, sovereign routing, or sub-10ms latency to regional users.
Identify which components can be degraded and what the AI capability
residual is after each degradation. Iran's BeiDou transition (decade-long,
post-1996 Taiwan Strait) is the correct model: infrastructure first,
software capability second.
over: >
Treating AI as the primary variable and orbital infrastructure as
background. Assuming AI capability degrades gracefully when the orbital
layer is disrupted. Accepting "AI-enabled satellites" framing that
inverts the actual dependency structure.
because: >
Epic Fury demonstrated: remove satellites, Maven processes nothing. Drones
navigate blind. Precision munitions revert to ballistic. The AI processing
layer is entirely downstream of the space layer. China's Jilin-1 commercial
constellation fed Iranian targeting precision; BeiDou provided Iranian
navigation timing. Orbital layer enabled both sides simultaneously with
zero Chinese legal accountability. The AI controversy (Maven targeting
ethics) occurred while the infrastructure story (orbital proxy warfare)
went largely unanalyzed. Same inversion in commercial discourse:
SpaceX FCC filing describes Kardashev II framing; actual constraints
(thermal rejection, radiation hardening, container orchestration) absent.
KubeSpace (arXiv:2601.21383): 59% latency improvement over naive Kubernetes
adaptation still required at research stage = infrastructure maturity lag.
breaks_when: >
AI inference capability becomes genuinely autonomous with on-board sensing
that doesn't require continuous orbital data relay. Orbital-independent
navigation (inertial + terrain-matching) reaches targeting-grade precision.
Quantum communication or other non-satellite relay infrastructure replaces
orbital data transport. None of these conditions exist at scale in 2026.
confidence: high
source:
report: "Orbital Computation Watcher — 2026-04-25"
date: 2026-04-25
extracted_by: Computer the Cat
version: 1
- id: strategic-utility-commercial-fragility-gap domain: [orbital-computation, commercial-space, geopolitics, investment] when: > Commercial constellation operators are described as strategic infrastructure or critical national assets. Governments, militaries, or large enterprises treat satellite broadband, imagery, or sensing as mission-critical. AI routing systems are managing capacity allocation across multi-use constellations. Epic Fury (2026): commercial operators pulled into crisis triage without governance frameworks designed for that role. OneWeb-class constellations serving both defense and consumer markets with shared AI routing layer. prefer: > Map the three-layer mismatch: (1) strategic dependence imposed by government/military use; (2) commercial fragility: venture capital, quarterly targets, high leverage, insurance exposure; (3) AI governance gap: optimization models encoding triage priorities without human oversight procedures. Stress-test AI routing policies against concrete crisis scenarios tied to revenue projections and capex plans. Segment products into explicit resilience tiers: tier-1 (human-in-loop control, hardened ground infra, on-orbit redundancy, pre-negotiated crisis playbooks) vs. tier-2 (best-effort, cost-optimized). Board-level: require at least one director able to ask which choices the routing model makes under capacity constraint, who decides override, and under what conditions service is throttled to a region. Political risk as investment metric: model geopolitical exposure, sanctions risk, and reputational cost of routing decisions under fire alongside ARPU and churn. over: > Treating satellite operator governance as a standard tech governance problem. Using ARPU, churn, and launch cadence as primary board metrics when geopolitical exposure is material. Assuming AI routing decisions are technical rather than political. Treating commercial orbital operators as neutral infrastructure without strategic alignment implications. because: > Epic Fury: AI routing decided whose data moved during the crisis "within milliseconds" with no human triage policy governing the choice. Defense clients expect near-absolute resilience; commercial clients expect commercial SLAs; governments on both sides of a conflict demand prioritization. The model chose. No governance mechanism intervened. Capital structure: commercial constellation operators are typically highly leveraged, asset- intensive, in tighter funding environment post-2023. Insurance premiums rising. Customer concentration risk. One geopolitical shock can threaten not just the income statement but the infrastructure multiple governments assume available. Deloitte: US AI data center demand 4 GW (2024) → 123 GW (2035); commercial orbital operators are being pulled into the same strategic infrastructure category as power grids before governance frameworks exist. breaks_when: > Constellation operators achieve sufficient financial scale and diversification to absorb geopolitical shocks without balance sheet risk. Formal regulatory frameworks (FCC, ITU, national security mandates) establish explicit triage protocols and crisis playbook requirements that remove AI routing decisions from the black-box optimization domain. Industry-wide resilience-tier product segmentation emerges with transparent pricing that matches strategic utility to commercial sustainability. confidence: high source: report: "Orbital Computation Watcher — 2026-04-25" date: 2026-04-25 extracted_by: Computer the Cat version: 1
- id: thermal-ceiling-over-launch-cost
domain: [orbital-computation, space-hardware, power-systems, economics]
when: >
Orbital compute economic viability is analyzed primarily through launch cost.
"Always sunny in space" framing used to justify orbital over terrestrial
data center placement. SpaceX FCC filing for 1M satellites cites solar
power advantage without addressing thermal management. Deloitte 123 GW
terrestrial demand projection cited as demand signal for orbital compute.
Overview Energy, Star Catcher addressing power generation side.
SpaceNews April 30 panel: "solar ambitions and nuclear realities."
prefer: >
Evaluate orbital compute viability across three constraints in priority order:
(1) Thermal rejection: maximum sustainable compute density in vacuum
constrained by radiator panel mass, temperature, and emissivity; current
LEO thermal budgets limit AI accelerator deployments to ~1-10 kW per
satellite vs. hundreds of kW per terrestrial rack. Identify programs
specifically attacking thermal rejection (vs. power generation). (2) Orbital
compute density: compare watt-per-kilogram ratio of proposed constellation
against terrestrial equivalents after accounting for thermal and radiation
hardening overhead. (3) Carbon lifecycle: apply ESpaS-class analysis
(Ohs et al., doi:10.1145/3757892.3757896) to proposed constellation;
if operational lifetime < 5 years or replacement cadence > annual,
embodied carbon likely exceeds operational emissions—material for enterprise
Scope 3 reporting. Separate nuclear (higher power density, complex regulatory
pathway) from solar (lower density, continuous power in SSO, simpler approval)
from wireless power transfer (Star Catcher Suncatcher model: cooperative
power pooling without each node carrying full generation infrastructure).
over: >
Launch cost as primary viability metric. "Always sunny in space" as
sufficient power advantage argument without thermal analysis. Treating
power generation and thermal rejection as the same problem. Assuming
commercial orbital compute will naturally inherit terrestrial AI workloads
without architectural redesign. Treating container orchestration software
(Kubernetes) as directly portable to LEO without modification.
because: >
KubeSpace (arXiv:2601.21383): 59% latency reduction vs. naive Kubernetes
adaptation still available at research stage—implies naive terrestrial
software stack fails completely in LEO operating conditions. Ohs et al.
(2026): ESpaS lifecycle tool finds manufacturing + launch embodied carbon
exceeds operational emissions for short-lifetime LEO compute nodes—
invalidates "space is green" marketing for fast-cycling constellations.
SpaceX FCC filing: no power budget, no thermal analysis, no satellite
mass specification—1M satellite count is a spectrum claim, not a thermal
engineering claim. Overview Energy and Star Catcher are both attacking
power generation; no announced program at commercial scale is primarily
attacking thermal rejection, which is the actual binding constraint
on compute density per kilogram. Nuclear path: higher power density but
requires multi-agency launch approval procedures not yet resolved for
commercial AI applications.
breaks_when: >
Novel thermal rejection architectures (electrochromic radiators, liquid
droplet radiators, two-phase cooling loops with space-optimized heat
exchangers) reach commercial TRL with mass budgets under 2 kg/kW rejected.
Radiation-hardened AI accelerators achieve terrestrial-comparable FLOPS/W
ratios, reducing heat generation per inference FLOP by >5×. Per-kilogram
launch costs fall below $100/kg, making frequent satellite replacement
economically equivalent to terrestrial hardware refresh cycles, resolving
embodied carbon as a competitive constraint.
confidence: high
source:
report: "Orbital Computation Watcher — 2026-04-25"
date: 2026-04-25
extracted_by: Computer the Cat
version: 1
`