🎯 Primer: A satellite is two boxes glued together — the bus (everything that keeps it alive) and the payload (everything that does the work). For an orbital AI data centre the payload is the AI accelerator farm; the bus is what keeps the farm powered, cool, oriented, and alive.

graph TD
  Payload["Payload
(AI accelerators)"]
  Power["⚡ Power
solar + battery"]
  ADCS["🧭 ADCS
pointing"]
  Thermal["🌡️ Thermal
radiators"]
  Comms["📡 Comms
antennas"]
  Prop["🚀 Propulsion
station-keeping"]
  Rad["☢️ Radiation
shielding"]
  Bus(["Bus: keeps the payload alive"])
  Payload --> Bus
  Power --> Bus
  ADCS --> Bus
  Thermal --> Bus
  Comms --> Bus
  Prop --> Bus
  Rad --> Bus
  classDef bus fill:#0f172a,stroke:#34d399,color:#e2e8f0;
  classDef payload fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  class Bus bus;
  class Payload payload;

🔍 Examples

• 🛰️ Starlink v2 Mini — ~800 kg wet mass, ~50 kW solar array, Hall-effect thrusters for orbit maintenance, krypton-ion propulsion for de-orbit. Bus does everything; payload is the phased-array user antennas.
• 🛰️ Starcloud-1 ("High Machines") — first orbital data centre prototype. 1× H100 GPU wrapped in aluminium shielding on a Starcloud bus. Payload is the GPU; bus is what keeps it alive at ~500 km.
• 🌡️ ISS external logistics — same engineering problem at 400 km: solar arrays produce ~120 kW, ammonia loops dump heat to radiators, gyros + reaction wheels keep orientation, and propellant holds the altitude.

📋 At a glance

• ⚡ Power — solar arrays + batteries cover the 35-min eclipse per 90-min orbit
• 🧭 ADCS — star trackers + reaction wheels point antennas within 0.1°
• 🌡️ Thermal — heat pipes + radiators reject waste heat (vacuum = no air cooling)
• 🚀 Propulsion — electric thrusters counter LEO atmospheric drag
• ☢️ Radiation — shielding + rad-hard parts + ECC memory + redundancy
• 🔁 Reliability — dual- or triple-string critical subsystems (no repairman in space)

📖 In depth

🚌 Bus and payload

The bus is the satellite's service module: power, ADCS, thermal, propulsion, comms, radiation shielding. The payload is the mission-specific equipment — for an ODC that's the AI accelerator farm. In a ground data centre the rack is the unit; in orbit the satellite is the unit, and the bus is everything that keeps that unit online.

⚡ Power: solar arrays and batteries

Sunlight in LEO is intense and nearly continuous. A typical 400-km circular orbit has a period of ~90 min, with ~35 min of eclipse per orbit and ~55 min of sunlight (ScienceDirect: LEO overview — "approximately 65 min in the Sun and eclipsed for 35 min"; ERAU IJAA: "in LEO the maximum eclipse duration remains close to 35 minutes"). Modern triple‑junction gallium arsenide solar arrays convert >30 % of that light into electricity. During eclipse, lithium‑ion batteries (or emerging solid‑state designs) supply power. For a 10 kW AI payload, you need roughly 25 m² of solar panels and a battery bank sized for the ~35-min eclipse.

🧭 ADCS

To keep solar panels sun-pointed and antennas aligned with ground stations, the satellite must know its orientation (determination) and adjust it (control). Determination uses star trackers, sun sensors, magnetometers, and gyroscopes. Control uses reaction wheels, magnetorquers, and occasionally thrusters. Precise pointing (<0.1°) is essential for high-gain Ka-band or optical links that carry terabits per second of data.

🌡️ Thermal control

Electronics generate heat; in vacuum the only way to dump it is thermal radiation. Heat pipes move waste heat from AI chips to radiator panels coated with high-emissivity white paint. Louvers or variable-conductance heat pipes adjust radiator effectiveness as the satellite moves in and out of eclipse. Without this, chips would overheat and throttle within minutes.

🚀 Propulsion and station-keeping

LEO suffers from atmospheric drag, which slowly decays altitude. Electric propulsion (Hall-effect thrusters or ionisers) or resistojets provide the small, continuous thrust needed to maintain orbit. For a 500 kg satellite at 550 km, ≈0.1 m/s per day of delta-v counters drag. Propulsion also enables de-orbit maneuvers at end-of-life to mitigate space debris.

☢️ Radiation shielding

Total ionising dose (TID) and single-event effects (SEE) can flip bits or latch up COTS electronics. Mitigation:

• 🛡️ Shielding — aluminium or tantalum walls around sensitive components
• 🧬 Rad-hard parts — specialised CPUs, FPGAs, memory designed for space
• 🧮 ECC memory — error-correcting codes detect and correct bit flips
• 🔁 Redundancy — triple-modular-redundant (TMR) logic for critical loops

🔁 Reliability

Space missions cannot call a repairman. Critical subsystems are duplicated (dual-string avionics) or tripled (TMR). Watchdog timers reset frozen processors, and latch-up protection cuts power to a faulty chip before it drags down the bus. MTBF > 5 years is typical for GEO comms sats; LEO ODCs aim for similar longevity despite the harsher radiation environment.

🧩 Putting it all together

An orbital data centre's hardware looks like a traditional comm-sat bus, but with a payload optimised for dense compute and high-speed inter-satellite links. The bus must deliver kilowatts of clean power, point within a tenth of a degree, dump megawatts of waste heat, and shield the AI chips from radiation. When all of these subsystems work together, the satellite can host an AI accelerator for years — turning the vacuum of LEO into a usable data centre.

🎯 Primer: A satellite is a relay — it forwards data between ground stations, between users, and between satellites. The orbital data centre case adds three constraints: terabit-per-second throughput (because AI payloads move big data), single-digit-millisecond latency (because real-time inference matters), and continuous global coverage (because the satellite is moving at 7.7 km/s and only sees any one ground station for ~10 minutes at a time).

graph LR
  User(["👤 User on Earth"])
  GS1(["📡 Ground station A"])
  GS2(["📡 Ground station B"])
  SAT1["🛰️ Sat 1
(over A)"]
  SAT2["🛰️ Sat 2
(mid-orbit)"]
  SAT3["🛰️ Sat 3
(over B)"]
  User -->|RF Ku/Ka| GS1
  GS1 -->|RF Ka| SAT1
  SAT1 -.->|"🔦 Optical ISL
(~100 Gbps)"| SAT2
  SAT2 -.->|"🔦 Optical ISL"| SAT3
  SAT3 -->|RF Ka| GS2
  GS2 -->|fiber| User
  classDef sat fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  classDef gs fill:#10b981,stroke:#047857,color:#0a0e1a;
  class SAT1,SAT2,SAT3 sat;
  class GS1,GS2 gs;

🔍 Examples

• 🛰️ Starlink — uses Ka-band user links + optical ISLs between satellites. ~160 Gbps per satellite, ~50 ms user-to-cloud latency.
• 📡 OneWeb — Ku-band user links, no ISL (relies entirely on ground stations). Lower throughput per sat but simpler architecture.
• 🔦 NASA's LCRD — laser comms demo between GEO and ground. Showed 1.244 Gbps optical downlink over 35,786 km — proves optical ISLs scale.

📋 At a glance

• 📶 Frequency bands — Ku (12–18 GHz) for broadcast, Ka (26.5–40 GHz) for broadband, optical (~1550 nm) for ISLs at terabit rates
• 📐 Link budget — transmit power + antenna gain − path loss − margin = positive C/N
• 🌍 Ground stations — 15–30 stations globally for continuous coverage from LEO
• 🔦 Optical ISLs — laser crosslinks, ~100 Gbps per link, narrow beam = no interference
• 🛰️ Walker constellation — (i:t:p:f) pattern guarantees continuous coverage as satellites pass overhead
• ⏱️ Latency — ~1.67 ms one-way at 500 km; ~30 ms end-to-end with one ISL hop

📖 In depth

📶 Frequency bands

Most commercial satellites use Ku-band (12–18 GHz) and Ka-band (26.5–40 GHz). Higher frequencies offer wider bandwidth and higher data rates but suffer more from rain fade and require more precise pointing. Emerging Q/V bands (33–50 GHz) and optical links (near-infrared, ≈1550 nm) reach hundreds of gigabits per second with narrow beams. An ODC for AI workloads will likely combine Ka-band for broad coverage and optical ISLs for the space-space backbone.

📐 Link budget

The link budget balances transmit power, antenna gains, path loss, and receiver sensitivity to compute the carrier-to-noise ratio (C/N₀). A positive link margin ensures a given bit error rate. For a 500 km LEO slant range, free-space path loss is about −173 dB at 30 GHz. High-gain phased-array antennas on both satellite and ground can recover 60–80 dB each, leaving a workable margin for high-order modulation (e.g. 32-APSK).

🌍 Ground station

A ground station is the terrestrial terminus of the link — large dish (or phased array), low-noise amplifier (LNA), downconverter, modem. For an ODC constellation you need a network of stations spaced so at least one is in view of each satellite at any time. Typical LEO constellations use 15–30 stations distributed globally. Modern stations track multiple satellites simultaneously and switch bands in milliseconds.

🔦 Inter-satellite link (ISL)

ISLs allow satellites in the same constellation to talk directly, relaying data around the world without hopping to the ground each time. This reduces latency and increases resilience. Optical ISLs (laser comms) are becoming standard — narrow beams, high frequency (~200 THz), multi-gigabit to terabit per second with small terminals. RF ISLs (Ka-band) exist but are limited by beamwidth and interference.

🛰️ Walker constellation

A Walker delta pattern (i:t:p:f) describes how satellites are placed in orbital planes to provide continuous coverage. Parameters:

• i — inclination (degrees)
• t — number of orbital planes
• p — phasing between planes
• f — number of satellites per plane

For a global LEO constellation with minimal handover, common choices are 55° inclination, 32 planes, 50 sats per plane (~1600 total). The pattern ensures that as one satellite moves out of range, another is already in view, enabling seamless handover for both user links and ISLs.

⏱️ Latency

Three main components:

1. 🌐 Propagation — light-speed travel time. 500 km altitude → ~1.67 ms one-way, ~3.3 ms round-trip.
2. 🛠️ Processing — modems, error correction, routing tables.
3. ⏳ Queueing — TDMA / FDMA slot waits.

With optical ISLs and modern onboard processing, end-to-end latency (user → ODC → user) can stay under 10 ms for intra-constellation traffic and under 30 ms to a well-located ground station.

📊 Modulation and coding

To squeeze more bits per hertz, satellites use complex modulation (QPSK, 8-PSK, 16-APSK, 32-APSK, 64-QAM) paired with forward error correction (LDPC, Turbo). Adaptive coding and modulation (ACM) changes the scheme on the fly based on real-time link conditions (rain fade, elevation), maintaining the highest possible throughput while keeping the link locked.

🧭 Phased array antenna

Instead of a single dish that must be mechanically steered, modern satellites use phased-array antennas — many small radiating elements whose phases are controlled electronically to steer the beam in milliseconds. This enables rapid switching between users, rapid ISL re-acquisition, and precision pointing for optical terminals. Phased arrays also support multiple simultaneous beams, improving spectral efficiency.

🧩 Putting it all together

An ODC's communication subsystem must provide:

• 📡 High-gain steerable antennas (phased array or dish) for both RF and optical
• 🔀 Flexible modem spanning Ku / Ka / Q / V bands and optical
• 📐 Robust link budget with margins for weather, pointing loss, aging
• 🔦 Optical ISL capability to form a low-latency space-space backbone
• 🛰️ Constellation design (Walker or similar) for continuous ground + ISL coverage
• 🧠 ACM + scheduling to maximise throughput under varying conditions

When these work together, the ODC can receive terabytes of raw sensor data per day, distribute processing across the constellation, and return refined insights to Earth with latency comparable to a terrestrial fibre connection.

🎯 Primer: An AI accelerator is a chip that does matrix multiplications very fast — GPUs are the general-purpose workhorse, TPUs are Google's custom silicon, and ASICs are purpose-built for one model class. For an orbital data centre the challenge is: the best chips (H100, Vera Rubin) weren't designed to fly in space, so we either shield them, replace them with rad-hard equivalents, or use many smaller chips instead of one big one.

graph TD
  App["🤖 Application
(LLM inference, vision)"]
  Arch["🏗️ Architecture
(dense · MoE · sparse)"]
  Chip["⚡ Chip class"]
  App --> Arch --> Chip
  Chip --> COTS["COTS
H100 · Vera Rubin · TPU
high teraflops · needs shielding"]
  Chip --> RAD["Rad-hard ASIC
Tenstorrent · Groq · Cerebras
lower perf · built for space"]
  Chip --> LOT["Many small chips
scale-out · redundancy"]
  classDef app fill:#34d399,stroke:#047857,color:#0a0e1a;
  classDef chip fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  class App app;
  class COTS,RAD,LOT chip;

🔍 Examples

• ⚡ H100 on Starcloud-1 — first COTS H100 in orbit (Dec 2025). Aluminium shielding + ECC + watchdog timers. Used for the first LLM trained in orbit (Gemma-2B).
• 🧬 Tenstorrent Grayskull — radiation-tested RISC-V AI core. Selected for ESA's ASCEND demonstrator.
• 🔮 Groq Cardinal — deterministic dataflow architecture; LEO radiation evaluation underway.
• 🧠 Cerebras WSE-2 — single-die wafer-scale engine; studies look at modular redundancy + liquid-metal cooling for space.
• 📱 Samsung Mach-1 / BrainChip Akida — neuromorphic ASICs built in rad-hard fabs for inference at the edge.

📋 At a glance

• ⚡ COTS GPUs — H100, Vera Rubin, TPU v4 — industry-leading perf but not space-rated
• ☢️ Radiation hardening — enclosed layout transistors, dual-intermediate contacts, triple-modular redundancy, ECC, watchdog timers
• 🛡️ Shielding + monitoring — aluminium / tantalum walls + error correction + scrubbing for COTS in space
• 🌡️ Thermal — heat pipes + radiators (no convection in vacuum)
• ⚖️ Trade-off — rad-hard lags COTS by 1–2 process nodes; bridge with more chips, lower precision (FP8/INT4), sparsity-aware engines
• 🎯 Sweet spot for ODCs — many small rad-tolerant chips + one big COTS accelerator behind shielding for peak loads

📖 In depth

🔄 From COTS to rad-hard

Commercial-off-the-shelf (COTS) AI accelerators such as NVIDIA's H100 or Google's TPU v4 offer industry-leading performance (hundreds of teraflops FP16) but are not designed for space. Total ionising dose (TID) gradually degrades transistor thresholds; single-event effects (SEE) like bit flips or latch-up cause sudden failures. To fly in LEO for years, AI hardware must be either:

• ☢️ Radiation-hardened by design — specialised fabrication processes, enclosed layout techniques, rad-tolerant libraries
• 🛡️ Shielded and monitored — COTS parts behind shielding, with ECC memory, watchdog timers, periodic scrubbing

🛰️ Current space-qualified options (2026)

Few AI accelerators have flown in space. Demonstrations:

• H100 on Starcloud-1 (Dec 2025) — COTS H100 + aluminium shielding + error-detecting code; first LLM trained in orbit (Gemma-2B)
• Tenstorrent Grayskull — radiation-tested RISC-V AI core; ESA ASCEND demonstrator
• Groq Cardinal — deterministic dataflow architecture; LEO radiation evaluation in progress
• Cerebras WSE-2 — wafer-scale engine; modular redundancy + liquid-metal cooling studies
• Custom ASICs — Samsung Mach-1, BrainChip Akida in rad-hard fabs (TSMC, GlobalFoundries)

🛡️ Radiation-hardening techniques

• 🧬 Enclosed layout transistors (ELT) — prevent rad-induced leakage at the oxide interface
• 🔀 Dual-intermediate contact (DIC) — reduces single-event upset (SEU) sensitivity
• 🗳️ Triple-modular redundancy (TMR) voting — three copies vote; masks single-point failures
• 🧮 EDAC — parity + ECC memory + register files + scrubbing
• ⏱️ Watchdog timers — reset processors that hang due to SEE latch-up
• 🔌 Power-gating + isolation — shut down faulty blocks to prevent contagion

🌡️ Thermal and power

AI accelerators consume watts to kilowatts and generate proportionate heat. In vacuum, convection does not exist; heat must conduct to radiator panels and radiate away. High-power AI chips therefore require:

• 🚰 Heat pipes / vapor chambers — move heat from die to bus structure
• 🤍 High-emissivity coatings — white paint or anodised aluminium with ε > 0.8
• 🔗 Thermal straps — conductive links between chips and radiators
• 💧 Active cooling (rare) — pumped fluid loops for >100 W densities (still experimental)

⚖️ Performance vs. reliability trade-offs

A rad-hard AI accelerator typically lags its COTS counterpart by one or two process nodes (e.g., rad-hard 28 nm vs. COTS 5 nm). The gap is bridged by:

• 🔢 More chips — scale-out with many modest-power accelerators
• 🎚️ Lower precision — FP8 / INT4 inference-only formats reduce transistor count and power
• 🎲 Approximate computing — tolerate small errors for higher throughput or lower power
• 🕳️ Sparsity-aware engines — skip zero weights in LLMs

🧩 Putting it all together

For an orbital data centre, the AI hardware layer balances three drivers:

1. ☢️ Survivability — withstand TID, SEE, latch-up, thermal cycling for the mission (3–5 years in LEO)
2. 🚀 Performance — deliver enough teraflops / tokens-per-second for the workload (real-time video analytics, LLM inference for constellation telemetry)
3. ⚡ Power + thermal — stay within the bus's power budget and radiator capacity

When these are satisfied, the ODC can host an AI accelerator that continuously ingests sensor data, runs inference, and downloads results to ground stations — turning the vacuum of LEO into a usable AI factory.

🔗 See also

• 📚 §6 Jensen Huang's 5-layer cake — the AI chip choices above sit inside Huang's "chips" layer (the second of five: energy → chips → infrastructure → models → applications). For orbital data centres the chip layer is gated by the energy layer above; you cannot double the teraflops without doubling the solar array area, the battery capacity, and the thermal radiator mass.

🎯 Primer: AI software is everything between the chip and the user's API call. In an orbital data centre the stack has to extract every possible token per joule because power and compute seconds are scarce. Three layers matter: the inference engine (vLLM, TGI, llama.cpp, TensorRT-LLM) that serves the model, the model architecture (dense, MoE, omnimodel, reasoning), and the optimisations (quantisation, KV cache, speculative decoding, continuous batching).

graph LR
  User(["👤 API request"])
  Engine["🔧 Inference engine
vLLM · TGI · llama.cpp · TensorRT-LLM"]
  Model["🧠 Model
dense · MoE · omnimodel · reasoning"]
  Opt["⚡ Optimisations
FP8 · KV cache · speculative · batching"]
  User -->|prompt| Engine
  Engine -->|forward pass| Model
  Engine -.->|"tunes"| Opt
  Model -.->|"trained weights"| Engine
  Engine -->|tokens| User
  classDef engine fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  classDef model fill:#34d399,stroke:#047857,color:#0a0e1a;
  classDef opt fill:#f59e0b,stroke:#b45309,color:#0a0e1a;
  class Engine engine;
  class Model model;
  class Opt opt;

🔍 Examples

• 🚀 vLLM — PagedAttention KV cache management. Almost zero memory waste, ~10× throughput vs naive serving on H100. The de-facto open-source standard.
• 🔢 llama.cpp — pure C/C++, runs on CPUs and modest GPUs, GGUF quantisation. Lets a 70B model run on a workstation, or a 7B model run on a satellite's housekeeping CPU.
• 🧪 TensorRT-LLM — NVIDIA's FP8 + tensor-parallel engine. Best per-watt throughput on H100 / Vera Rubin.
• 🌳 Mixtral 8x7B (MoE) — 46 B total params but only ~12 B active per token. Trades storage for compute efficiency.
• 🤔 DeepSeek R1 (reasoning) — chain-of-thought before answering; uses 10–100× more compute per query but solves hard problems classical LLMs miss.

📋 At a glance

• 🔧 Inference engines — vLLM (best throughput), TGI (latency), llama.cpp (portable), TensorRT-LLM (NVIDIA-tuned)
• 🌳 MoE — many params, few active per token; better FLOPs-per-quality ratio
• 🌐 Omnimodel — one model handles text + image + audio; less storage and switching overhead
• 🤔 Reasoning — o1 / R1 style; spend more compute on thinking before answering
• 🎚️ Quantisation — FP16 → FP8 / INT4; halves memory bandwidth at minimal accuracy cost
• 📚 KV cache — PagedAttention (vLLM) eliminates fragmentation; compression + sliding-window for long sequences
• ⚡ Speculative decoding — small draft + big target = 2–3× throughput for memory-bound workloads
• 📦 Continuous batching — fill slots as they free up; ~2× utilisation vs static batches during contact windows

📖 In depth

🔧 Inference engines

An inference engine takes a trained model and serves it via an API (gRPC, HTTP, or custom binary). Key features for space:

• 🚀 High throughput — many requests per second
• ⏱️ Low latency — time to first token
• 📦 Efficient batching — amortise overhead
• 💾 Low memory footprint — fit within satellite RAM
• 🎯 Deterministic execution — no jitter interfering with attitude control

Popular open-source engines:

• vLLM — PagedAttention for KV cache, near-zero waste, high throughput, low latency
• TGI — latency-optimised, tensor parallelism, quantisation
• llama.cpp — pure C/C++, runs on CPUs, GGML/GGUF quantisation, highly portable
• TensorRT-LLM — NVIDIA-optimised, TensorRT kernels, FP8/TF32 precision

🌳 Mixture of Experts (MoE)

MoE replaces a dense feed-forward layer with a set of expert networks and a gating network that selects which experts to run per token. Benefits:

• 💡 Compute efficiency — only a fraction of experts active per token
• 📈 Parameter scaling — trillions of params, billions active per token
• 🛡️ Fault tolerance — if one expert fails (radiation hit), gating routes around it

Notable: Mixtral 8x7B, DeepSeekMoE, Google Switch Transformer, NVIDIA Vera Rubin (rumoured MoE).

🌐 Omnimodel

A single model handling multiple modalities (text, image, video, audio) and multiple tasks (classification, generation, reasoning) without task-specific fine-tuning. For an ODC, this reduces the need to store and switch between many specialised models, saving storage and simplifying the stack.

Research: Google's UniCM, NVIDIA's Omni-Modal, vision-language models (BLIP, Flamingo) taking steps toward omni-capability.

🤔 Reasoning models

Reasoning models (OpenAI o1-series, DeepSeek R1) are trained to spend more compute on thinking before answering. In an ODC, a reasoning mode could activate for high-value tasks (anomaly detection in constellation telemetry) while a faster, lighter model handles routine housekeeping.

🎚️ Quantisation

Reduces numerical precision (FP16 → INT8 / FP8), cutting memory bandwidth and storage:

• ⚡ Post-training quantisation (PTQ) — quick conversion, small accuracy drop
• 🎯 Quantisation-aware training (QAT) — higher fidelity, requires retraining
• 🆕 FP8 (E4M3, E5M2) — supported on Hopper and Blackwell, 2× speedup over FP16

📚 KV cache optimisation

During autoregressive generation, the model caches previous keys and values to avoid recomputation. Optimisations:

• 📄 PagedAttention (vLLM) — non-contiguous pages, no fragmentation
• 🗜️ Cache compression — quantise or low-rank approximation
• 🪟 Sliding window — discard oldest tokens when cache exceeds limit

⚡ Speculative decoding

A small fast draft model proposes multiple future tokens; the target verifies them in parallel. Accepted drafts effectively multiply throughput. Pairs can be (small Llama, large Llama) or (tiny transformer, MoE). Particularly effective when the target is memory-bandwidth bound.

📦 Continuous batching

Adds new requests to the batch as soon as a slot frees up (when a request finishes). Keeps utilisation high and reduces tail latency — important during bursty contact windows.

🧩 Putting it all together

An ODC's AI software stack should:

1. 🔧 Pick the inference engine matched to the hardware (vLLM for GPUs, llama.cpp for CPUs, TensorRT-LLM for NVIDIA)
2. 🌳 Prefer MoE for more model capacity per active FLOP
3. 🌐 Consider an omnimodel to reduce model-switching overhead
4. 🎚️ Quantise (FP8 / INT8) to shrink memory footprint
5. 📚 Optimise KV cache with paging or compression
6. ⚡ Use speculative decoding for latency-sensitive workloads
7. 📦 Continuous batching to maximise utilisation during contact windows
8. 🤔 Reasoning mode for high-value, infrequent tasks

When these layers work together, the same hardware processes more sensor data, runs more inference queries, and delivers more insights per watt and per second of orbital lifetime.

🔗 See also

• 📚 §6 Jensen Huang's 5-layer cake — inference engines + model architectures sit inside Huang's "models" layer (the fourth of five: energy → chips → infrastructure → models → applications). The orbital data centre's unique value comes from running this layer in space, where latency to the user, data sovereignty, and edge-data privacy all favour the orbital position.
• 📚 §7 Karpathy's software eras — the same models are programmed three different ways: as human code (Software 1.0), as trained neural network weights (Software 2.0), or as English prompts to an LLM (Software 3.0). The orbital implication is significant: a Software 3.0 stack on orbit can be re-tasked without uploading new weights — the prompt is the program.

🎯 Primer: Scaling laws are empirical rules that say loss falls as a power law when you add more data, parameters, or compute. For an orbital data centre — where watts, thermal, and compute seconds are all scarce — the practical question is: which of those three resources gives the biggest quality improvement per joule?

graph TD
  R["📉 Loss
(lower = better)"]
  P["📏 Parameters
(model size)"]
  T["📚 Tokens
(training data)"]
  C["⚡ Compute
(FLOPs)"]
  P -->|"scales as X^-α"| R
  T -->|"scales as X^-α"| R
  C -->|"scales as X^-α"| R
  P <-.->|"coupled"| T
  T <-.->|"coupled"| C
  P <-.->|"coupled"| C
  classDef loss fill:#34d399,stroke:#047857,color:#0a0e1a;
  classDef axis fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  class R loss;
  class P,T,C axis;

🔍 Examples

• 🦫 Chinchilla (DeepMind, 2022) — trained Gopher (280 B) and Chinchilla (70 B). Same compute, Chinchilla got better loss because it used 4× more tokens. Lesson: scale data with model size.
• 📊 Kaplan (OpenAI, 2020) — first big scaling-laws paper. Showed smooth power-law loss across 8 orders of magnitude. Some exponents later refined by Chinchilla.
• 🪄 Emergent abilities — at ~10²² FLOPs, LLMs suddenly do multi-step arithmetic, follow complex instructions, and use tools. Below threshold, they can't.
• 🧠 o1 / R1 (test-time compute) — same model, but instead of 1 forward pass it does 100. ~10× better on hard math/coding problems, ~100× more FLOPs per query.

📋 At a glance

• 📉 Power law — Loss = A · X^(−α) + B (irreducible noise floor); straight line on log-log
• 🦫 Chinchilla-optimal — for every doubling of params, double the training tokens
• 📚 Kaplan exponents — earlier scaling rules; trends within a regime, less prescriptive than Chinchilla
• 🪄 Emergent abilities — abilities appear abruptly past a critical scale (reasoning, tool use, multi-step arithmetic)
• ⏱️ Test-time compute — o1 / R1 spend 10–100× more FLOPs per query to think harder; trades latency for accuracy
• 🥲 The bitter lesson — generic + scalable (transformer + search) beats hand-crafted heuristics over the long run
• 🎯 For an ODC — pick the compute-optimal model for your watt budget; reserve test-time compute for high-value tasks

📖 In depth

📉 The power-law form

Most scaling laws follow a power law:

Loss = A · X^(−α) + B

where X is the resource (data, parameters, or compute), A and α are positive constants, and B is the irreducible loss floor. On a log-log plot, this appears as a straight line with slope −α.

🔀 Three primary scalings

1. 📚 Data scaling — loss improves with more training tokens (model + compute fixed)
2. 📏 Model size scaling — loss improves with more parameters (data + compute fixed)
3. ⚡ Compute scaling — loss improves with more training FLOPs (data + model fixed)

In practice the three are coupled: more compute lets you train a bigger model or train the same model on more data.

🦫 Chinchilla (data-optimal scaling)

In 2022, DeepMind's Chinchilla project showed that for a given compute budget, doubling params without doubling tokens wastes compute. The compute-optimal point doubles both in proportion: for every 2× params, 2× tokens. "Chinchilla-optimal" or "data-optimal" models are not wasting compute on an over-large model starved of data.

📊 Kaplan et al. (earlier scaling laws)

Before Chinchilla, Kaplan et al. (2020) analysed scaling across many orders of magnitude and proposed slightly different exponents. Their work showed loss decreases smoothly as you scale any of the three, but did not emphasise the compute-optimal balance Chinchilla highlighted. Kaplan's laws are still useful for understanding trends within a regime (e.g., how much loss improves if you just double the data).

🪄 Emergent abilities

Certain abilities appear abruptly only when a model exceeds a critical scale:

• 🧮 Multi-step arithmetic
• 🛠️ Tool use
• 💬 Following complex multi-instruction prompts
• 🪞 Situational awareness

For an ODC, this means a slightly larger model might suddenly gain a useful capability (reasoning about satellite telemetry) without a proportional cost increase — provided you are past the threshold.

⏱️ Test-time compute (o1 / R1)

Recent work (OpenAI o1-series, DeepSeek R1) shows that allocating compute at inference time dramatically improves performance on hard problems. Instead of one forward pass, the model generates a chain-of-thought, evaluates multiple candidates, or uses search-like strategies. You spend more seconds (and watts) for a more accurate answer. For an ODC, you could reserve a fraction of the compute budget for high-value, infrequent tasks (anomaly detection in downlink data) where extra time to think is worthwhile.

🥲 The bitter lesson

Rich Sutton's "bitter lesson": over the long term, the most effective AI approaches leverage computation via general-purpose methods (search, learning), not hand-encoded knowledge. In scaling-law terms: simply scaling up compute, data, and model size with a generic architecture (transformer) tends to beat carefully hand-crafted models. For an ODC, this reinforces investing in a scalable, general-purpose AI stack (transformer + MoE) over a narrow, hand-tuned solution.

🧩 Putting it all together for an orbital data centre

An ODC has a fixed power budget (watts from solar), a thermal dissipation limit (watts you can radiate), and a compute budget (ops per second without overheating). To maximise useful work per watt:

1. 🎯 Pick the compute-optimal point — for the FLOPs you can afford per second, choose a model size + dataset on the Chinchilla-optimal curve
2. 🪄 Watch for emergent abilities — if a slightly larger model (still within budget) gains a needed capability, the extra watts may be worth it
3. ⏱️ Reserve test-time compute — for infrequent but critical inferences, spending extra seconds on chain-of-thought improves accuracy dramatically
4. 🥲 Follow the bitter lesson — prefer general-purpose scalable architecture over specialised heuristics

By treating power, thermal, and compute as constrained resources and applying scaling-law insights, an ODC can allocate its scarce budget for maximum scientific and economic return per watt of orbital lifetime.

🎯 Primer: Jensen Huang's canonical framing of the AI industry is five layers stacked vertically: energy → chips → infrastructure → models → applications. Every layer pulls on every layer beneath it. For orbital AI, the punchline is that energy is the only binding constraint — every chip, every kilowatt, every orbital plane must answer to the application, not the other way around.

graph TD
  L1["⚡ Layer 1 — Energy
(the only binding constraint)"]
  L2["🔌 Layer 2 — Chips
(transform energy → computation)"]
  L3["🏭 Layer 3 — Infrastructure
(land, power, cooling, networking)"]
  L4["🧠 Layer 4 — Models
(LLMs, reasoning, protein AI, physics)"]
  L5["🎯 Layer 5 — Applications
(where economic value is created)"]
  L1 --> L2 --> L3 --> L4 --> L5
  L5 -.->|"pulls on every layer below"| L1
  classDef base fill:#0f172a,stroke:#34d399,color:#e2e8f0;
  classDef mid fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  classDef top fill:#f59e0b,stroke:#b45309,color:#0a0e1a;
  class L1 base;
  class L2,L3 mid;
  class L4,L5 top;

In March 2026, NVIDIA's CEO Jensen Huang published a canonical framing of the AI industry: "AI is a 5-layer cake". The layers, in his exact words, are: energy → chips → infrastructure → models → applications (NVIDIA blog, 10 March 2026; this exact ordering is also reproduced verbatim in secondary reporting).

Each layer pulls on the ones beneath it. Huang's full sentence: "Every successful application pulls on every layer beneath it, all the way down to the power plant that keeps it alive." (NVIDIA blog)

🔍 Examples

• 🏭 NVIDIA's own AI factories — Huang mentions "tens of thousands of processors" orchestrated into "AI factories". Stargate (OpenAI + NVIDIA + Oracle + SoftBank) is the $500 B, 10 GW physical instantiation of his mental model.
• 🇪🇺 Sovereign AI — the EU's €200 B AI factory programme explicitly adopts Huang's 5-layer cake. Each country runs its own AI factory stack: data centres → chips → models → applications.
• 🛰️ Orbital data centre — the 5 layers map cleanly: Layer 1 = solar arrays + batteries; Layer 2 = H100 / Vera Rubin; Layer 3 = Walker constellation of LEO sats with optical ISLs; Layer 4 = MoE LLM split across satellites; Layer 5 = real-time inference close to users + European data sovereignty.

📋 At a glance

• ⚡ Energy — the only binding constraint; every layer above is a function of watts delivered
• 🔌 Chips — processors that turn electrons into tokens (H100, Vera Rubin, TPU)
• 🏭 Infrastructure — the AI factory itself: data centres, networking, cooling
• 🧠 Models — language, biology, chemistry, physics, robotics, autonomous systems
• 🎯 Applications — drug discovery, robotics, copilots, self-driving — where the money is
• 🔁 Every layer pulls on every layer below — energy is the floor; applications are the ceiling

📖 In depth

⚡ Layer 1 — Energy

"Intelligence generated in real time requires power generated in real time. Every token produced is the result of electrons moving, heat being managed and energy being converted into computation. There is no abstraction layer beneath this." (NVIDIA blog)

This is the binding constraint on orbital AI: in LEO, a typical 400-km circular orbit has a period of ~90 min, with ~35 min of eclipse per orbit and ~55 min of sunlight (ScienceDirect: LEO overview — "approximately 65 min in the Sun and eclipsed for 35 min"; ERAU IJAA: "in LEO the maximum eclipse duration remains close to 35 minutes"). So a 10 kW AI payload needs roughly 25 m² of triple-junction GaAs solar arrays (≈30 % BOL efficiency under AM0 ≈ 1361 W/m²) plus a battery bank sized for the ~35-min eclipse — see §1 satellite hardware.

🔌 Layer 2 — Chips

Processors designed to "transform energy into computation efficiently at massive scale" (NVIDIA blog). For an orbital data centre, this means GPUs (H100 → Vera Rubin) or custom silicon (Tenstorrent, Groq, Cerebras, TPU) that survive total ionising dose and single-event effects — see §3 AI hardware.

🏭 Layer 3 — Infrastructure

"Land, power delivery, cooling, construction, networking and the systems that orchestrate tens of thousands of processors into one machine. These systems are AI factories." (NVIDIA blog)

In orbit, the "AI factory" is the satellite cluster itself — a Walker constellation of LEO satellites each running part of a model in a fault-tolerant fabric. See §2 satellite communication for the inter-satellite links that stitch the factory together.

🧠 Layer 4 — Models

"AI models understand many kinds of information: language, biology, chemistry, physics, finance, medicine and the physical world itself. Language models are only one category." (NVIDIA blog)

See §4 AI software for the inference engines (vLLM, TGI, llama.cpp, TensorRT-LLM), model architectures (MoE, omnimodels, reasoning models), and optimisation techniques that turn a model into an orbital service.

🎯 Layer 5 — Applications

"Drug discovery platforms. Industrial robotics. Legal copilots. Self-driving cars. A self-driving car is an AI application embodied in a machine. A humanoid robot is an AI application embodied in a body. Same stack. Different outcomes." (NVIDIA blog)

For orbital data centres the most valuable applications are latency-sensitive: real-time inference close to the user, model fine-tuning on edge data, and federated training across a satellite cluster.

💰 Why this framing matters for orbital AI

Huang's stack makes the orbital case concrete in two ways. First, it identifies energy as the only binding constraint — every other layer is a function of how many watts you can deliver to the payload. This is the same constraint that drives the entire data-centre industry to co-locate with cheap power (NVIDIA blog: "a few hundred billion dollars into [the buildout]; trillions of dollars"). For orbit, the trade-off is solar array area vs. payload mass vs. downlink capacity — a triple constraint that has no terrestrial analogue.

Second, the framing makes the application layer the only place where economic value is created. An orbital data centre that runs the same model as a ground cloud has no advantage; it must run models that benefit from being in space (latency to the user, sovereignty of European data, edge inference on space-generated data). The 5-layer cake forces a top-down read: every chip, every kilowatt, every orbital plane must answer to the application, not the other way around.

🔗 Cross-references

• 📚 From §3 AI hardware: the chip layer choices (H100, Vera Rubin, Tenstorrent, Groq, Cerebras, TPU) sit inside Huang's "chips" tier.
• 📚 From §4 AI software: the model architecture choices (dense, MoE, omnimodel, reasoning) and inference engine choices (vLLM, TGI, llama.cpp, TensorRT-LLM) sit inside Huang's "models" tier. See also §7 Karpathy's software eras for the same models classified by how they are programmed (weights vs. prompts).

🎯 Primer: Karpathy's framing is that the same task can be programmed three different ways: (1) hand-written code (Software 1.0), (2) trained neural network weights (Software 2.0), or (3) English prompts to an LLM (Software 3.0). For an orbital data centre the punchline is that Software 3.0 changes the upgrade story — to give the satellite a new capability you change the prompt, not the weights.

graph LR
  Task["🎯 Task
(e.g. sentiment classification)"]
  S1["👨‍💻 Software 1.0
Python / C++
hand-written rules"]
  S2["🧠 Software 2.0
trained NN weights
dataset + architecture"]
  S3["💬 Software 3.0
English prompt
programs the LLM"]
  Task --> S1
  Task --> S2
  Task --> S3
  S1 -.->|"compiled from code"| Output["📤 Output"]
  S2 -.->|"compiled from data"| Output
  S3 -.->|"in-context program"| Output
  classDef era1 fill:#0ea5e9,stroke:#0284c7,color:#0a0e1a;
  classDef era2 fill:#10b981,stroke:#047857,color:#0a0e1a;
  classDef era3 fill:#f59e0b,stroke:#b45309,color:#0a0e1a;
  class S1 era1;
  class S2 era2;
  class S3 era3;

🔍 Examples

• 📝 Sentiment classification — Karpathy's running example throughout the YC talk: classify a tweet as positive/negative. Software 1.0 = a Python rule-based classifier or sklearn pipeline. Software 2.0 = a trained MLP on a labelled dataset. Software 3.0 = a few-shot LLM prompt: "Classify this tweet as POSITIVE or NEGATIVE. Tweet: '{tweet}'. Answer:".
• 🤖 Tesla Autopilot — Karpathy observed at Tesla that the C++ stack (Software 1.0) shrank over time as neural networks (Software 2.0) absorbed capabilities (image stitching across cameras, lane keeping). The C++ was being deleted, not added.
• 🛰️ Orbital inference — Software 1.0: rule-based anomaly detector. Software 2.0: a fine-tuned anomaly model uploaded as weights. Software 3.0: prompt the in-orbit LLM with the new anomaly taxonomy in English. The Software 3.0 path skips the upload.

📋 At a glance

• 👨‍💻 Software 1.0 — human-written code in Python/C++; explicit logic
• 🧠 Software 2.0 — neural network weights compiled from data via backprop + SGD
• 💬 Software 3.0 — English prompts that program an LLM; "we're now programming computers in English"
• 📐 The source-of-truth axis — code → weights → English (the "language" becomes progressively more human)
• 🛰️ Orbital implication — Software 3.0 changes the upgrade path: prompt change vs. weight upload
• ⏱️ Iteration cost — Software 1.0: minutes (edit + run); Software 2.0: weeks (retrain + push); Software 3.0: seconds (change prompt)

📖 In depth

👨‍💻 Software 1.0 (the classical stack)

In a 2017 essay, Andrej Karpathy introduced a distinction that has since reshaped how engineers talk about AI code: Software 1.0 is "classical stack" code (Python, C++, etc.), and Software 2.0 is "neural network weights" (Karpathy, Software 2.0, 11 November 2017). The essay's exact framing: "I sometimes see people refer to neural networks as just 'another tool in your machine learning toolbox'... Unfortunately, this interpretation completely misses the forest for the trees. Neural networks are not just another classifier, they represent the beginning of a fundamental shift in how we develop software. They are Software 2.0."

The "classical stack" of Software 1.0 is what we're all familiar with — written in Python, C++, etc. By writing each line of code, the programmer "identifies a specific point in program space with some desirable behavior" (2017 essay).

🧠 Software 2.0 (neural network weights)

Software 2.0 is written in much more abstract, human-unfriendly language: the weights of a neural network. No human is involved in writing this code (there are too many weights). Instead, we specify the goal (e.g., a dataset of input-output pairs), write a rough skeleton (the architecture), and let backpropagation + stochastic gradient descent search for the program.

The source code of Software 2.0 is the dataset + the architecture; the weights are "compiled from data rather than written by hand" (MindStudio summary, 2 May 2026).

💬 Software 3.0 (LLM prompts in natural language)

In June 2025, Karpathy extended the framework at YC AI Startup School with a new tier: Software 3.0 (transcript, 18 June 2025; annotated notes by Latent Space; official YC library page). His exact framing: "neural networks became programmable with large language models. And so I see this as quite new, unique, it's a new kind of a computer. And so in my mind, it's worth giving it a new designation of Software 3.0. And basically, your prompts are now programs that program the LLM."

Two properties distinguish 3.0 from 1.0 and 2.0:

1. 📝 The "source" is English, not code or weights. This makes the medium radically more accessible — anyone who can write a sentence can program an LLM.
2. 🌐 The program is "live", executed in-context by the model at inference time. There is no compile step; the prompt is the program.

Karpathy: "remarkably we're now programming computers in English. And so when this blew my mind a few, I guess, years ago now, I tweeted this, and I think it captured the attention of a lot of people, and this is my currently pinned tweet, is that remarkably we're now programming computers in English" (YC talk transcript).

📐 The three eras, side by side

Karpathy uses sentiment classification as a running example: "...if you're doing sentiment classification, for example, you can imagine writing some amount of Python to basically do sentiment classification, or you can train a neural net, or you can prompt a large language model" (singjupost transcript; Medium summary, 20 June 2025). Same task, three implementations:

• 👨‍💻 Software 1.0: a hand-written Python classifier (rule-based or scikit-learn pipeline). Source code: .py files. The programmer "identifies a specific point in program space with some desirable behavior" (2017 essay).
• 🧠 Software 2.0: a trained neural network. Source code: dataset + architecture. The weights are compiled from data. Optimisation is backprop + SGD.
• 💬 Software 3.0: a few-shot LLM prompt. Source code: English. Your prompts are now programs that program the LLM.

🔁 The Latent Space summary

Latent Space's annotation of the YC talk noted that Karpathy's diagram shows the patchwork/coexistence of all three eras: "Software 3.0 is eating 1.0/2.0" and "a huge amount of software will be rewritten" (Latent Space annotation). The 2017 essay concluded with a similar image: "Software (1.0) is eating the world, and now AI (Software 2.0) is eating software."

🛰️ Why this matters for orbital data centres

The three eras map directly onto orbital AI economics:

• 👨‍💻 Software 1.0 in orbit — hand-written code: deterministic, low-power, debuggable from the ground. Ideal for housekeeping, ADCS, fault detection.
• 🧠 Software 2.0 in orbit — trained weights uploaded as files. High accuracy on narrow tasks (anomaly detection, classification). Iteration cost: weeks (retrain, validate, upload, verify).
• 💬 Software 3.0 in orbit — an LLM running on orbit, with new capabilities shipped as English prompts via the ground link. Iteration cost: seconds (change the prompt, no upload). The on-orbit model stays put; only the prompt moves.

The practical consequence: an orbital data centre running Software 3.0 can upgrade its capability without uploading new weights. The iteration cost of orbital AI collapses from "weeks (retrain + push weights)" to "seconds (change prompt)". Combined with the latency, sovereignty, and edge-data privacy that makes the orbital case uniquely valuable, Software 3.0 is the lever that makes the orbital AI factory economical.

An S-curve plots adoption over time: slow start, rapid take-off, then saturation. For orbital compute, the adoption curve tells us when to jump technological generations — and why the "mid-2027 architecture lock" is a timing decision, not just a thesis.

The Bass diffusion model (1969)

Try it live above this section: the interactive plot lets you drag p, q, m, and the time window. As you slide, the curve re-shapes, t* (peak year) re-positions, and the metrics panel updates. Defaults are the worked example below (p = 0.05, q = 0.40, m = 100 → t* ≈ 4.6 years).

The canonical math for adoption of a new product. Three parameters:

• p (innovation coefficient): external influence (PR, founders, specialists). Typical range 0.01–0.03.
• q (imitation coefficient): word-of-mouth, peer influence. Typical range 0.30–0.50.
• m (ultimate market potential): total adopters at saturation.

Differential equation

dN/dt = [p + q·N/m] · [m − N]

N(t) = cumulative adopters at time t. The term [m − N] is the remaining market.

Closed-form solution

N(t) = m · [1 − exp(−(p+q)·t)] / [1 + (q/p)·exp(−(p+q)·t)]

Key derived properties

• Time of peak sales (new adopters per period): t* = [1/(p+q)] · ln(q/p)
• Cumulative adoption at peak: N(t*) = m · (p+q−2p) / (2(p+q−p)) → varies, often ~50% of m for high q
• Growth-onset heuristic: N(t) ≈ m · p/q (illustrative only)

For disruptive innovations, q tends higher. For corporate infrastructure (like orbital compute), p tends slightly higher (more strategic buyers).

---

Applying Bass to high machines / orbital compute

The relevant market is commercial orbital compute (not consumer). Use strategic-markets defaults: p = 0.05 (capital decision, not consumer FOMO), q = 0.40 (typical imitation), m = 100 (relative TAM units).

The 4 phases (my read, July 2026)

1. Late introduction (~2024-2027)

   • ~$1.02B+ raised across 11+ startups (per state-of-the-art.md funding table)
   • 1 AI model trained in space (Starcloud, Dec 2025)
   • Multiple FCC filings, reusable launch drops $/kg to LEO
   • Early bets: $1.1B/$2B valuations on Starcloud, Cowboy Space

2. Inflection expected (2027-2029)

   • Mid-2027 architecture lock (prime contractors standardise orbital AI compute)
   • 4,300-satellite network (1 GW compute) technically launched
   • First commercial contracts (satellite operators + hyperscaler adjacency)
   • Series A → Series B transition for leaders

3. Take-off (if it happens) — 2029-2032

   • $35B projected market by 2030 (MarketsandMarkets, sources.db entry 23)
   • Mass multi-tenant deployments
   • New architecture-standard firms emerge
   • EU data sovereignty case hardens (forced demand)

4. Plateau — 2032+

   • Market consolidation (~3-5 firms dominate)
   • Standards locked, "computing in space" is a procurement decision

What the math says

With p = 0.05, q = 0.40, m = 100:

t* = ln(0.40/0.05) / 0.45 = ln(8) / 0.45 ≈ 4.6 years
N(t*) ≈ 100 · (0.45 − 0.10) / (2·0.45 − 0.10) = 100 · 0.35/0.80 ≈ 44 units

Interpretation: from time-of-introduction, peak new deployments happen in ~4.5 years. If introduction = 2024 (Starcloud-2 era), peak ≈ 2028-2029. The architecture lock must land 1-2 years before peak → ~2027, matching the existing claim. Good sanity check.

Strategic S-curve (Foster) insight

Every technology’s performance is an S-curve. When your curve plateaus, you must jump to a new one:

1. First S-curve: Initial orbital compute (closed-vendor: AOCS/power/thermal/GPU optimised independently)
2. Second S-curve: Standardised compute bus (concurrent engineering of whole sat — AI4CE PhD work target)
3. Third S-curve: Orbital DC-as-a-service (multi-tenant, edge-cloud primitives in space)

Jumping too early = building standard for a market that doesn’t exist. Too late = primes lock curve 1 and the standard moves without you. The inflection is the jump window.

---

Open questions for further work

• Validate introduction date: Was 2024 right? Or 2026 (SpaceX mega-merger + FCC filing)? Shifts peak by 1-2 years.
• Estimate m in compute capacity units: GW-class orbital data centres × $/GW × lifetime. The 4,300-sat/1-GW number is a start.
• Real data on early adopters: Who funded what in 2024-2026? Sequoia/a16z/NFX/Coinbase bets map to the p coefficient.
• Comparable S-curve: Cloud adoption (AWS 2006 → 2013 → 2020+) is the cleanest analog.

---

Python sketch (copyable)

import numpy as np
from scipy.optimize import curve_fit

def bass(t, p, q, m):
    """Cumulative adopters N(t) at time t (years)."""
    return m * (1 - np.exp(-(p + q) * t)) / (1 + (q / p) * np.exp(-(p + q) * t))

def bass_new(t, p, q, m):
    """New adopters per period (derivative)."""
    N = bass(t, p, q, m)
    return (p + q * N / m) * (m - N)

# Fit to data: years (t_data) and cumulative adopters (N_data)
# p0 = [0.03, 0.38, N_data.max() * 3]  # initial guess
# popt, pcov = curve_fit(bass, t_data, N_data, p0=p0, maxfev=10_000)
# print("p, q, m:", popt)

# Peak sales time
t_peak = np.log(popt[1] / popt[0]) / (popt[0] + popt[1])

This is a 2-3 hour desk exercise. The data-side work (collecting 2024-2026 capital raised + sats launched per quarter + GPU launches in space) is the harder part. Worth doing if JP wants to defend the "mid-2027 architecture lock" claim with a number, not just a thesis.

---