Orbital Computation · 2026-05-01

🛰️ Orbital Computation — 2026-05-01

🚀 Starcloud Seeks $200M at $2.2B Valuation as Orbital Data Center Investment Decouples from Operational Proof
📡 Amazon Leo Crosses 302 Satellites But July FCC Deadline Becomes Untenable as Vulcan and New Glenn Stay Grounded
🔐 SpaceComputer's Space Fabric Tests Trustless Distributed Orbital Compute Architecture in October
⚡ Space Force Selects K2 Satellites to Prove MEO Optical Crosslinks for Golden Dome's $180M Bandwidth Problem
🏭 SpaceX Terafab Targets 1 Terawatt of D3 Space Chips Per Year to Break Its Own Supply Chain Bottleneck
🌐 From Bench to Orbit: Google's 800 Gbps Suncatcher Benchmark and the Dawn-Dusk Architecture Convergence

---

🚀 Starcloud Seeks $200M at $2.2B Valuation as Orbital Data Center Investment Decouples from Operational Proof

Starcloud is in talks to raise at least $200 million at a valuation doubling to roughly $2.2 billion — less than five weeks after the two-year-old Redmond, Washington startup achieved unicorn status with a $170 million Series A that made it the fastest company in Y Combinator history to reach $1 billion. The funding talks, first reported by The Information, came as CEO Philip Johnston spoke April 30 at a SpaceNews orbital data center event in Washington, D.C., attributing the surge in investor demand directly to Elon Musk's public posture: "There seems to be strong investor demand in what we're doing, especially since Elon has been so vocal about the possibilities."

The funding dynamic reveals a structural pattern shaping the emerging orbital compute market: SpaceX's ambition — particularly its FCC filing for a one-million satellite constellation — has functioned as a demand catalyst for third-party competitors rather than a competitive threat. Johnston explicitly distinguished Starcloud's infrastructure-as-a-service model from SpaceX's anticipated internal focus on xAI and Tesla workloads. The gap between these positioning strategies reveals the first-generation market structure: one vertically integrated operator running proprietary AI workloads, and a separate open infrastructure tier serving the broader commercial market.

Starcloud's deployment timeline is fully Starship-dependent. Its 88,000-satellite constellation FCC filing requires Starcloud-3, a three-ton, 200-kilowatt spacecraft fitting roughly 50 units per Starship launch — approximately 10 megawatts of compute capacity per flight. Johnston has pegged the mid-to-late 2028 window for first Starship commercial customer deployments, contingent on SpaceX validating the vehicle for large Starlink V3 satellites first. The plan calls for launching "hundreds of satellites per month" at scale to add tens of gigawatts of annual capacity.

Two technical bottlenecks remain unresolved: developing a large, low-cost deployable radiator capable of rejecting heat from high-density processors, and achieving reliable operation of COTS chips — including the NVIDIA H100 processor proven on Starcloud-1 — in LEO's elevated radiation environment. Starcloud-2, slated for later this year, will run commercial workloads for early customer Crusoe AI alongside AWS and Google Cloud partnerships. Its 8-kilowatt power system represents a 100-fold increase from Starcloud-1, and it will carry the largest commercial deployable radiator ever flown. That radiator's performance data will define the technical feasibility envelope for Starcloud-3's 200-kilowatt target.

Current fundraising dynamics suggest investors are not waiting for the technical envelope to close. The orbital compute sector is entering a pre-proof-of-concept valuation regime — Series A unicorn status on a company whose largest deployed hardware generates 80 watts — where position in the emerging stack matters more than demonstrated performance. Whether that compression of the proof timeline is sustainable will depend on whether the 2027 demonstration cohort produces performance data that closes the gap between theoretical thermal limits and actual chip throughput.

Sources:

---

📡 Amazon Leo Crosses 302 Satellites But July FCC Deadline Becomes Untenable as Vulcan and New Glenn Stay Grounded

A pair of launches this week pushed Amazon's broadband constellation to 302 deployed satellites: 32 more from an Ariane 64 on April 30 and 29 from an Atlas 5 on April 27. The milestone is largely symbolic. Amazon's July 30 FCC license requires half of its 3,232-satellite constellation — 1,616 units — to be in orbit. At 302 satellites, Amazon has deployed 9.4% of that target with 91 days remaining and no plausible path to compliance.

The bottleneck is structural, not operational. Amazon's primary heavy-lift vehicles are both grounded: ULA's Vulcan shed a solid rocket booster during a February launch and remains down indefinitely, while Blue Origin's New Glenn suffered an upper stage failure April 19 that left an AST SpaceMobile satellite stranded in an unrecoverable orbit. Amazon signed contracts in 2022 for 38 Vulcan launches (40+ satellites each) and now holds 24 New Glenn contracts (48+ satellites each). Both vehicle families are unavailable for the duration of their respective failure investigations.

Amazon filed in January to extend the FCC deadline by two years or waive it entirely, citing "a near-term shortage in launch capacity." The commission's response will function as a regulatory bellwether: whether the FCC enforces milestone obligations against a company with documented launch-vehicle failures will signal how rigorously spectrum-warehousing rules apply under infrastructure force majeure. This enforcement posture will shape every subsequent orbital operator's expectation of what FCC timelines actually mean.

For orbital computation specifically, the Amazon Leo situation reveals a load-bearing dependency that spacecraft-centric analysis misses. Starcloud's FCC filing explicitly names Amazon Leo — alongside Starlink and Blue Origin's TeraWave — as one of its primary inter-satellite link relay partners. Starcloud-2's commercial architecture assumes Amazon Leo broadband backhaul. If Leo's constellation deploys on a two-year delay, the relay network that compute nodes depend on is substantially thinner than planned. The orbital compute value chain runs: launch vehicle → relay constellation → compute node → application — and failures cascade upward.

Amazon's March announcement to double its annual launch rate to more than 20 flights accelerated deployment planning — but without Vulcan and New Glenn, the math doesn't close before July 30. The next Amazon launch is Atlas 5 on May 22. The next Ariane 6 flight will use upgraded P160C solid rocket motors enabling higher satellite counts per mission, but neither vehicle can compensate for the absence of two contracted heavy-lift fleets simultaneously. The July 30 deadline is now effectively an enforcement decision, not a deployment milestone.

Sources:

---

🔐 SpaceComputer's Space Fabric Tests Trustless Distributed Orbital Compute Architecture in October

SpaceComputer, a Singapore-based startup founded in 2024 by Technical University of Munich researcher Filip Rezabek and blockchain entrepreneur Daniel Bar, plans to test its Space Fabric architecture in orbit in October. The test — on an as-yet-undisclosed satellite — addresses a problem that most orbital data center proposals treat as solved: how multiple operators and customers can share orbital compute resources without trusting each other or the platform operator.

Space Fabric is a hardware and software layer that creates physically isolated computing elements linking ground stations with satellites and enabling satellite-to-satellite resource sharing. Each Space Fabric printed circuit board generates its own cryptographic keys in orbit, eliminating the need to trust the hardware operator. Two secure elements attest against each other for redundancy — a design pattern borrowed from trusted execution environments in terrestrial computing, adapted for LEO's harsher radiation environment. Use cases range from secure computing and communications to provenance verification for geospatial data — proving that a satellite image was captured by a specific sensor at a specific time without operator manipulation.

The architecture positions SpaceComputer as a protocol layer beneath the vertically integrated orbital data center stacks proposed by SpaceX, Starcloud, and others. Bar frames the gap explicitly: "There isn't yet much thought about the space internet. There needs to be an open, protocol-oriented approach that would make it possible for different stakeholders to interface to each other, rather than operate in silos." A second SpaceComputer product, Orbitport, serves as a secure API gateway linking orbital payloads with terrestrial compute — reducing integration friction between satellite operators and ground station providers.

The strategic logic mirrors the early internet's layering: application protocols (orbital workloads) built on transport protocols (ISL relay networks) built on physical infrastructure (satellite buses and launches). SpaceComputer is betting that the orbital compute sector will require a trust and interoperability layer before the application tier can function at commercial scale — particularly as commercial imaging constellations adopt AI inference for change detection, where the ability to cryptographically bind inference results to sensor origin becomes a due-diligence requirement.

SpaceComputer has raised $10 million in pre-seed and seed funding with advisors including UCSB computer science professor Dahlia Malkhi, known for Byzantine fault-tolerant distributed systems research, and Will Heltsley, the former SpaceX vice president of propulsion. The October test will be the sector's first on-orbit demonstration of trustless orbital compute — an architectural layer the rest of the orbital data center field has not yet addressed.

Sources:

---

⚡ Space Force Selects K2 Satellites to Prove MEO Optical Crosslinks for Golden Dome's $180M Bandwidth Problem

The U.S. Space Force has selected K2 Space's satellites for its OPIR Space Modernization Initiative (SMI), a research program maturing technologies for next-generation missile-warning systems. The FY2027 SMI budget totals $180 million, with $7.3 million specifically earmarked for optical intersatellite crosslink demonstrations — experiments attempting space-to-space and space-to-ground laser communications from medium Earth orbit, a regime where no commercial operator has validated high-bandwidth optical links.

The selection ties Golden Dome, the Pentagon's proposed space-based missile-defense architecture, to the orbital compute sector's critical unsolved network problem: how to move data rapidly between spacecraft across orbital shells. Golden Dome depends on a large network of sensors and interceptors sharing targeting data in near real time. John Plumb, K2's head of strategy and former Defense Department space policy official, described the core constraint: "You need to move the information that the sensors get fast enough to get it to a shooter, whether that shooter is on the ground, on a ship or in space." The physics of missile-defense timelines demand data movement rates incompatible with current satellite-to-ground downlink architectures.

MEO crosslinks are technically harder than the optical inter-satellite links SpaceX already deploys in Starlink's LEO constellation. Longer orbital distances require more transmit power or tighter pointing precision; the radiation environment in MEO's Van Allen belts substantially exceeds LEO's particle flux, stressing electronics and optical components; handover geometry operates on different timescales. K2's Gravitas satellite, launched March 30 with a 20-kilowatt power system and 12 undisclosed payloads, serves as the company's technology baseline for its "Mega" class platform capable of high-power missions. Plumb stated plainly: "No one has solved space-to-space data links in MEO."

That gap matters for orbital compute beyond missile defense. Distributed compute architectures spanning LEO, MEO, and GEO require cross-shell bandwidth that LEO-only optical link designs don't provide. If K2's experiments succeed, they establish the technical foundation for heterogeneous orbital compute networks — configurations that reduce single-shell concentration risk and enable latency-optimized routing for different workload classes. Data-intensive Earth observation inference stays in LEO-LEO links; latency-sensitive applications route through MEO crosslinks to minimize round-trip time to ground. The architecture becomes genuinely tiered rather than flat.

Commercially, the military contract functions as funded R&D with dual-use residual value. The $180 million SMI program will produce crosslink specifications, radiation-tolerance datasets, and operational protocols in MEO that commercial orbital compute operators currently cannot afford to develop independently. Starcloud's relay architecture explicitly depends on inter-satellite links operating at sufficient bandwidth across the orbital stack — data that MEO crosslink experiments will help define. When those specifications are published, they will accelerate the private sector's MEO compute roadmap by years.

Sources:

---

🏭 SpaceX Terafab Targets 1 Terawatt of D3 Space Chips Per Year to Break Its Own Supply Chain Bottleneck

At a March 21 event in Austin, Texas, Elon Musk disclosed the supply-chain mechanism that makes SpaceX's one-million satellite orbital data center FCC filing architecturally coherent. The Terafab initiative — a joint program across SpaceX, Tesla, and xAI — targets production of one terawatt of processors annually: 50 times the combined output of all current manufacturers of advanced AI chips. Musk described chips as the "missing ingredient" in his orbital constellation plans and stated plainly: "We either build the Terafab or we don't have the chips."

Terafab's starting facility is an "Advanced Technology Fab" under development in Austin near Tesla's existing factory. The fab's primary output is a chip called D3, engineered specifically for space deployment — designed to run hotter than terrestrial accelerators with radiation-hardening measures that allow operation in LEO's elevated particle flux. Musk said the "vast majority" of D3 production targets orbital applications. The decision to design from scratch rather than qualify existing COTS chips reflects a genuine engineering constraint: standard GPU and AI accelerator chips carry thermal profiles and radiation sensitivity thresholds incompatible with LEO's radiation budget at the power densities orbital data centers require. Starcloud-1's H100 qualification at 80 watts is proof-of-concept, not scalable supply-chain evidence.

The AI Sat Mini, SpaceX's first-generation orbital data center spacecraft shown at the March event, provides 100 kilowatts of solar power to onboard processors and features a 100-square-meter radiator for heat rejection. At the scale illustrated against Starship V3's 124-meter height, the spacecraft would be more than 170 meters long. Musk's "mini" designation signals a subsequent megawatt-class platform. The radiator surface area per chip watt, not chip performance, is the binding design constraint across the entire orbital data center sector — a constraint D3's "runs hotter" specification directly addresses by reducing thermal rejection requirement per compute unit.

The vertical integration logic extends across the full stack: SpaceX controls launch vehicle (Starship), spectrum rights (FCC filing), AI workload (xAI/Grok post-acquisition), and now chip fabrication (Terafab/D3). Each layer locks out third-party single-points of failure that would otherwise constrain deployment cadence. The structural implication for competitors: Starcloud and other independent operators who rely on COTS chips, third-party launch, and commercial relay networks face supply-chain vulnerabilities at every layer that SpaceX has internalized.

Terafab has no disclosed timeline or cost estimate. TSMC's Arizona fabs cost $65 billion across three facilities; SpaceX provided no comparable figure. The 1-terawatt annual production target, if achieved, would restructure global AI chip supply far beyond the orbital market. Starcloud's NVIDIA H100 qualification in November 2025 demonstrated COTS chips run at 80 watts in orbit; whether that proof scales to volumes SpaceX's constellation requires — without Terafab — remains the defining supply-chain question for all independent orbital compute operators.

Sources:

---

🌐 From Bench to Orbit: Google's 800 Gbps Suncatcher Benchmark and the Dawn-Dusk Architecture Convergence

Google's Project Suncatcher research, developed in partnership with Planet Labs, has produced the clearest published architecture specification for orbital AI compute to date — and the clearest evidence of why all serious proposals are converging on the same orbital design: dawn-dusk sun-synchronous orbits with tightly clustered satellites connected by short-range free-space optical links. Google's preprint paper describes a notional cluster of 81 satellites flying 100 to 200 meters apart, using dense wavelength-division multiplexing transceivers to achieve inter-satellite link throughput in the tens of terabits per second range. A bench-scale demonstrator already achieved 800 Gbps each-way — 1.6 terabits total — over a single transceiver pair.

The architecture specificity resolves the two most commonly cited objections to orbital data centers. Dawn-dusk sun-synchronous orbits provide near-continuous solar illumination, eliminating large battery banks to sustain compute through orbital darkness. Tight formation flying (100-200m separation) enables link budgets that scale with received power inversely proportional to the square of distance — at 100 meters rather than 100 kilometers, the power requirement drops by a factor of one million. The cluster's thermal load is distributed across formation members and rejected through radiation into cold space, with no atmospheric convection limit on heat transfer rates.

Two Planet spacecraft carrying Google TPUs are slated to launch by early 2027, testing TPU performance in the radiation environment and validating high-bandwidth inter-satellite links in actual orbit conditions. Planet CEO Will Marshall described Suncatcher's alignment with the company's existing Owl satellite bus development as a tactical advantage: the same satellite platform supports both imaging and compute payloads, lowering marginal development cost. Planet's experience deploying more than 600 satellites — one of only two companies with scaled constellation operations beside SpaceX — gives the Suncatcher program operational credibility that pure compute startups cannot yet claim.

Aetherflux's "Galactic Brain" reaches the same architectural conclusion from a different starting point. Founded by Robinhood co-founder Baiju Bhatt, Aetherflux is primarily a space-based solar power startup whose laser beam-down infrastructure requires identical orbital power systems, pointing precision, and thermal management as an orbital data center. Bhatt's framing — "sunlight next to the silicon, skips the power grid entirely" — describes a convergence making SBSP and orbital compute two faces of the same engineering stack. Aetherflux plans its first Galactic Brain node for Q1 2027, the same launch window as Suncatcher.

The 2027 cohort — Google/Planet TPU demo, Aetherflux Galactic Brain, and Starcloud-2 commercial workloads — will produce the first empirical dataset on sustained AI compute in orbit. The architecture thesis will meet orbital operations reality simultaneously from three independent organizations, providing the sector's most meaningful signal yet about whether the dawn-dusk solar-cluster design delivers at scale what the bench demonstrations and theory predict.

Sources:

---

Research Papers

KubeSpace: A Low-Latency and Stable Control Plane for LEO Satellite Container Orchestration — Zhao, Wu, Su, Zhu, Gao (January 2026) — Proposes a distributed ground-control-node architecture that binds each LEO satellite to its nearest controller with orbit-aware container placement, reducing management latency by 59% versus Kubernetes-based terrestrial approaches. Directly addresses the orchestration gap orbital data centers must solve before running cloud-native workloads at scale; demonstrates that LEO's frequent handover dynamics require purpose-built control planes, not adapted terrestrial orchestration.

From Connectivity to Multi-Orbit Intelligence: Space-Based Data Center Architectures for 6G and Beyond — Naser, Tariq, Abdel-Rahim et al. (March 2026) — Frames LEO satellite data centers as a core capability of 6G non-terrestrial networks, analyzing direct handset-to-satellite communication and multi-orbit compute distribution. Provides the first systematic comparison of compute placement strategies across LEO, MEO, and GEO shells for AI inference workloads; validates the architectural rationale behind K2 Space's MEO crosslink experiments and Google's multi-shell design thinking.

Dirty Bits in Low-Earth Orbit: The Carbon Footprint of Launching Computers — Ohs, Stock, Schmidt, Fraire, Hermanns (February 2026, ACM SIGENERGY Energy Informatics Review) — Quantifies the launch-embodied carbon cost of deploying computing infrastructure to LEO, identifying a fundamental trade-off: operational carbon advantage from perpetual solar power versus manufacturing and launch carbon debt from delivering hardware to orbit. Essential counterweight to sustainability claims made by all major orbital compute proposals; the launch-carbon accounting methodology will become regulatory-relevant as space debris and environmental impact rules mature.

---

Implications

The week's events clarify three structural forces shaping orbital computation's transition from speculative infrastructure into an investment-grade asset class — and the gaps between them.

Capital is pricing in proof that does not yet exist. Starcloud's pursuit of $200 million at a $2.2 billion valuation — with one 80-watt satellite in orbit — follows platform investment logic, not product investment logic. Investors are buying position in an infrastructure layer before its performance envelope is empirically established. The same dynamic characterized early cloud: AWS was a capital-intensive bet on standardized infrastructure before anyone demonstrated that renting compute from a utility would make economic sense at enterprise scale. The difference is timeline compression. AWS spent a decade proving its model; orbital compute is pricing in a decade of proof at pre-proof valuations. Whether that compression is sustainable depends entirely on whether the 2027 demonstration cohort — Suncatcher TPU demo, Aetherflux Galactic Brain, Starcloud-2 commercial workloads — produces sustained performance data that closes the gap between theoretical thermal limits and actual chip throughput.

The relay layer is the critical path, not the compute node. Amazon Leo's deadline crisis exposes a dependency structure invisible in spacecraft-focused analysis. Orbital compute infrastructure is not a standalone stack; it is built atop broadband relay constellations that provide backhaul. Starcloud explicitly lists Amazon Leo, Starlink, and Blue Origin's TeraWave as relay partners. If Amazon's deployment slips two years — which the Vulcan and New Glenn groundings make nearly certain — the relay layer that compute node architectures assume is substantially thinner than planned at commercial launch. The FCC's enforcement decision on Amazon's July deadline will reveal whether spectrum-warehousing rules function as effective governance tools or symbolic obligations defeatable through force majeure claims. That decision sets precedent for every subsequent orbital operator.

The architecture has converged; the supply chain has not. Every serious proposal — Google/Planet Suncatcher, SpaceX AI Sat Mini, Starcloud-3, Aetherflux Galactic Brain — converges on dawn-dusk sun-synchronous orbits, free-space optical inter-satellite links, large deployable radiators, and chips optimized for space thermal profiles. The variables differentiating competitors are not architecture but deployment path: SpaceX internalizes Starship, D3 chips, and xAI workload; Starcloud uses Starship as a contract customer with COTS chips; Planet leverages an existing satellite bus and Google's TPU; Aetherflux repurposes SBSP infrastructure. The convergence on architecture while diverging on deployment path suggests the thermal-optical-solar design space has a narrow viable corridor, and most players have found it. The question is not whether orbital compute is architecturally feasible — Google's 800 Gbps bench demonstration and Starcloud-1's H100 in orbit establish that — but whether the supply chain (D3 chips, Starship cadence, deployable radiators at scale) can ramp fast enough to close the cost curve before terrestrial data center buildouts absorb the AI demand surge driving the investment thesis. Supplier economics dominate the near term; operator-level returns remain structurally unproven.

---

HEURISTICS

`yaml heuristics: - id: relay-dependency-chain domain: [orbital-compute, LEO, satellite-infrastructure, supply-chain] when: > Orbital data center companies announce deployment timelines and customer commitments. Backhaul relay constellations (Starlink, Amazon Leo, TeraWave) cited as primary inter-satellite link partners. Relay operator faces regulatory or launch-vehicle delays. Compute node architecture assumes relay density that relay operator has not yet achieved. prefer: > Map the full infrastructure stack before evaluating compute node timelines. Identify relay dependency explicitly: which broadband constellation provides backhaul, what fraction of planned coverage exists today, what is that constellation's deployment status and regulatory exposure. Compute deployment schedule minus relay deployment delay equals realistic customer availability date. Starcloud-2 architecture assumes Amazon Leo relay density requiring ~1,616 satellites by July 2026. Current count: 302 (May 1). Relay deficit = 1,314 satellites = ~5.4x current deployment. Both primary Amazon heavy-lift vehicles (Vulcan, New Glenn) currently grounded. over: > Evaluating orbital compute companies as standalone infrastructure. Treating launch milestone as the primary progress metric. Ignoring relay layer when assessing compute node operational dates. Accepting operator-reported deployment schedules without mapping relay dependency. because: > Starcloud FCC filing (2026-02-02): Amazon Leo named as primary ISL relay partner. Amazon Leo: 302 satellites deployed of 1,616 required by FCC July 30 deadline. Blue Origin New Glenn upper stage failure April 19 grounds primary heavy-lift. Vulcan grounded since February solid booster incident. No resumption date. FCC enforcement decision on Amazon deadline will set precedent for all subsequent orbital operators facing milestone pressure. breaks_when: > Compute nodes deploy sufficient autonomous inter-satellite links to operate without third-party relay constellations. SpaceX Starlink reaches sufficient density and bandwidth to serve as sole relay network for all operators. FCC grants Amazon two-year extension, aligning Leo timeline with compute node deployment windows. New launch vehicles enter service at equivalent cadence. confidence: high source: report: "Orbital Computation — 2026-05-01" date: 2026-05-01 extracted_by: Computer the Cat version: 1

- id: orbital-thermal-ceiling domain: [orbital-compute, satellite-architecture, chip-design, thermal-management] when: > Orbital data center proposals specify power budgets per satellite and claim competitive AI compute costs versus terrestrial infrastructure. Chip manufacturers announce space-optimized chip programs. Radiator mass and area figures cited as key design parameters. Companies downplay thermal rejection as a solved or minor engineering problem. prefer: > Derive thermal rejection ceiling from first principles before accepting claimed performance targets. Stefan-Boltzmann radiation in LEO provides roughly 100-150 W/m² passive rejection capacity at operational temperatures. Map each proposal's radiator area against claimed processor power load. Derive implied compute density ceiling. Cross-check against proposed chip specifications and duty cycle requirements. SpaceX AI Sat Mini: 100m² radiator for 100 kW processor load. Starcloud-2: "largest commercial deployable radiator ever flown" for 8 kW. Google/Planet Suncatcher: formation-distributed thermal load across 81-satellite cluster flying 100-200m apart — distributes rejection surface across cluster area. D3 chip rationale: "runs hotter than terrestrial chips" reduces rejection requirement per FLOP. Quantify the improvement before accepting efficiency claims. over: > Accepting claimed compute-per-watt efficiency without deriving implied radiator requirements. Treating radiator mass as a secondary design concern. Accepting Musk's dismissal of radiator debate without examining the data. Assuming that space-heritage thermal management scales linearly from Starlink's ~500 W/satellite to data-center 100 kW/satellite power densities. because: > SpaceX AI Sat Mini (March 21 Austin event): 100m² radiator for 100 kW. Musk: "For some reason there's been a bizarre debate about radiators." The debate is real: Starlink operates at ~500W/satellite. AI Sat Mini requires 200x higher power density per satellite. Orders-of-magnitude extrapolation from proven operations to proposed architecture. KubeSpace (arXiv:2601.21383): container orchestration framework assumes available compute, not thermally constrained duty cycles — engineering gap. Google 800 Gbps bench demo validates optical link performance; thermal validation at orbital scale remains 2027 demonstration target. breaks_when: > Phase-change thermal storage or active cooling achieves effective radiator area beyond passive radiation limits at acceptable mass penalty. D3 chip achieves >3x performance-per-watt versus H100 in orbit, making thermal ceiling non-binding before radiator deployment constraints. Formation-flying thermal distribution (Google cluster model) validated in orbit as viable substitute for per-satellite radiator scaling. confidence: high source: report: "Orbital Computation — 2026-05-01" date: 2026-05-01 extracted_by: Computer the Cat version: 1

- id: orbital-operational-ladder domain: [orbital-compute, deployment-status, competitive-intelligence] when: > Companies claim orbital AI compute capability or competitive positioning. Press releases describe "commercial workloads," "operational data centers," or "first-generation orbital compute." Valuations exceed demonstrated hardware performance by orders of magnitude. Investors cite market position rather than operational milestones when justifying commitments. prefer: > Apply a five-stage operational ladder to distinguish rhetoric from demonstrated capability. Track each company's actual vs. claimed stage. Stage 1 — Hardware in orbit, component-level test: Starcloud-1 H100 (Nov 2025) Stage 2 — Commercial workloads sustained on orbit: Starcloud-2 target (2026) Stage 3 — Multi-node cluster with optical ISLs, AI inference validated: Google/Planet Suncatcher, Aetherflux Galactic Brain (2027 targets) Stage 4 — Sustained commercial SLA competitive with terrestrial edge: Starcloud-3 batch deployments (2028+ contingent on Starship) Stage 5 — Grid-competitive cost per FLOP at gigawatt scale: undefined, no timeline Map gap between claimed and actual stage = rhetorical distance. $2.2B valuation at Stage 1 (80W satellite) = Stage 1-to-5 gap priced in. over: > Accepting company-reported stages as operational milestones. Treating FCC filing as evidence of technical capability. Equating investor valuation with demonstrated infrastructure maturity. Accepting benchmark demonstrations as evidence of sustained operational performance. because: > Starcloud: $2.2B valuation at Stage 1 (80W in orbit, May 1). SpaceX: ~$1.5T IPO target on FCC filing + Terafab announcement (Stage 0 for orbital compute). SpaceComputer: October test would be first trustless compute demonstration (Stage 1 candidate). China Guowang/Qianfan: 10,000+ satellites planned; compute-specific deployment undemonstrated. SpaceX million-satellite FCC filing requests milestone waiver before demonstrating a single operational AI satellite. Rhetorical ladder position: pre-Stage 1. breaks_when: > A Stage 3 or higher operator publishes verifiable SLA performance data for commercial customers. Sustained >1 MW orbital compute demonstrated for >90 days continuously. Amazon Web Services or equivalent hyperscaler launches orbital compute as a billable product with documented uptime SLAs. confidence: high source: report: "Orbital Computation — 2026-05-01" date: 2026-05-01 extracted_by: Computer the Cat version: 1

- id: chip-supply-vertical-integration domain: [orbital-compute, semiconductor, supply-chain, vertical-integration] when: > Orbital data center operators project massive constellation sizes requiring custom space-hardened chips. Chip manufacturers cannot supply radiation-tolerant high-performance accelerators at commercial volume or price. A single operator proposes to self-supply chips at terawatt scale. Competitors rely on COTS chips qualified through small-scale in-orbit testing. prefer: > Evaluate vertical integration as a supply-chain forcing function, not cost optimization. Map chip dependency explicitly: who supplies radiation-tolerant AI accelerators today, what is current rad-hard chip production volume, what chip count is implied by proposed constellation sizes. SpaceX AI Sat Mini at 100 kW per satellite × 1,000,000 satellites implies chip quantities orders of magnitude above current total global AI chip production. D3 self-supply via Terafab collapses the TSMC bottleneck for SpaceX's specific use case. Independent operators (Starcloud) face chip supply risk at every scale inflection point where COTS qualification must be repeated. Terafab target: 1 TW/year = 50x all current AI chip manufacturers combined. Cost: undisclosed. TSMC Arizona 5-fab program = $165B for reference. over: > Treating chip supply as a solved input-cost problem for orbital compute. Assuming COTS chip qualification at 80W satellite level scales without fab capacity expansion to million-satellite deployments. Ignoring that radiation-hardening at high performance is a distinct engineering challenge from commercial chip production at scale. Treating Terafab announcement as equivalent to demonstrated production capacity. because: > Terafab target: 1 TW annually (50x current combined all-manufacturer AI output). SpaceX D3 chip: "runs hotter than terrestrial" + radiation protection = new device class. Starcloud-1 H100 qualification: 80W in orbit. Stage 1. Current rad-hard AI accelerators: small-volume specialty production, estimated $10x-100x price premium vs. commercial equivalents. Without Terafab, SpaceX's million-satellite constellation has no chip supply path. With Terafab, SpaceX controls the supply chain that competitors depend on purchasing. breaks_when: > Third-party chip manufacturer qualifies high-performance accelerator for LEO radiation environment at commercial prices. SpaceX licenses D3 to third parties, removing supply-chain exclusivity. Radiation tolerance requirements relaxed by operational experience showing COTS chips achieve acceptable error rates with software-level mitigation alone. confidence: medium source: report: "Orbital Computation — 2026-05-01" date: 2026-05-01 extracted_by: Computer the Cat version: 1 `