Curriculum Layout

This document maps the full arc from foundations to a working SSA simulation. Each module builds on the previous ones. The final module project is the payoff: a Rust implementation of a small game-theoretic SSA scenario using everything learned.

The arc in one sentence per module

0. Orbital mechanics and SDA domain: TLEs, SGP4, reference frames, CDMs, conjunction probability, and the commercial SDA data ecosystem — the domain foundation every later ML model is built on top of. SP. Spacepower theory and strategic context: Dolman, Lutes, USSF doctrine, counterspace taxonomy, deterrence stability, Krepinevich's RMA/MTR, Chinese theory, and the mapping from strategic frameworks to game-theoretic tools — why your wargame design choices are the ones they are.
1. Foundations: probability, linear algebra, calculus, SVD, the multivariate Gaussian, and constrained optimization — every tool every later algorithm uses.
2. Neural networks: MLPs as function approximators, PyTorch mechanics, loss functions with MLE/MAP foundations.
3. Reinforcement learning: MDPs, DQN, policy gradients, actor-critic, hierarchical RL, and IMPALA distributed training.
4. Search and planning: MCTS, AlphaZero self-play, and IS-MCTS for fog-of-war games.
5. Game theory: extensive-form games, Nash equilibria, CFR, MCCFR, and Deep CFR.
6. Multi-agent RL: PSRO, fictitious play, alpha-rank, and cooperative CTDE with MAPPO and QMIX.
7. Partial observability: POMDPs, particle filters, imperfect-information games, and opponent modeling.
8. OpenSpiel and capstone: the full OpenSpiel → PettingZoo → Ray RLlib pipeline, a Rust CFR solver, SBIR contracting, and LLM wargame adjudication.
9. Applied SDA ML: sequence models and LSTM maneuver detection from TLE history — the first commercially viable product.

Module 0: Orbital Mechanics and the SDA Data Ecosystem

Builds toward: a Space-Track conjunction screening pipeline; the domain knowledge that grounds every ML model in Modules 1–9.

Project: Space-Track conjunction screening pipeline in Python.

Module SP: Spacepower Theory and Strategic Context

Builds toward: the wargame design choices in Modules 4–8; the strategic vocabulary for government customer conversations.

No project — strategic theory module; connections to later projects are explicit in each lesson.

Module 1: Foundations

Builds toward: a Monte Carlo conjunction probability estimator.

Project: Monte Carlo conjunction probability estimator in Python.

Module 2: Neural Networks as Function Approximators

Builds toward: a trained MLP that predicts conjunction risk from orbital features, the value function approximator pattern used in every later RL module.

Project: train a small MLP to approximate a conjunction-risk scoring function from simulated orbital feature data. Lays the groundwork for the value network in Module 4.

Module 3: Reinforcement Learning Fundamentals

Builds toward: a DQN sensor allocation agent; the distributed training infrastructure for thousands of parallel SSA game simulations.

Project: a DQN agent that learns to allocate sensor dwell time across a set of tracked objects to maximize conjunction-detection reward. First OpenSpiel touchpoint: the game is defined as an OpenSpiel environment.

Module 4: Search and Planning

Builds toward: an AlphaZero-lite agent for pursuit-evasion; IS-MCTS as the inference-time planner for fog-of-war SSA games.

Project: an AlphaZero-lite agent trained by self-play on a small pursuit-evasion game between two spacecraft. Uses an OpenSpiel game definition and PyTorch policy/value networks. Rust translation: the MCTS tree structure.

Module 5: Game Theory and Equilibrium Computation

Builds toward: a CFR solver for a small orbital negotiation game (who maneuvers to avoid conjunction?).

Project: a vanilla CFR and MCCFR solver for the "who maneuvers?" conjunction game defined in OpenSpiel. Rust translation: the CFR data structures (information set table, regret vector). This is the most Rust-relevant lesson in the curriculum.

Module 6: Multi-Agent Reinforcement Learning

Builds toward: a PSRO solver for adversarial satellite-constellation games; MAPPO for cooperative ally coalition training.

Project: a PSRO loop for a 2-player satellite constellation coverage game. Alpha-rank used to analyze which strategies dominate.

Module 7: Partial Observability

Builds toward: a particle-filter RSO belief tracker; the belief-propagation infrastructure for the Module 8 capstone.

Project: a bootstrap particle filter tracking an uncooperative RSO from noisy RA/Dec observations, with ESS monitoring and roughening for deprivation recovery.

Module 8: OpenSpiel and the Rust Capstone

Builds toward: the full production pipeline — OpenSpiel game → PettingZoo → Ray RLlib distributed training — plus a Rust CFR solver, a business on-ramp via SBIR, and LLM wargame adjudication.

Project (capstone): a Rust crate implementing:

• A two-player extensive-form SSA game (attacker tries to mask a maneuver; defender allocates sensors to detect it)
• A vanilla CFR solver over the game tree using native Rust data structures
• A burn neural network trained to approximate regret values (replacing tabular CFR for larger state spaces)
• A simple CLI that runs self-play and prints the Nash equilibrium strategy profile

This is the artifact you could drop into a thesis simulation. It references every concept built in modules 0 through 7 and fills the gap left by the absence of a Rust-native OpenSpiel.

Module 9: Applied SDA ML

Builds toward: a production maneuver detection pipeline — the first commercially viable SDA AI product built entirely from public data.

Project: production LSTM maneuver detection pipeline on Space-Track TLE history with ISS reboost test evaluation.

Curriculum Layout

This curriculum builds from orbital domain knowledge through mathematical foundations to a production-grade AI system for space domain awareness (SDA) wargaming. Each module introduces a new layer of the recommended architecture and connects it to SSA/SDA applications throughout.

Module 0: Orbital Mechanics and the SDA Data Ecosystem

The domain foundation required before any SDA ML work. Covers the TLE format and Keplerian orbital elements, coordinate reference frames (ECI/ECEF/TEME/RTN), SGP4 propagation, conjunction analysis and the CCSDS CDM format, and the commercial SDA data ecosystem (Space-Track, CelesTrak, LeoLabs, and commercial providers). Every concept is tied to practical data engineering: parsing TLEs, batch propagation with python-sgp4, reading CDM covariance matrices, and building a conjunction screening pipeline.

Key outcomes: Parse and ingest TLE and OMM data from Space-Track and CelesTrak; propagate orbital states with python-sgp4; understand the TEME → ECI frame conversion; interpret CDM fields including covariance matrices in the RTN frame; build a 7-day conjunction screening pipeline; understand the SSA vs. SDA distinction and the commercial provider landscape.

Module SP: Spacepower Theory and Strategic Context

The strategic theory foundation for wargame design and the ML deterrence thesis. Six lessons: (1) Foundational spacepower theory (Dolman, Lutes, USSF Space Capstone Publication, Ziarnick, Chinese theory from Carlson), the Outer Space Treaty and its limits; (2) the counterspace operations taxonomy, deterrence stability, Krepinevich's RMA/MTR, commercial space as military infrastructure (Viasat/Starlink/CASR), deterrence by resilience (PWSA, Starshield, disaggregation), allied and partner dimensions (Five Eyes, NATO Space COE, EU SST, Kronos); (3) historical case studies — 2007 Chinese ASAT test, Russia's Luch co-orbital program, Viasat KA-SAT hack; (4) Chinese spacepower doctrine in depth (PLA informationized warfare, Qiao Liang's Unrestricted Warfare, Three Warfares, gray zone wargame findings, Hal Brands on coalition dynamics); (5) space escalation dynamics — the 8-rung escalation ladder with firebreaks, Russian calibrated escalation, Brands/Cooper deterrence dilemmas, ISR blinding as escalation accelerant, the crisis communication problem, the ML deterrence-by-detection thesis; (6) mapping from strategic frameworks to game structures. No code.

Key outcomes: State the Lutes definition of spacepower and explain the OST's actual legal limits; classify counterspace capabilities by kinetic/non-kinetic and reversible/irreversible; describe the Viasat KA-SAT hack and its implications for commercial space as a military target; explain the PWSA resilience logic and the CASR framework; describe the 2007 Chinese ASAT test and Russia's Luch program and the common pattern of capability demonstration below response thresholds; explain the stability-instability paradox and the MTR/RMA distinction; describe PLA Three Warfares doctrine with space examples; explain the gray zone wargame findings and their implications for behavioral detection requirements; name the 8 escalation rungs and 2 firebreaks, and identify which rungs have been operationally observed; articulate the ML deterrence-by-detection thesis including honest limitations; explain why CFR is correct for the conjunction-masking game and when PSRO is required instead; connect each curriculum module to a specific component of the ML deterrence framework.

Module 1: Foundations

Mathematical foundations required for all subsequent modules. Covers probability, Bayesian reasoning, linear algebra (including SVD and Cholesky decomposition), multivariate calculus, the multivariate Gaussian distribution, and constrained optimization. Every concept is introduced in the context of SSA problems: orbital state estimation, conjunction probability, radar measurement uncertainty, and sensor scheduling.

Key outcomes: Understand and implement Bayesian belief update, Monte Carlo estimation, SVD-based dimensionality reduction, covariance matrix manipulation, Mahalanobis distance, and Lagrange multiplier optimization.

Module 2: Neural Networks as Function Approximators

Builds PyTorch neural networks from scratch: activation functions, forward passes, loss functions (with their MLE/MAP probabilistic interpretations), and the full training loop with gradient descent and backpropagation. The emphasis is on understanding what a neural network is mathematically — a parameterized function — before treating it as a black box.

Key outcomes: Implement a working MLP in PyTorch, choose the correct loss function for regression vs. classification, understand why MSE is MLE under Gaussian noise and cross-entropy is MLE for categorical distributions, and debug a training loop.

Module 3: Reinforcement Learning Fundamentals

Sequential decision-making under uncertainty. Markov Decision Processes, value functions, Bellman equations, Q-learning, Deep Q-Networks, policy gradient methods, and actor-critic. Extends to hierarchical RL for decomposing complex multi-scale decisions (strategic/operational/tactical), and IMPALA for distributed large-scale training. Every algorithm is motivated by the sensor-tasking and orbital-maneuver-decision problems in SSA.

Key outcomes: Implement DQN and actor-critic in PyTorch, understand policy gradient variance reduction via baselines and GAE, design a hierarchical RL agent with sub-goal decomposition, and understand IMPALA's actor-learner decoupling for training thousands of parallel environments.

Module 4: Search and Planning

Tree search as an alternative to pure function approximation. Minimax, alpha-beta pruning, MCTS, neural-guided MCTS (AlphaZero-style), and Information Set MCTS for fog-of-war games. IS-MCTS is the inference-time planner in the recommended production architecture: it uses the trained neural network as a prior and handles hidden state by sampling determinizations.

Key outcomes: Implement MCTS and understand UCB exploration, understand how AlphaZero combines MCTS with neural network training, implement IS-MCTS with determinization sampling for an imperfect-information SSA scenario.

Module 5: Game Theory and Equilibrium Computation

Formal game theory: normal-form and extensive-form games, Nash equilibrium, information sets, and imperfect information. CFR (Counterfactual Regret Minimization) is the primary algorithm — the one that produced superhuman poker play. Monte Carlo CFR scales CFR to large games via sampling. Deep CFR replaces tabular regret storage with a neural network, making CFR applicable to games too large for exact tabular methods.

Key outcomes: Understand Nash equilibrium and why it is the right solution concept for adversarial multi-agent problems, implement vanilla CFR for a small extensive-form game, understand MCCFR's sampling strategies and their variance-speed tradeoff, understand Deep CFR's neural network approximation.

Module 6: Multi-Agent Reinforcement Learning

Running RL in multi-agent environments: non-stationarity, joint policy search via PSRO, population evaluation via Alpha-rank, and the CTDE (Centralized Training, Decentralized Execution) paradigm. CTDE is the foundation of MAPPO and QMIX — the practical algorithms for training cooperative multi-agent systems. In the recommended SSA wargame architecture, CTDE trains the ally coalition while PSRO/self-play trains adversarial agents.

Key outcomes: Understand why multi-agent non-stationarity breaks single-agent RL convergence guarantees, implement the PSRO outer loop with meta-game Nash solving, implement MAPPO with a centralized critic and decentralized execution, understand QMIX's value decomposition for cooperative reward sharing.

Module 7: Partial Observability

Hidden state inference combined with decision-making. POMDPs as the formal framework, belief states as sufficient statistics, particle filters for nonlinear/non-Gaussian state estimation, and imperfect-information games when multiple strategic agents each have private information. Opponent modeling: Bayesian type inference and KL divergence-based model drift detection.

Key outcomes: Implement a particle filter for orbital state estimation, understand why the belief state is a sufficient statistic (the Markov property applied to beliefs), connect POMDP belief updating to the Kalman filter, model an opponent's type from observed actions using Bayes' rule.

Module 8: OpenSpiel and the Rust Capstone

Production engineering of the full stack. OpenSpiel's C++ game architecture and Python bindings, implementing custom games, the PettingZoo/shimmy/Ray RLlib integration pipeline (OpenSpiel → PettingZoo → MARLlib → distributed training), and the Rust/burn production gap. The module also covers the business on-ramp: SBIR/SpaceWERX contracting for uncleared solo founders, and LLM-in-the-loop wargame adjudication using locally-deployed models. The capstone implements a Rust CFR solver for an SSA conjunction-masking game.

Key outcomes: Implement a custom game in OpenSpiel's C++ API, wire it to PettingZoo via the shimmy compatibility wrapper, configure Ray RLlib for multi-agent training with thousands of parallel environments, understand SBIR eligibility requirements and the commercial-first vs. SBIR-first trade-off, build an LLM-adjudicated wargame with local models meeting FedRAMP constraints, and complete the capstone CFR solver.

Module 9: Applied SDA ML

The curriculum's commercial product module. Takes the ML foundations from Modules 1–8 and applies them to the highest-value SDA AI product a solo uncleared founder can build from public data: maneuver detection from TLE history. Covers the label scarcity problem and synthetic data generation, feature engineering for orbital sequences (time-normalized delta features, J2 drift removal, BSTAR caveats), LSTM architecture and training, and operational evaluation metrics (detection latency, false alarm rate) that matter for deployment.

Key outcomes: Build a full maneuver detection pipeline on Space-Track TLE history; engineer physically meaningful orbital sequence features; train an LSTM classifier using synthetic label injection; evaluate against real ISS reboost test events with detection latency and false alarm rate metrics; understand the competitive landscape for TLE-based SDA AI products.

Module 0: Orbital Mechanics and the SDA Data Ecosystem

Why this module comes before everything else

Every lesson in this curriculum involves building, evaluating, or deploying a machine learning model that processes space domain data. Before you can reason about what those models are doing, you need to understand the data artifacts they consume.

This is not an orbital mechanics course. You will not derive Kepler's laws or integrate the equations of motion by hand. What you will do is develop working knowledge of the data structures, coordinate systems, propagation tools, and domain concepts that appear in every SDA data pipeline. When a conjunction assessment model ingests a CDM and produces a risk score, you need to know what a CDM is, what its fields mean, what assumptions went into generating it, and what the model is actually learning. Without that, you cannot debug the pipeline, assess model quality, or explain results to a customer.

The lessons here are deliberately practical. Each one starts with a real data artifact — a TLE, a CDM, an API response — and builds the theory needed to interpret it correctly.

SSA vs. SDA: a distinction that matters for your customers

These terms are often used interchangeably in commercial settings, and carelessly conflating them will mark you as a newcomer to DoD customers.

SSA (Space Situational Awareness) is the legacy term, dominant through the 2010s. It refers primarily to catalog maintenance, object tracking, and conjunction screening — understanding where things are and predicting where they will be. SSA is positional: detecting, tracking, characterizing, and cataloging resident space objects.

SDA (Space Domain Awareness) is the current DoD term, adopted officially in 2020. SDA extends SSA to include adversarial intent characterization, RF intelligence, behavioral analysis, and the fusion of multi-source intelligence to understand not just where objects are but what they are doing and why. A maneuvering satellite that happens to reposition near a US asset is an SSA event (we detected a maneuver) and an SDA question (is this an intelligence-gathering approach or a routine station-keeping burn?).

The practical distinction for product positioning: commercial satellite operators primarily need SSA capabilities — conjunction avoidance, maneuver detection for collision risk, covariance realism for accurate Pc. Government customers, especially at the combatant command level, want SDA — behavioral pattern-of-life analysis, RF characterization, anomaly detection with adversarial context. Your ML product architecture is similar either way, but your customer conversations and contract structures differ significantly.

In this curriculum, we use SDA as the umbrella term because it encompasses everything we build. Where the distinction matters, we call it out explicitly.

Lessons in this module

Lesson 1: TLEs and Keplerian Elements

The canonical data artifact for tracking space objects is the Two-Line Element set (TLE). This lesson starts with a real TLE, parses every field, then builds the six Keplerian elements needed to understand what those fields represent. Covers the critical warning about mean vs. osculating elements and why you cannot difference consecutive TLE elements to detect maneuvers. Introduces the OMM (Orbit Mean-elements Message) format that Space-Track now returns from its API.

Lesson 2: Reference Frames

A position vector means nothing without a reference frame. This lesson covers the four frames you will encounter in every SDA pipeline: ECI (J2000/GCRF) for orbital mechanics, ECEF for ground station geometry, TEME for SGP4 output, and RTN/RIC for conjunction analysis covariances. Includes the most common pipeline bug in SSA software: treating SGP4's TEME output as J2000 ECI and comparing it with telescope observations without converting.

Lesson 3: SGP4 Propagation

SGP4 is the propagation engine behind every public TLE. This lesson covers what SGP4 includes (J2 through J6 harmonics, atmospheric drag via BSTAR), what it excludes (third-body gravity for LEO/MEO objects — that is SDP4), and its honest accuracy characterization. Includes working Python code for single-object and batch propagation, and the signature of a maneuver in TLE history.

Lesson 4: Conjunction Analysis

Two objects pass close enough to trigger a screening event. This lesson covers the full conjunction analysis pipeline: asymmetric pizza-box screening volumes, the conjunction plane geometry, the Foster/Chan Pc computation method, and the CCSDS CDM format in detail. Covers covariance realism — why TLE-derived covariances are systematically too small, and why this makes ML covariance inflation models commercially valuable.

Lesson 5: The SDA Data Ecosystem (no quiz)

A reference lesson covering every major data source you will encounter: Space-Track/18 SDS, CelesTrak, LeoLabs, COMSPOC, ExoAnalytic, Kayhan, Slingshot, EU SST, and others. Covers API access patterns, data pipeline architecture for ML feature engineering, and the commercial product landscape your models will compete in.

How this module connects to the rest of the curriculum

The connections are direct and specific:

Module 1 (Foundations) — Monte Carlo Pc: Module 1 Lesson 3 covers Monte Carlo estimation. The canonical SDA application is Monte Carlo Pc: sampling from the CDM's combined covariance and counting collision events. That lesson assumes you know what a covariance matrix in RTN space means, what a CDM is, and why the analytical Foster Pc differs from a Monte Carlo estimate. Lesson 4 here gives you that foundation.

Module 7 (Partial Observability) — Particle Filters for Orbit Determination: The particle filter lesson applies sequential Monte Carlo to tracking a maneuvering satellite. The state vector is position and velocity in ECI. The observation model involves reference frame conversions from ground-based radar. Every concept from Lessons 1–3 of this module feeds directly into that application.

Module 8 (Capstone) — SSA Game: The capstone strategic game involves RSO tracking, sensor scheduling, and maneuver attribution. Players work with TLE-derived features, CDM-derived risk scores, and the behavioral analysis concepts from the SDA ecosystem lesson. You need the full Module 0 vocabulary to engage with the capstone at the right level.

Module 9 (Applied SDA ML): The applied module builds production ML features from TLE histories, CDM sequences, and behavioral indicators. Every feature engineering decision in that module traces back to domain concepts introduced here: J2-driven RAAN precession as a baseline to subtract, along-track uncertainty as the dominant CDM covariance dimension, epoch age as a weak uncertainty proxy.

What you will be able to do after this module

After completing Module 0, you will be able to:

• Read a TLE or OMM from Space-Track and correctly interpret every field
• Propagate any tracked object forward using python-sgp4 and correctly identify the output reference frame as TEME
• Convert TEME positions to GCRS/J2000 using Astropy for comparison with external observation sources
• Parse a CCSDS CDM, extract the covariance matrix, understand which dimension is largest and why, and explain what the COLLISION_PROBABILITY field represents and what method produced it
• Access Space-Track and CelesTrak programmatically and build a simple TLE history ingestion pipeline
• Explain the SSA/SDA distinction to both commercial satellite operators and DoD customers
• Describe the competitive landscape of commercial SDA data and analytics providers

These capabilities are prerequisites for every applied lesson in the curriculum. The module project builds a complete conjunction screening pipeline from public data that demonstrates all of them together.

Lesson 1: TLEs and Keplerian Elements

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem Source: Satellite Orbits — Oliver Montenbruck & Eberhard Gill, Chapter 3; Space-Track.org API documentation; Celestrak GP documentation; Hoots & Roehrich (1980), "Models for Propagation of NORAD Element Sets"

Where this fits

Before any ML model can process space domain data, a data engineer has to answer a fundamental question: what exactly is the input data, and where does it come from? In SDA, the answer starts here — with the Two-Line Element set. TLEs are the most widely used format for tracking the 50,000+ objects in Earth orbit. Every public conjunction screening pipeline, every orbital mechanics simulation, every satellite pass prediction tool starts by reading TLEs. This lesson makes you fluent in the format.

The data engineer's natural approach is to start with the artifact and work backward to the theory. That is exactly what we do here. By the end of this lesson you will be able to parse any TLE programmatically, understand every field's physical meaning, and know exactly where the format's limits are — including the critical warning about what you cannot do with TLE data that is a frequent source of bugs in production pipelines.

A space scenario to motivate everything

It is early morning at your commercial SDA company. An automated alert fires: a client satellite has a conjunction event scheduled for 14:32 UTC — 11 hours from now. Your pipeline ingested the latest Space-Track CDM at 02:15 UTC. To validate the alert, you open the raw data and see this:

ISS (ZARYA)
1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991
2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697

This is a TLE. Three lines of ASCII text encode the complete orbital state of the International Space Station. Your ML feature engineering pipeline reads thousands of these per hour. This lesson explains every character.

Here is a real TLE — let us parse it

A TLE has three lines. Line 0 is the satellite name. Lines 1 and 2 contain the orbital data. The format was designed in the 1970s for punched cards, which is why it looks the way it does — fixed-width ASCII fields with no delimiters.

Line 0: the name

ISS (ZARYA)

This is simply the satellite's common name. It can be up to 24 characters. The NORAD catalog number on Line 1 is the authoritative identifier — the name is informational.

Line 1: catalog and epoch data

1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991

Let us go field by field:

About ndot and ndotdot: These fields are labeled "first and second time derivatives of mean motion" and were used in the legacy SDP4 analytical model. In SGP4/SDP4 as actually implemented, BSTAR and the mean motion directly drive the drag calculation. The ndot and ndotdot fields are present for format compatibility but are typically set to zero or near-zero in modern TLEs distributed by Space-Track. Do not use them as drag signals; use BSTAR.

Reading BSTAR: The implied decimal format 27837-3 means 0.27837 × 10⁻³ = 0.00027837. Higher BSTAR means more atmospheric drag — the object has a large area-to-mass ratio (like a flat panel or solar array) or is at a lower altitude where the atmosphere is denser.

Reading the epoch: 24274.50000000 decodes as: year 2024, day 274.5. Day 274 of 2024 is September 30. Day 274.5 is noon on September 30, 2024 UTC. The epoch tells you when this TLE was fitted — it is the reference time from which SGP4 propagates forward or backward.

Line 2: orbital elements

2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697

The six orbital elements on Line 2 (inclination, RAAN, eccentricity, argument of perigee, mean anomaly, mean motion) encode the satellite's orbit shape, orientation, and current position. The next section explains each one physically.

The six classical Keplerian elements

Keplerian elements describe an orbit under idealized two-body gravity (Earth as a point mass, no perturbations). TLEs store a modified version of these elements — mean elements averaged over short-period perturbations — but the physical intuition comes from the classical Keplerian picture.

Semi-major axis (a): orbit size

The semi-major axis is the "radius" of the ellipse — half the longest dimension. For a circular orbit, it equals the actual orbital radius. It is not stored directly in a TLE; instead TLEs store mean motion (revolutions per day), and you derive a from the relationship:

$$n=\sqrt{\frac{G{M}_{\oplus }}{a^3}}⟹a={\left(\frac{G{M}_{\oplus }}{n^2}\right)}^{1/3}$$

where $n$ is mean motion in radians per second and $G{M}_{\oplus }=3.986\times 10^{14}$ m³/s² is Earth's standard gravitational parameter. For the ISS with mean motion 15.5 rev/day, this gives a ≈ 6,785 km — about 407 km above Earth's surface (Earth radius ≈ 6,378 km).

Orbit regime intuitions:

• LEO (Low Earth Orbit): a ≈ 6,550 to 8,375 km (170 to 2,000 km altitude)
• MEO (Medium Earth Orbit): a ≈ 8,375 to 42,165 km (GPS at 20,200 km altitude)
• GEO (Geostationary Earth Orbit): a = 42,164 km exactly (35,786 km altitude, ~24h period)
• HEO (Highly Elliptical Orbit): large a with high eccentricity — Molniya orbits

Eccentricity (e): orbit shape

Eccentricity describes how elliptical the orbit is. e = 0 is a perfect circle; e approaching 1 is a very elongated ellipse.

• ISS: e = 0.0001567 — nearly perfectly circular
• GPS satellites: e ≈ 0.001 — slightly elliptical but functionally circular
• Molniya orbit: e ≈ 0.74 — highly elliptical, designed to spend most time over high latitudes
• GTO (Geostationary Transfer Orbit): e ≈ 0.73 — elliptical, used to transfer from LEO to GEO

For circular orbits (e ≈ 0), the argument of perigee (ω) becomes poorly defined — there is no perigee to speak of because the orbit has no closest-approach point. This is a common source of numerical issues in algorithms that use ω as a feature for near-circular LEO objects.

Inclination (i): orbital plane tilt

Inclination is the angle between the orbital plane and Earth's equatorial plane.

• i = 0°: equatorial orbit, satellite always over the equator (GEO)
• i = 51.6°: ISS — chosen to allow Russian cosmonaut launches from Baikonur
• i = 55.0°: GPS Block IIR constellation
• i = 90°: polar orbit, passes over both poles
• i = 97–98°: sun-synchronous orbit, the retrograde drift from J2 is designed to keep the orbital plane aligned with the Sun
• i > 90°: retrograde orbit, satellite moves opposite to Earth's rotation

Inclination directly determines ground coverage. A satellite at 51.6° can never pass over latitudes above 51.6° or below -51.6°. If you are asking "can this object observe [some ground target]?", inclination is the first filter.

RAAN (Ω): which half of the sky

The Right Ascension of the Ascending Node describes where the orbital plane intersects the equatorial plane, measured from the vernal equinox (a fixed reference direction in inertial space). RAAN tells you which "slice" of the sky the orbit occupies.

For a sun-synchronous orbit at 500 km, 97.4° inclination, J2 causes RAAN to precess eastward at about +0.986°/day — exactly one degree per day, matching Earth's motion around the Sun. This keeps the orbital plane at a fixed angle relative to the Sun, which is why remote-sensing satellites use it (consistent illumination geometry).

For the ISS at 51.6° inclination and 400 km altitude, J2 causes RAAN to precess westward at approximately -6.75°/day. Over one week, RAAN shifts about 47°. This is a predictable, secular drift — it is not a maneuver. Before using RAAN as a maneuver-detection feature, you must subtract the J2-predicted drift. Otherwise you will flag every non-maneuvering LEO object as maneuvering.

The J2 RAAN precession rate formula:

$$\dot{\Omega }=-\frac{3}{2}n{J}_2{\left(\frac{R_{\oplus }}{a}\right)}^2\frac{\cos i}{(1-e^2{)}^2}$$

where $J_2=1.08263\times 10^{-3}$ is Earth's second zonal harmonic coefficient, $R_{\oplus }$ is Earth's mean equatorial radius, and $n$ is mean motion. For the ISS, this evaluates to approximately -6.75°/day.

Argument of perigee (ω): which end is closest

For an elliptical orbit, one end is closer to Earth (perigee) and one is farther (apogee). The argument of perigee describes which direction perigee points, measured within the orbital plane from the ascending node.

For near-circular LEO orbits (e ≈ 0), ω is numerically unstable and physically meaningless — the "perigee" can be anywhere around the orbit because the orbit is nearly circular. SGP4 handles this gracefully internally, but be cautious using ω as a raw feature for LEO objects.

For Molniya or HEO orbits, ω is critical and well-defined. Molniya orbits are designed with ω = 270° so that apogee (the slow, high part) is over the northern hemisphere.

Mean anomaly (M): where in the orbit right now

Mean anomaly is a linear angle proxy for the satellite's current position in its orbit. It increases uniformly from 0° to 360° over one orbital period, reaching 360° at the same time the satellite completes one revolution. At M = 0°, the satellite is at perigee (for an elliptical orbit).

Important distinction: TLEs store mean anomaly (M), not true anomaly (ν). These are different:

• Mean anomaly (M): a mathematical construct that increases uniformly. It does not equal the actual angular position.
• True anomaly (ν): the actual geometric angle of the satellite from perigee. For a circular orbit, M = ν. For an elliptical orbit, ν varies nonlinearly — the satellite moves faster near perigee and slower near apogee.

SGP4 internally converts mean anomaly to true anomaly (via the eccentric anomaly) when computing the position vector. You do not have to do this conversion yourself — just know that when you see M in a TLE, it is the uniform linear angle, not the geometric angle.

Mean elements vs. osculating elements

This distinction is the source of a critical production bug that appears repeatedly in SDA pipelines.

Osculating elements are the instantaneous Keplerian elements that match the satellite's exact position and velocity at a specific moment, accounting for all perturbations at that instant. They change continuously as perturbations (J2, drag, third-body gravity) act on the orbit.

Mean elements are computed by averaging out short-period perturbations. TLEs store mean elements defined specifically for use with the SGP4 propagation algorithm. The mean element values have no meaning outside of SGP4 — they are SGP4 input parameters, not physical observables.

The critical warning: never difference consecutive TLE Keplerian elements

Suppose you download a TLE history for a satellite and compute the difference in RAAN between consecutive TLEs, hoping to detect maneuvers as anomalous jumps. This approach has two fundamental problems:

1. Secular J2 drift: RAAN precesses at -6.75°/day for the ISS. If you difference two TLEs 3 days apart, you get a ~20° RAAN change from J2 alone. You have to subtract the predicted J2 drift — and that requires knowing the exact epoch difference and the J2 formula for this specific orbit.

2. Mean elements are SGP4-internal: Even after correcting for J2 drift, the mean element values from consecutive TLEs reflect SGP4's averaging conventions. Differencing them mixes secular drift, periodic perturbation modeling artifacts, and observation data batch update artifacts in ways that are not cleanly separable from maneuver signals.

The correct approach: propagate both TLEs to a common epoch using SGP4 and compare the resulting Cartesian position and velocity vectors. A maneuver appears as a sudden change in the propagated trajectory between two TLE epochs that exceeds what J2, drag, and other perturbations would predict. This is what the ML maneuver detection models in Module 9 do.

Additionally: TLE mean elements are not interchangeable with mean elements from other propagators. The $GM$ value embedded in TLE mean motion ($GM=398600.4418$ km³/s²) differs slightly from the IAU standard. High-fidelity numerical propagators use a different $GM$. Mixing them without conversion introduces systematic errors.

TLE freshness and accuracy

TLE accuracy degrades with time from the epoch, but not smoothly or predictably.

Epoch age is the time since the TLE was fitted to radar observations. A 1-day-old TLE is generally more accurate than a 7-day-old TLE — but this is a weak proxy for uncertainty. The actual accuracy depends on:

1. Unmodeled maneuvers: if a satellite maneuvered after the TLE epoch, the old TLE's prediction can be wrong by tens to hundreds of kilometers, regardless of how fresh it is. A 12-hour-old TLE for a satellite that maneuvered 6 hours ago is essentially useless for collision avoidance.

2. Atmospheric drag variability: the BSTAR term encodes a mean drag coefficient. During geomagnetic storms (elevated Kp index) or periods of high solar activity (elevated F10.7 flux), the upper atmosphere expands and drag forces increase dramatically. LEO objects can deviate tens of kilometers from their predicted positions within hours of a major geomagnetic storm.

3. Observation data quality: TLEs are fitted to radar observations from the Space Surveillance Network. The accuracy of the fitted TLE depends on how many observations were available, their geometric diversity, and the fitting algorithm.

A practical rule of thumb: a TLE epoch older than 3 days for a maneuvering satellite should be treated with extreme skepticism. For passive debris with stable drag, a 7-day-old TLE might be good to a few kilometers. For a GEO object where solar radiation pressure is the dominant perturbation and is poorly modeled, even a 1-day-old TLE can be several kilometers off.

For ML purposes: epoch age is a feature, but covariance from CDMs is a much stronger uncertainty signal. Build your models to prefer covariance-based uncertainty quantification when available.

The OMM format: TLE data in JSON

Space-Track's API now returns orbital data as Orbit Mean-elements Messages (OMM) in JSON or XML format. OMM is defined in the CCSDS standard (CCSDS 502.0-B-2). The data content is identical to a TLE — same SGP4 mean elements — but the format is structured, machine-readable, and extensible.

Key point: OMM is not higher-fidelity than TLE. It is the same data in a better format. You still use SGP4 to propagate it; the OMM fields map directly to TLE fields.

A sample Space-Track OMM JSON response:

{
  "CCSDS_OMM_VERS": "2.0",
  "COMMENT": "GENERATED VIA SPACE-TRACK.ORG API",
  "CREATION_DATE": "2024-10-01T06:00:00",
  "ORIGINATOR": "18 SPACE DEFENSE SQUADRON",
  "OBJECT_NAME": "ISS (ZARYA)",
  "OBJECT_ID": "1998-067A",
  "CENTER_NAME": "EARTH",
  "REF_FRAME": "TEME",
  "TIME_SYSTEM": "UTC",
  "MEAN_ELEMENT_THEORY": "SGP4",
  "EPOCH": "2024-10-01T00:00:00.000000",
  "MEAN_MOTION": "15.50095566",
  "ECCENTRICITY": "0.0001567",
  "INCLINATION": "51.6415",
  "RA_OF_ASC_NODE": "282.4781",
  "ARG_OF_PERICENTER": "231.1584",
  "MEAN_ANOMALY": "128.9321",
  "EPHEMERIS_TYPE": "0",
  "CLASSIFICATION_TYPE": "U",
  "NORAD_CAT_ID": "25544",
  "ELEMENT_SET_NO": "999",
  "REV_AT_EPOCH": "47269",
  "BSTAR": "0.00027837",
  "MEAN_MOTION_DOT": "0.00015669",
  "MEAN_MOTION_DDOT": "0.0"
}

The field names are self-documenting. Note that REF_FRAME is listed as TEME — this is correct and important. SGP4 outputs are in TEME, not J2000 ECI. Lesson 2 covers reference frame conversion.

Code

Parsing a TLE with python-sgp4

"""
Parse a real ISS TLE and inspect all fields using python-sgp4.

Install: pip install sgp4
"""
from sgp4.api import Satrec, jday
from datetime import datetime, timezone
import math

# Real ISS TLE (NORAD 25544) — Line 0, Line 1, Line 2
TLE_LINE0 = "ISS (ZARYA)"
TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"

# Parse the TLE into an sgp4 satellite record
satellite = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# --- Inspect all SGP4-accessible fields ---
print("=== TLE Metadata ===")
print(f"NORAD catalog number : {satellite.satnum}")
print(f"International desig  : {satellite.intldesg}")
print(f"Classification       : {satellite.classification}")
print(f"Element set number   : {satellite.elnum}")
print(f"Revolution number    : {satellite.revnum}")

print("\n=== Epoch ===")
print(f"Epoch year (2-digit) : {satellite.epochyr}")
print(f"Epoch day of year    : {satellite.epochdays:.8f}")
# Reconstruct full epoch as a Python datetime for human readability
epoch_year = 2000 + satellite.epochyr if satellite.epochyr < 57 else 1900 + satellite.epochyr
epoch_day  = satellite.epochdays
epoch_int  = int(epoch_day)
epoch_frac = epoch_day - epoch_int
epoch_dt   = datetime(epoch_year, 1, 1, tzinfo=timezone.utc)
from datetime import timedelta
epoch_dt  += timedelta(days=epoch_int - 1, seconds=epoch_frac * 86400)
print(f"Epoch (UTC)          : {epoch_dt.isoformat()}")

print("\n=== Keplerian Mean Elements (SGP4 internal) ===")
# Mean motion is stored internally in radians per minute by sgp4
# Convert to revolutions per day for TLE convention
rev_per_day = satellite.no_kozai * (1440.0 / (2 * math.pi))
print(f"Mean motion (rev/day): {rev_per_day:.8f}")
print(f"Inclination (rad)    : {satellite.inclo:.6f}  ({math.degrees(satellite.inclo):.4f}°)")
print(f"RAAN (rad)           : {satellite.nodeo:.6f}  ({math.degrees(satellite.nodeo):.4f}°)")
print(f"Eccentricity         : {satellite.ecco:.7f}")
print(f"Arg of perigee (rad) : {satellite.argpo:.6f}  ({math.degrees(satellite.argpo):.4f}°)")
print(f"Mean anomaly (rad)   : {satellite.mo:.6f}  ({math.degrees(satellite.mo):.4f}°)")

print("\n=== Drag / Force Model ===")
print(f"BSTAR drag term      : {satellite.bstar:.8f}")
print(f"ndot (ndot/2 stored) : {satellite.ndot:.8f}  (rev/day²)")
print(f"ndotdot              : {satellite.nddot:.8f}  (rev/day³)")

print("\n=== Derived: Semi-major Axis ===")
# GM for SGP4 (XKMPER and XKE constants baked into sgp4 library)
# Use the TLE mean motion to derive semi-major axis
# n in rad/s, GM in km^3/s^2
GM_km3s2 = 398600.4418  # km³/s²
n_rad_s  = satellite.no_kozai / 60.0  # convert from rad/min to rad/s
a_km     = (GM_km3s2 / n_rad_s**2) ** (1.0 / 3.0)
alt_km   = a_km - 6378.137  # subtract Earth equatorial radius
print(f"Semi-major axis      : {a_km:.1f} km")
print(f"Approximate altitude : {alt_km:.1f} km")

# --- Propagate to epoch to get TEME position/velocity ---
print("\n=== Propagate to Epoch (TEME frame) ===")
# Get Julian date for the TLE epoch
jd_epoch, fr_epoch = satellite.jdsatepoch, satellite.jdsatepochF
e, r, v = satellite.sgp4(jd_epoch, fr_epoch)
print(f"Error code           : {e}  (0 = success)")
print(f"TEME position (km)   : x={r[0]:.3f}, y={r[1]:.3f}, z={r[2]:.3f}")
print(f"TEME velocity (km/s) : x={v[0]:.6f}, y={v[1]:.6f}, z={v[2]:.6f}")
orbital_speed = (v[0]**2 + v[1]**2 + v[2]**2)**0.5
print(f"Orbital speed (km/s) : {orbital_speed:.3f}")

Parsing an OMM JSON from Space-Track API

"""
Ingest an OMM JSON response from Space-Track and convert to an sgp4 satellite record.

This demonstrates:
1. How to interpret OMM field names
2. How to build a TLE string from OMM fields for use with python-sgp4
3. Schema validation for a production ingestion pipeline

Install: pip install sgp4
"""
import json
import math
from sgp4.api import Satrec

# Sample OMM JSON — this is the format Space-Track's GP endpoint returns
# Endpoint: https://www.space-track.org/basicspacedata/query/class/gp/
#           NORAD_CAT_ID/25544/format/json
OMM_JSON = """
{
  "CCSDS_OMM_VERS": "2.0",
  "OBJECT_NAME": "ISS (ZARYA)",
  "OBJECT_ID": "1998-067A",
  "CENTER_NAME": "EARTH",
  "REF_FRAME": "TEME",
  "TIME_SYSTEM": "UTC",
  "MEAN_ELEMENT_THEORY": "SGP4",
  "EPOCH": "2024-10-01T12:00:00.000000",
  "MEAN_MOTION": "15.50095566",
  "ECCENTRICITY": "0.0001567",
  "INCLINATION": "51.6415",
  "RA_OF_ASC_NODE": "282.4781",
  "ARG_OF_PERICENTER": "231.1584",
  "MEAN_ANOMALY": "128.9321",
  "EPHEMERIS_TYPE": "0",
  "CLASSIFICATION_TYPE": "U",
  "NORAD_CAT_ID": "25544",
  "ELEMENT_SET_NO": "999",
  "REV_AT_EPOCH": "47269",
  "BSTAR": "0.00027837",
  "MEAN_MOTION_DOT": "0.00015669",
  "MEAN_MOTION_DDOT": "0.0"
}
"""

omm = json.loads(OMM_JSON)

# --- Print every field with explanation ---
FIELD_DESCRIPTIONS = {
    "CCSDS_OMM_VERS":      "CCSDS standard version",
    "OBJECT_NAME":         "Common name (informational)",
    "OBJECT_ID":           "International designator (YYYY-NNNP)",
    "CENTER_NAME":         "Central body for the orbit",
    "REF_FRAME":           "Reference frame for state vector output (TEME for SGP4)",
    "TIME_SYSTEM":         "Time system for epoch",
    "MEAN_ELEMENT_THEORY": "Propagator theory — must be SGP4 to use python-sgp4",
    "EPOCH":               "Reference epoch for the mean elements (UTC)",
    "MEAN_MOTION":         "Revolutions per day (TLE Line 2 column 53-63)",
    "ECCENTRICITY":        "Dimensionless, 0=circular, 1=parabolic escape",
    "INCLINATION":         "Orbital plane tilt from equator, degrees",
    "RA_OF_ASC_NODE":      "RAAN: right ascension of ascending node, degrees",
    "ARG_OF_PERICENTER":   "Argument of perigee, degrees (ill-defined if e≈0)",
    "MEAN_ANOMALY":        "Linear angle proxy for position, degrees (not true anomaly)",
    "EPHEMERIS_TYPE":      "Always 0 for public TLEs",
    "CLASSIFICATION_TYPE": "U=unclassified, S=secret, C=classified",
    "NORAD_CAT_ID":        "Primary key for Space-Track lookups",
    "ELEMENT_SET_NO":      "Sequential TLE revision counter for this object",
    "REV_AT_EPOCH":        "Total revolutions completed since launch at epoch",
    "BSTAR":               "SGP4 drag coefficient (incorporates B*CD*A/2m)",
    "MEAN_MOTION_DOT":     "First derivative of mean motion, rev/day² (usually small)",
    "MEAN_MOTION_DDOT":    "Second derivative of mean motion, rev/day³ (usually 0)",
}

print("=== OMM Field Inventory ===")
for field, value in omm.items():
    desc = FIELD_DESCRIPTIONS.get(field, "")
    print(f"  {field:<25} = {str(value):<20}  # {desc}")

# --- Build TLE strings from OMM for use with python-sgp4 ---
# python-sgp4 can also construct from OMM directly via Satrec.twoline2rv,
# but building explicit TLE strings is useful for logging and debugging.

def build_tle_from_omm(omm: dict) -> tuple[str, str]:
    """
    Reconstruct TLE Line 1 and Line 2 strings from an OMM JSON dict.
    Note: this produces a TLE-formatted string; the underlying data is identical.
    """
    norad    = int(omm["NORAD_CAT_ID"])
    intl     = omm["OBJECT_ID"].replace("-", "")[:8]  # e.g. 1998067A -> 98067A
    intl_fmt = intl[2:] if len(intl) > 6 else intl    # strip century from year

    # Parse epoch
    from datetime import datetime
    epoch_dt = datetime.fromisoformat(omm["EPOCH"].replace("Z", ""))
    year2    = epoch_dt.year % 100
    day_of_year = epoch_dt.timetuple().tm_yday
    frac_day    = (epoch_dt.hour * 3600 + epoch_dt.minute * 60 +
                   epoch_dt.second + epoch_dt.microsecond / 1e6) / 86400.0
    epoch_str   = f"{year2:02d}{day_of_year + frac_day:012.8f}"

    # Format drag fields (implied decimal notation for TLE)
    def fmt_implied(val: float, width: int = 8) -> str:
        """Format a float in TLE implied-decimal notation (e.g. 0.27837e-3 -> 27837-3)."""
        if val == 0.0:
            return " 00000-0"
        import math
        exp = math.floor(math.log10(abs(val))) + 1
        mantissa = val / (10 ** exp)
        return f"{mantissa:+.5f}".replace("0.", "").replace(".", "") + f"{exp:+02d}"[-2:]

    ndot_str   = f"{float(omm['MEAN_MOTION_DOT']):+.8f}"
    ndotdot_str = " 00000-0"  # almost always zero
    bstar_str   = fmt_implied(float(omm["BSTAR"]))
    classif     = omm.get("CLASSIFICATION_TYPE", "U")

    line1 = (f"1 {norad:05d}{classif} {intl_fmt:<8} {epoch_str} "
             f"{ndot_str} {ndotdot_str} {bstar_str} 0 {int(omm['ELEMENT_SET_NO']):4d}0")

    ecc_str  = f"{float(omm['ECCENTRICITY']):.7f}".replace("0.", "")
    line2 = (f"2 {norad:05d} "
             f"{float(omm['INCLINATION']):8.4f} "
             f"{float(omm['RA_OF_ASC_NODE']):8.4f} "
             f"{ecc_str} "
             f"{float(omm['ARG_OF_PERICENTER']):8.4f} "
             f"{float(omm['MEAN_ANOMALY']):8.4f} "
             f"{float(omm['MEAN_MOTION']):11.8f}"
             f"{int(omm['REV_AT_EPOCH']):5d}0")

    return line1, line2

line1, line2 = build_tle_from_omm(omm)
print(f"\n=== Reconstructed TLE ===")
print(f"Line 1: {line1}")
print(f"Line 2: {line2}")

# Verify by parsing with sgp4
sat = Satrec.twoline2rv(line1, line2)
print(f"\nParsed NORAD ID : {sat.satnum}")
print(f"Inclination     : {math.degrees(sat.inclo):.4f}°")
print(f"BSTAR           : {sat.bstar:.8f}")

Key Takeaways

• The TLE is a fixed-width ASCII format encoding six SGP4 mean orbital elements plus metadata. Every field has a specific physical meaning. NORAD ID is the primary key for Space-Track lookups. Epoch encodes the reference time. BSTAR is the drag proxy. ndot and ndotdot are legacy fields, usually zeroed.

• Mean anomaly (M) is a linear angle proxy, not the true geometric angle. SGP4 converts M to a position vector internally. Never confuse M with true anomaly ν.

• Mean elements are SGP4-internal quantities, not physical observables. You cannot subtract consecutive TLE Keplerian elements to detect maneuvers. The mean element values are defined only in the context of SGP4. To detect maneuvers, propagate both TLEs to a common epoch and compare Cartesian positions.

• RAAN precesses due to J2 at a predictable rate (~-6.75°/day for ISS orbit). This is secular drift, not a maneuver. Subtract the J2-predicted drift before using RAAN as a feature.

• Epoch age is a weak proxy for uncertainty. Accuracy depends on unmodeled maneuvers and atmospheric density variability, not just how old the TLE is. A 6-hour-old TLE for a satellite that maneuvered 3 hours ago is useless for conjunction avoidance.

• OMM is TLE in JSON format, not higher-fidelity data. Space-Track's API returns OMM by default. Parse it with the same SGP4 library; the physics is identical.

Quiz

Lesson 2: Reference Frames

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem Source: Satellite Orbits — Oliver Montenbruck & Eberhard Gill, Chapter 2; IERS Conventions (2010), SOFA Library documentation; Vallado, Fundamentals of Astrodynamics and Applications, Chapter 3

Where this fits

In Lesson 1 you parsed a TLE and propagated the ISS to a position vector using SGP4. The output was three numbers — something like (−2338.5, 5481.2, 3834.7) km. But a position vector means nothing without knowing what those axes point toward. This lesson answers that question.

Reference frames matter in practical SDA work for two reasons. First, you cannot meaningfully subtract two position vectors unless they are expressed in the same frame. If your ML pipeline ingests telescope observations and TLE-derived positions without converting them to a common frame, the residuals are garbage — and the model will quietly learn to predict garbage. Second, the covariance matrices in CDMs are expressed in a specific non-inertial frame (RTN), and interpreting them correctly requires understanding what the axes represent.

A space scenario to motivate everything

Your pipeline ingests two data streams for the same conjunction event:

1. A SGP4 propagation of each object's TLE, producing position vectors at the TCA
2. Telescope observations from a commercial optical network, providing astrometric positions at the same time

You want to compute the residual — how far off is the TLE-derived position from the telescope observation? You subtract one from the other and get a 400 km discrepancy. Is the TLE wrong? Did you make an error? Are the objects actually 400 km apart?

The answer is almost certainly that you forgot to convert from TEME to J2000. The SGP4 output is in TEME. The telescope observation is in J2000/GCRF. Subtracting them directly is physically meaningless. This specific bug is one of the most common errors in SSA software, and it takes less than a lesson to prevent it permanently.

Why coordinate frames matter

A Cartesian position vector $(x,y,z)$ implicitly assumes three things:

1. An origin — the point (0, 0, 0) is "here"
2. An orientation — the x, y, z axes point in specific directions
3. A scale — what units are used (km, m, etc.)

All the orbital mechanics frames we care about share Earth's center as origin and use kilometers. The differences are entirely in axis orientation — which directions do x, y, and z point?

The practical consequence: if you have a position vector ${\mathbf{r}}_1$ in frame A and a position vector ${\mathbf{r}}_2$ in frame B, the difference ${\mathbf{r}}_1-{\mathbf{r}}_2$ tells you nothing about the actual spatial separation between the objects unless A and B are the same frame. Converting between frames requires a rotation matrix (and sometimes an additional correction for Earth's rotation).

ECI: Earth-Centered Inertial (J2000 / GCRF)

Earth-Centered Inertial (ECI) frames have Earth's center as the origin and do not rotate with the Earth. The axes are fixed to the (approximately) inertial reference of distant stars, not to Earth's surface.

The specific ECI frame used in modern SDA work is the GCRF (Geocentric Celestial Reference Frame), which is the practical realization of the ICRS (International Celestial Reference System) for geocentric calculations. For most SDA purposes, it is sufficient to call this "J2000 ECI" — the axes are defined at the J2000.0 epoch (January 1.5, 2000, i.e., noon on January 1, 2000 UTC).

Axis definitions:

• X axis: toward the mean vernal equinox of J2000.0 (the direction in the sky where the Sun crosses the equatorial plane moving north, averaged over short-period nutation, as defined at J2000.0)
• Z axis: toward the mean celestial north pole of J2000.0 — this is defined by Earth's mean rotation axis at J2000.0, not by geographic north. They are very close but not identical; the difference is the nutation and precession between J2000.0 and the current date.
• Y axis: completes the right-handed system (Y = Z × X)

What ECI is used for: orbital mechanics calculations. When you integrate equations of motion, compute orbital periods, or describe orbital geometry, you use ECI. Orbital elements (inclination, RAAN, argument of perigee) are defined with respect to ECI axes.

What ECI is not used for: ground station locations or geographic coordinates. The Earth rotates under the ECI frame, so a fixed ground station's position in ECI changes continuously — it traces out a circle. For anything geographic, use ECEF.

ECEF: Earth-Centered Earth-Fixed

Earth-Centered Earth-Fixed (ECEF) has the same origin as ECI — Earth's center — but the axes rotate with Earth. A fixed point on Earth's surface has a constant position in ECEF.

Axis definitions:

• X axis: toward the prime meridian (0° longitude) at the equator
• Z axis: toward the geographic north pole (Earth's mean rotation axis, the same as the Z axis for the ITRF)
• Y axis: completes the right-handed system (90° east longitude at the equator)

What ECEF is used for:

• Ground station locations (ground station latitude/longitude/altitude converts directly to ECEF XYZ)
• Visibility calculations (which ground stations can see this satellite right now?)
• Geodetic coordinates (WGS84 latitude, longitude, altitude)

Converting ECI to ECEF: the transformation requires knowing the Earth's rotation angle at the specific epoch. The key quantity is the Greenwich Mean Sidereal Time (GMST) — the angle between the prime meridian and the vernal equinox direction. GMST rotates at approximately 360°/86164 seconds (one sidereal day). The conversion is a single rotation around the Z axis by the GMST angle:

$${\mathbf{r}}_{\text{ECEF}}=R_z({\theta }_{\text{GMST}})\cdot {\mathbf{r}}_{\text{ECI}}$$

where $R_z(\theta )$ is a rotation matrix around the Z axis. For more precise conversions, polar motion corrections and Earth rotation irregularities are included (IERS corrections), but for SDA applications the GMST rotation is usually sufficient.

TEME: the actual SGP4 output frame

This is the frame you need to know about before touching any SGP4 output.

TEME (True Equator Mean Equinox) is the reference frame in which SGP4 produces its position and velocity vectors. It is not the same as J2000 ECI, and using TEME output as if it were J2000 is the most common reference frame bug in SSA pipelines.

What TEME is: TEME uses:

• The true equator of date: the instantaneous equatorial plane, accounting for nutation (the periodic wobble of Earth's rotation axis due to lunar and solar torques). "Of date" means it is computed for the specific epoch of the propagation, not frozen at J2000.0.
• The mean equinox of date: the vernal equinox direction corrected for precession (the long-term drift of Earth's rotation axis through the sky) but not for nutation. This is a hybrid — it applies only part of the full nutation correction.

Why TEME exists: TEME is an artifact of the SGP4 algorithm's historical development. The original Hoots & Roehrich (1980) implementation was designed to work with TLE observations processed in a specific way by the Space Surveillance Network, and TEME was the frame in which those observations were reduced. SGP4 outputs TEME because that is how it was built, not because TEME is physically convenient.

The magnitude of the TEME-to-J2000 error: at LEO altitudes, the error from ignoring the TEME-to-J2000 conversion ranges from hundreds of meters to low kilometers, depending on the epoch. The nutation terms that differ between TEME and J2000 have amplitudes of up to ~17 arcseconds, which at 400 km altitude corresponds to position errors of about 30–60 meters per arcsecond contribution. During periods of high nutation amplitude, the total error can exceed 1 km.

For ML feature engineering purposes: if you are computing features entirely from TLE-derived SGP4 output (no external observations), staying consistently in TEME is acceptable. The frame matters when comparing with external observation sources — telescope astrometry (J2000), GPS-based precise ephemerides (GCRF), or external CDM state vectors.

The correct tool for conversion: Astropy's astropy.coordinates module has a TEME frame class that handles the conversion to GCRS (the Astropy equivalent of J2000/GCRF) correctly, including nutation and precession.

RTN: the conjunction analysis frame

The RTN frame (also called RIC: Radial-In-track-Cross-track) is the frame in which CDM covariance matrices are expressed. It is not a global inertial frame — it is a local frame centered on one of the conjunction objects, and its axes move with that object's orbital position.

Axis definitions (centered on the primary object):

• R (Radial): points radially outward from Earth's center, in the direction of the satellite's position vector. For a satellite at altitude h, R points "up" from Earth's surface directly below the satellite.
• T (Transverse / In-track): for a circular orbit, T points along the velocity vector. For an elliptical orbit, T is defined along the instantaneous velocity vector projected perpendicular to R. T is approximately "forward" in the orbit.
• N (Normal / Cross-track): perpendicular to the orbital plane, completing the right-handed system. N = R × T. This direction is approximately "up" out of the orbital plane.

Why RTN is used for CDMs: the position uncertainty of a tracked satellite is not isotropic. It has a characteristic shape aligned with the orbital geometry:

• Along-track (T) uncertainty is typically the largest — often 10 to 100 times the radial uncertainty. Along-track errors accumulate from J2 perturbations, drag modeling errors, and OD batch update timing. For a typical LEO debris object, along-track 1σ uncertainty might be 500m–5km, while radial uncertainty is 50–200m.
• Radial (R) uncertainty is typically the smallest for well-tracked objects — direct radar ranging constrains the radial distance well.
• Cross-track (N) uncertainty is typically intermediate.

This structure means the CDM covariance matrix in RTN is nearly diagonal, with $C_{TT}\gg C_{NN}>C_{RR}$ in the position block. In ECI, the same covariance would be dense and rotation-dependent — harder to interpret and harder to validate.

Reading a CDM covariance matrix: CDMs provide a 6×6 covariance matrix in RTN for each object. The matrix is ordered [R, T, N, Ṙ, Ṫ, Ṅ] — position first, then velocity. The [0,0] element is radial position variance (${\sigma }_R^2$), the [1,1] element is along-track position variance (${\sigma }_T^2$), and the [2,2] element is cross-track position variance (${\sigma }_N^2$).

The conjunction plane: for Pc calculation, the combined position uncertainty is projected onto the conjunction plane — the plane perpendicular to the relative velocity vector at TCA. In a typical LEO head-on encounter, the relative velocity is nearly along the T direction of one of the objects. The large along-track uncertainty (T) projects primarily along the relative velocity direction, which — because objects pass through this direction quickly — has relatively little effect on Pc. The cross-track and radial uncertainties, which are smaller in magnitude, determine how spread the position PDF is in the conjunction plane.

Code: converting SGP4 TEME output to J2000/GCRS with Astropy

"""
Demonstrate the TEME-to-GCRS (J2000) conversion using Astropy.

This example:
1. Propagates the ISS TLE to a specific epoch using python-sgp4 (fast)
2. Wraps the TEME output in an Astropy TEME frame
3. Converts to GCRS (the Astropy equivalent of J2000/GCRF)
4. Shows the difference between raw TEME and GCRS coordinates

Install: pip install sgp4 astropy
"""
from sgp4.api import Satrec, jday
from astropy.coordinates import TEME, GCRS, CartesianRepresentation, CartesianDifferential
from astropy.time import Time
import astropy.units as u
import numpy as np

# ISS TLE
TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"

satellite = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# Define the propagation epoch as an Astropy Time object
epoch_str = "2024-10-01T12:00:00"
t = Time(epoch_str, format="isot", scale="utc")

# Propagate using python-sgp4 at this epoch
# jday() converts to Julian date split into integer + fractional parts
jd, fr = jday(t.datetime.year, t.datetime.month, t.datetime.day,
               t.datetime.hour, t.datetime.minute,
               t.datetime.second + t.datetime.microsecond / 1e6)

error_code, r_teme_km, v_teme_kms = satellite.sgp4(jd, fr)

if error_code != 0:
    raise RuntimeError(f"SGP4 error code {error_code} — check TLE validity and epoch range")

print("=== SGP4 Raw Output (TEME frame) ===")
print(f"Position (km) : x={r_teme_km[0]:10.3f}, y={r_teme_km[1]:10.3f}, z={r_teme_km[2]:10.3f}")
print(f"Velocity (km/s): x={v_teme_kms[0]:10.6f}, y={v_teme_kms[1]:10.6f}, z={v_teme_kms[2]:10.6f}")

# Convert TEME to GCRS (J2000-equivalent) using Astropy
# Step 1: build an Astropy TEME coordinate object
r_teme = CartesianRepresentation(r_teme_km * u.km)
v_teme = CartesianDifferential(np.array(v_teme_kms) * u.km / u.s)

teme_coord = TEME(r_teme.with_differentials(v_teme), obstime=t)

# Step 2: convert to GCRS
gcrs_coord = teme_coord.transform_to(GCRS(obstime=t))

r_gcrs = gcrs_coord.cartesian.without_differentials()
v_gcrs = gcrs_coord.cartesian.differentials.get("s")

print("\n=== After Conversion to GCRS (J2000-equivalent) ===")
print(f"Position (km) : x={r_gcrs.x.to(u.km).value:10.3f}, "
      f"y={r_gcrs.y.to(u.km).value:10.3f}, "
      f"z={r_gcrs.z.to(u.km).value:10.3f}")

# Compute the difference (TEME raw vs GCRS-converted)
dx = r_gcrs.x.to(u.km).value - r_teme_km[0]
dy = r_gcrs.y.to(u.km).value - r_teme_km[1]
dz = r_gcrs.z.to(u.km).value - r_teme_km[2]
delta_km = (dx**2 + dy**2 + dz**2)**0.5

print(f"\n=== TEME vs GCRS Difference ===")
print(f"Component differences: dx={dx:.3f} km, dy={dy:.3f} km, dz={dz:.3f} km")
print(f"Total magnitude      : {delta_km:.3f} km  ({delta_km * 1000:.1f} m)")
print(f"\nIgnoring this conversion would introduce a {delta_km * 1000:.0f} m error")
print("when comparing SGP4 output with telescope observations in J2000.")

Understanding frame relationships in context

"""
Demonstrate ECI vs ECEF for ground station visibility.

Shows why you need ECEF for ground station geometry
and why you cannot use ECI positions for lat/lon lookups.
"""
from sgp4.api import Satrec, jday
from astropy.coordinates import TEME, GCRS, ITRS, CartesianRepresentation, CartesianDifferential
from astropy.coordinates import EarthLocation
from astropy.time import Time
import astropy.units as u
import numpy as np

TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"
satellite  = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# Sample ground station: Schriever SFB, Colorado (approximate)
gs_lat_deg =  38.8    # degrees North
gs_lon_deg = -104.5   # degrees East (negative = West)
gs_alt_km  =  1.9     # km above sea level

t = Time("2024-10-01T12:00:00", format="isot", scale="utc")
jd, fr = jday(t.datetime.year, t.datetime.month, t.datetime.day,
               t.datetime.hour, t.datetime.minute, float(t.datetime.second))

_, r_teme_km, v_teme_kms = satellite.sgp4(jd, fr)

# Convert satellite TEME -> GCRS
r_cart = CartesianRepresentation(r_teme_km * u.km)
v_cart = CartesianDifferential(np.array(v_teme_kms) * u.km / u.s)
teme   = TEME(r_cart.with_differentials(v_cart), obstime=t)
gcrs   = teme.transform_to(GCRS(obstime=t))

# Convert GCRS -> ITRS (ECEF equivalent for Earth surface) for visibility check
itrs_sat = gcrs.transform_to(ITRS(obstime=t))

# Ground station in ECEF
gs_loc = EarthLocation(lat=gs_lat_deg * u.deg,
                        lon=gs_lon_deg * u.deg,
                        height=gs_alt_km * u.km)
gs_itrs = gs_loc.get_itrs(obstime=t)

# Compute range vector from ground station to satellite (in ECEF)
sat_xyz = itrs_sat.cartesian.xyz.to(u.km).value
gs_xyz  = gs_itrs.cartesian.xyz.to(u.km).value
range_vec_km = sat_xyz - gs_xyz
range_km     = np.linalg.norm(range_vec_km)

print("=== Ground Station Visibility Analysis ===")
print(f"Ground station       : Schriever SFB approx ({gs_lat_deg}°N, {gs_lon_deg}°E)")
print(f"Satellite ITRS pos   : {sat_xyz[0]:.1f}, {sat_xyz[1]:.1f}, {sat_xyz[2]:.1f} km")
print(f"Ground station ITRS  : {gs_xyz[0]:.1f}, {gs_xyz[1]:.1f}, {gs_xyz[2]:.1f} km")
print(f"Range to satellite   : {range_km:.1f} km")

# Elevation angle (above local horizon) — dot product of range vec with up vec
up_hat = gs_xyz / np.linalg.norm(gs_xyz)  # unit vector pointing radially up from ground station
range_hat = range_vec_km / range_km
sin_elev = np.dot(range_hat, up_hat)
elev_deg = np.degrees(np.arcsin(sin_elev))

print(f"Elevation angle      : {elev_deg:.1f}°")
print(f"Visible (>5° horizon): {'YES' if elev_deg > 5 else 'NO'}")
print()
print("Note: this calculation would be WRONG if we used ECI (GCRS) satellite")
print("position directly against a fixed ground station ECI position, because")
print("the ground station's ECI position changes continuously as Earth rotates.")

Key Takeaways

• A position vector is meaningless without specifying its reference frame. ECI, ECEF, TEME, and RTN are four distinct coordinate systems used in SDA pipelines. Mixing them without conversion produces physically meaningless results.

• SGP4 outputs TEME, not J2000 ECI. TEME uses the true equator of date but the mean equinox of date — a historical artifact of how the SSN processed radar observations. The error from ignoring this conversion is hundreds of meters to low kilometers depending on epoch. Use Astropy's TEME frame class to convert correctly.

• ECI is used for orbital mechanics; ECEF is used for ground station geometry. Never use a satellite's ECI position to compute ground station visibility — the ground station's ECI position is constantly changing. Convert to ECEF (ITRS in Astropy) for any calculation involving geographic coordinates.

• CDM covariance matrices are in RTN (Radial-Transverse-Normal). The [1,1] element is the along-track (T) variance — typically the largest by a factor of 10–100 relative to radial. This along-track dominance is a structural feature of the uncertainty, not a data quality problem. Any ML model that ingests CDM covariances must understand this geometry.

• For ML feature engineering from TLE-only data, staying consistently in TEME is acceptable. The frame conversion matters when comparing SGP4 output with external observation sources (telescopes, GPS-based precise ephemerides). When all inputs come from SGP4 and all outputs stay in SGP4, frame consistency is maintained automatically.

Quiz

Lesson 3: SGP4 Propagation

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem Source: Hoots & Roehrich (1980), "Models for Propagation of NORAD Element Sets"; Vallado et al. (2006), "Revisiting Spacetrack Report #3"; Satellite Orbits — Montenbruck & Gill, Chapter 3; python-sgp4 library documentation

Where this fits

Lessons 1 and 2 taught you what a TLE contains and what reference frame SGP4 uses. This lesson covers the propagator itself — what SGP4 actually computes, what physics it includes, and critically, what it gets wrong and why. Understanding SGP4's accuracy model is prerequisite to building any ML system that uses TLE-derived features: every ground truth label you compute, every feature residual you engineer, and every uncertainty estimate you use derives from propagation. If you do not know when SGP4 is reliable and when it is not, you cannot reason about your training data quality.

A space scenario to motivate everything

Your maneuver detection model flags a Starlink satellite as having potentially maneuvered based on a divergence between two consecutive TLE propagations. Before you alert an operator, you need to answer three questions: Is the divergence within normal SGP4 uncertainty for this object? Could this be a geomagnetic storm artifact rather than a real maneuver? And how do you know whether the divergence is big enough to be operationally significant?

Those questions require knowing SGP4's accuracy envelope. That is what this lesson provides.

What SGP4 is — and what it is not

SGP4 (Simplified General Perturbations model 4) is a semi-analytical propagator designed specifically to work with TLE mean elements. "Semi-analytical" means it is not a numerical integrator — it does not step forward in time using differential equations. Instead, it is a closed-form analytical solution that computes position and velocity directly at any specified epoch without stepping through intermediate states.

This distinction matters for your pipeline architecture:

• Numerical integrators (like Runge-Kutta methods used in high-fidelity propagators) compute state at time $t+\Delta t$ from state at time $t$. They are more accurate but slower — typically microseconds to milliseconds per state evaluation, and they require careful tuning of step sizes.
• SGP4 computes the state at any time $t$ from the TLE epoch in a single pass. The computation is extremely fast — microseconds per evaluation — making catalog-scale propagation of 50,000+ objects computationally trivial.

This speed advantage is why SGP4 dominates public SSA applications. The entire catalog can be propagated to any epoch in seconds on a single CPU core.

Physical perturbations SGP4 includes

SGP4 models these orbital perturbations:

Gravitational harmonics: J2, J3, J4, and J6 zonal harmonics — corrections to Earth's gravitational field due to Earth's equatorial bulge (oblateness) and higher-order mass distribution asymmetries. J2 is by far the largest and dominates the secular RAAN drift and argument-of-perigee precession described in Lesson 1.

Atmospheric drag: modeled via the BSTAR drag coefficient combined with a simplified exponential atmospheric density model. This is a single averaged drag coefficient per TLE — not a time-varying drag model. Changes in atmospheric density due to solar activity between TLE updates are not captured.

Resonance effects: for objects near geosynchronous altitude, gravitational resonances between Earth's tesseral harmonics and the satellite's orbital period produce non-trivial perturbations. SGP4 includes special handling for deep-resonance orbits.

What SGP4 does NOT include for standard LEO/MEO/GEO objects

Lunar and solar third-body gravity: for standard LEO and MEO orbits, the gravitational attraction of the Moon and Sun is small relative to Earth's oblateness effects. SGP4 does not include these perturbations. This is why SGP4 is adequate for LEO/MEO but would be inadequate for highly eccentric orbits with long periods.

For objects with orbital periods greater than approximately 225 minutes (roughly above a semi-major axis of ~40,000 km — high MEO, GEO, and HEO objects), the deep-space version SDP4 is activated automatically by the sgp4 library. SDP4 adds lunar and solar gravity perturbations. When you call satellite.sgp4() in python-sgp4, the library automatically selects SGP4 or SDP4 based on the mean motion. You do not need to choose.

Solar radiation pressure (SRP): not included in either SGP4 or SDP4. For high area-to-mass objects in GEO (like defunct spacecraft with large solar arrays), SRP is a significant perturbation. GEO debris with unknown attitude and area-to-mass ratios can have large along-track errors even with fresh TLEs, for this reason.

High-fidelity atmospheric density: the SGP4 density model is a simple exponential based on a historical average. Real atmospheric density varies significantly with solar activity (F10.7 flux and Kp index). This is the dominant error source for LEO objects during active solar periods.

Accuracy characterization: be honest with yourself

SGP4 accuracy is often described with a hand-wavy "1 km per day" rule. That rule is wrong in both directions — too optimistic in some cases and too pessimistic in others. Here is an honest accuracy characterization:

Quiet LEO debris with fresh TLEs

For passively decaying debris objects with TLEs less than 24 hours old, during periods of low solar activity:

• Radial error: ~100–500 m (1σ)
• Cross-track error: ~100–500 m (1σ)
• Along-track error: 1–3 km (1σ)

These are the best-case numbers. The along-track error is larger because along-track position errors accumulate from unmodeled perturbations and from the TLE fitting process.

Error growth is not smooth or linear

SGP4 error does not grow at a constant rate. It is dominated by:

1. Unmodeled maneuvers: if a satellite executed a maneuver after the TLE epoch, the old TLE is fundamentally wrong. A 12-hour-old TLE for a satellite that maneuvered 6 hours ago may be 50–100+ km off. Maneuver age, not epoch age, determines accuracy.

2. Atmospheric density variations: during geomagnetic storms (Kp ≥ 5), the thermosphere swells significantly. Drag-sensitive LEO objects (high BSTAR, low altitude) can deviate tens of kilometers from their predicted positions within hours. Epoch age of the TLE is nearly irrelevant during a major geomagnetic storm if the BSTAR was fitted during quiet conditions.

3. Batch update artifacts: when the Space Surveillance Network re-fits a TLE from new radar observations, the new TLE may be slightly inconsistent with the previous one due to the OD fitting process. This creates apparent discontinuities in element histories that are OD artifacts, not real maneuvers.

GEO objects

GEO objects have different accuracy limiters. J2 and drag are small at GEO altitude. The dominant unmodeled perturbation is solar radiation pressure, which is driven by the object's area-to-mass ratio and reflectivity — both unknown for debris. GEO debris can have large covariances even with fresh TLEs.

The practical ML implication

Epoch age is a weak signal for uncertainty. Build your models with this mental model:

• High epoch age → elevated uncertainty, but only a loose bound
• CDM covariance size → much stronger signal, directly encoding the OD solution's uncertainty estimate
• Recent geomagnetic storm (high Kp) → dramatically elevated uncertainty for drag-sensitive LEO objects, regardless of epoch age
• Object in MANEUVERABLE category → any TLE older than the last known maneuver time is suspect

If you are building uncertainty-aware conjunction risk models, you want CDM covariances as primary inputs and epoch age as one of many context features, not the primary uncertainty signal.

Using python-sgp4

The canonical SGP4 implementation for Python is the sgp4 library by Brandon Rhodes. It is a direct port of the Vallado et al. (2006) reference implementation and is the de facto standard for production SDA pipelines.

For production and catalog-scale work: use python-sgp4 directly. It is fast (microseconds per call with the Fortran-accelerated backend), well-tested, and the output is well-understood.

For single-object analysis and frame conversion: Astropy wraps python-sgp4 through its EarthSatellite class. This is convenient for one-off analysis but adds substantial per-call overhead — Astropy's coordinate machinery does a lot of work per evaluation. For propagating 50,000 objects over multi-day windows at 5-minute intervals, use python-sgp4 directly. For converting one object's state vector from TEME to GCRS, use Astropy.

Single-object propagation

"""
Propagate the ISS using python-sgp4 and convert the TEME output to GCRS.

Demonstrates:
- python-sgp4 API for single-object propagation
- Astropy TEME-to-GCRS conversion
- Error code interpretation

Install: pip install sgp4 astropy
"""
from sgp4.api import Satrec, jday
from astropy.coordinates import TEME, GCRS, CartesianRepresentation, CartesianDifferential
from astropy.time import Time
import astropy.units as u
import numpy as np

TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"

sat = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# Propagate 6 hours after TLE epoch
t = Time("2024-10-01T18:00:00", format="isot", scale="utc")
jd, fr = jday(t.datetime.year, t.datetime.month, t.datetime.day,
               t.datetime.hour, t.datetime.minute, float(t.datetime.second))

error_code, r_km, v_kms = sat.sgp4(jd, fr)

# SGP4 error codes:
#   0 = success
#   1 = mean eccentricity < 0 or > 1 (bad TLE)
#   2 = mean motion < 0 (object below ground)
#   3 = pert eccentricity < 0 or > 1
#   4 = semi-latus rectum < 0
#   5 = epoch elements sub-orbital
#   6 = satellite has decayed (perigee below Earth surface)
if error_code != 0:
    raise RuntimeError(f"SGP4 propagation failed with error code {error_code}")

print(f"TEME position (km) : {r_km}")
print(f"TEME velocity (km/s): {v_kms}")

# Convert to GCRS
r_cart = CartesianRepresentation(np.array(r_km) * u.km)
v_cart = CartesianDifferential(np.array(v_kms) * u.km / u.s)
teme_coord = TEME(r_cart.with_differentials(v_cart), obstime=t)
gcrs_coord = teme_coord.transform_to(GCRS(obstime=t))

print(f"\nGCRS position (km) : "
      f"x={gcrs_coord.cartesian.x.to(u.km).value:.3f}, "
      f"y={gcrs_coord.cartesian.y.to(u.km).value:.3f}, "
      f"z={gcrs_coord.cartesian.z.to(u.km).value:.3f}")

Batch propagation: ground track over one orbit

"""
Propagate the ISS forward over one complete orbit (~92 minutes) at 10-minute steps.
Plot the ground track as geodetic latitude vs. longitude.

This demonstrates:
- Vectorized batch propagation with python-sgp4
- TEME -> GCRS -> ITRS chain for lat/lon conversion
- The ground track's relationship to inclination

Install: pip install sgp4 astropy numpy matplotlib
"""
from sgp4.api import Satrec, jday
from astropy.coordinates import TEME, GCRS, ITRS, CartesianRepresentation, CartesianDifferential
from astropy.time import Time
import astropy.units as u
import numpy as np

TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"

sat = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# Generate time array: TLE epoch + 0 to 92 minutes in 10-minute steps
epoch_str = "2024-10-01T12:00:00"
t0        = Time(epoch_str, format="isot", scale="utc")
dt_min    = np.arange(0, 93, 10)          # 0, 10, 20, ..., 90 minutes
times     = t0 + dt_min * 60 * u.s        # Astropy Time array

# --- Batch propagation using python-sgp4 ---
# Build arrays of Julian dates for each time step
jd_arr = np.array([
    jday(t.datetime.year, t.datetime.month, t.datetime.day,
         t.datetime.hour, t.datetime.minute, float(t.datetime.second))
    for t in times
])
jd_ints  = jd_arr[:, 0]
jd_fracs = jd_arr[:, 1]

# Vectorized SGP4 call (returns arrays of error codes, positions, velocities)
e_arr, r_arr, v_arr = sat.sgp4_array(jd_ints, jd_fracs)

# Check all error codes are 0
if np.any(e_arr != 0):
    bad = np.where(e_arr != 0)[0]
    print(f"Warning: {len(bad)} propagation errors at indices {bad}")

r_arr = np.array(r_arr)   # shape (N, 3), TEME km
v_arr = np.array(v_arr)   # shape (N, 3), TEME km/s

# --- Convert to geodetic lat/lon via TEME -> GCRS -> ITRS ---
lats  = []
lons  = []
alts  = []

for i, t in enumerate(times):
    r_cart    = CartesianRepresentation(r_arr[i] * u.km)
    v_cart    = CartesianDifferential(v_arr[i] * u.km / u.s)
    teme_c    = TEME(r_cart.with_differentials(v_cart), obstime=t)
    gcrs_c    = teme_c.transform_to(GCRS(obstime=t))
    itrs_c    = gcrs_c.transform_to(ITRS(obstime=t))
    geodetic  = itrs_c.earth_location
    lats.append(geodetic.lat.deg)
    lons.append(geodetic.lon.deg)
    alts.append(geodetic.height.to(u.km).value)

lats = np.array(lats)
lons = np.array(lons)
alts = np.array(alts)

print("=== ISS Ground Track (one orbit at 10-minute intervals) ===")
print(f"{'Time (min)':>10}  {'Lat (°)':>8}  {'Lon (°)':>9}  {'Alt (km)':>9}")
print("-" * 45)
for i, dt in enumerate(dt_min):
    print(f"{dt:>10.0f}  {lats[i]:>8.2f}  {lons[i]:>9.2f}  {alts[i]:>9.1f}")

print(f"\nLatitude range: {lats.min():.1f}° to {lats.max():.1f}°")
print(f"(Should be within ±51.6° — the ISS inclination)")

# Optional: plot with matplotlib
try:
    import matplotlib.pyplot as plt
    plt.figure(figsize=(12, 5))
    plt.plot(lons, lats, "b.-", markersize=8)
    for i, dt in enumerate(dt_min):
        plt.annotate(f"{int(dt)}m", (lons[i], lats[i]),
                     fontsize=7, textcoords="offset points", xytext=(3, 3))
    plt.axhline(51.6, color="r", linestyle="--", alpha=0.5, label="Max latitude (inclination)")
    plt.axhline(-51.6, color="r", linestyle="--", alpha=0.5)
    plt.xlabel("Longitude (°)")
    plt.ylabel("Latitude (°)")
    plt.title("ISS Ground Track — One Orbit (~92 min)")
    plt.legend()
    plt.grid(True, alpha=0.3)
    plt.tight_layout()
    plt.savefig("iss_ground_track.png", dpi=100)
    plt.show()
    print("Ground track saved to iss_ground_track.png")
except ImportError:
    print("matplotlib not installed; skipping plot")

Performance comparison: python-sgp4 vs. Astropy loop

"""
Performance benchmark: python-sgp4 vectorized vs. Astropy EarthSatellite per-call.

This shows why you should use python-sgp4 directly for catalog-scale propagation.
"""
import time
import numpy as np
from sgp4.api import Satrec, jday

TLE_LINE1 = "1 25544U 98067A   24274.50000000  .00015669  00000-0  27837-3 0  9991"
TLE_LINE2 = "2 25544  51.6415 282.4781 0001567 231.1584 128.9321 15.50095566472697"

sat = Satrec.twoline2rv(TLE_LINE1, TLE_LINE2)

# Generate 1000 time points (e.g., 5-minute intervals over ~3.5 days)
from astropy.time import Time
import astropy.units as u
t0    = Time("2024-10-01T12:00:00", format="isot", scale="utc")
times = t0 + np.arange(1000) * 5 * 60 * u.s

jd_arr = np.array([
    jday(t.datetime.year, t.datetime.month, t.datetime.day,
         t.datetime.hour, t.datetime.minute, float(t.datetime.second))
    for t in times
])
jd_ints  = jd_arr[:, 0]
jd_fracs = jd_arr[:, 1]

# --- Benchmark 1: python-sgp4 vectorized array call ---
n_trials = 20
start = time.perf_counter()
for _ in range(n_trials):
    e, r, v = sat.sgp4_array(jd_ints, jd_fracs)
elapsed_sgp4 = (time.perf_counter() - start) / n_trials

# --- Benchmark 2: Astropy EarthSatellite per-call ---
try:
    from astropy.coordinates import EarthSatellite
    tle_sat = EarthSatellite(TLE_LINE1, TLE_LINE2, "ISS")

    start = time.perf_counter()
    # Astropy supports batch mode via Time arrays — test that
    positions_astropy = tle_sat.at(times)
    elapsed_astropy = time.perf_counter() - start
    astropy_available = True
except Exception as ex:
    elapsed_astropy = None
    astropy_available = False
    print(f"Astropy batch mode failed: {ex}")

print("=== Performance Comparison: 1,000 time points ===")
print(f"python-sgp4 vectorized : {elapsed_sgp4 * 1000:.2f} ms per run")
print(f"  Per point             : {elapsed_sgp4 / 1000 * 1e6:.2f} μs")
if astropy_available:
    print(f"Astropy batch          : {elapsed_astropy * 1000:.2f} ms per run")
    print(f"  Per point             : {elapsed_astropy / 1000 * 1e6:.2f} μs")
    print(f"Speedup factor        : {elapsed_astropy / elapsed_sgp4:.0f}×")

print()
print("At 50,000 objects × 2016 points (7 days × 5 min intervals):")
total_points = 50_000 * 2016
t_sgp4_total = elapsed_sgp4 / 1000 * total_points
print(f"  python-sgp4 total time: {t_sgp4_total:.1f} seconds")
print(f"  (Astropy would be {elapsed_astropy / elapsed_sgp4:.0f}× slower if same ratio holds)")

What a maneuver looks like in TLE history

When a satellite executes a maneuver, the Space Surveillance Network (SSN) re-acquires the object with radar, collects new observations, and fits updated TLEs to the new trajectory. In the resulting TLE history, a maneuver leaves characteristic signatures:

Mean motion discontinuity: the most reliable maneuver indicator. A burn that raises or lowers the orbit changes the orbital energy and thus changes mean motion. A 10 m/s radial burn on a 400 km LEO object produces a change in semi-major axis of roughly 20 km, which corresponds to a mean motion change of about 0.005 rev/day.

Tracking gap: after a maneuver, the SSN must re-acquire the object — it is not where predicted. There is often a gap in TLE history (no new TLE for 12–48 hours) followed by a new TLE with an updated element set number. The gap is itself a signal.

Correlated changes in RAAN and argument of perigee residuals: a maneuver with an out-of-plane component changes the inclination and RAAN. After subtracting the J2-predicted drift, an anomalous change in the corrected RAAN residual may indicate an out-of-plane maneuver.

Why element jumps alone are not sufficient evidence

This is a critical domain concept for ML model development. Mean motion changes that look like maneuvers can also be caused by:

1. Atmospheric density spikes from solar activity: a geomagnetic storm (Kp ≥ 5, elevated F10.7 solar flux) increases thermospheric density substantially, increasing drag on all LEO objects simultaneously. Every passive debris object at similar altitudes shows correlated mean motion decreases during a major geomagnetic storm. If you flag these as maneuvers, your false positive rate will spike every solar event.

2. OD batch update artifacts: the SSN uses a batch OD process. When a new observation batch is processed, the fitted TLE may jump slightly due to the fitting algorithm, especially if the observation coverage was sparse or asymmetric. These artifacts can produce apparent element jumps that are not physically real.

3. Area-to-mass ratio changes (rare but real): for objects with flexible structures (like tangled debris), actual changes in the effective drag cross-section can change the observed mean motion without a propulsive maneuver.

The correct ML approach: a maneuver detection model should take as input not just element residuals but contextual features including geomagnetic indices (F10.7 solar flux, Kp index at the time of the change), whether similar changes appear in other objects at similar altitudes (correlated changes suggest environmental, not propulsive, cause), whether the object is in the MANEUVERABLE or PAYLOAD category, and the availability of a tracking gap before the new TLE.

This is precisely the feature engineering problem that sequence models (RNNs, Transformers) address well — and the motivation for that later curriculum lesson.

Key Takeaways

• SGP4 is a semi-analytical propagator, not a numerical integrator. It computes position analytically from TLE mean elements, making it fast enough for catalog-scale propagation. The entire 50,000+ object catalog can be propagated in seconds with python-sgp4.

• SGP4 includes J2–J6 harmonics and atmospheric drag (via BSTAR). For objects with periods less than ~225 minutes (standard LEO/MEO/GEO), it does NOT include lunar and solar third-body gravity. SDP4, activated automatically for deep-space orbits (period > ~225 min), does include third-body effects.

• SGP4 accuracy is NOT "1 km per day." For fresh TLEs of quiet LEO debris, along-track error is 1–3 km. For maneuvering satellites or during geomagnetic storms, errors can be 10–100+ km regardless of TLE age. Epoch age is a weak uncertainty proxy.

• Use python-sgp4 directly for catalog-scale propagation. Astropy wraps python-sgp4 but adds overhead per call that makes it impractical for bulk propagation. Use Astropy for frame conversion after propagating with python-sgp4.

• Maneuver detection from TLE history requires corroborating evidence. A mean motion jump in one object is not sufficient. Check geomagnetic indices, look for correlated changes in nearby objects, check for tracking gaps, and consider the object's maneuverable status.

Quiz

Lesson 4: Conjunction Analysis

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem Source: Foster & Estes (1992), "A Parametric Analysis of Orbital Debris Collision Probability"; Chan (1997), "Spacecraft Collision Probability"; CCSDS 508.0-B-1 Conjunction Data Message standard; Alfano (2005), "A Numerical Implementation of Spherical Object Collision Probability"; Letizia et al. (2018), "Application of a debris index for global evaluation of mitigation strategies"

Where this fits

The previous three lessons gave you the data artifact (TLE), the coordinate systems, and the propagation engine. This lesson puts them together for the most operationally important application in commercial SDA: conjunction analysis. When two cataloged objects will pass close to each other in the future, operators need to quantify the collision risk and decide whether to execute an avoidance maneuver. That decision is what conjunction analysis supports.

This lesson covers the entire chain from initial screening through probability of collision computation and the CDM format that encodes the result. Module 1 Lesson 3 extends this with Monte Carlo Pc computation. Module 7's particle filter application uses many of the same state estimation concepts for tracking maneuvering objects.

A space scenario to motivate everything

Space-Track issues an automated email at 03:47 UTC: "CONJUNCTION WARNING — PROBABILITY OF COLLISION 1.1e-4 — TCA 2024-10-03 14:32:17 UTC — OBJECT1: 25544 (ISS (ZARYA)) — OBJECT2: 46876 (COSMOS 2499 DEB)." Your client's satellite operations team is asking three questions: Is 1.1e-4 a high Pc? Should we maneuver? And how do we know the CDM is accurate?

This lesson gives you the framework to answer all three.

Conjunction screening

Before you can compute a probability of collision, you need to identify which pairs of objects are close enough to matter. The Space Surveillance Network tracks 50,000+ objects. That is roughly 1.25 billion possible pairs. You cannot compute full Pc for all of them — the computation would be far too slow. Screening narrows the field.

The Space-Track pizza-box screening volume

The 18th Space Defense Squadron (18 SDS) uses an asymmetric screening volume around each satellite to identify candidate conjunction pairs. This is commonly called the "pizza-box" volume because of its shape:

• Radial (R): ±1 km
• Along-track (T): ±25 km
• Cross-track (N): ±1 km

This is NOT a sphere. The along-track dimension is 25× larger than the radial and cross-track dimensions. That asymmetry is deliberate.

Why asymmetric? Recall from Lesson 2 that position uncertainty in RTN space is dominated by the along-track direction — typical along-track uncertainty is 10–100× the radial uncertainty for LEO objects. If you used a spherical screening volume of radius 1 km, you would miss most true high-risk conjunctions because the objects' predicted close approach might be several kilometers apart in the along-track direction while actually being physically close due to TLE uncertainty. A spherical 25 km volume would work but would generate enormous numbers of false positives. The pizza-box matches the uncertainty geometry: tight radial and cross-track bounds (where uncertainty is small) and a generous along-track window (where uncertainty is large).

Commercial providers use different screening volumes. LeoLabs, for example, uses different dimensions based on their higher-quality OD solutions. When you compare event counts between providers, always check the screening volume.

Miss distance and closest approach

For each pair that passes within the screening volume, the conjunction assessment pipeline computes the Time of Closest Approach (TCA) and miss distance — the separation vector and scalar range at TCA.

Miss distance is decomposed into R, T, N components. These components are important for understanding the encounter geometry:

• Large along-track miss distance + small radial miss distance = the objects are passing in nearly parallel orbits, separated mainly vertically — the along-track uncertainty dominates the Pc geometry
• Small miss distance in all three components = high geometric risk regardless of which direction uncertainty is largest

Relative velocity at TCA is also reported. For LEO-LEO head-on encounters, relative velocity is typically 10–15 km/s. For co-planar debris passes, it can be as low as 0.1–1 km/s. Higher relative velocity means shorter encounter duration, which simplifies the linear-motion approximation used in Pc calculation.

The conjunction plane and Pc geometry

The probability of collision is computed by projecting the three-dimensional position uncertainty onto a two-dimensional plane.

Linear relative motion approximation

For typical conjunction geometries, the encounter is brief — objects at 10 km/s relative velocity cross a 10 km screening volume in about 1 second. During this interval, both objects travel in nearly straight lines. The linear relative motion approximation replaces the true curved orbital trajectories with straight-line motion, transforming the 3D problem into a 2D problem.

The conjunction plane

The conjunction plane is the plane perpendicular to the relative velocity vector at TCA. When the linear approximation holds, the probability of collision depends entirely on where the objects' positions, distributed according to the combined position uncertainty, land relative to each other in this 2D plane.

Why project onto the conjunction plane? The relative position uncertainty along the relative velocity direction does not affect whether collision occurs — if the objects are traveling toward each other at 10 km/s, a 5 km uncertainty along the velocity direction just means the closest approach might happen 0.5 milliseconds earlier or later. What matters is how spread out the positions are in the two directions perpendicular to the relative velocity — those are the directions in which a miss distance greater than the hard body radius actually prevents collision.

The combined covariance

Each CDM provides a 3×3 position covariance (in RTN) for each object. The combined covariance for Pc computation is the sum:

$${\mathbf{C}}_{\text{combined}}={\mathbf{C}}_1+{\mathbf{C}}_2$$

This assumes the two objects' position errors are independent — a reasonable approximation for objects in different orbits. After projecting onto the conjunction plane, the combined covariance becomes a 2×2 matrix describing the distribution of the relative position in the plane.

The hard body radius (HBR)

A collision occurs when the centers of the two objects are within the sum of their physical radii. This combined radius is called the hard body radius (HBR):

$$R_{\text{HBR}}=r_1+r_2$$

Typical values:

• Active satellites: 2–10 m radius → 4–20 m HBR contribution
• Rocket bodies: 1–3 m radius
• Debris fragments: 0.05–0.5 m radius

If no physical dimensions are known (common for debris), conservative estimates are used. The ISS has an HBR of approximately 50 m due to its large structure and solar arrays.

The Foster/Chan Pc calculation

The standard Pc method is due to Foster & Estes (1992) and Chan (1997). The calculation integrates the 2D Gaussian probability density function (representing the combined position uncertainty projected onto the conjunction plane) over the disk of radius $R_{\text{HBR}}$ centered at the origin:

$$P_c=\frac{1}{2\pi {\sigma }_1{\sigma }_2}\int {\int }_{x^2+y^2\le R_{\text{HBR}}^2}\exp \left(-\frac{x^2}{2{\sigma }_1^2}-\frac{y^2}{2{\sigma }_2^2}\right)dxdy$$

where ${\sigma }_1$ and ${\sigma }_2$ are the semi-axes of the combined uncertainty ellipse in the conjunction plane (assuming the principal axes are aligned — the general case requires a full 2×2 covariance matrix).

In practice, this integral is computed numerically, often via series expansion. The key insight: Pc depends on two things — how large the combined uncertainty ellipse is relative to the HBR disk, and how the uncertainty is shaped relative to the encounter geometry.

What determines whether Pc is high or low?

• Large combined uncertainty relative to HBR: the probability mass is spread over a large area, so the fraction that falls inside the small HBR disk is small → low Pc
• Small combined uncertainty, miss distance comparable to HBR: all the probability mass is concentrated near the HBR boundary → high Pc
• The miss distance in the conjunction plane: if the best-estimate closest approach is zero (head-on collision course), Pc is highest. As miss distance increases, Pc decreases rapidly.

Covariance realism: why operational Pc values are often too small

TLE-derived covariances are systematically underestimated. The SSN fits TLEs using radar observations with known measurement noise, and the resulting covariance reflects that observation noise. It does not capture force model uncertainty — unmodeled atmospheric density variations, unmodeled maneuvers, OD batch update artifacts, and BSTAR fitting errors all contribute to actual position uncertainty but are not reflected in the fitted covariance.

Studies have found that actual position errors are typically 3–10× larger than TLE-derived covariances suggest. This means operational Pc values from Space-Track (which use these underestimated covariances) often understate the true collision risk.

For ML applications: this is a commercially significant problem. ML models that learn to predict "covariance inflation factors" — multipliers that scale the raw TLE-derived covariance to better match actual position errors — are one of the most valuable products in the commercial SDA market. Your ML model is not replacing Pc calculation; it is correcting the covariance input to Pc calculation.

The Pc method field in CDMs (COLLISION_PROBABILITY_METHOD) is important precisely because different methods make different covariance assumptions. Alfano (2005) provides a generalized short-encounter Pc method. Monte Carlo Pc (sampling from the combined covariance and counting simulated collisions) is a third approach. Pc values computed by different methods for the same CDM geometry are not directly comparable. If your ML pipeline ingests CDMs from multiple sources, you must either normalize to a single method or treat the method as a feature.

The CCSDS CDM format

The Conjunction Data Message (CDM) is the standard format for exchanging conjunction assessment data. It is defined in CCSDS standard 508.0-B-1. Understanding every field is essential for any SDA ML pipeline.

CDMs come in two encoding formats: KVN (Key-Value Notation) — a simple text format, one field per line — and XML. Space-Track provides CDMs in KVN format via its REST API.

A CDM has a header section, then an OBJECT1 block and OBJECT2 block. OBJECT1 is typically the higher-priority or primary object (the satellite the operator cares about). OBJECT2 is the secondary object (the debris or other satellite).

Critical CDM fields

Header section:

• CREATION_DATE: when this CDM was generated. Not the same as TCA. For freshness assessment, you want CREATION_DATE relative to TCA.
• ORIGINATOR: who generated the CDM (e.g., "18 SPACE DEFENSE SQUADRON")
• MESSAGE_ID: unique identifier for this specific CDM

Conjunction geometry fields:

• TCA (Time of Closest Approach): the predicted time of minimum miss distance, in UTC
• MISS_DISTANCE: scalar miss distance at TCA, in meters. This is the most human-readable risk indicator but does not account for uncertainty.
• RELATIVE_SPEED: relative velocity magnitude at TCA, in m/s
• RELATIVE_POSITION_R/T/N: miss distance components in RTN frame, meters
• COLLISION_PROBABILITY: the computed Pc value (e.g., 1.1e-4)
• COLLISION_PROBABILITY_METHOD: which algorithm produced the Pc (e.g., FOSTER-1992, CHAN-1997, ALFANO-2005, MONTE_CARLO)

Per-object fields (both OBJECT1 and OBJECT2 blocks):

• OBJECT / OBJECT_DESIGNATOR: NORAD catalog ID
• OBJECT_NAME: common name
• OBJECT_TYPE: PAYLOAD, ROCKET BODY, DEBRIS, UNKNOWN, or OTHER. Note: the field is OBJECT_TYPE, not "object class."
• MANEUVERABLE: YES, NO, or N/A. A maneuverable satellite can execute a collision avoidance maneuver. This fundamentally changes the risk interpretation — a YES OBJECT1 has lower effective risk than the raw Pc suggests, because the operator can choose to maneuver.
• X, Y, Z: Cartesian position in GCRF (J2000 ECI), km, at TCA
• X_DOT, Y_DOT, Z_DOT: velocity in GCRF, km/s
• CR_R, CT_T, CN_N, CRdot_R, CTdot_T, CNdot_N: diagonal elements of the 6×6 RTN covariance matrix (m²). CDMs use the notation CR_R for the R-R element, CT_T for T-T, etc.
• Off-diagonal terms: CT_R, CN_R, CN_T for the lower triangle of the position block

Code: parsing a CDM

"""
Parse a synthetic but realistic CCSDS CDM in KVN format.
Extract key fields, reconstruct the 3x3 position covariance in RTN,
and compute basic statistics.

This is the data structure your ML pipeline will process for every conjunction event.
"""
import re
import numpy as np
from dataclasses import dataclass, field
from typing import Optional

# A synthetic but realistic CDM KVN string
CDM_KVN = """CCSDS_CDM_VERS = 1.0
CREATION_DATE = 2024-10-01T08:00:00.000
ORIGINATOR = 18 SPACE DEFENSE SQUADRON
MESSAGE_ID = 2024-274-00123
TCA = 2024-10-03T14:32:17.421
MISS_DISTANCE = 432.5
RELATIVE_SPEED = 14823.4
RELATIVE_POSITION_R = -38.2
RELATIVE_POSITION_T = 421.4
RELATIVE_POSITION_N = -62.1
COLLISION_PROBABILITY = 1.12E-04
COLLISION_PROBABILITY_METHOD = FOSTER-1992
OBJECT = OBJECT1
OBJECT_DESIGNATOR = 25544
OBJECT_NAME = ISS (ZARYA)
INTERNATIONAL_DESIGNATOR = 1998-067A
OBJECT_TYPE = PAYLOAD
MANEUVERABLE = YES
ORBIT_CENTER = EARTH
REF_FRAME = EME2000
GRAVITY_MODEL = EGM-96: 36D 36O
ATMOSPHERIC_MODEL = JACCHIA 70
EPHEMERIS_NAME = NONE
COVARIANCE_METHOD = CALCULATED
MANEUVER_APPLICABLE = YES
X = -2338.512
Y = 5481.234
Z = 3834.721
X_DOT = -5.234812
Y_DOT = -1.823456
Z_DOT = 5.912345
CR_R = 40000.0
CT_R = -8500.0
CT_T = 12500000.0
CN_R = 1200.0
CN_T = -3400000.0
CN_N = 180000.0
CRDOT_R = -2.1
CTDOT_R = 420.0
CTDOT_T = -85000.0
CNDOT_R = 0.8
CNDOT_T = 17200.0
CNDOT_N = -340.0
CRRDOT_DOT = 0.00045
OBJECT = OBJECT2
OBJECT_DESIGNATOR = 46876
OBJECT_NAME = COSMOS 2499 DEB
INTERNATIONAL_DESIGNATOR = 2014-028G
OBJECT_TYPE = DEBRIS
MANEUVERABLE = NO
ORBIT_CENTER = EARTH
REF_FRAME = EME2000
GRAVITY_MODEL = EGM-96: 36D 36O
ATMOSPHERIC_MODEL = JACCHIA 70
EPHEMERIS_NAME = NONE
COVARIANCE_METHOD = CALCULATED
MANEUVER_APPLICABLE = NO
X = -2338.082
Y = 5481.654
Z = 3834.143
X_DOT = -5.227341
Y_DOT = -1.815123
Z_DOT = 5.905678
CR_R = 62500.0
CT_R = -12000.0
CT_T = 18900000.0
CN_R = 1800.0
CN_T = -5100000.0
CN_N = 270000.0
CRDOT_R = -3.1
CTDOT_R = 630.0
CTDOT_T = -127500.0
CNDOT_R = 1.2
CNDOT_T = 25800.0
CNDOT_N = -510.0
CRRDOT_DOT = 0.00067"""


@dataclass
class ObjectBlock:
    """Holds per-object fields from a CDM."""
    designator:   Optional[str]   = None
    name:         Optional[str]   = None
    object_type:  Optional[str]   = None
    maneuverable: Optional[str]   = None
    x_km:         Optional[float] = None
    y_km:         Optional[float] = None
    z_km:         Optional[float] = None
    # Position covariance diagonal (m²)
    cr_r:  Optional[float] = None
    ct_t:  Optional[float] = None
    cn_n:  Optional[float] = None
    # Position covariance off-diagonal (m²)
    ct_r:  Optional[float] = None
    cn_r:  Optional[float] = None
    cn_t:  Optional[float] = None


def parse_cdm_kvn(cdm_text: str) -> dict:
    """
    Parse a CDM in KVN format into a structured dictionary.
    Returns header fields and two ObjectBlock instances.
    """
    header = {}
    objects = {}
    current_obj = None

    for raw_line in cdm_text.strip().splitlines():
        line = raw_line.strip()
        if not line or line.startswith("COMMENT"):
            continue

        # Split on first ' = '
        if " = " not in line:
            continue
        key, _, value = line.partition(" = ")
        key   = key.strip()
        value = value.strip()

        # Track which object block we are in
        if key == "OBJECT" and value in ("OBJECT1", "OBJECT2"):
            current_obj = value
            objects[current_obj] = ObjectBlock()
            continue

        if current_obj is None:
            # Still in header section
            header[key] = value
        else:
            # In an object block
            obj = objects[current_obj]
            if   key == "OBJECT_DESIGNATOR": obj.designator   = value
            elif key == "OBJECT_NAME":       obj.name         = value
            elif key == "OBJECT_TYPE":       obj.object_type  = value
            elif key == "MANEUVERABLE":      obj.maneuverable = value
            elif key == "X":                 obj.x_km         = float(value)
            elif key == "Y":                 obj.y_km         = float(value)
            elif key == "Z":                 obj.z_km         = float(value)
            elif key == "CR_R":              obj.cr_r         = float(value)
            elif key == "CT_T":              obj.ct_t         = float(value)
            elif key == "CN_N":              obj.cn_n         = float(value)
            elif key == "CT_R":              obj.ct_r         = float(value)
            elif key == "CN_R":              obj.cn_r         = float(value)
            elif key == "CN_T":              obj.cn_t         = float(value)

    return {"header": header, "objects": objects}


def build_position_covariance_rtn(obj: ObjectBlock) -> np.ndarray:
    """
    Build the 3x3 RTN position covariance matrix from CDM fields.
    Order: [R, T, N] — covariance is in m².

    The CDM provides the lower triangle:
      [CR_R,  CT_R,  CN_R ]
      [CT_R,  CT_T,  CN_T ]
      [CN_R,  CN_T,  CN_N ]
    """
    C = np.array([
        [obj.cr_r,  obj.ct_r,  obj.cn_r],
        [obj.ct_r,  obj.ct_t,  obj.cn_t],
        [obj.cn_r,  obj.cn_t,  obj.cn_n],
    ])
    return C


# --- Parse the CDM ---
parsed = parse_cdm_kvn(CDM_KVN)
hdr    = parsed["header"]
obj1   = parsed["objects"]["OBJECT1"]
obj2   = parsed["objects"]["OBJECT2"]

print("=== CDM Header ===")
for k, v in hdr.items():
    print(f"  {k:<35} = {v}")

print("\n=== Object 1 ===")
print(f"  NORAD ID     : {obj1.designator}")
print(f"  Name         : {obj1.name}")
print(f"  Type         : {obj1.object_type}")
print(f"  Maneuverable : {obj1.maneuverable}")

print("\n=== Object 2 ===")
print(f"  NORAD ID     : {obj2.designator}")
print(f"  Name         : {obj2.name}")
print(f"  Type         : {obj2.object_type}")
print(f"  Maneuverable : {obj2.maneuverable}")

print("\n=== Conjunction Geometry ===")
miss_m  = float(hdr["MISS_DISTANCE"])
rel_r   = float(hdr["RELATIVE_POSITION_R"])
rel_t   = float(hdr["RELATIVE_POSITION_T"])
rel_n   = float(hdr["RELATIVE_POSITION_N"])
pc      = float(hdr["COLLISION_PROBABILITY"])
method  = hdr["COLLISION_PROBABILITY_METHOD"]
print(f"  TCA                : {hdr['TCA']}")
print(f"  Miss distance      : {miss_m:.1f} m")
print(f"  Miss distance R/T/N: {rel_r:.1f} / {rel_t:.1f} / {rel_n:.1f} m")
print(f"  Collision Prob (Pc): {pc:.2e}  [{method}]")
print(f"  Relative speed     : {float(hdr['RELATIVE_SPEED']):.1f} m/s = "
      f"{float(hdr['RELATIVE_SPEED'])/1000:.1f} km/s")

print("\n=== Covariance Analysis (RTN, position block only) ===")
C1 = build_position_covariance_rtn(obj1)
C2 = build_position_covariance_rtn(obj2)
C_combined = C1 + C2

sigma1_r = np.sqrt(C1[0, 0])
sigma1_t = np.sqrt(C1[1, 1])
sigma1_n = np.sqrt(C1[2, 2])

sigma2_r = np.sqrt(C2[0, 0])
sigma2_t = np.sqrt(C2[1, 1])
sigma2_n = np.sqrt(C2[2, 2])

sigma_comb_r = np.sqrt(C_combined[0, 0])
sigma_comb_t = np.sqrt(C_combined[1, 1])
sigma_comb_n = np.sqrt(C_combined[2, 2])

print(f"\n  Object 1 position 1σ (m) — R: {sigma1_r:.1f}  T: {sigma1_t:.1f}  N: {sigma1_n:.1f}")
print(f"  Object 2 position 1σ (m) — R: {sigma2_r:.1f}  T: {sigma2_t:.1f}  N: {sigma2_n:.1f}")
print(f"  Combined 1σ (m)          — R: {sigma_comb_r:.1f}  T: {sigma_comb_t:.1f}  N: {sigma_comb_n:.1f}")
print(f"\n  Along-track / Radial uncertainty ratio (Object 1): "
      f"{sigma1_t / sigma1_r:.0f}×")
print(f"  (Expected: 10–100× for well-tracked LEO objects — T >> R)")

print(f"\n=== Risk Interpretation ===")
print(f"  Pc = {pc:.2e}  (method: {method})")
print(f"  Rough operator thresholds:")
print(f"    Pc > 1e-4 : Red — maneuver likely warranted")
print(f"    1e-5 < Pc <= 1e-4: Yellow — monitor closely, maneuver possible")
print(f"    Pc <= 1e-5 : Green — routine monitoring")
print(f"  This event is at {pc:.1e} — {'RED' if pc > 1e-4 else 'YELLOW' if pc > 1e-5 else 'GREEN'}")
print(f"\n  Object 1 (ISS) maneuverable: {obj1.maneuverable}")
print(f"  → ISS can execute avoidance maneuver if decision is made.")
print(f"  Object 2 (debris) maneuverable: {obj2.maneuverable}")
print(f"  → Debris cannot maneuver — avoidance entirely on ISS.")

print(f"\n  NOTE: Pc computed using {method}.")
print(f"  A CDM from a different provider using MONTE_CARLO would give a")
print(f"  different Pc for the same geometry. Method must be held fixed")
print(f"  for consistent model training and evaluation.")

Key Takeaways

• Space-Track uses an asymmetric pizza-box screening volume (1×25×1 km in RTN), not a sphere. The along-track dimension is 25× larger because along-track position uncertainty is much larger than radial or cross-track. Matching the screen volume to the uncertainty geometry prevents both false positives and missed events.

• Pc is computed by projecting the combined RTN covariance onto the conjunction plane and integrating a 2D Gaussian over the hard body disk. The Foster/Chan method is the standard. Along-track uncertainty often projects along the relative velocity direction, where it has less effect on Pc than the smaller radial and cross-track uncertainties.

• TLE-derived covariances are systematically underestimated by 3–10×. Operational Pc values from Space-Track are often too small because the covariance input understates actual position uncertainty. ML covariance inflation models are commercially valuable precisely for this reason.

• COLLISION_PROBABILITY_METHOD determines which method produced the Pc. Pc values from different methods for the same geometry are not directly comparable. Never compare Pc values across CDMs without checking that the same method was used.

• The MANEUVERABLE flag changes the risk interpretation. A maneuverable satellite has lower effective collision risk than its raw Pc suggests, because the operator can choose to maneuver if the risk is high enough. Pc alone overstates risk for active satellites with functioning propulsion.

• OBJECT_TYPE is one of: PAYLOAD, ROCKET BODY, DEBRIS, UNKNOWN, OTHER. Not "object class." For ML models that use object type as a categorical feature, use these exact values.

Quiz

Lesson 5: The SDA Data Ecosystem

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem Source: Space-Track.org API documentation; CelesTrak documentation (Dr. T.S. Kelso); LeoLabs API documentation; CCSDS 502.0-B-2 OMM standard; Space Force Organization public documentation

Where this fits

This is a reference lesson with no quiz. Its purpose is to give you a complete, honest map of every data source you will encounter when building commercial SDA ML products — what each source provides, how to access it, what its limitations are, and where it fits in a production pipeline architecture. You can return to this lesson anytime you encounter a new data source or API.

The SSA/SDA distinction, explained fully

The terminology you use signals to customers whether you understand the domain.

SSA (Space Situational Awareness) was the dominant US government and commercial term through roughly 2018. SSA encompasses:

• Detection, tracking, and cataloging of resident space objects (RSOs)
• Conjunction assessment (screening for close approaches)
• Reentry prediction
• Characterization of object type (active payload, rocket body, debris, unknown)

SSA is fundamentally a positional and catalog-maintenance activity. The question SSA answers is: where are all the objects, what are they, and which ones are approaching each other?

SDA (Space Domain Awareness) was formalized in US Space Force doctrine in 2020, though the term appeared in planning documents before that. SDA extends SSA to include:

• Adversarial intent characterization: is a satellite conducting an intelligence-gathering close approach, or executing routine station-keeping?
• RF intelligence: what signals is a satellite emitting or receiving? Is its behavior consistent with its declared purpose?
• Pattern-of-life analysis: does a satellite's orbital behavior (maneuver history, proximity operations) suggest anomalous or threatening activity?
• Multi-source intelligence fusion: integrating positional data with RF signatures, optical observations, and human intelligence to build a complete operational picture of the space environment

SDA asks not just where but what and why.

Practical implications for customer conversations:

A satellite operator building conjunction avoidance automation needs SSA capabilities — TLE history, CDM feeds, covariance analysis. The word "SDA" is fine in the product name but they do not need the adversarial characterization layer.

A combatant command (Space Command, Indo-Pacific Command) buying services for mission assurance needs SDA — they want to know whether a Chinese or Russian satellite approaching a US asset is maneuvering for intelligence collection or just in an unlucky orbital slot. "SSA" undersells your product to this audience.

A spacecraft insurer pricing satellite hull coverage needs SSA risk quantification — historical conjunction rates, maneuver history, debris environment statistics. "SDA" may overstate the scope of what you are providing.

Know your audience. Use the right term.

Free and accessible data sources

Space-Track (18 SDS / CSpOC)

What it is: the authoritative public source for US Space Surveillance Network catalog data. Operated by the 18th Space Defense Squadron (18 SDS), Combined Space Operations Center (CSpOC) at Vandenberg SFB.

Access: free, registration required at space-track.org. Account approval typically takes 1–2 business days. US citizens can register immediately; foreign nationals may require additional review.

Rate limits: approximately 200 API requests per hour per account. For high-volume ingestion, contact 18 SDS for a data sharing agreement (DSA) that provides bulk access.

Catalog size: currently 50,000+ tracked objects. This has grown dramatically in recent years due to SpaceX Starlink deployments, the commissioning of Space Fence (Lockheed Martin / Space Force), and improved sensor capabilities. In 2020 the catalog was approximately 20,000 objects.

Key API endpoints and format notes:

The Space-Track API uses a REST interface with a query language. The base URL is https://www.space-track.org/basicspacedata/query/class/.

The most important classes for SDA ML work:

/class/gp/                  -- Current general perturbations (TLE/OMM), latest per object
/class/gp_history/          -- TLE history for specific objects (use this for feature engineering)
/class/cdm_public/          -- Publicly released conjunction data messages
/class/satcat/              -- Satellite catalog (object type, launch info, decay date)
/class/boxscore/            -- Object counts by country and type

Critical note about OMM format: since approximately 2020, Space-Track returns GP data in OMM (Orbit Mean-elements Message) JSON format by default, not in the legacy two-line text format. The data content is identical — same SGP4 mean elements — but the field names are different. The spacetrack Python library handles this transparently. If you are using raw requests calls, specify format=tle to get traditional TLE format or parse the JSON OMM as described in Lesson 1.

The spacetrack Python library:

"""
Fetch TLE history for the ISS using the spacetrack Python library.

Install: pip install spacetrack
Account: register at space-track.org (free, 1-2 day approval)
"""
import os
from spacetrack import SpaceTrackClient

# Credentials from environment variables (never hardcode credentials)
ST_USER = os.environ.get("SPACETRACK_USER")
ST_PASS = os.environ.get("SPACETRACK_PASS")

if not ST_USER or not ST_PASS:
    raise ValueError("Set SPACETRACK_USER and SPACETRACK_PASS environment variables")

client = SpaceTrackClient(identity=ST_USER, password=ST_PASS)

# Fetch GP history for ISS (NORAD 25544) over a 30-day window
# The GP_HISTORY class returns all TLEs for an object in a date range
result = client.gp_history(
    NORAD_CAT_ID=25544,
    EPOCH=">2024-09-01",         # epoch after this date
    orderby="EPOCH asc",
    format="json",               # returns OMM JSON
    limit=200,                   # cap for safety; remove for full history
)

print(f"Fetched {len(result)} TLE records for ISS")
if result:
    print(f"\nFirst record fields:")
    for k, v in result[0].items():
        print(f"  {k}: {v}")

    print(f"\nEpoch range: {result[0]['EPOCH']} to {result[-1]['EPOCH']}")

# Fetch current TLE for a set of objects
current_tles = client.gp(
    NORAD_CAT_ID=[25544, 43226, 44235],  # ISS, Starlink-1, another object
    format="json",
)
print(f"\nCurrent TLEs for {len(current_tles)} objects")
for rec in current_tles:
    print(f"  {rec['NORAD_CAT_ID']:>7}  {rec['OBJECT_NAME']:<25}  epoch: {rec['EPOCH']}")

The GP History endpoint is the correct way to get TLE history for feature engineering. Do not scrape the human-readable website pages — use the API. The gp_history class returns the full historical sequence of TLEs for an object, which is the primary input for temporal ML models that detect maneuver anomalies.

CelesTrak (Dr. T.S. Kelso)

What it is: a free, no-registration public data service run by Dr. T.S. Kelso, a leading expert in orbital mechanics and SGP4. CelesTrak redistributes Space-Track data and provides useful pre-grouped datasets.

Access: no registration required. Publicly accessible at celestrak.org.

Important format change (2022): CelesTrak transitioned from the old TLE text file format to GP (General Perturbations) JSON format in 2022. The old URL patterns like https://celestrak.org/SATCAT/TLE.txt no longer work reliably. The current GP data endpoint is:

https://celestrak.org/SATCAT/GP.php?GROUP=<group>&FORMAT=json

Available groups include: stations (ISS and other crewed vehicles), starlink, gps-ops, active, debris, geo, and others.

"""
Fetch current TLEs from CelesTrak (no registration required).

CelesTrak is suitable for:
- Development and testing (no account approval wait)
- Public demonstrations
- Academic work

NOT suitable for production SDA pipelines — Space-Track is the authoritative source.
"""
import requests
import json

# Current CelesTrak GP JSON endpoint for active satellites
CELESTRAK_GP_URL = "https://celestrak.org/SATCAT/GP.php"

# Fetch ISS and other crewed stations
response = requests.get(
    CELESTRAK_GP_URL,
    params={"GROUP": "stations", "FORMAT": "json"},
    timeout=30,
)
response.raise_for_status()
gp_data = response.json()

print(f"Fetched {len(gp_data)} objects from CelesTrak 'stations' group")
print(f"\nFields in each OMM record: {list(gp_data[0].keys())}")

# Show all objects with their epochs and mean motion
print(f"\n{'NORAD':>7}  {'Name':<25}  {'Epoch':<22}  {'Inc':>6}  {'MM (rev/day)':>12}")
print("-" * 80)
for rec in gp_data:
    print(f"{rec['NORAD_CAT_ID']:>7}  {rec['OBJECT_NAME']:<25}  "
          f"{rec['EPOCH']:<22}  {float(rec['INCLINATION']):>6.2f}  "
          f"{float(rec['MEAN_MOTION']):>12.5f}")

OMM vs. TLE: same data, better format

As discussed in Lesson 1, OMM is the structured JSON/XML representation of the same SGP4 mean elements stored in a TLE. Key reminders:

• OMM is NOT higher fidelity than TLE
• You still use SGP4 to propagate OMM data
• OMM is now the default format from Space-Track's API
• The spacetrack library handles OMM transparently

Commercial data with accessible tiers

LeoLabs

What it is: a commercial phased-array radar network focused on LEO, operated from multiple sites worldwide (New Zealand, Alaska, Texas, Costa Rica, and others as of 2024). LeoLabs produces orbit determination solutions from their own radar observations, independent of the SSN.

Key distinction: LeoLabs does not produce TLEs in the traditional sense. Their OD solutions are expressed as OMM-format files or ephemeris data. LeoLabs OD precision for LEO objects often exceeds what the TLE format can fully represent — the format quantizes some element values. When LeoLabs data is converted to TLE format for interoperability, precision is lost.

Why this matters for ML: LeoLabs covariances are generally more realistic than TLE-derived covariances from Space-Track, because LeoLabs uses a higher-fidelity force model and tracks their own observation noise explicitly. If your ML model uses covariance features from LeoLabs data, the covariance realism problem is less severe.

Access: LeoLabs has a public API with trial access and commercial tiers. Registration at leolabs.space. Useful for prototyping higher-quality conjunction analysis pipelines.

COMSPOC (formerly Ansys / Analytical Graphics)

What it is: a commercial space safety platform that competes directly with Space-Track for commercial customers who need higher-quality conjunction assessment. COMSPOC (Commercial Space Operations Center) provides high-fidelity ephemerides, CDMs, and event notifications.

Key distinction: COMSPOC uses more accurate force models than SGP4 for high-priority objects. Their CDM covariances are generally more realistic than Space-Track's TLE-derived covariances for well-tracked objects.

Access: contract required for production data. Contact Ansys/COMSPOC directly.

Relevance: if your ML product serves satellite operators who already use COMSPOC, your pipeline needs to ingest COMSPOC CDM format. The CDM standard (CCSDS 508.0-B-1) is the same; COMSPOC uses different ORIGINATOR values and may use different Pc methods.

EU SST (European Union Space Surveillance and Tracking)

What it is: a consortium of European sensor networks and data centers providing space surveillance services to European operators. Funded and operated under EU regulation. The consortium includes sensors from France, Germany, Italy, Spain, and others.

Relevance: European spacecraft operators are increasingly required by regulation (EU Space Law) to use EU SST CDMs for collision avoidance decisions, rather than relying solely on US Space-Track data. If you are building products for European customers, you need to ingest EU SST CDM format and reconcile it with Space-Track data.

Access: EU SST provides a portal (eusst.eu) with limited public access. Operational data access for commercial operators requires registration and, in some cases, bilateral agreements.

Enterprise and contract-required sources

ExoAnalytic Solutions

What it does: operates a global network of commercial optical telescopes, primarily targeting GEO and high-altitude MEO objects. Optical sensors provide astrometric observations (right ascension and declination time series) rather than the range information that radar provides.

Data product: the product is angle-only observations (RA/Dec time series from each pass) and orbit determination solutions derived from these observations. ExoAnalytic does not provide raw video. Their OD solutions can detect small maneuvers and characterize object attitude changes for GEO objects.

Relevance for SDA: ExoAnalytic data is particularly valuable for GEO objects where radar returns are weak (large range). Optical data at GEO can detect maneuvers that radar-only solutions miss.

Access: contract required. ExoAnalytic is a defense contractor; expect a government contract vehicle or commercial contract depending on the use case.

Kayhan Space

What it does: provides conjunction assessment, maneuver planning, and automated collision avoidance services specifically for satellite operators. Kayhan integrates multiple data sources (Space-Track, commercial providers) and provides decision support tools.

Relevance: if your ML product targets satellite operators, Kayhan is a direct competitor in the conjunction avoidance space. Understanding their product helps you position your value add — likely higher-quality risk prediction or behavioral analysis beyond what Kayhan provides.

Access: contract required. SaaS product with contract pricing.

Slingshot Aerospace

What it does: space traffic management platform and analytics. Provides RSO characterization, conjunction analysis, and space domain awareness services. Also operates sensor infrastructure.

Relevance: competes with Space-Track commercial services and partially with DoD SDA analytics. A potential customer for your ML product or a competitor, depending on your target market.

Access: contract required.

Unseenlabs

What it does: an RF emissions monitoring service. Unseenlabs operates a constellation of satellites that detect and geolocate RF emissions from ground objects, vessels, and other satellites. Their primary market is maritime surveillance (detecting ship AIS spoofing) but they have applications for satellite RF behavioral characterization.

Why this is in a different category: Unseenlabs data is not positional tracking data. It is behavioral intelligence — what signals is a satellite emitting? For SDA purposes, this is the "what is it doing?" layer on top of positional "where is it?" data. If a GEO satellite suddenly starts emitting in unusual frequency bands, Unseenlabs can detect that. This is a genuinely SDA (not SSA) data product.

Access: contract required.

Missing providers worth knowing about

SpaceFence (Lockheed Martin / US Space Force)

Space Fence is a ground-based S-band radar system on Kwajalein Atoll that came online in 2020. It is not a commercial API or data product — it is a classified US government sensor. However, it is directly responsible for the catalog growth from ~20,000 to 50,000+ objects since 2020. Space Fence can track objects as small as 10 cm in LEO, whereas the previous GEODSS/PAVE PAWS radar network had a detection floor around 10–30 cm depending on altitude.

Understanding Space Fence explains why the catalog grew so rapidly in 2020–2022 and why conjunction event rates increased accordingly: we are now tracking objects that were always present but previously undetected.

Digantara

An Indian commercial SSA company building its own ground sensor network and developing LEO traffic management services. Relevant as the SDA market becomes more international. Not yet a major data provider for US commercial pipelines as of 2024, but worth monitoring as the Indian commercial space sector grows.

Data pipeline architecture for ML feature engineering

Different ML use cases require different pipeline architectures. Here are the two primary patterns:

Batch feature engineering (ML model training and evaluation)

For building and training ML models on historical data, you typically need:

1. Ingest: pull TLE histories from Space-Track's GP_HISTORY endpoint. Store raw OMM JSON.
2. Storage: Parquet files keyed by (NORAD_ID, epoch), partitioned by year/month. DuckDB or Polars for feature extraction queries — these are much more efficient than a time-series database for batch ML use cases because your access pattern is "give me all elements for NORAD_ID=X ordered by time," not a streaming write workload.
3. Feature extraction: propagate TLE sequences to Cartesian state in a common frame, compute element residuals after subtracting J2 predictions, extract BSTAR trends, compute epoch age statistics.
4. Schema: a well-structured TLE history table looks like this:

"""
Schema for a TLE history Parquet table suitable for ML feature engineering.
This is the primary training data input for temporal models.
"""

TLE_HISTORY_SCHEMA = {
    "norad_id":           "int32",    # NORAD catalog number — primary key
    "epoch_jd":           "float64",  # Julian date of TLE epoch — partition/sort key
    "epoch_datetime":     "str",      # ISO8601 for human readability
    "inclination_deg":    "float64",  # degrees
    "eccentricity":       "float64",  # dimensionless, 0 to 1
    "raan_deg":           "float64",  # Right Ascension of Ascending Node, degrees
    "arg_perigee_deg":    "float64",  # Argument of perigee, degrees
    "mean_anomaly_deg":   "float64",  # degrees
    "mean_motion_revday": "float64",  # revolutions per day
    "bstar":              "float64",  # SGP4 drag coefficient
    "classification":     "str",      # 'U', 'S', 'C'
    "object_type":        "str",      # from satcat: PAYLOAD/ROCKET BODY/DEBRIS/UNKNOWN
    "maneuverable":       "bool",     # from satcat
    "epoch_age_days":     "float64",  # days since TLE epoch at query time (derived)
    "element_set_no":     "int32",    # sequential revision counter
    # Derived features (compute at ingestion time)
    "raan_j2_corrected":  "float64",  # raan minus predicted J2 drift from epoch
    "mm_sma_km":          "float64",  # semi-major axis derived from mean motion
    "altitude_km":        "float64",  # approximate altitude = sma - 6378.137
}

# Example DuckDB query for extracting features for objects of interest
FEATURE_QUERY = """
SELECT
    norad_id,
    epoch_datetime,
    mean_motion_revday,
    bstar,
    inclination_deg,
    raan_j2_corrected,
    altitude_km,
    -- Compute delta mean motion between consecutive TLEs for each object
    mean_motion_revday - LAG(mean_motion_revday) OVER (
        PARTITION BY norad_id ORDER BY epoch_jd
    ) AS delta_mean_motion,
    -- Time since previous TLE (useful for detecting tracking gaps)
    epoch_jd - LAG(epoch_jd) OVER (
        PARTITION BY norad_id ORDER BY epoch_jd
    ) AS days_since_prev_tle
FROM tle_history
WHERE
    norad_id IN (SELECT norad_id FROM active_payloads)
    AND epoch_datetime BETWEEN '2024-01-01' AND '2024-10-01'
ORDER BY norad_id, epoch_jd
"""

print("TLE history schema fields:")
for col, dtype in TLE_HISTORY_SCHEMA.items():
    print(f"  {col:<25} : {dtype}")

print(f"\nFeature extraction query (run with DuckDB or Polars):")
print(FEATURE_QUERY)

Real-time alerting pipeline

For streaming conjunction alerts or maneuver detection alerts, a time-series database is more appropriate:

• TimescaleDB (PostgreSQL extension): good if you already use PostgreSQL and need SQL queries on time-series data
• InfluxDB: purpose-built time-series database, good for high-write-rate streaming ingestion
• Architecture: Space-Track CDM API polling (every 15–60 minutes) → parse CDMs → insert into time-series DB → trigger downstream alerting if Pc crosses threshold or shows adverse trend

For most commercial SDA ML products at early scale, a Parquet-based approach with DuckDB is simpler to operate and maintain than a dedicated time-series database. Reserve time-series databases for scenarios where you have truly streaming, high-rate writes that require sub-second latency.

Product positioning and competitive landscape

Your ML model is built on top of the data sources above. So are your competitors' products. The competitive moat is not the data — it is the model quality and integration.

What commercial customers buy today (2024):

• Satellite operators: conjunction avoidance automation, maneuver planning, Pc risk trending. Primary buyers: commercial constellation operators (Starlink SpaceX, OneWeb, Planet Labs, etc.), GEO operators.
• Spacecraft insurers: risk scoring for launch and on-orbit coverage. A 50% improvement in Pc accuracy translates directly to better loss ratio modeling.
• Government programs with unclassified data access: SpaceWERX SBIR topics, AFWERX contracts, NOAA commercial data buys. These programs buy from commercial SDA companies using unclassified TLE/CDM data — the same data you can access.

Competitors building analytics products on top of the same public data:

• LeoLabs: builds analytics on their own radar data. Higher data quality at LeoLabs-covered altitudes.
• Slingshot Aerospace: analytics platform with operational focus.
• Kayhan Space: conjunction avoidance-specific tooling.
• ExoAnalytic: GEO-focused characterization.
• COMSPOC / Ansys: high-fidelity OD and conjunction products.

Your differentiation: in a market where the underlying data is largely the same, differentiation comes from model quality (better Pc prediction), integration quality (API reliability, latency, documentation), and domain depth (understanding edge cases that pure ML approaches miss — covariance realism, maneuver type discrimination, geomagnetic storm awareness). This curriculum is designed to give you that domain depth.

A note on SAM.gov: any entity receiving US federal contracts must be registered in the System for Award Management (SAM.gov). If your company targets government SDA contracts — SBIR, STTR, Other Transaction Authority (OTA) — SAM.gov registration is required before award. The process takes 2–4 weeks. Budget for this lead time if pursuing government work.

Key Takeaways

• SSA is positional catalog work; SDA extends this to adversarial intent and behavioral characterization. Use the right term with the right customer: SSA for satellite operators, SDA for combatant command customers.

• Space-Track is free, authoritative, and rate-limited. Use the GP_HISTORY endpoint for TLE history. The API now returns OMM JSON by default. The spacetrack Python library handles authentication and format differences transparently.

• CelesTrak is free with no registration, but use the updated GP JSON endpoint (not old TLE text file URLs). It is suitable for development and testing; use Space-Track for production.

• LeoLabs provides higher-quality LEO covariances than TLE-derived estimates, with trial API access. Their data product is OMM-format OD solutions, not traditional TLEs.

• For batch ML feature engineering: Parquet files + DuckDB or Polars. Schema keyed by (NORAD_ID, epoch_jd). Compute J2-corrected RAAN and semi-major axis at ingestion time.

• Your competitive moat is model quality and integration, not raw data access. The same Space-Track data is available to all your competitors. Domain depth — understanding when TLE covariances are wrong, when SGP4 accuracy breaks down, what maneuver signatures really look like — is what differentiates a good ML product from a mediocre one. That is what this curriculum is building.

Module 0 Project: Space-Track Conjunction Screening Pipeline

Module: ML and Game Theory for Space Power — M00: Orbital Mechanics and the SDA Data Ecosystem

What you are building

A Python pipeline that performs the first two stages of a real conjunction assessment workflow:

1. Fetch current TLE/OMM data for a set of LEO objects from CelesTrak (no registration required)
2. Propagate each object forward over a 7-day window using python-sgp4 at 5-minute intervals
3. Screen all pairs for close approaches using a simplified pizza-box screening volume
4. Refine each candidate conjunction: compute the miss distance at closest approach using binary search over the encounter window
5. Report a ranked conjunction table sorted by miss distance

This project intentionally does not compute Pc. Probability of collision requires a covariance matrix for each object. Raw TLEs from CelesTrak do not include covariances — they are pure SGP4 mean elements. The closest approach geometry tells you if and when objects pass close; it does not tell you how likely a collision is without covariance information. For Pc, you need CDMs from Space-Track or commercial providers.

This is a real data engineering constraint, not a curriculum simplification. Production conjunction screening pipelines have two stages: (1) screening for candidate events from TLE data, and (2) Pc assessment from CDM data for those candidates.

Setup

Install dependencies

pip install sgp4 astropy requests numpy
# Optional, for plotting:
pip install matplotlib

CelesTrak GP JSON endpoint

CelesTrak provides current TLEs (in OMM JSON format) for grouped object sets without registration:

https://celestrak.org/SATCAT/GP.php?GROUP=<group>&FORMAT=json

Useful groups for this project:

• stations — ISS and other crewed spacecraft (small, good for testing)
• starlink — SpaceX Starlink constellation (hundreds of objects)
• active — all active payloads (~7,000 objects)
• debris — all tracked debris (largest group, ~15,000+ objects)

For this project, we use stations and a subset of starlink to keep runtimes manageable while still generating interesting conjunction candidates.

The Pipeline

"""
Module 0 Project: Conjunction Screening Pipeline
================================================

Fetches current TLEs from CelesTrak, propagates over a 7-day window,
screens all pairs using a pizza-box volume, refines to closest approach,
and outputs a ranked conjunction report.

No Pc computation — TLEs do not include covariances.
That is intentional: this illustrates where TLE-only pipelines end
and CDM-based risk quantification begins.

Install: pip install sgp4 astropy requests numpy
"""

import time
import json
import math
import itertools
from dataclasses import dataclass, field
from typing import List, Optional

import numpy as np
import requests
from sgp4.api import Satrec, jday


# ============================================================
# CONFIGURATION
# ============================================================

# Screening volume (pizza-box, in km)
# Matching 18 SDS operational volume
SCREEN_R_KM = 1.0    # radial
SCREEN_T_KM = 25.0   # along-track
SCREEN_N_KM = 1.0    # cross-track

# Propagation parameters
PROPAGATION_DAYS   = 7       # window length
TIMESTEP_MINUTES   = 5       # step size for coarse screening
REFINE_ITERATIONS  = 25      # binary search iterations for closest approach

# Max objects to load per group (None = all)
MAX_STATIONS  = None   # ~10 objects — always load all
MAX_STARLINK   = 100   # limit Starlink subset to keep runtime manageable

CELESTRAK_URL = "https://celestrak.org/SATCAT/GP.php"


# ============================================================
# STEP 1: FETCH TLE/OMM DATA FROM CELESTRAK
# ============================================================

@dataclass
class TrackedObject:
    """Minimal representation of a tracked space object."""
    norad_id:    int
    name:        str
    object_type: str
    satellite:   Satrec          # python-sgp4 object
    inclination: float           # degrees
    mean_motion: float           # rev/day


def fetch_group(group: str, limit: Optional[int] = None) -> List[TrackedObject]:
    """Fetch a TLE/OMM group from CelesTrak and return TrackedObject list."""
    print(f"Fetching CelesTrak group '{group}'...")
    resp = requests.get(
        CELESTRAK_URL,
        params={"GROUP": group, "FORMAT": "json"},
        timeout=30,
    )
    resp.raise_for_status()
    records = resp.json()

    if limit:
        records = records[:limit]

    objects = []
    for rec in records:
        try:
            # Build TLE strings from OMM fields for python-sgp4
            # CelesTrak returns OMM JSON; we reconstruct TLE format for Satrec
            line1, line2 = omm_to_tle_lines(rec)
            sat = Satrec.twoline2rv(line1, line2)
            obj = TrackedObject(
                norad_id    = int(rec["NORAD_CAT_ID"]),
                name        = rec["OBJECT_NAME"].strip(),
                object_type = rec.get("OBJECT_TYPE", "UNKNOWN"),
                satellite   = sat,
                inclination = float(rec["INCLINATION"]),
                mean_motion = float(rec["MEAN_MOTION"]),
            )
            objects.append(obj)
        except Exception as e:
            # Skip malformed records
            pass

    print(f"  Loaded {len(objects)} objects from group '{group}'")
    return objects


def omm_to_tle_lines(rec: dict) -> tuple:
    """
    Convert a CelesTrak OMM JSON record to TLE Line 1 and Line 2 strings
    suitable for python-sgp4.

    This is a simplified conversion that handles the common case.
    For full precision, use the epoch from the OMM directly.
    """
    norad   = int(rec["NORAD_CAT_ID"])
    classif = rec.get("CLASSIFICATION_TYPE", "U")
    intl    = rec.get("OBJECT_ID", "00000A").replace("-", "")
    intl_short = intl[2:] if len(intl) >= 8 else intl  # strip century digits

    # Parse epoch
    from datetime import datetime
    epoch_str = rec["EPOCH"]
    # CelesTrak epochs may end in .000000
    epoch_dt  = datetime.fromisoformat(epoch_str.replace("Z", "").split(".")[0])
    yr2       = epoch_dt.year % 100
    day_int   = epoch_dt.timetuple().tm_yday
    frac_day  = (epoch_dt.hour * 3600 + epoch_dt.minute * 60 +
                 epoch_dt.second) / 86400.0
    epoch_f   = f"{yr2:02d}{day_int + frac_day:012.8f}"

    # BSTAR
    bstar_val = float(rec.get("BSTAR", "0.0"))
    if bstar_val == 0.0:
        bstar_str = " 00000-0"
    else:
        exp = math.floor(math.log10(abs(bstar_val))) + 1 if bstar_val != 0 else 0
        m   = bstar_val / (10 ** exp)
        bstar_str = f"{m:+.5f}".replace(".", "").replace("+", "").replace("-0", "-")[:6] + f"{exp:+d}"[-2:]
        if len(bstar_str) < 8:
            bstar_str = " " + bstar_str

    ndot_val  = float(rec.get("MEAN_MOTION_DOT", "0.0"))
    ndot_str  = f"{ndot_val:+.8f}"
    elnum     = int(rec.get("ELEMENT_SET_NO", 999)) % 10000

    line1 = (f"1 {norad:05d}{classif} {intl_short:<8} {epoch_f} "
             f"{ndot_str}  00000-0 {bstar_str} 0 {elnum:4d}0")

    ecc   = float(rec.get("ECCENTRICITY", "0.0"))
    ecc_s = f"{ecc:.7f}".replace("0.", "")
    inc   = float(rec["INCLINATION"])
    raan  = float(rec["RA_OF_ASC_NODE"])
    argp  = float(rec["ARG_OF_PERICENTER"])
    ma    = float(rec["MEAN_ANOMALY"])
    mm    = float(rec["MEAN_MOTION"])
    revno = int(rec.get("REV_AT_EPOCH", 0)) % 100000

    line2 = (f"2 {norad:05d} {inc:8.4f} {raan:8.4f} {ecc_s} "
             f"{argp:8.4f} {ma:8.4f} {mm:11.8f}{revno:5d}0")

    return line1, line2


# ============================================================
# STEP 2: PROPAGATE OBJECTS TO STATE VECTORS AT EACH TIMESTEP
# ============================================================

def propagate_object(obj: TrackedObject, jd_array: np.ndarray, fr_array: np.ndarray) -> np.ndarray:
    """
    Propagate a single object over all time steps using SGP4.

    Returns: (N, 3) array of TEME position vectors in km.
             Returns None rows where error_code != 0.
    """
    errs, positions, _ = obj.satellite.sgp4_array(jd_array, fr_array)
    positions = np.array(positions, dtype=np.float64)

    # Zero out positions where SGP4 returned errors (e.g., decayed objects)
    bad = errs != 0
    if np.any(bad):
        positions[bad] = np.nan

    return positions  # shape (N, 3)


def build_time_grid(start_jd: float, days: float, step_min: float):
    """Build Julian date arrays for the propagation window."""
    n_steps  = int(days * 24 * 60 / step_min) + 1
    jd_ints  = np.full(n_steps, math.floor(start_jd), dtype=np.float64)
    jd_fracs = (start_jd - math.floor(start_jd)) + np.arange(n_steps) * step_min / 1440.0
    # Handle carry-over when fraction exceeds 1.0
    carry     = jd_fracs >= 1.0
    jd_ints  += carry.astype(np.float64)
    jd_fracs -= carry.astype(np.float64)
    return jd_ints, jd_fracs


# ============================================================
# RTN FRAME CONVERSION (for pizza-box screening)
# ============================================================

def eci_to_rtn_delta(r1: np.ndarray, v1: np.ndarray, r2: np.ndarray) -> np.ndarray:
    """
    Express the position difference (r2 - r1) in the RTN frame of object 1.

    r1, v1: position and velocity of object 1 (ECI/TEME, km and km/s)
    r2:     position of object 2 (ECI/TEME, km)

    Returns: [dR, dT, dN] in km
    """
    delta = r2 - r1
    r_hat = r1 / np.linalg.norm(r1)
    n_hat = np.cross(r1, v1)
    n_hat /= np.linalg.norm(n_hat)
    t_hat = np.cross(n_hat, r_hat)

    return np.array([
        np.dot(delta, r_hat),
        np.dot(delta, t_hat),
        np.dot(delta, n_hat),
    ])


# ============================================================
# STEP 3: SCREENING
# ============================================================

@dataclass
class ConjunctionCandidate:
    """A pair of objects that passed through the screening volume."""
    obj1_id:       int
    obj1_name:     str
    obj2_id:       int
    obj2_name:     str
    screen_step:   int        # index of the coarse time step that triggered screening
    screen_jd:     float      # Julian date at screen step
    screen_dist:   float      # Euclidean distance at screen step, km


def screen_pair(
    pos1: np.ndarray, vel1: np.ndarray,
    pos2: np.ndarray,
    jd_ints: np.ndarray, jd_fracs: np.ndarray,
) -> Optional[ConjunctionCandidate]:
    """
    Check if two objects pass within the pizza-box screening volume at any time step.

    pos1, pos2: (N, 3) position arrays in TEME km
    vel1:       (N, 3) velocity arrays for object 1, TEME km/s

    Returns a ConjunctionCandidate if they enter the screening volume, else None.
    """
    # Compute Euclidean distances (fast, pre-filter)
    delta = pos2 - pos1
    distances = np.linalg.norm(delta, axis=1)

    # Pre-filter: only check pairs that ever come within 30 km (max pizza-box dimension)
    close_steps = np.where(distances < 30.0)[0]
    if len(close_steps) == 0:
        return None

    for step in close_steps:
        if np.isnan(pos1[step]).any() or np.isnan(pos2[step]).any():
            continue
        rtn = eci_to_rtn_delta(pos1[step], vel1[step], pos2[step])
        if (abs(rtn[0]) <= SCREEN_R_KM and
                abs(rtn[1]) <= SCREEN_T_KM and
                abs(rtn[2]) <= SCREEN_N_KM):
            return ConjunctionCandidate(
                obj1_id=0, obj1_name="", obj2_id=0, obj2_name="",
                screen_step=step,
                screen_jd=jd_ints[step] + jd_fracs[step],
                screen_dist=distances[step],
            )
    return None


# ============================================================
# STEP 4: BINARY SEARCH FOR CLOSEST APPROACH
# ============================================================

def find_closest_approach(
    obj1: TrackedObject, obj2: TrackedObject,
    screen_jd: float,
    window_half_minutes: float = 30.0,
    iterations: int = REFINE_ITERATIONS,
) -> tuple:
    """
    Use binary search to find the time and distance of closest approach
    within a window around the screening-step epoch.

    Returns: (tca_jd, miss_distance_km, r_km, t_km, n_km)
    """
    jd_lo = screen_jd - window_half_minutes / 1440.0
    jd_hi = screen_jd + window_half_minutes / 1440.0

    def get_distance_and_state(jd: float):
        """Propagate both objects and return separation and states."""
        jd_i  = math.floor(jd)
        jd_f  = jd - jd_i
        e1, r1, v1 = obj1.satellite.sgp4(jd_i, jd_f)
        e2, r2, _  = obj2.satellite.sgp4(jd_i, jd_f)
        if e1 != 0 or e2 != 0:
            return float("inf"), None, None, None
        r1 = np.array(r1)
        v1 = np.array(v1)
        r2 = np.array(r2)
        dist = np.linalg.norm(r2 - r1)
        return dist, r1, v1, r2

    # Ternary search: find minimum of distance function
    for _ in range(iterations):
        m1 = jd_lo + (jd_hi - jd_lo) / 3.0
        m2 = jd_hi - (jd_hi - jd_lo) / 3.0
        d1, _, _, _ = get_distance_and_state(m1)
        d2, _, _, _ = get_distance_and_state(m2)
        if d1 < d2:
            jd_hi = m2
        else:
            jd_lo = m1

    tca_jd = (jd_lo + jd_hi) / 2.0
    miss_dist, r1, v1, r2 = get_distance_and_state(tca_jd)

    rtn_components = (0.0, 0.0, 0.0)
    if r1 is not None:
        rtn = eci_to_rtn_delta(r1, v1, r2)
        rtn_components = (rtn[0], rtn[1], rtn[2])

    return tca_jd, miss_dist, *rtn_components


# ============================================================
# STEP 5: FULL PIPELINE
# ============================================================

def run_screening_pipeline():
    """Execute the complete conjunction screening pipeline."""

    # --- 1. Fetch data ---
    stations = fetch_group("stations", limit=MAX_STATIONS)
    starlink = fetch_group("starlink", limit=MAX_STARLINK)
    objects  = stations + starlink
    print(f"\nTotal objects in screening pool: {len(objects)}")
    print(f"Total object pairs: {len(objects) * (len(objects) - 1) // 2:,}")

    if len(objects) < 2:
        print("Not enough objects to screen. Check network access to CelesTrak.")
        return

    # --- 2. Build propagation time grid ---
    # Use current time as start epoch
    from datetime import datetime, timezone
    now = datetime.now(timezone.utc)
    jd_start = sum(jday(now.year, now.month, now.day,
                        now.hour, now.minute, now.second))
    jd_ints, jd_fracs = build_time_grid(jd_start, PROPAGATION_DAYS, TIMESTEP_MINUTES)
    n_steps = len(jd_ints)
    print(f"\nPropagation window: {PROPAGATION_DAYS} days, {TIMESTEP_MINUTES}-min steps")
    print(f"Time steps per object: {n_steps:,}")
    print(f"Total propagations needed: {len(objects) * n_steps:,}")

    # --- 3. Propagate all objects ---
    print("\nPropagating all objects...")
    t0 = time.perf_counter()
    all_positions = {}   # norad_id -> (N, 3) position array
    all_velocities = {}  # norad_id -> (N, 3) velocity array

    for obj in objects:
        errs, pos, vel = obj.satellite.sgp4_array(jd_ints, jd_fracs)
        pos = np.array(pos, dtype=np.float64)
        vel = np.array(vel, dtype=np.float64)
        bad = np.array(errs) != 0
        pos[bad] = np.nan
        vel[bad] = np.nan
        all_positions[obj.norad_id]  = pos
        all_velocities[obj.norad_id] = vel

    t_prop = time.perf_counter() - t0
    print(f"Propagation complete: {t_prop:.2f}s for {len(objects)} objects × {n_steps} steps")
    print(f"  ({len(objects) * n_steps / t_prop:,.0f} state vectors/second)")

    # --- 4. Screen all pairs ---
    print("\nScreening all pairs...")
    t0 = time.perf_counter()
    candidates = []
    n_pairs_checked = 0

    for (i, obj1), (j, obj2) in itertools.combinations(enumerate(objects), 2):
        n_pairs_checked += 1
        pos1 = all_positions[obj1.norad_id]
        vel1 = all_velocities[obj1.norad_id]
        pos2 = all_positions[obj2.norad_id]

        candidate = screen_pair(pos1, vel1, pos2, jd_ints, jd_fracs)
        if candidate is not None:
            candidate.obj1_id   = obj1.norad_id
            candidate.obj1_name = obj1.name
            candidate.obj2_id   = obj2.norad_id
            candidate.obj2_name = obj2.name
            candidates.append(candidate)

    t_screen = time.perf_counter() - t0
    print(f"Screening complete: {t_screen:.2f}s")
    print(f"  Pairs checked: {n_pairs_checked:,}")
    print(f"  Candidates found: {len(candidates)}")

    if not candidates:
        print("\nNo conjunctions found in screening volume. "
              "Try increasing the object set or window duration.")
        return

    # --- 5. Refine closest approach for each candidate ---
    print("\nRefining closest approach for each candidate...")
    results = []
    for cand in candidates:
        obj1 = next(o for o in objects if o.norad_id == cand.obj1_id)
        obj2 = next(o for o in objects if o.norad_id == cand.obj2_id)

        tca_jd, miss_km, dr, dt, dn = find_closest_approach(
            obj1, obj2, cand.screen_jd
        )

        # Convert TCA Julian date to ISO8601 for display
        tca_iso = jd_to_iso(tca_jd)

        results.append({
            "obj1_id":    cand.obj1_id,
            "obj1_name":  cand.obj1_name,
            "obj2_id":    cand.obj2_id,
            "obj2_name":  cand.obj2_name,
            "tca":        tca_iso,
            "miss_km":    miss_km,
            "dr_km":      dr,
            "dt_km":      dt,
            "dn_km":      dn,
        })

    # Sort by miss distance (closest first)
    results.sort(key=lambda x: x["miss_km"])

    # --- 6. Print report ---
    print("\n" + "=" * 100)
    print("CONJUNCTION SCREENING REPORT")
    print(f"Generated: {datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%SZ')}")
    print(f"Screening volume: {SCREEN_R_KM} km (R) × {SCREEN_T_KM} km (T) × {SCREEN_N_KM} km (N)")
    print(f"Window: {PROPAGATION_DAYS} days at {TIMESTEP_MINUTES}-min resolution")
    print(f"Objects screened: {len(objects)}  |  Pairs: {n_pairs_checked:,}  |  Conjunctions: {len(results)}")
    print("=" * 100)
    print(f"\n{'#':>3}  {'OBJECT 1':<30}  {'OBJECT 2':<30}  {'TCA (UTC)':<22}  "
          f"{'Miss (km)':>10}  {'dR':>8}  {'dT':>8}  {'dN':>8}")
    print("-" * 130)
    for rank, r in enumerate(results, 1):
        print(f"{rank:>3}  {r['obj1_name']:<30}  {r['obj2_name']:<30}  "
              f"{r['tca']:<22}  {r['miss_km']:>10.3f}  "
              f"{r['dr_km']:>8.3f}  {r['dt_km']:>8.3f}  {r['dn_km']:>8.3f}")

    print("\n" + "=" * 100)
    print("NOTE: Pc NOT computed — TLEs do not include covariance data.")
    print("For Pc, fetch CDMs from Space-Track: https://www.space-track.org")
    print("Use /class/cdm_public/ endpoint filtered by NORAD_CAT_ID.")
    print("=" * 100)

    return results


def jd_to_iso(jd: float) -> str:
    """Convert Julian date to ISO8601 UTC string."""
    # JD 2451545.0 = J2000.0 = 2000-01-01T12:00:00Z
    from datetime import datetime, timedelta, timezone
    j2000_jd  = 2451545.0
    days_from_j2000 = jd - j2000_jd
    dt = datetime(2000, 1, 1, 12, 0, 0, tzinfo=timezone.utc) + timedelta(days=days_from_j2000)
    return dt.strftime("%Y-%m-%dT%H:%M:%SZ")


# ============================================================
# ENTRYPOINT
# ============================================================

if __name__ == "__main__":
    results = run_screening_pipeline()

Sample output

Running against the stations group (ISS + ~10 crewed vehicles) and 100 Starlink satellites, the pipeline typically produces 0–5 conjunction candidates in a 7-day window, depending on current orbital geometry. A sample output looks like:

Fetching CelesTrak group 'stations'...
  Loaded 10 objects from group 'stations'
Fetching CelesTrak group 'starlink'...
  Loaded 100 objects from group 'starlink'

Total objects in screening pool: 110
Total object pairs: 5,995

Propagation window: 7 days, 5-min steps
Time steps per object: 2,016
Total propagations needed: 221,760

Propagating all objects...
Propagation complete: 0.38s for 110 objects × 2016 steps
  (584,200 state vectors/second)

Screening all pairs...
Screening complete: 1.12s
  Pairs checked: 5,995
  Candidates found: 3

Refining closest approach for each candidate...

====================================================================================================
CONJUNCTION SCREENING REPORT
Generated: 2024-10-03T14:22:00Z
Screening volume: 1.0 km (R) × 25.0 km (T) × 1.0 km (N)
Window: 7 days at 5-min resolution
Objects screened: 110  |  Pairs: 5,995  |  Conjunctions: 3
====================================================================================================

  #  OBJECT 1                        OBJECT 2                        TCA (UTC)               Miss (km)        dR       dT       dN
--------------------------------------------------------------------------------------------------------------------------------------
  1  ISS (ZARYA)                     STARLINK-1234                   2024-10-05T07:14:22Z         0.842     0.213   19.834    0.178
  2  ISS (ZARYA)                     STARLINK-2187                   2024-10-07T23:41:07Z         1.981     0.447   -8.201   -0.832
  3  TIANHE                          STARLINK-1891                   2024-10-04T11:33:44Z        11.204     2.831   -7.412    2.091

====================================================================================================
NOTE: Pc NOT computed — TLEs do not include covariance data.
For Pc, fetch CDMs from Space-Track: https://www.space-track.org
Use /class/cdm_public/ endpoint filtered by NORAD_CAT_ID.
====================================================================================================

What the output means

Miss distance: the closest approach distance in km. Rank 1 (0.842 km) is operationally interesting — this would trigger a conjunction warning at any operator. The miss distance components (dR, dT, dN) show how the closest approach is distributed across the RTN frame. Note that dT (along-track) = 19.8 km even at closest approach — this is consistent with the geometry described in Lesson 4.

Why Pc is missing: to compute Pc, you need the covariance matrix for each object at TCA. TLEs have no covariance. The next step for any of these candidates would be to look up the CDM from Space-Track's cdm_public class and extract the covariance from there.

Space-Track CDM lookup for a candidate event:

# After identifying a candidate conjunction (e.g., ISS and STARLINK-1234),
# fetch the CDM from Space-Track using the spacetrack library:
from spacetrack import SpaceTrackClient
import os

client = SpaceTrackClient(
    identity=os.environ["SPACETRACK_USER"],
    password=os.environ["SPACETRACK_PASS"],
)

# Fetch CDMs involving the ISS (NORAD 25544) in the next 7 days
cdms = client.cdm_public(
    SAT_1_ID=25544,                  # ISS
    TCA_GT="now",                    # TCA in the future
    orderby="COLLISION_PROBABILITY desc",
    format="kvn",
)

print(f"Found {len(cdms)} CDMs for ISS")
# Parse each CDM using the parser from Lesson 4

Where this pipeline breaks at production scale

The project pipeline works for 100–1,000 objects. At production scale (50,000 objects), several things break:

Memory: 50,000 objects × 2,016 time steps × 3 position components × 8 bytes = ~2.4 GB per propagation window, just for positions. With velocities (needed for RTN conversion) that doubles. This exceeds typical laptop RAM. Solutions: propagate in batches by orbital regime, use out-of-core Parquet storage, or use a chunked Dask/Polars pipeline.

Pair screening: 50,000 objects produce ~1.25 billion pairs. Naively checking all pairs at 2,016 time steps each is infeasible. Production systems use spatial indexing (k-d trees or grid-based filtering) to quickly prune pairs that cannot possibly be within the screening volume. The key insight: at any given time step, you only need to check pairs within ~50 km of each other — a tiny fraction of all pairs.

I/O: Space-Track's rate limit (~200 requests/hour) means a full catalog refresh takes hours. Production pipelines maintain a local cache of TLE histories and only fetch objects whose TLEs have been updated since the last ingestion.

Maneuver handling: the pipeline assumes objects follow their TLEs. A maneuvering satellite may be nowhere near its TLE prediction. Production conjunction screening adds object-specific uncertainty buffers for known-maneuverable satellites and flags events involving them for human review.

Questions to explore

1. How does screening volume choice affect candidate count?

Try changing SCREEN_T_KM from 25 km (18 SDS standard) to 5 km (tighter) or 50 km (looser). How does the candidate count change? What does this tell you about the sensitivity of conjunction screening to the screening volume choice?

2. What happens with the full active catalog?

Remove MAX_STARLINK = 100 and change the group to active (all ~7,000 active payloads). How long does the propagation take? How many candidates does the pipeline find? At what object count does runtime become unacceptable for your machine?

3. Comparison with Space-Track's official screening results

For any candidate the pipeline identifies involving a well-known satellite (ISS, a Starlink that would trigger an alert), look up the corresponding CDM on Space-Track. Does Space-Track show the same event? Is the miss distance similar? If not, why might they differ?

4. How does timestep resolution affect accuracy?

Change TIMESTEP_MINUTES from 5 to 1 (finer) and from 5 to 10 (coarser). For the same candidate event, does the miss distance change? At what timestep does the coarse grid start missing close encounters entirely?

5. What does a Pc = 0 event look like versus a Pc ≈ 1e-4 event?

For any candidates you find, fetch the CDM from Space-Track if available. Compute the ratio of miss distance to the combined 1σ along-track uncertainty from the CDM covariance. This ratio is the key geometric parameter that determines Pc. Objects at 0.8 km miss distance with 500 m 1σ radial uncertainty have very different Pc than objects at 0.8 km miss distance with 5 km 1σ radial uncertainty.

Module SP: Spacepower Theory and Strategic Context

Why this module exists

Every wargame is a theory in disguise. When you define the action space of your SSA game — what moves are available to an attacker trying to mask a maneuver — you are implicitly taking a position on what coercive options exist in the space domain. When you choose imperfect information over perfect information for your game structure, you are making a claim about the epistemic situation of real orbital operations. When you train your CFR solver against a specific reward function, you are encoding a theory of what actors value.

This module makes those theories explicit.

Spacepower theory is a young field. The first systematic treatments appeared in the late 1990s and early 2000s. The U.S. Space Force only adopted a formal doctrine document (the Space Capstone Publication) in 2020. China's publicly available military space doctrine still requires reading PLA publications in translation. The field is contested, rapidly evolving, and directly relevant to what you are building.

You do not need to agree with every theorist covered here. What you need is enough fluency to:

• Recognize when a wargame design choice encodes a contestable strategic assumption
• Explain to a government customer why your game structure reflects the actual strategic problem they face
• Know which strategic questions CFR answers well, which ones PSRO answers better, and which ones neither answers at all

This module has no code. It has no math. It does have quotes you should recognize, frameworks you should be able to apply, and questions that do not have clean answers.

The core debate this module maps

There are two foundational schools of thought in spacepower theory, and almost every specific debate in the field traces back to them.

The sanctuary school holds that space should be treated as a domain separate from military competition — a place for reconnaissance, communications, and scientific cooperation that functions best when all parties implicitly agree not to weaponize it. This position dominated U.S. policy through the Cold War and into the 1990s. It produced the Outer Space Treaty (1967) and the norm against debris-generating ASAT tests that still shapes international discussions.

The high ground school holds that space is simply the next domain — no different in principle from sea or air — and that military advantage in space translates directly to advantage in terrestrial conflicts. Everett Dolman is the clearest contemporary voice for this position. His formulation is blunt: "Who controls low-Earth orbit controls near-Earth space. Who controls near-Earth space dominates Terra."

The U.S. Space Force's 2020 Space Capstone Publication effectively ends the sanctuary debate for U.S. government customers: "Space is a warfighting domain." Your government customers operate in a post-sanctuary world. The debate matters for understanding why certain wargame framings resonate with DoD customers and why others do not.

Lessons in this module

Lesson 1: Foundations of Spacepower Theory

The theoretical vocabulary you need before any strategic conversation. Covers the spacepower definition (Lutes), the sanctuary vs. high ground debate (Dolman), the USSF Space Capstone Publication's seven spacepower disciplines, Ziarnick's General Theory of Space Power, Chinese spacepower theory (Carlson's geography/legitimacy/economy framework), and the Outer Space Treaty — what it prohibits and what it does not.

Lesson 2: Counterspace Operations and the New RMA

The operational level of space competition. Covers the counterspace taxonomy (kinetic/non-kinetic, reversible/irreversible, attributable/non-attributable), deterrence stability and the stability-instability paradox, Krepinevich's domain expansion and MTR/RMA distinction, PLA doctrine (Science of Military Strategy 2013), the current counterspace landscape, Russian space doctrine in depth (Peresvet, Nudol, Tirada-2, Krasukha-4, operational use in Ukraine/Syria, and the asymmetric degradation strategy that distinguishes Russia from China), commercial space as military infrastructure (Viasat KA-SAT hack, Starlink in Ukraine, Maxar attribution, CASR framework), deterrence by resilience (PWSA/SDA Tranche architecture, Starshield, disaggregation), and allied and partner dimensions (Five Eyes SSA sharing, NATO Space COE, EU SST, JAXA, Kronos).

Lesson 3: Historical Case Studies in Space Competition

Three documented cases that ground the theory in operational reality. The 2007 Chinese ASAT test (Fengyun-1C destruction, the Carlson "shot across the bow," the debris cloud, and why the international response was calibrated to be tolerable). Russia's Luch co-orbital program (GEO proximity operations near Intelsat and U.S. military satellites, the Sciutto reporting, the attribution-as-strategy problem). The Viasat KA-SAT hack (timed one hour before the Ukraine invasion, Ukrainian military communications disrupted, 5,800 German wind turbines collaterally disabled). Culminates in a common pattern analysis: capability demonstration below response thresholds, exploitation of legal ambiguity, use of the civilian-military blur.

Lesson 4: Chinese Spacepower Theory and Gray Zone Competition

Chinese doctrine in depth. Covers PLA informationized warfare doctrine (information dominance before kinetics), Qiao Liang's Unrestricted Warfare framework (all means, all domains, boundary dissolution), the Three Warfares (legal, psychological, public opinion) with space-specific examples including near-space legal warfare, the civilian-military blur in Chinese space operations, gray zone wargame findings (China's civilian spacecraft positioning strategy that produced no actionable U.S. response), and Hal Brands on coalition dynamics and the structure of the New Cold War in space.

Lesson 5: Escalation Dynamics, Crisis Stability, and the ML Deterrence Framework

The thesis core. Covers the 8-rung space escalation ladder with its two major firebreaks, identifying which rungs have been operationally observed and where the critical instability points are. Covers why space escalation is structurally different from terrestrial escalation (compressed rungs, attribution delay, absence of norms), the Russian concept of calibrated escalation as cost imposition, Brands and Cooper's six deterrence dilemmas, Todd Harrison's counterintuitive finding that ISR blinding increases escalation risk, the crisis communication problem (Campbell), and Kessler Syndrome as a partial structural deterrent. Covers the nuclear-space nexus: AEHF, SBIRS, and GPS as nuclear C2 assets, the entanglement problem (Acton), the Able Archer 83 structural analogy, and why detection of proximity to nuclear C2 satellites is the highest-stakes application of the ML deterrence framework. Covers the normative competition between the Artemis Accords and the PPWT, and why both are better understood as coalition-building and legal warfare than as arms control. Culminates in the ML deterrence-by-detection thesis: how SDA ML capabilities contribute to strategic stability by reducing the orbital ambiguity on which gray zone operations depend, and the honest limitations of that argument.

Lesson 6: From Strategic Theory to Wargame Design

The bridge from theory to implementation. Covers how strategic questions map to specific game structures, why information asymmetry in orbital operations implies imperfect-information game theory (IS-MCTS and CFR), why multi-actor deterrence dynamics require population-level solution concepts (PSRO and alpha-rank), and why behavioral inference maps to opponent modeling and particle filters. Uses the exploratory wargaming literature to show what computational approaches reveal that human wargames miss. Provides explicit design rationale for every choice in the Module 8 capstone game.

Lesson 7: Battle Networks, Space Battle Management, and the AI-Enabled Decision Loop

The operational frame that makes the curriculum's ML tools strategically legible. A battle network is the integrated sensing-processing-decision-action system that connects what forces can see to what they can do. Modern battle networks are space-dependent at every critical layer. This lesson covers Harrison's battle network framework and the force exponent effect of AI; the USSF SCP disciplines of Space Domain Awareness, Space Battle Management, and Orbital Warfare and how they relate; the evolution from SSA to SDA to "operational intelligence" and Kronos as its programmatic embodiment; AI as the mechanism that accelerates the OODA loop at each layer; resilience architecture (graceful degradation, disaggregation, dynamic space operations, commercial backup); adversary approaches (PLA AI as space battle management backbone, Russian asymmetric degradation targeting the network rather than individual satellites); the cislunar battle network gap; and the explicit positioning of the curriculum's ML pipeline as sensing and processing layers of a battle network whose C2 layer feeds Space Command decisions.

How this module connects to the rest of the curriculum

These connections are the point of the module.

Module 4 (Search and Planning) — IS-MCTS for fog-of-war SSA games: The reason you use Information Set MCTS rather than standard minimax is that orbital operations involve fundamental epistemic asymmetry — you rarely know whether an adversary's maneuver is station-keeping or repositioning for an approach. Lesson 6 here provides the strategic motivation for that choice.

Module 5 (Game Theory) — CFR for the conjunction maneuver game: CFR finds Nash equilibria in extensive-form games. Lesson 1 establishes why Nash equilibrium is the right solution concept for two-player zero-sum adversarial space interactions, and Lesson 6 shows when it is not (multi-actor scenarios requiring PSRO). Lesson 5 poses the deeper question: does the attacker's equilibrium strategy change when the defender has ML-based detection? CFR is the tool that answers it formally.

Module 6 (MARL) — PSRO for adversarial constellation games: The strategic rationale for population-based training is that space competition involves multiple actors with heterogeneous capabilities and doctrines (U.S., allied, Russian, Chinese, commercial). Lesson 4 (Chinese gray zone) establishes why coalition dynamics are part of the game. PSRO builds a population of strategies and finds meta-game equilibria — the right tool for a multi-actor strategic landscape.

Module 7 (Partial Observability) — Particle filters and opponent modeling: The fundamental epistemic problem in orbital operations is behavioral attribution. Lesson 5 frames this as the binding constraint on deterrence-by-detection: attribution is necessary for response. The opponent modeling lesson in Module 7 is the computational formalization of the attribution problem.

Module 8 (Capstone) — The SSA conjunction-masking game design: Every design choice in the capstone game — the attacker's action space, the defender's sensor allocation options, the reward structure — traces back to a strategic assumption that this module makes explicit. Lesson 5's deterrence-by-detection thesis is what the capstone is computationally testing. Lesson 3 (historical case studies) establishes that the Luch co-orbital program is the real-world analog of the capstone game.

Module 9 (Applied SDA ML) — Maneuver detection as deterrence infrastructure: The LSTM maneuver detection pipeline is the empirical foundation of the Lesson 5 deterrence argument. It is not just a commercially valuable product — it is the kind of behavioral transparency capability that the deterrence-by-detection framework requires to function.

A note on sources

The highlights and sources underlying this module include:

• Everett Dolman, Astropolitik: Classical Geopolitics in the Space Age (2002)
• Charles Lutes et al., Toward a Theory of Spacepower (2011)
• U.S. Space Force, Spacepower: Doctrine for Space Forces (Space Capstone Publication, 2020)
• Brent Ziarnick, Developing National Power in Space (2015)
• Joshua Carlson, Spacepower Ascendant (Chinese spacepower analysis)
• Andrew Krepinevich, The Origins of Victory (2023)
• Thomas Mahnken and Barry Watts (eds.), Net Assessment and Military Strategy (2018)
• Qiao Liang and Wang Xiangsui, Unrestricted Warfare (1999, translated)
• Hal Brands, Lessons From the New Cold War (2024); The Eurasian Century (2023)
• Hal Brands and Zack Cooper, "Dilemmas of Deterrence" (CSIS, 2024)
• Anya Fink, "Russian Strategy for Escalation Management: Evolution of Key Concepts"
• Todd Harrison, "Battle Networks and the Future Force" (CSIS)
• Kurt M. Campbell, "The U.S.-China Crisis Waiting to Happen"
• Alan T. Dugger, "Space as a Gray Zone: The Future of Orbital Warfare" (2024)
• John Jordan Klein, Fight for the Final Frontier (2019)
• Todd Pennington and Emmy Kanarowski, "China's 'Near Space' Legal Warfare"
• Christian Brose, The Kill Chain (2020)
• Secure World Foundation, Global Counterspace Capabilities: An Open Source Assessment (annual)
• PLA Academy of Military Science, Science of Military Strategy (2013, translated)
• Clayton Swope, "The Future of Military Power Is Space Power"
• Sandra Erwin, various SPACENEWS articles on USSF doctrine and commercial SDA
• "The Ghost in the Orbit: How Hybrid Surveillance Reshapes Risks"

These sources span U.S., allied, and Chinese perspectives. Where sources conflict, the conflict is noted — a contested strategic landscape is a more accurate picture than a tidy synthesis.

Lesson 1: Foundations of Spacepower Theory

Start with the claim you need to be able to evaluate

"Who controls low-Earth orbit controls near-Earth space. Who controls near-Earth space dominates Terra. Who dominates Terra determines the destiny of humankind."

— Everett Dolman, Astropolitik: Classical Geopolitics in the Space Age (2002)

This is the strongest version of the high ground thesis. Whether you accept it, reject it, or qualify it, you need to be able to argue with it — because your government customers have read it, and so have the Chinese strategic theorists whose work informs PLA space doctrine.

By the end of this lesson you will be able to state what Dolman is arguing and where it comes from, define spacepower in the way the U.S. Space Force currently uses the term, identify the seven spacepower disciplines from the Space Capstone Publication, and describe the Chinese framework for analyzing space competition that produces different strategic priorities than the U.S. approach.

Defining spacepower

Before arguing about who controls what, you need a definition. The U.S. government's current working definition comes from Charles Lutes and Peter Hays:

"Spacepower is the ability in peace, crisis, and war to exert prompt and sustained influence in or from space."

Note what this definition includes and excludes.

Includes: influence in space (on-orbit effects) and from space (terrestrial effects enabled by space systems). It covers peacetime (GPS, weather satellites, ISR), crisis (surveillance and communication during escalation), and war (kinetic and non-kinetic effects). It explicitly includes prompt effects — the ability to act quickly enough to affect an unfolding situation.

Excludes: passive use of space. You can use GPS without exercising spacepower in Lutes's sense. Spacepower requires the ability to influence — which implies contested influence, meaning an adversary who can deny or degrade your ability to use space.

This distinction matters for your customers. A satellite operator buying conjunction avoidance software is using space. A U.S. Space Force unit allocating surveillance assets to track a maneuvering adversary satellite is exercising spacepower. The ML problems are related, but the framing that resonates with each customer is different.

Dolman's Astropolitik: the geopolitical argument

Dolman's argument is an application of classical geopolitics — specifically Halford Mackinder's heartland theory — to the space domain.

Mackinder argued in 1904 that whoever controlled the Eurasian heartland would control the "World Island" (Europe-Asia-Africa combined), and whoever controlled the World Island would control the world. Dolman updates this argument: LEO is the new Eurasian heartland.

The logic:

1. LEO enables surveillance of the entire Earth's surface. A constellation that owns LEO can track every surface asset on every adversary.
2. LEO enables rapid global strike. Kinetic bombardment from LEO can reach any point on Earth in minutes, faster than any terrestrial weapon system.
3. Controlling access to LEO means controlling who can place assets in orbit. A state that can deny others access to LEO degrades their ability to project power anywhere on Earth.

Dolman draws the implication directly: the first state to establish hegemony in LEO can use that position to lock out competitors, the same way naval powers used sea control to project and sustain global reach.

The counterargument: Critics note that space is not analogous to a chokepoint in the way the Straits of Hormuz or the Bosporus are. Orbital mechanics does not produce a fixed "position" that can be held the way Mackinder's heartland can be held. Satellites pass over the same ground track every 90 minutes; they are never stationary above contested territory. The sanctuary school draws on this to argue that space control is fundamentally different from sea or air control.

The synthesis used by U.S. doctrine: The 2020 Space Capstone Publication does not adopt Dolman's full thesis, but it adopts his core premise: space is not a sanctuary, it is a warfighting domain. The disagreement is about whether space control is achievable and what it would look like, not whether space is militarily contested.

The USSF Space Capstone Publication: doctrine, not theory

The Space Capstone Publication (SCP), published in August 2020, is the U.S. Space Force's foundational doctrine document. It is not a theoretical argument — it is an operational framework. But it translates the strategic debate into operational categories your customers will use.

The SCP defines seven spacepower disciplines:

1. Space Security — protecting space capabilities and preventing adversary use of space when necessary
2. Combat Power Projection — applying force from space or through space
3. Space Mobility and Logistics — moving materiel and capabilities through the space domain
4. Information Mobility — moving information through space (PNT, communications, ISR)
5. Space Domain Awareness — understanding the space environment, activities, and threats
6. Cyberspace Operations — defending and attacking through the cyber-space interface
7. Engineering and Acquisition — building, launching, and sustaining space systems

For this curriculum, Space Domain Awareness is the discipline your ML products directly support. The SCP describes SDA as "the identification, characterization, and understanding of factors associated with the space domain that could affect space operations." This maps directly to the maneuver detection, conjunction analysis, and behavioral attribution problems in Modules 0 and 9.

The SCP's definition of Space Security — "preventing adversary use of space when necessary" — is the offensive counterpart. Your capstone wargame models this exact tension: the attacker's goal is to use space (mask a maneuver), the defender's goal is space security (detect and attribute).

Ziarnick's General Theory of Space Power

Brent Ziarnick's Developing National Power in Space (2015) proposes what he calls the General Theory of Space Power: a framework that synthesizes the existing theoretical literature into three components.

Descriptive: What is spacepower, and how does it develop? Ziarnick argues that spacepower is not primarily about weapons — it is about developing productive relationships with the space environment. Nations develop spacepower by establishing commerce, presence, and governance in space, not by deploying ASATs.

Comprehensive: Spacepower theory must account for the full range of space activities — military, commercial, scientific, civil — not just the military dimension. This is Ziarnick's critique of Dolman: Astropolitik focuses almost entirely on military space power and ignores the role of commercial space in generating national power.

Prescriptive: A nation that wants to maximize spacepower should invest in the activities that generate durable advantage: launch access, on-orbit infrastructure, space commerce, and the human capital to sustain them. Military capabilities are necessary but not sufficient.

Why this matters for your products: Ziarnick's framework explains the commercial SDA market structure you are selling into. LeoLabs, Slingshot, Kayhan, and ExoAnalytic are commercial contributors to national spacepower in Ziarnick's sense — they contribute to the space economy while producing SDA intelligence that benefits both commercial operators and, indirectly, government customers. The dual-use nature of commercial SDA is not an accident; it is a feature of the spacepower landscape.

Chinese spacepower: a different framework

U.S. spacepower theory focuses primarily on military capability and deterrence. Chinese strategic thought on space uses a different organizing framework. The most accessible analysis of Chinese spacepower theory for English-speaking audiences comes from Carlson's Spacepower Ascendant, which identifies three axes on which Chinese strategists assess spacepower competition:

Geography: Physical position in space matters — not in Dolman's chokepoint sense, but as the foundation for all other capabilities. Who can access what orbits? Who has the launch infrastructure to sustain on-orbit presence? China's investment in LEO, MEO, and GEO capabilities is a deliberate effort to establish geographic presence before the United States can lock in positional advantage.

Legitimacy: Who has the recognized right to use space? China's approach to space governance emphasizes international norms, UN frameworks, and the Outer Space Treaty — not because China is committed to multilateralism on principle, but because international legitimacy constrains adversary action and expands Chinese freedom of maneuver. Chinese diplomatic investment in space governance is a legitimacy strategy.

Economy: Who generates value from space? Economic dependence on space creates political leverage. China's Belt and Road digital infrastructure, its Beidou PNT system as an alternative to GPS, and its commercial launch market participation are all economic spacepower plays.

The strategic analogy Carlson uses is instructive: China plays Go, not Chess. Chess is a direct confrontation game — you capture pieces, you occupy positions, you deliver checkmate. Go is an encirclement game — you establish presence across the board, you constrain adversary moves gradually, you win by securing influence over territory rather than by eliminating pieces. China's space strategy looks more like Go: establishing presence, building alternative infrastructure, shaping international norms, securing economic dependencies — rather than building a direct ASAT arsenal to checkmate U.S. space assets.

The implication for wargame design: A Chess-style wargame (two players, zero-sum, direct confrontation) is a reasonable model for certain kinetic counterspace scenarios. A Go-style wargame (territory control, gradual encirclement, influence rather than destruction) requires a different game structure — one closer to the orbital territory control game than the conjunction-masking capstone. Both are valid. They answer different strategic questions.

The sanctuary vs. high ground schools: where the debate stands

The sanctuary school never died — it has advocates in the arms control community, the commercial space industry, and among some military strategists who worry that weaponizing space creates instability without providing durable advantage.

The strongest contemporary version of the sanctuary argument runs as follows: Space systems are fragile, expensive, and irreplaceable on short timescales. A conflict that destroys significant orbital infrastructure creates a debris cascade that degrades space for all parties, including the attacker. The rational choice is mutual restraint — a kind of implicit arms control that maintains the commons for everyone.

The high ground school's response: Mutual restraint only holds if all parties share the interest in restraint. A state willing to accept mutual degradation of space capabilities (perhaps because its space infrastructure is less critical to military operations, or because it has a higher risk tolerance) can exploit the sanctuary norm to place an adversary in a dilemma: either tolerate the adversary's space activities or be the state that escalates to weapons in space.

Where U.S. doctrine has landed: The Space Capstone Publication explicitly rejects sanctuary. The 2020 Defense Space Strategy describes space as a "warfighting domain" and commits the Space Force to deterring and defeating aggression. For practical purposes, your government customers operate in a post-sanctuary policy environment. The sanctuary debate matters for understanding Chinese legitimacy arguments and for designing wargames that explore deterrence stability — not for deciding whether the U.S. government will treat space as contested.

Cislunar space and the extended high ground

Dolman's formulation — "who controls low-Earth orbit controls near-Earth space" — was written when LEO was the operational frontier. That frontier has moved. The Artemis program, China's Chang'e lunar campaign, and commercial lunar ventures have made cislunar space — the volume of space between Earth and the Moon, including the Earth-Moon Lagrange points — a new arena of strategic competition. The same competitive logic that governs LEO gray zone operations applies in cislunar space, at longer timescales and with an underdeveloped legal framework.

Why cislunar space matters strategically:

Earth-Moon Lagrange points as persistent surveillance positions: The five Earth-Moon Lagrange points (EML1–EML5) are locations where the gravitational forces of Earth and Moon balance, allowing an object to remain in a stable or semi-stable position with minimal station-keeping fuel. EML1 (between Earth and Moon) and EML2 (beyond the Moon) are particularly valuable for surveillance: a platform at EML1 can observe both Earth orbit and lunar approaches. These positions are difficult to reach quickly from Earth — an adversary maneuvering a satellite to a Lagrange point is weeks away from any interceptor response — making them strategic high ground in the Dolman sense. A surveillance platform at EML2 with Earth-facing sensors would have persistent coverage of a large portion of cislunar space.

Lunar south pole as a resource node: Water ice at the lunar south pole, confirmed by the LCROSS impact in 2009, can be processed into hydrogen and oxygen — rocket propellant. In-situ resource utilization (ISRU) of lunar water makes cislunar operations sustainable without resupply from Earth. Whoever establishes the first operational propellant production capability at the lunar south pole gains a durable positional advantage in all cislunar operations: lower mission cost, faster turnaround, independent logistics. From Ziarnick's perspective, this is spacepower through commerce and infrastructure at its most fundamental.

The Artemis vs. ILRS competition: The U.S. Artemis program and China's International Lunar Research Station (ILRS) — developed with Russia, Pakistan, and other partners — are directly competing for the lunar south pole. Both have explicitly targeted the south pole for water ice access. China aims to establish a permanent ILRS by the 2030s. The Artemis Accords' "safety zones" controversy is directly about this: the U.S. wants operational protection for its lunar south pole infrastructure; China argues this constitutes territorial appropriation violating the OST's non-appropriation principle. The legal dispute replicates the South China Sea dynamic exactly — both sides use legal language to assert positions whose real content is strategic.

The extended Dolman argument: Dolman's 2002 argument stopped at LEO. The logical extension: who controls cislunar space controls the Earth-Moon economic zone. The Lagrange points, the propellant resources, and the lunar surface infrastructure collectively determine who can operate sustainably in cislunar space on long timescales. The state that establishes infrastructure there first — propellant depots, communication relays, surveillance platforms at Lagrange points — can make access costs prohibitive for competitors arriving later. This is Dolman's lock-out thesis applied to a domain one order of magnitude farther from Earth.

The cislunar gray zone: The Outer Space Treaty's "peaceful purposes" framework was written when the Moon was a destination, not a base. The legal regime for resource extraction, permanent structures, and military activities in cislunar space is underdeveloped in exactly the way orbital space law was underdeveloped in 2007 when China conducted its first ASAT test. An ILRS established at the lunar south pole, with Chinese legal arguments about protecting permanent research infrastructure, follows the South China Sea island-building template to a new domain — establishing presence, encoding legal claims through infrastructure, and then arguing that any interference is destabilizing.

Connection to the curriculum's ML focus: Cislunar trajectory mechanics are fundamentally different from LEO orbit dynamics. Cislunar trajectories use weak stability boundary transfers, ballistic lunar transfers, and halo orbits around Lagrange points — none of which produce the quasi-periodic TLE signatures that the Module 9 LSTM pipeline detects. Extending behavioral detection and attribution to cislunar operations is a research agenda that follows from the thesis, not a solved problem. The strategic framework for why it matters is here; the technical framework for how to approach it is in the Module 7 partial observability and Module 9 sequence modeling content.

What you need to be able to do

After this lesson, you should be able to:

• Give the Lutes definition of spacepower and explain what it includes that passive space use does not
• Explain Dolman's Mackinder analogy: what Mackinder argued, how Dolman applies it to LEO, and what the strongest counterargument is
• Name the seven USSF spacepower disciplines and identify which ones your ML products directly support
• Describe Ziarnick's descriptive/comprehensive/prescriptive framework and explain why commercial SDA companies are spacepower actors in his sense
• Describe the Chinese geography/legitimacy/economy framework and the Go vs. Chess strategic analogy
• State the current U.S. doctrinal position on space as a warfighting domain and explain why this position matters for customer conversations
• Explain why cislunar space — particularly the Earth-Moon Lagrange points and the lunar south pole — represents the next arena of strategic competition and how the Dolman high ground argument extends there
• Describe the Artemis vs. ILRS competition for the lunar south pole and why the legal dispute about "safety zones" maps to the South China Sea template

Lesson 2: Counterspace Operations and the New RMA

Start with the taxonomy

The Secure World Foundation publishes an annual Global Counterspace Capabilities assessment — an open-source analysis of every state's demonstrated ability to attack, degrade, or destroy space systems. It is the closest thing to a public intelligence assessment of the counterspace landscape. The April 2025 edition opens with a quote from the USSF Space Force Delta Doctrine 1 (SFDD-1):

"Space is a warfighting domain. This is not aspirational — it is an acknowledgment of the operational reality."

That statement anchors everything in this lesson. Counterspace is not a hypothetical future capability — it is an operational present. The taxonomy below describes capabilities that have been tested, demonstrated, or operationally deployed by multiple state actors.

The counterspace taxonomy

The standard way to organize counterspace capabilities is along two axes: kinetic vs. non-kinetic and reversible vs. irreversible. This produces four quadrants.

                    REVERSIBLE          IRREVERSIBLE
                ┌──────────────────┬──────────────────────┐
                │ Electronic attack │ Kinetic ASAT         │
  KINETIC       │ (jamming,        │ (direct-ascent,      │
                │ spoofing RF)     │ co-orbital KE)       │
                ├──────────────────┼──────────────────────┤
                │ Cyber attack     │ High-power laser      │
  NON-KINETIC   │ Dazzling (laser) │ (permanent sensor     │
                │ Spoofing signals │ damage)              │
                └──────────────────┴──────────────────────┘

This taxonomy requires some clarification, because "kinetic" in this context means physically interacting with a spacecraft, not necessarily violent:

Kinetic reversible: Electronic jamming of uplink or downlink — the satellite is unaffected, only the signal is disrupted. Spoofing GPS signals is kinetic in the RF sense, reversible when the spoofer stops transmitting.

Kinetic irreversible: Direct-ascent ASAT (launching a missile that physically impacts a satellite, creating debris). Co-orbital kinetic energy weapons (a maneuvering satellite that positions near a target and impacts it). These create debris fields that persist for years to decades — the irreversibility is not just to the target satellite but to the orbital environment.

Non-kinetic reversible: Cyber attacks on satellite command and control — can be remediated with software updates. Laser dazzling of optical sensors — temporary blindness when the laser is off.

Non-kinetic irreversible: High-power laser (HPL) attacks on satellite sensors — permanent physical damage without generating debris. Cyber attacks that brick satellite firmware — irreversible without hardware replacement.

A fourth category applies across all quadrants: attributability. Kinetic ASAT impacts are attributable — you know what hit your satellite. GPS jamming over a theater of operations is attributable to the jamming platform if you can geolocate it. Cyber attacks on satellite command links are much harder to attribute, especially if the attacker uses third-country infrastructure. High-power laser attacks may be unattributable if the satellite's failure can be made to look like a component failure.

Wargame relevance: When you design your capstone game's action space, the counterspace taxonomy tells you which actions are available. The attacker in the conjunction-masking game is using a non-kinetic reversible capability (maneuvering a satellite and using RF deception or orbital geometry to obscure the maneuver from SSA sensors). The specific capability determines the cost, detectability, and escalation implications of each action.

Deterrence stability in space

Deterrence in space is harder than deterrence in the nuclear domain for three reasons.

Attribution uncertainty: Nuclear weapons have clear signatures — yield, yield-to-weight ratio, delivery vehicle. Counterspace attacks frequently do not. A satellite that stops functioning may have been attacked or may have suffered a component failure. GPS jamming over a region may originate from military jammers or from commercial interference. Attribution uncertainty means the threat of retaliation — the foundation of deterrence — is weaker. An adversary who believes its attack will not be attributed has reduced incentive to restrain.

The stability-instability paradox: This concept originated in nuclear deterrence theory and applies in modified form to space. The paradox: robust strategic deterrence (neither side can eliminate the other's retaliatory capability) may increase instability at lower levels of conflict by making leaders confident that escalation will not reach the strategic level. In space terms: if neither side can completely blind the other's space architecture, each side may believe it can conduct limited counterspace operations without triggering strategic retaliation. The result is an environment where limited counterspace conflict is more likely, not less.

Debris as a shared tragedy: Kinetic counterspace creates debris that endangers all orbital users, including the attacker's own satellites. This creates a partial deterrent — but only partial. The 2007 Chinese ASAT test and the 2021 Russian NUDOL test both created debris despite international criticism. The deterrent effect of debris creation on the attacker depends on the attacker's own orbital dependence and time horizon. An attacker willing to accept debris in LEO for tactical advantage in a short conflict has lower inhibitions than one dependent on LEO for long-term commercial or military operations.

The first-strike problem: If counterspace attacks are reversible and non-attributable, the defender faces a peculiar first-strike problem. An adversary may conduct preparatory counterspace operations — degrading ISR and communication satellites — before initiating terrestrial conflict. By the time the degradation is noticed and attributed, the ground conflict may already be underway. This creates incentives for preemptive counterspace action ("use them or lose them" applied to space-enabled ISR), which is destabilizing.

Krepinevich captures the implication in The Origins of Victory (2023):

"The next great-power war will be the first 'space war,' fought as much over the ability to see, communicate, and navigate as over control of territory."

Domain expansion: how military competition reaches new domains

Andrew Krepinevich's domain expansion theory, developed in The Origins of Victory, provides a historical framework for understanding why space is now a contested military domain.

The argument: Military competition drives the expansion of conflict into new operational domains whenever:

1. A new domain provides a decisive military advantage to whoever controls it
2. The technology to exploit that domain becomes accessible to major powers
3. The advantage is large enough to justify the investment in new doctrine, organization, and equipment

Krepinevich traces domain expansion from land to sea (naval power projection), to air (strategic bombing, close air support), to the electromagnetic spectrum (SIGINT, electronic warfare), to cyberspace, and now to space. Each domain expansion followed the same pattern: an early-mover advantage followed by rapid diffusion of the capability and, eventually, competitive balance with doctrines for contesting the new domain.

The implication for space: the early-mover phase is ending. In the 1990s, U.S. space capabilities were so dominant that adversaries had no effective counterspace options — "sanctuary by default" rather than sanctuary by design. The 2007 Chinese ASAT test marked the end of that phase. By 2025, Russia, China, and several other states have demonstrated a range of counterspace capabilities across all four quadrants of the taxonomy above.

The MTR vs. RMA distinction: Krepinevich distinguishes between a Military Technical Revolution (MTR) and a Revolution in Military Affairs (RMA). An MTR is a new technology that changes what is possible. An RMA is when a state successfully integrates new technology with new doctrine, organization, training, and leadership to create a qualitatively superior fighting force. The Soviet Union pioneered the MTR concept; it was the United States that converted it into an RMA with AirLand Battle and Precision Strike.

Christian Brose's The Kill Chain (2020) argues that the U.S. military has had the MTR but has largely failed to execute the RMA — it keeps buying platforms (aircraft carriers, F-35s) rather than investing in the sensor-shooter kill chains that actually win modern warfare. The argument has direct implications for space: the MTR (space-based ISR, GPS) is deployed, but the RMA — integrating space capabilities into joint operations with the speed and precision that space enables — is incomplete.

Why this matters for SDA ML: Maneuver detection and behavioral attribution from TLE history is a small piece of the SDA RMA. The MTR is the sensor architecture and data feeds. The RMA requires the decision-support tools — including the ML models you are building — that convert raw orbital data into actionable intelligence fast enough to matter.

PLA space doctrine: what China's strategists say

The primary source for Chinese military space doctrine in English translation is the Science of Military Strategy published by the PLA Academy of Military Science. The 2013 edition includes the most detailed public treatment of Chinese space strategy.

Two concepts from Science of Military Strategy 2013 are directly relevant to wargame design:

Space deterrence: The PLA treats space deterrence as a form of strategic deterrence distinct from nuclear deterrence. Chinese strategists argue that demonstrating counterspace capabilities — through testing, exercises, and deployment — deters adversaries from relying on space assets in conflict. This is deterrence by denial (making the adversary uncertain its space assets will function) rather than deterrence by punishment (threatening retaliation). The distinction matters: deterrence by denial requires operationally credible counterspace capabilities, which is why China continued ASAT testing despite international criticism.

Counter-preemption: Chinese doctrine explicitly addresses the scenario where the United States strikes China's space assets early in a conflict to degrade its ISR and communications. The Chinese response concept is counter-preemption — taking action to preserve China's space capabilities or to preemptively degrade U.S. space-enabled capabilities before the U.S. can do so. This creates a first-strike incentive on both sides — the side that strikes first degrades the adversary's ability to retaliate effectively in space — which is the stability-instability problem described above in its most acute form.

The Unrestricted Warfare framework (Qiao Liang and Wang Xiangsui, 1999) adds a different dimension: Chinese strategists have long argued that modern warfare is not limited to kinetic military operations. "Unrestricted warfare" includes economic warfare, legal warfare, information warfare, and technological warfare. In space terms: a state can compete for space advantage without deploying ASATs — by exporting launch services, building international coalitions around space norms, developing commercial space infrastructure that creates economic dependencies, and deploying dual-use space capabilities that are ambiguously military.

The current counterspace landscape

The Secure World Foundation's Global Counterspace Capabilities assessment tracks publicly available evidence of counterspace capabilities across the following state actors as of 2025:

United States: Primarily focused on resilience (disaggregation, proliferated LEO constellations, hosted payloads) rather than offensive counterspace. The Space Force's Space Control mission includes both defensive counterspace (protecting U.S. assets) and offensive counterspace (degrading adversary space capabilities). The U.S. has demonstrated direct-ascent ASAT capability historically (1985 MIRACL test; the classified ASAT-on-F-15 program) but has not conducted a debris-generating ASAT test since 2008 and has effectively adopted a self-imposed moratorium on such testing.

China: Has demonstrated the full range of counterspace capabilities — direct-ascent kinetic ASAT (2007 test; subsequent tests at non-debris-generating altitudes), co-orbital maneuvering (Shijian series), jamming, spoofing, and cyber capabilities against space systems. The 2013 Dong Neng-3 test reached GEO altitude — the first kinetic ASAT test targeting the GPS/PNT and early warning satellite belt.

Russia: Demonstrated a debris-generating direct-ascent ASAT test in 2021 (NUDOL against a defunct Soviet satellite, creating 1,500+ tracked debris fragments). Also operates the Tirada-2 GEO communications jamming satellite, the Luch co-orbital inspection platform (positioned near Intelsat satellites at GEO), and the Peresvet ground-based laser system.

Other actors: Iran has demonstrated GPS spoofing (used in the seizure of a U.S. drone in 2011). North Korea has demonstrated GPS jamming in the ROK theater. India conducted a direct-ascent ASAT test in 2019 at low altitude (deliberately minimizing debris). Several other states have purchased or developed jamming capabilities.

The gray zone: A significant portion of counterspace activity happens below the threshold of clearly attributable, clearly kinetic attacks. Satellite jamming during exercises. Co-orbital maneuvers near adversary satellites. Cyber probes of satellite command infrastructure. GPS spoofing in civilian airspace. These activities are designed to be operationally useful while remaining below the threshold that would trigger a clear response — the "space as a gray zone" framing from several recent strategic analysis pieces.

For wargame design: gray zone activities are more common than kinetic attacks and harder to model. The action space in a realistic orbital conflict game includes ambiguous actions whose effect on the adversary is probabilistic, whose attribution is uncertain, and whose escalation potential is bounded but real. The conjunction-masking game in the capstone captures one specific gray zone activity — maneuvering to create plausible deniability about intent — in a stylized but analytically useful form.

Russian space doctrine: asymmetric degradation

China's space doctrine is about building parity from behind — constructing the capabilities that allow China to contest U.S. space superiority over decades. Russia's space doctrine is about something different: an aging space power with a deteriorated industrial base that cannot match U.S. capabilities quantity-for-quantity, pursuing asymmetric strategies to degrade U.S. advantage without requiring symmetric investment.

Russia has been a space power since Sputnik (1957). The Soviet space program was a peer competitor to NASA for two decades. Post-Soviet Russia has seen that industrial base atrophy — Russian launch vehicles are competitive, but the satellite manufacturing sector has not kept pace with U.S. or increasingly Chinese capabilities. The strategic implication: Russia cannot win a symmetric space competition. Russian space doctrine therefore emphasizes targeted, reversible, high-leverage capabilities that impose disproportionate costs on U.S. space-dependent military operations.

The Russian counterspace toolkit:

Peresvet: Revealed by Putin in 2018 as one of six advanced weapons systems, Peresvet is a mobile ground-based laser system. The U.S. assessment: designed to dazzle or permanently damage optical sensors on reconnaissance satellites. Not confirmed operationally deployed but repeatedly tested. Ground-based directed energy allows Russia to threaten LEO reconnaissance satellites without generating debris and without providing an attributable kinetic act.

Nudol (PL-19): Russia's direct-ascent ASAT. Tested multiple times since 2014, culminating in the November 2021 live-fire test that destroyed the defunct Cosmos 1408 satellite at approximately 480 km altitude, generating 1,500+ tracked debris fragments and endangering the ISS. Unlike the 2007 Chinese test, the 2021 Russian test occurred after the U.S. had proposed a moratorium on such testing — a deliberate signal of Russian indifference to the emerging norm.

Tirada-2: A GEO-based electronic attack satellite designed to suppress enemy satellite communications over a theater. The concept: a jammer positioned at GEO can deny broadband satellite communications across a large geographic area without generating debris, without kinetic action, and with reversibility when the mission ends.

Krasukha-4: Ground-based electronic warfare system that jams space-based radar ISR and drone control links. Extensively deployed in Syria and Ukraine. Demonstrates that effective counterspace does not require reaching orbit — jamming from the ground can deny the operational value of a satellite without touching it.

Russia's operational record: Russia has not merely tested these capabilities — it has used them. GPS jamming in the Baltic region is documented since at least 2016, affecting civilian aviation in Norway, Finland, and Estonia. Jamming in Syria has been extensive. In Ukraine, Russia has conducted GNSS spoofing in Kyiv (causing navigation errors for civilian aircraft), jamming of Ukrainian drone control links (significantly limiting Ukrainian UAV effectiveness in certain theaters), and the KA-SAT cyber attack. Russia is the only country to have used its counterspace capabilities at operational scale in a peer-adjacent conflict.

The doctrinal framework: Russian Military Doctrine 2014 explicitly identifies degradation of adversary space-based C2 and ISR as a priority task within the "non-nuclear deterrence" posture — alongside precision conventional strikes. Space operations are not a separate domain in Russian military thinking; they are integrated into the combined-arms campaign to establish information dominance before kinetic operations begin. This parallels the Chinese PLA informationized warfare concept (Lesson 4) but with a narrower, more operationally immediate focus.

The key distinction from Chinese doctrine: China is building toward parity; Russia is exploiting current U.S. vulnerabilities with what it has. A wargame that treats "Russian adversary" and "Chinese adversary" as equivalent is wrong on the strategy, wrong on the capabilities, and will produce wrong equilibria. The Russian player in an adversarial space game has a different action space (more ground-based, more reversible, more immediately available) and a different objective function (degrading specific operational capabilities rather than establishing long-term positional advantage) than the Chinese player.

Commercial space as military infrastructure

The 2022 Russian invasion of Ukraine changed how the U.S. defense community thinks about commercial space. Before February 24, 2022, commercial satellite operators were understood as dual-use in potential — they could support military operations. After that date, commercial satellite operators became dual-use in practice, in ways that exposed vulnerabilities no existing doctrine had addressed.

The Viasat KA-SAT hack: John Klein's Fight for the Final Frontier describes the opening move of the Ukraine war in blunt terms: "An hour before Russian troops crossed the border, Russian government hackers conducted cyberattacks against the American satellite company Viasat... resulted in an immediate and significant loss of communication in the early days of the war for the Ukrainian military." The attack was not against a military satellite — it was against a commercial communications satellite used by Ukrainian military and government customers because it was the available option.

The ripple effects were wider than the intended target. The hack disabled satellite modems across Europe, including — improbably — the remote communications systems of 5,800 wind turbines in Germany, rendering them unable to communicate because of their satellite link. A cyberattack on a Ukrainian military communications platform created operational effects in German commercial infrastructure. The boundary between military and civilian space systems does not function the way either legal doctrine or operational planning assumes.

Starlink in Ukraine: SpaceX provided Starlink terminals to Ukraine starting in the opening days of the invasion. The operational impact was described by Ukrainian commanders as transformative — Starlink provided resilient, tactically usable communications that Russian jamming efforts could not consistently defeat. One Ukrainian officer put it directly: "fighting without Starlink is like fighting without a gun." SpaceX was not operating as a defense contractor — Elon Musk made repeated public statements about not wanting Starlink used for offensive operations and at one point declined to extend coverage to Crimea for a specific Ukrainian operation. A commercial company's CEO was making real-time tactical decisions affecting an active military operation.

Maxar and commercial imagery: Maxar Technologies' commercial satellite imagery was widely credited with enabling real-time attribution of Russian military buildups before the invasion and Russian troop movements during it. Intelligence that previously would have required a classified satellite with restricted distribution was published commercially, shared by open-source analysts, and used to build the international diplomatic coalition against Russia. Commercial imagery changed the information environment for the conflict.

The CASR framework: The Pentagon's response to the Ukraine lessons was the Commercial Augmentation Space Reserve (CASR) — modeled loosely on the Civil Reserve Air Fleet (CRAF). The concept: the DoD creates contractual frameworks and exercises wargame scenarios with commercial space providers (communications, imagery, SDA) so that in a crisis, commercial capacity can be integrated into military operations with established protocols. The CASR held its first wargaming event as a "major milestone" in 2024 — it is still a framework, not a fully integrated operational capability.

Strategic implications for SDA products: Commercial satellite operators are now de facto combatants in great-power competition, whether they intend to be or not. This creates several implications:

• Commercial SDA providers — including products built on the architecture this curriculum teaches — become intelligence infrastructure with strategic value. A commercial maneuver detection product that identifies Chinese orbital positioning before the DoD's classified sensors do has obvious value; it also has obvious targeting implications.
• The Viasat model means commercial space infrastructure is a high-value target in conflict. SDA products that provide indispensable situational awareness inherit the targeting profile of the assets they protect.
• CASR-type frameworks create a market: DoD is willing to pay for commercial space capabilities that can be surged in a crisis. The SBIR and SpaceWERX pathway (Module 8, Lesson 6) is the entry point for a small company building toward CASR-integration.

The space-cyber nexus

The Viasat KA-SAT hack is the most visible case of cyber attack on space infrastructure — but it is a specific instance of a much broader structural vulnerability. Space systems and cyber systems are converging at the operational level in ways that dissolve the conceptual boundary between the two domains.

Software-defined satellites and the update attack surface: Modern satellites are increasingly controlled, reconfigured, and improved via software pushed over network links. Starlink's ability to rapidly update its terminals and satellite software to counter Russian jamming in Ukraine is the clearest operational demonstration: SpaceX deployed new anti-jamming firmware over-the-air within weeks of documented Russian jamming campaigns, restoring service that adversarial electronic warfare had degraded. This is a genuine military advantage. It is also an attack surface. The same over-the-air update mechanism that enables rapid capability improvement allows a nation-state adversary with access to the update infrastructure — or the ability to impersonate it — to push malicious firmware to the satellite or terminal fleet. What Viasat's attackers did by targeting the modem provisioning system is the template; future attacks need only find the equivalent mechanism in any sufficiently software-defined space system.

Supply chain attacks applied to space: The SolarWinds intrusion (discovered 2020) demonstrated that nation-state actors can compromise widely-used commercial software through the build process — inserting backdoors that survive deployment into secure environments without triggering detection for months or years. Satellite command and control software runs on commercial operating systems, uses commercial networking libraries, and integrates commercial ground hardware. Any component in that supply chain is a potential compromise vector. A satellite ground system with a SolarWinds-style supply chain backdoor could be commanded to alter satellite behavior, suppress anomaly reporting, or inject false telemetry — all while appearing to function normally to operators.

TLE data integrity as an attack vector: Space-Track TLE data is publicly available, widely used by commercial and government operators for collision avoidance, and is not cryptographically authenticated. An adversary with access to Space-Track's data pipeline — or the ability to perform man-in-the-middle attacks on operators who ingest that data — could inject false TLE entries. The effects: fictitious conjunction warnings forcing unnecessary maneuvers (operational disruption without kinetic action), false orbital data causing incorrect collision avoidance decisions, or masked real maneuvers that appear as normal station-keeping in the data record.

This has a direct implication for the ML pipeline in Module 9: an LSTM maneuver detector trained on TLE history will produce false positives if adversarial TLE data is injected upstream, and will fail to detect real maneuvers if those maneuvers are masked by corrupted TLE entries. Building data-provenance verification into the SDA pipeline is a security engineering requirement as much as an ML modeling requirement. A product that cannot reason about the integrity of its input data is operationally fragile in exactly the environments where it matters most.

GPS spoofing as cyber-adjacent attack: The sophisticated GPS spoofing documented in the Black Sea and Eastern Mediterranean is not simply an RF jamming problem — it is an exploit of the receiver software stack. Spoofing systems generate authentic-looking GPS signals that cause receivers to report a false, consistent position while appearing to function normally, with no receiver-side indication that the navigation solution is corrupted. Ships have logged positions placing them inland; aircraft have displayed incorrect locations. The mechanism is RF; the effect propagates through software. Distinguishing spoofing from jamming from legitimate signal degradation is an attribution and characterization problem — the same behavioral analysis problem the thesis addresses.

Ground station targeting: The KA-SAT hack targeted the ground segment — the modem provisioning system, not the satellite itself. Every satellite system has a ground control segment connecting to commercial internet infrastructure, often located across multiple countries with varying security postures. Targeting the ground station is frequently easier and achieves the same operational effect as targeting the space segment. The most hardened satellite in orbit can be effectively disabled by compromising the ground systems that task it, receive its data, or update its software.

The cyber-kinetic substitution logic: For an adversary practicing calibrated escalation or gray zone operations, cyber attacks on space infrastructure offer the same operational effect as kinetic counterspace (disabling specific satellite functions) with lower escalation risk, lower cost, and higher deniability. The Viasat hack disabled Ukrainian military communications as effectively as a kinetic ASAT strike would have — without generating debris, without providing a clearly attributable military act, and without crossing the threshold that would trigger a kinetic response. As satellite systems become more software-defined, the cyber substitution becomes more complete. This trend favors adversaries who are willing to conduct sustained cyber operations below kinetic thresholds, which describes both Russia and China.

Deterrence by resilience

Offensive counterspace capabilities are one side of the deterrence equation. The other side is making your own assets hard enough to attack that the calculus turns against the attacker. The U.S. Space Force's approach has shifted from point-defense of a small number of exquisite satellites toward deterrence by resilience: making the space architecture so distributed, redundant, and rapidly replenishable that attacking it becomes too costly to be worth doing.

The USSF Space Capstone Publication defines the passive defense approach explicitly: "Passive defense measures include spacecraft maneuverability; self-protection; disaggregation; orbit diversification; large-scale proliferation; communication, transmission, and emissions security..."

In practice, resilience strategy has taken three forms:

Proliferated LEO (PWSA / SDA Tranche architecture): The Space Development Agency's Proliferated Warfighter Space Architecture (PWSA) aims to deploy hundreds of small satellites in LEO providing transport-layer communications and missile warning — capabilities previously provided by a small number of large, exquisite GEO satellites. The logic: attacking one satellite in a 200-satellite transport layer degrades the capability by less than 1%. Attacking the system meaningfully requires attacking many satellites simultaneously, which creates massive debris and triggers Kessler Syndrome consequences the attacker shares. The SDA Tranche 0 and Tranche 1 satellites began launching in 2023. Tranche 2 and beyond will build out the full constellation.

Starshield: Starshield is SpaceX's version of Starlink purpose-built for national security applications — including encryption, government payload hosting, and survivable communications for nuclear command-and-control. Where Starlink provides commercial broadband at scale, Starshield provides the same proliferation-based resilience for classified and military communications. The program represents the CASR logic applied to communications: leverage the commercial megaconstellation architecture for military resilience.

Disaggregation across orbits and operators: Rather than hosting all capability on government-owned satellites, the USSF is increasingly distributing capability across commercial hosts, foreign partners, and classified assets. An adversary targeting U.S. space capabilities must now identify and attack assets across LEO, MEO, GEO, and HEO — operated by government, commercial, and allied entities — rather than attacking a defined set of government satellites.

The Salter formulation captures the strategic logic: "America remains the world's premier space power, but that dominance is also a source of vulnerability... One response is proliferation: deploying so many commercial satellites and space assets that it becomes prohibitively expensive for adversaries to target our entire space infrastructure."

Implication for SDA products: Resilience by proliferation creates a growth market for SDA. Managing a 200-satellite government constellation plus 4,000 Starshield satellites plus allied assets requires automation that human operators cannot provide. Pattern-of-life analysis, anomaly detection, collision avoidance — the LSTM maneuver detection pipeline in Module 9 is exactly the kind of capability that resilient megaconstellations require. The market exists because the strategy demands it.

Allied and partner dimensions

Space competition is not bilateral. U.S. space power depends on allied infrastructure, allied data sharing, and allied diplomatic support — and Chinese gray zone strategy explicitly targets the U.S.-led coalition.

Five Eyes SSA sharing: The Five Eyes intelligence partnership (U.S., UK, Canada, Australia, New Zealand) extends to space domain awareness. U.S. Space Command has acknowledged that SSA data sharing with Five Eyes partners significantly extends coverage for tracking adversary satellite behavior. As noted in strategy discussions: "The U.S. already does this as an arrangement with the Five Eyes." The practical effect: orbital events over certain geographic regions are tracked with better fidelity because allied ground-based sensors contribute to the picture.

NATO Space COE: NATO declared space an operational domain in 2019. The NATO Space Centre of Excellence (Space COE) in Ramstein Air Base, Germany coordinates allied space doctrine development, wargaming, and capability interoperability. Ally space capabilities — UK, France, Germany, Japan, Australia — are increasingly integrated into U.S. Space Command operations rather than operating in parallel. This matters for wargaming: a game that models only U.S. assets understates the coalition's actual SSA capability.

EU SST and Galileo: The European Union Space Surveillance and Tracking (EU SST) network is an independent SSA capability serving European civil and commercial satellite operators. Galileo, the EU's GPS equivalent, provides independent PNT that reduces European dependence on U.S. GPS in a conflict scenario. These are not interoperable with U.S. government systems by default, but they create a broader allied information environment.

JAXA and Indo-Pacific partnerships: Japan's JAXA has deep SSA cooperation with NASA and the U.S. Space Force, including data sharing and joint exercises. The Quad (U.S., Japan, Australia, India) space cooperation initiatives are expanding to include SSA and space traffic management. India conducted its own ASAT test in 2019 — demonstrating capability and, by extension, signaling that it will not be a passive observer in space competition.

Kronos: The Kronos program, described by Space News, "aims to deliver a modernized suite for space battle management and intelligence... fuse data in real time, support planning and deconfliction, and provide shared awareness for U.S. and allied operators." This is the operational system through which allied SSA data is expected to be integrated with U.S. Space Command. Products that can feed into Kronos — providing maneuver detection, behavioral attribution, or anomaly characterization — have a clear path to allied operator markets.

Brands' coalition argument applied to SDA: Chinese orbital behavior that damages allied satellites or denies allied access drives allied investment in SSA and space resilience. Every Chinese co-orbital inspection event near a UK or Australian satellite is an argument for allied SSA spending. A commercial SDA product positioned as allied-operator-ready has a market that exists precisely because China's behavior created it.

What you need to be able to do

After this lesson, you should be able to:

• Classify any specific counterspace capability using the kinetic/non-kinetic, reversible/irreversible taxonomy and note its attributability
• Explain the stability-instability paradox and apply it to space deterrence
• Describe the first-strike problem in space conflict and why it creates incentives for preemptive counterspace action
• Explain Krepinevich's MTR vs. RMA distinction and apply it to the current state of U.S. space power
• Describe the two key concepts from PLA Science of Military Strategy 2013 (space deterrence by denial; counter-preemption) and their wargame design implications
• Name the primary counterspace actors and characterize each one's demonstrated capability set
• Explain why gray zone space activities are strategically significant and why they are harder to model than kinetic attacks
• Describe the Viasat KA-SAT hack and its strategic implications for how commercial space infrastructure is targeted in conflict
• Explain the PWSA/SDA Tranche architecture and the logic of deterrence by resilience through proliferation
• Describe the CASR framework and its market implications for commercial SDA products
• Name at least three allied/partner SSA frameworks and explain why the coalition dimension matters for SDA product positioning
• Describe Russia's four primary counterspace capabilities (Peresvet, Nudol, Tirada-2, Krasukha-4) and explain how Russia's strategic approach differs from China's
• Explain why Russian counterspace doctrine focuses on asymmetric degradation rather than parity-building, and what that implies for wargame action space design
• Explain why software-defined satellites create a cyber attack surface, and describe the supply chain attack model applied to satellite ground systems
• Explain the TLE data integrity problem and why it matters for ML-based maneuver detection pipelines operating in contested environments
• Describe the cyber-kinetic substitution logic: why cyber attacks on space infrastructure are attractive alternatives to kinetic counterspace for adversaries practicing calibrated escalation

Lesson 3: Historical Case Studies in Space Competition

Why cases matter in theory-building

The strategic frameworks in Lessons 1 and 2 are tools for thinking — useful precisely because they abstract away from particular events. But abstraction can become a liability when you need to explain to a government customer why your wargame design captures a real problem, or when you need to judge whether a strategic claim is supported by actual adversary behavior.

This lesson grounds the theory in three documented cases of space competition that span the full range of the counterspace taxonomy: a kinetic irreversible test, an extended co-orbital positioning campaign, and a cyber attack on commercial space infrastructure. Together they define what "space competition below the threshold of armed conflict" has actually looked like.

Case 1: The 2007 Chinese ASAT Test

On January 11, 2007, China used a ground-launched ballistic missile to destroy the Fengyun-1C weather satellite at approximately 865 km altitude. The satellite was defunct. The debris cloud was not.

The test generated over 2,000 tracked debris fragments and an estimated 150,000 fragments too small to track reliably. Fengyun-1C was in a sun-synchronous LEO orbit that intersects most of the heavily used commercial and government remote-sensing bands. More than a decade later, Fengyun-1C debris remains the single largest contributor to tracked debris in LEO.

The strategic signal: Carlson's Spacepower Ascendant calls it directly: "In 2007, in what was considered by many a shot across the US space bow, China tested an anti-satellite (ASAT) missile on one of its satellites, generating a debris cloud that still exists in orbit." Clayton Swope notes: "China's 2007 debris-generating test of a kinetic anti-satellite weapon was the first of two other tests of similar weapons." The test was not operationally necessary. No mission required destroying a defunct Chinese weather satellite. The purpose was demonstration: China is a space power that can reach your satellites.

The international response: The test drew widespread condemnation. NASA's administrator called it "inconsistent" with China's stated peaceful space activities. The UN Committee on the Peaceful Uses of Outer Space received formal objections. China's initial response was delay — weeks passed before Beijing officially acknowledged the test had occurred. This non-response response is itself a signal: China calculated that the international costs of the test were tolerable and that the strategic benefit of demonstrating counterspace capability outweighed them.

The stability implications: The test operationalized the stability-instability paradox (Lesson 2). By demonstrating it could attack LEO satellites, China signaled that U.S. space superiority was not uncontested — degrading U.S. confidence that space-enabled ISR and communications would be available throughout a conflict. The debris cost was borne globally; the strategic benefit accrued to China. This asymmetry is characteristic of kinetic irreversible counterspace attacks: the attacker absorbs a fraction of the operational cost while imposing shared degradation on the orbital environment.

Lessons for wargame design: A wargame action space that allows kinetic ASAT use must model debris creation as a shared cost that affects all players, not just the defender. The 2007 test shows that states are willing to accept shared debris costs for strategic signaling purposes — which means Kessler Syndrome is a deterrent of limited effectiveness against a state willing to accept shared orbital degradation for short-term strategic gain.

Case 2: Russia's Luch and Co-orbital Maneuvering Operations

Russia's Luch/Olympus satellite is one of the most documented examples of co-orbital intelligence collection and intimidation in the unclassified record. The Luch program began attracting international attention around 2014, when the satellite began executing maneuvers that placed it in proximity to communication satellites operated by Intelsat and other commercial GEO operators.

What Luch does: Jim Sciutto's reporting describes the operational behavior: "Kosmos 2499 performed several 'orbits' of the US satellite before firing its micro-thrusters to move on to its next target. From such distances, it could disable or destroy a US satellite." Luch (also designated Olympus and Kosmos 2456/2480 in different configurations) has been documented parking itself between GEO communication satellites — close enough for inspection, close enough for disruption.

The satellite has no publicly stated civilian mission. It has conducted proximity operations near satellites operated by Intelsat, SES, and other commercial GEO operators — including assets used to route U.S. military communications. Commercial satellite operators have tracked Luch's movements publicly; the activity has been described in congressional testimony as "battlefield preparation" for satellite disruption.

Cat-and-mouse in GEO: Andrew Jones documents the broader pattern: "U.S., Chinese and Russian satellites have increasingly engaged in 'cat and mouse' activities in GEO." A specific example: "Shiyan-12 (02)... made a close approach Sept. 11 to a U.S. missile early warning satellite, the Space Based Infrared System (SBIRS) GEO 6." The proximity operations are not accidental — SBIRS is a protected military system with enormous strategic significance. Approaching it is a signal about Chinese capability and intent.

The non-attribution problem: Unlike the 2007 ASAT test, co-orbital maneuvering is not attributable to hostile intent. A satellite parked near an Intelsat asset could be: conducting inspection to assess spacecraft health, testing proximity maneuvering technology for future commercial servicing, or gathering intelligence on military communications routing. None of these can be distinguished from the outside. This is the attribution problem (Lesson 2) in its most operationally relevant form.

Strategic value of ambiguity: The non-attributability is not incidental — it is the point. Russia gets the intelligence collection and intimidation value without providing a legal or diplomatic basis for a U.S. response. The U.S. can track Luch, can brief allies, can raise the issue in diplomatic channels. It cannot shoot it down under existing rules of engagement, cannot deter it by threatening attribution, and cannot compel Russia to stop through legal mechanisms because nothing Luch does violates the OST.

Lessons for wargame design: The Luch case is the direct operational analog of the conjunction-masking game in Module 8. The attacker maneuvers near a target, using the ambiguity of orbital mechanics to deniably threaten. The defender must allocate sensor resources to characterize the approach without an actionable response option if characterization comes too late. The wargame is not a hypothetical — it is a stylized version of an ongoing operational reality.

Case 3: The Viasat KA-SAT Hack (February 24, 2022)

On February 24, 2022, at approximately 05:00 UTC — roughly one hour before Russian ground forces crossed into Ukraine — Russian government hackers executed a cyberattack against the Viasat KA-SAT satellite communication network. The attack used malicious firmware that caused modems to become unresponsive, requiring physical replacement to restore service.

Klein's account: "An hour before Russian troops crossed the border, Russian government hackers conducted cyberattacks against the American satellite company Viasat... resulted in an immediate and significant loss of communication in the early days of the war for the Ukrainian military."

The immediate operational effect: Ukrainian military and government users who relied on KA-SAT for communications lost connectivity at the precise moment Russian forces were initiating the invasion. The timing was not coincidental — it was sequenced as part of the operational plan, disabling Ukrainian command-and-control exactly when it was most needed.

The unintended collateral effects: The attack disrupted more than its intended target. Wind energy operator Enercon, which operated 5,800 wind turbines in Germany using KA-SAT for remote monitoring and control, suddenly found its turbines incommunicado. Jones documents the cascade: "The attacks impacted 5,800 German wind turbines, rendering them unable to communicate because of issues with their satellite communication." This was not a satellite attack — this was a cyberattack on a ground network that propagated through a commercial satellite's modem firmware, creating operational effects in unrelated European civilian infrastructure.

What was and wasn't targeted: The attack targeted KA-SAT, a U.S.-owned commercial satellite. It was not a kinetic attack on a satellite in orbit — it was a cyber attack on a ground-based modem management system. The satellite itself was not affected. The attack demonstrates that the most vulnerable component of commercial space infrastructure is not the satellite — it is the ground segment and the distribution network connecting it to users.

Attribution and response: The attack was attributed to Russia's GRU by the United States, European Union, United Kingdom, Canada, Australia, and New Zealand (Five Eyes plus EU). The attribution was public and collective — an unusually fast and coordinated allied response. The Maguire assessment frames the broader implication: "As with the 2022 KA-SAT incident during the lead-up to Russia's invasion of Ukraine, this event highlights the persistence of cyber threats against commercial space infrastructure." The attack was not a one-time event — it is a template.

Strategic implications:

The KA-SAT hack is the clearest evidence that commercial space infrastructure is now a target in great-power conflict — not because adversaries wanted to attack a commercial company, but because commercial infrastructure had become the de facto military communications architecture of the defender. When the Ukrainian military uses the best available communications — and the best available communications is Viasat's commercial product — Viasat becomes a military target.

The hack also demonstrates the CASR problem: without established protocols, commercial operators have no playbook for responding to what is effectively a wartime attack on their infrastructure. SpaceX deployed Starlink faster and more flexibly because Elon Musk made unilateral decisions — not because a framework existed.

The pattern across all three cases

Reading these cases together reveals a consistent adversary playbook:

Demonstrate capability below thresholds that require response: The 2007 ASAT test destroyed a Chinese satellite, not a U.S. one. Luch maneuvers near commercial and military satellites but does not attack them. The KA-SAT hack was attributed but did not trigger a kinetic or space-based response. In each case, the action demonstrated capability and imposed costs while remaining below the threshold that would justify a direct military response.

Exploit legal ambiguity: Nothing in the 2007 test violated the OST. Luch's proximity operations are legal under existing space law. The KA-SAT hack was a cyber operation on commercial infrastructure — ambiguous enough that "act of war" determinations were avoided. Each operation was carefully calibrated to avoid providing a legal basis for a disproportionate response.

Use the civilian-military blur deliberately: Luch is a nominally dual-use satellite. KA-SAT was a commercial network. The gray zone between civilian and military operates as a buffer against response — the U.S. cannot shoot down a nominally civilian satellite and cannot claim an act of war against a commercial communications network without precedents it does not want to set.

Impose shared costs on the attacker's adversary: The Fengyun-1C debris cloud is shared. KA-SAT's German turbine failures were shared with the EU. The costs of counterspace operations do not fall only on the target state.

The behavioral detection requirement: All three cases had one thing in common: the pattern of behavior was discernible in the data before the action became irreversible — if you had the right detection capability. TLE anomalies preceded the 2007 test by preparation maneuvers. Luch's trajectory before each approach was visible in commercial tracking data. KA-SAT's ground system vulnerabilities were documentable in advance. The LSTM maneuver detection pipeline in Module 9 addresses the TLE-based detection problem; operational security posture for ground systems is out of scope. But the cases establish that early behavioral detection is the decisive variable — if you see the pattern in time, you create response options that close after the fact.

What you need to be able to do

After this lesson, you should be able to:

• Describe the 2007 Chinese ASAT test: what satellite was destroyed, what debris resulted, and what the strategic signal was
• Explain why the Fengyun-1C debris is considered strategically significant beyond its kinetic effects
• Describe the operational behavior of Russia's Luch satellite program and why it constitutes "battlefield preparation" rather than a legal violation
• Explain the attribution problem as illustrated by co-orbital maneuvering: why proximity operations cannot be characterized as hostile even when they are
• Describe the Viasat KA-SAT hack: timing relative to the Ukraine invasion, operational effect on Ukrainian military communications, and the German wind turbine collateral effect
• Explain the civilian-military boundary problem that the KA-SAT hack exposed and the CASR framework as a response
• Identify the common pattern across all three cases: capability demonstration below response thresholds, exploitation of legal ambiguity, use of civilian-military blur
• Connect the behavioral detection requirement to each case: what pattern in available data would have provided early warning, and how does this motivate the maneuver detection pipeline in Module 9

Lesson 4: Chinese Spacepower Theory and Gray Zone Competition

Start with the provocation

"The coming war with China will be fought for control of outer space. Although its effects will be widely felt, the conflict itself will not be visible to those looking up into the night sky. It will not be televised. Most will not even be aware it is occurring. It may already have begun."

— Everett Dolman, New Frontiers, Old Realities (2010)

Dolman wrote that fifteen years ago. Read the current Secure World Foundation assessment, or the U.S. Space Force Chief of Space Operations' public testimony, and the assessment has not changed — it has only become more urgent. US Space Command has acknowledged that American space infrastructure is under "low-threshold attack every day." Chinese and Russian forces conduct reconnaissance missions that senior Space Force leaders describe as "battlefield prep" activities.

The war Dolman described as possibly already begun is not a war of kinetic antisatellite weapons — not yet. It is a war of positioning, norming, blurring, and probing. To understand what that means operationally, you need to understand how China thinks about space competition. That is what this lesson covers.

The foundational doctrine: informationized warfare

China's military theory for the past two decades has been organized around the concept of "local wars under informatized conditions" — a phrase attributed to Hu Jintao and formalized in PLA training doctrine. The central argument: the future of military competition is not about who has more tanks or bombers, but about who can gather, convey, analyze, and act on information faster than the adversary.

Space is the foundation of informatized warfare. Satellites provide the reconnaissance, navigation, timing, and communications that enable precision strike, coordinated operations, and real-time battlefield management. A military that can see and a military that is blind are not fighting the same war.

The implication for Chinese strategy is straightforward: attack space first. Degrade the adversary's ability to see, navigate, and coordinate before kinetic conflict begins, and the kinetic phase — if it happens at all — will be conducted against a disoriented, poorly coordinated force. The Science of Military Strategy (2013) is explicit that space and cyber operations are primary components of the campaign to establish information dominance before armed conflict.

This is why Chinese space strategy cannot be understood as simply an effort to match U.S. capabilities satellite-for-satellite. It is a campaign to erode U.S. information advantages in the event of a conflict, conducted below the threshold of armed conflict, over years and decades.

Unrestricted warfare: the theoretical framework

Qiao Liang and Wang Xiangsui's Unrestricted Warfare (1999) is not an official PLA doctrinal document. It is better understood as a theoretical provocation — two PLA colonels arguing that the United States' overwhelming conventional military superiority had forced China to think asymmetrically.

Their central argument:

"Warfare which transcends all boundaries and limits, in short: unrestricted warfare. If this name becomes established, this kind of war means that all means will be in readiness, that information will be omnipresent, and the battlefield will be everywhere. It means that all weapons and technology can be superimposed at will, it means that all the boundaries lying between the two worlds of war and non-war, of military and non-military, will be totally destroyed."

Unrestricted Warfare enumerates the tools: psychological warfare, media warfare, drug warfare, network warfare, technological warfare, legal warfare, economic aid warfare, cultural warfare. Space is treated as part of the "network space" that enables all other forms of warfare. The relevant implication for your curriculum: Chinese strategic thinking does not distinguish between military space operations and other forms of competition the way U.S. doctrine does. A Chinese commercial satellite company providing imagery to a third party in a conflict zone is not a civilian actor doing a commercial thing — it is a component of an integrated competitive strategy. (This happened: Chinese commercial satellite imagery companies were sanctioned by the United States for providing satellite imagery and assistance to the Wagner Group during Russia's war in Ukraine.)

Wargame relevance: A wargame that models Chinese actions as only military actions misses most of what Chinese strategy actually involves. The action space for a Chinese player in a realistic orbital competition game includes legal maneuvering, commercial positioning, norm-shaping, and economic dependency creation — not just ASAT deployment.

The Three Warfares

The PLA's "Three Warfares" doctrine formalizes three non-kinetic competition modes that operate continuously — in peacetime, crisis, and war:

Legal warfare (法律战): Using international law and legal arguments as a competitive tool. The goal is to constrain adversary action through legal claims while preserving maximum Chinese freedom of maneuver. China's near-space claim is a direct application: PLA writing since 2011 has argued that airspace between 20 km and 100 km altitude is a "legal blank that needs to be filled urgently" — and that China should define what norms apply there before the United States does. If China successfully establishes near-space as a legally cognizable zone with its own rules, it gains the ability to contest U.S. access to that altitude band on legal grounds.

The South China Sea islands analogy is instructive: China built islands, declared them territorial, and then argued that challenging their status was a violation of Chinese sovereignty. The analogous play in space is to establish presence, declare legal norms that legitimize that presence, and then argue that adversary response is the illegal act.

Psychological warfare (心理战): Shaping adversary decision-maker perceptions and will. In space, this includes demonstrating counterspace capabilities (ASAT tests, co-orbital maneuvers near adversary satellites, proximity operations) to signal that U.S. space assets are vulnerable — without actually attacking them. The goal is to induce risk aversion in U.S. planning: if planners believe their satellites are vulnerable, they may pull back from operations that depend on space assets, even without an actual attack.

Public opinion warfare (舆论战): Shaping the international narrative about the legitimacy of each side's space activities. China's advocacy for the Prevention of the Placement of Weapons in Outer Space (PPWT) treaty — while simultaneously developing ASAT capabilities — is public opinion warfare: it positions China as the responsible party and the United States as the obstacle to arms control. As Carlson's Spacepower Ascendant notes bluntly: "their charade of good will is nothing more than a brazen act of lawfare; an attempt to trick the West into agreeing to forego defending our space systems upon which our militaries, economic centers, and information driven societies depend."

Civilian-military blur: no private space sector in China

No nation-state has mastered the blending of commercial and military space operations as thoroughly as China. Chinese space agencies have a "proven record of space-based achievements" — and these agencies blur the line between civilian and military operations in ways that have no U.S. equivalent.

In the United States, SpaceX is a private company. It can choose to provide or withhold service. It is accountable to shareholders, not the PLA. In China, the distinction between civilian and commercial space companies and the military is legally thin and politically nearly nonexistent. Any capability the Chinese civilian space sector has could be militarized on short notice.

Specific examples:

Guowang / Qianfan (Thousand Sails) constellations: China is constructing LEO megaconstellations that are direct counterparts to Starlink. China's central government has identified commercial space as "of key strategic value." These constellations serve commercial purposes — broadband, direct-to-device connectivity — and also provide PLA with organic communications and ISR capacity that does not depend on government-owned satellites.

Commercial imaging: Chinese commercial satellite imagery companies now produce high-resolution imagery competitive with U.S. commercial providers. The sanctioned companies that provided imagery to Wagner Group in Ukraine were operating as commercial entities. The dual-use nature is not incidental — it is architectural.

Reusable launch vehicles: China's private companies are developing reusable launch vehicles similar to SpaceX's. The U.S. Space Force has raised concerns about this capability as a space security issue — reusable launch enables rapid replenishment of satellite constellations after conflict, changing the deterrence calculus.

ITU filings as orbital positioning warfare

The International Telecommunication Union (ITU) coordinates radio frequency spectrum and orbital slot assignments globally. For geostationary orbit, specific longitudinal positions are assigned to specific national operators. For non-geostationary orbits (LEO, MEO), the principle is "first-come, first-served": file a network with specific parameters, complete required coordination with potentially affected operators, then launch within the deadline to "bring the network into use" and establish priority.

China has used this administrative system with the same strategic intentionality it applies to near-space legal claims and South China Sea island-building.

The filing scale: China's state-owned Guowang constellation has filed with the ITU for 12,992 satellites. The Qianfan (Thousand Sails) constellation has filed for an additional 13,000+ satellites. Together, these filings stake claims to a large fraction of the most commercially valuable LEO frequency bands and altitude shells — particularly the 1,200 km shell where low latency and broad coverage intersect, the same shell where Starlink operates. Both SpaceX and Chinese operators have filed active adversarial coordination requests against each other at the ITU — formal legal proceedings that will determine who operates at scale in contested bands.

The reservation-before-use strategy: ITU filings are public records. China has filed satellite networks under names that don't correspond to known operational programs — essentially reserving spectrum and orbital capacity against future deployment. The ITU's "bring into use" deadline requires launching some satellites to establish priority, but does not require launching the full constellation. A few launched satellites locks the filing for the rest. This is a bureaucratic positional strategy: claim the orbital capacity before competitors can, at far lower cost than actually deploying the constellation.

Why this is Three Warfares applied to orbital infrastructure: No weapons. No OST violations. No diplomatic controversy comparable to an ASAT test. Just the aggressive, early use of an international administrative process to pre-empt competitor access to orbital resources. The legal warfare dimension is direct: by filing first, China can object to competitors' subsequent filings as "interfering with prior-coordinated networks" — turning its own filing position into a legal basis for blocking U.S. commercial constellation expansion.

The South China Sea analogy is exact: occupy the territory and establish legal claims before the international community can coordinate a norm against it. The Spratly Island chain and the ITU filing ledger are different in medium but identical in strategic logic.

The spectrum scarcity constraint: Unlike terrestrial land, the orbital environment is genuinely scarce in specific ways. The most valuable communication frequencies (Ka-band, Ku-band, V-band) have finite capacity in a given orbital shell — too many satellites in the same band at similar altitudes create interference. ITU coordination is the mechanism for managing that scarcity. A state that aggressively preempts those bands through early filing constrains what future operators (including U.S. commercial and military operators) can do in those bands without coordination agreement from the prior filer — which China can withhold.

Implication for wargame design: A wargame of orbital competition that only models kinetic and electronic counterspace misses the ITU-filing vector entirely. The action space for a realistic Chinese player includes administrative actions — filing, coordination objection, delayed coordination response — that achieve positional advantage without any observable orbital behavior. These actions are invisible to SSA sensors and produce no TLE signatures. They are, however, detectable in public ITU filing records. A commercial SDA product that monitors ITU filing activity alongside TLE history provides a more complete picture of adversary orbital strategy than one that monitors only observable orbital behavior.

The gray zone wargame: what China actually does

Dugger's "Space as a Gray Zone" (2024) describes a wargame involving senior DoD, State Department, NASA, and intelligence officials. The findings are instructive:

"Role-players acting as China were able to present the United States and her allies with a problem for which there failed to materialize an actionable solution — by quietly positioning civilian spacecraft onto orbital trajectories that could threaten US military position, navigation, and timing or communications satellites. They were then able to reinforce their own positions by quickly launching low-cost and disposable bodyguard satellites to protect their own assets from being threatened in retaliation."

Several things about this wargame outcome are worth unpacking.

Civilian spacecraft: The threatening assets are commercial or civilian in designation. Responding to them militarily requires the U.S. to either accept the threat or take action against a "civilian" spacecraft — triggering the international law and public opinion warfare dimensions simultaneously.

Disposable bodyguard satellites: Low-cost satellites that can absorb an attack, protecting the valuable asset while generating debris. This makes the U.S. response to the threatening satellite more costly and creates a debris problem that damages the U.S. as well.

No actionable solution materialized: This is the key finding. The wargame was played by senior officials. They could not find a response to China's positioning strategy. The gray zone worked.

The implication is direct: the problem your ML models are addressing — detecting anomalous maneuvers, attributing behavior, classifying intent — is the decisive competitive problem in this gray zone environment. The United States and its allies need to see the game before it ends. That requires behavioral detection and attribution capabilities that do not currently exist at the speed and scale that orbital operations demand.

Hal Brands on the structure of the competition

Hal Brands (Lessons From the New Cold War, 2024) synthesizes the U.S.-China competition with observations that directly affect how you frame the wargaming problem.

The rivalry is about coalitions: "The US-China rivalry is about coalition-making and coalition-breaking, and the outcome is too much in doubt." In space, this means the competitive landscape is not U.S. vs. China — it is U.S. + allies vs. China + partners, with a set of neutral/swayable states whose alignment affects access to launch infrastructure, orbital slots, and international norms.

There is no grand bargain: "Outside analysts, and some government officials, have periodically proposed purchasing Sino-American peace by trading Taiwan or the South China Sea away. They might as well save their energy." Applied to space: there is no negotiated arms control agreement that resolves the competition. The OST is already the existing framework and it does not prevent any of the capabilities China has developed. Space competition will continue regardless of diplomatic initiatives.

China's overreach creates coalition opportunities: Brands notes that "its autocratic ambition and aggression were driving potential victims together." In space terms: Chinese behavior (ASAT tests, proximity operations to allies' satellites, imagery for Wagner Group) has driven allied space cooperation — the Five Eyes SSA sharing agreements, NATO Space COE, allied ISR coordination — that would not otherwise exist. Chinese gray zone operations create their own deterrent by making the coalition case for allied space cooperation.

This is not the Cold War: "One world" is no longer possible. The infrastructure, economic relationships, and technological dependencies are deeply intertwined in ways the U.S.-Soviet competition was not. Chinese commercial space companies serve Western customers. U.S. chip manufacturers depend on Chinese raw materials. The competition takes place inside a web of economic interdependence that makes the "unrestricted warfare" framework more, not less, applicable — because the economic and commercial dimensions are genuine vectors of competition.

The South China Sea as strategic template

Carlson's Spacepower Ascendant draws the South China Sea analogy explicitly:

"If space is viewed by China the same way that it sees those islands, then cooperation cannot occur since the Chinese government cannot be trusted to act in good faith."

The SCS pattern is: assert presence, build infrastructure that encodes legal claims, deploy military capabilities under civilian cover, and then argue that any response is destabilizing. The islands were described as for "peaceful purposes" before they became military air bases with anti-air and anti-ship missiles.

The analogous space pattern: China's Shijian co-orbital inspection satellites are described as for on-orbit servicing research. The Guowang constellation is described as commercial broadband. The near-space altitude claim is framed as filling a legal vacuum for peaceful uses.

Klein's Fight for the Final Frontier generalizes the point: "Historical experience should teach policy makers and strategists that a less-capable power's space strategy is likely to be indirect and cumulative." The South China Sea was won incrementally, through fait accompli after fait accompli, none of which individually rose to the level requiring a U.S. military response. The cumulative effect was a Chinese-controlled sea lane.

The question for your thesis: can ML-enabled behavioral detection move fast enough to identify the pattern before the cumulative fait accompli is complete?

Wargame design implications

A wargame designed to explore U.S.-China orbital competition must capture several features that standard two-player zero-sum games miss:

The civilian ambiguity problem: Chinese assets are not cleanly military or civilian. A game that forces a binary "military/civilian" classification misses the strategic value of ambiguity. You need to model assets with uncertain status and defender rules of engagement that reflect the real decision: how much proof of hostile intent is required before action?

The long game: Chinese strategy is cumulative and indirect. A game with a fixed short time horizon misses the dynamics of gradual positioning. The CFR solver finds equilibria for a fixed game structure — the strategic problem of defining the game structure to capture long-horizon cumulative strategy is a design challenge that precedes the algorithm.

The coalition dimension: A multi-player game (U.S., China, allies, neutral commercial operators) captures the coalition dynamics that matter. PSRO (Module 6) is the right tool for this — it handles heterogeneous actor populations better than two-player Nash equilibrium.

The Three Warfares as action space: Legal, psychological, and public opinion actions should be in the action space alongside kinetic and electronic counterspace. This expands the game dramatically but reflects the actual competition.

What you need to be able to do

After this lesson, you should be able to:

• Explain the PLA concept of "informationized warfare" and why space is foundational to it
• Describe the three components of Qiao Liang's Unrestricted Warfare argument and explain how they apply to space competition
• Name the Three Warfares (legal, psychological, public opinion) and give a specific space domain example of each
• Explain the civilian-military blur in Chinese space operations and why it creates strategic problems for the U.S.
• Describe what the gray zone wargame (Dugger 2024) found and why it matters for behavioral detection requirements
• Apply the South China Sea template to Chinese space strategy: what does fait accompli look like in the orbital domain?
• Explain Brands' coalition dynamics argument and its implication for how to structure a multi-actor space competition wargame
• Explain how ITU megaconstellation filings function as orbital positioning warfare and why this vector is invisible to SSA sensors but detectable in public records
• Describe the spectrum scarcity constraint and why pre-emptive ITU filing creates a legal basis for blocking competitor operations in contested bands

Lesson 5: Escalation Dynamics, Crisis Stability, and the ML Deterrence Framework

The scenario that should keep you up at night

"In a world without the verification protocols once provided by New START, a commercial maneuver near a nuclear command-and-control node could be misinterpreted as a prelude to a strike, creating a hair-trigger environment where a technical error or a pilot's misjudgment becomes an existential threat."

— "The Ghost in the Orbit: How Hybrid Surveillance Reshapes Risks"

This is not a hypothetical future scenario. It describes the current orbital environment. The New START treaty lapsed in 2026 without renewal. Commercial satellites from multiple countries now operate in GEO near U.S. and Russian early warning and nuclear command-and-control satellites. There is no verification protocol, no hotline for orbital incidents, no agreed definition of what constitutes a threatening approach. And as the research on SDA ML consistently shows, behavioral attribution from kinematics alone — the only tool most SDA pipelines have — cannot reliably distinguish station-keeping from a pre-attack approach until it is too late to matter.

This lesson is about why that problem is so hard, what strategic frameworks illuminate it, and how ML-enabled behavioral transparency might contribute to solving it. This is the theoretical foundation for a specific thesis claim: that sufficiently capable, rapidly deployed SDA ML systems could contribute to strategic stability by making orbital aggression more detectable and therefore more costly.

What escalation means in the space domain

Herman Kahn's escalation ladder (1965) described nuclear conflict as a series of rungs — each escalation step communicates seriousness of intent and raises the cost of the conflict for both parties. The ladder serves two functions: it provides a framework for signaling, and it provides decision-makers with options between "do nothing" and "all-out war."

Space conflict has an analogous structure, but with several features that make the ladder harder to manage:

Low threshold for strategic effects: Destroying or disabling GPS, nuclear early warning satellites, or protected military communications satellites has immediate strategic-level consequences — not tactical ones. There is almost no "limited" kinetic attack on space infrastructure. The ladder's rungs are compressed: you go from "jamming a tactical communications link" to "threatening nuclear command and control" in a small number of steps.

Attribution problem compresses decision time: On the ground, you generally know when you have been attacked and by whom within minutes to hours. In space, a satellite that stops functioning may have been attacked, failed due to a component defect, been hit by natural debris, or suffered cyber intrusion. Attribution takes days to weeks — if it happens at all. Decision-makers must either wait for attribution (losing response windows) or act without it (risking escalation based on incorrect attribution).

"Satellites don't have mothers": Klein's Fight for the Final Frontier identifies this phrase as a critical problem in space conflict threshold analysis. The implication: actions against satellites are perceived as less severe than equivalent attacks against ground forces or civilian infrastructure, precisely because the cost is abstract and the systems are unmanned. This lowers the threshold for attacks that adversaries calculate will not trigger a full response — but the actual strategic effect of the attack may be enormous.

No precedent, no norms: As Mitchell noted: "space is treated very differently across different nations and until we reach some type of almost unanimous agreement on what can be done in space, we are going to have those who treat it as a Wild Wild West." The absence of agreed norms means that every actor is simultaneously setting and testing the norms — creating uncertainty about where red lines actually are.

Russian escalation management: calibrated escalation as cost imposition

Anya Fink's analysis of Russian strategic deterrence doctrine provides a model that differs fundamentally from U.S. deterrence theory and that applies to the space domain in important ways.

The Russian concept of "strategic deterrence" is not primarily about nuclear weapons — it is a "holistic Russian national security concept for managing escalation, and containing adversaries in peacetime, by integrating military and nonmilitary means." The operating mechanism is calibrated escalation: communicating to an adversary that the Russian military can inflict progressively higher costs while lowering expected gains, signaling the need to forgo aggression, de-escalate, or terminate the conflict.

Russian strategic culture has "a strong predilection for cost imposition (rather than denial of benefits)." In U.S. deterrence theory, the primary logic is denial — make it impossible for the adversary to achieve their objectives. In Russian theory, the primary logic is cost imposition — make achieving objectives so painful that rational adversaries stop. The distinction matters for space because:

• Denial in space requires resilient architecture: proliferated constellations, redundancy, backup systems. This is the U.S. deterrence-by-resilience approach.
• Cost imposition in space requires counterspace capabilities that can credibly threaten adversary assets. This is the Russian/Chinese approach: demonstrate that U.S. space assets are vulnerable, raising the cost of U.S. military operations.

For calibrated escalation to work, both sides need to understand the escalation ladder — to know what each step costs and what each response means. The absence of agreed norms in space means calibrated escalation operates without the shared understanding of thresholds that makes it work. An adversary may intend a limited cost-imposition signal; the receiver may interpret it as an attack that demands a response at a higher rung. This is the miscalculation problem.

The six deterrence dilemmas (Brands and Cooper)

Hal Brands and Zack Cooper's "Dilemmas of Deterrence" (CSIS, 2024) identifies six trade-offs in U.S. deterrence strategy that have direct application to space. The deterrence strategies that are strong on one dimension tend to be weak on another:

Deterrence vs. reassurance: Actions that strengthen deterrence (visible force deployments, capability demonstrations) may alarm allies or signal hostility to the adversary, reducing crisis stability. In space, demonstrating offensive counterspace capabilities deters adversary attacks but may trigger preemptive action from an adversary who fears being disarmed.

Deterrence vs. de-escalation: Credible deterrent threats require maintaining escalation options, but maintaining escalation options makes de-escalation harder because actors are committed to response options that are difficult to step back from. A U.S. declaratory policy that defines specific red lines in space makes threats credible but constrains flexibility when adversaries probe those red lines from ambiguous positions.

Symmetric vs. asymmetric deterrence: Deterring space attacks by threatening equivalent space attacks (symmetric deterrence) is expensive and requires matching adversary capabilities. Deterring space attacks by threatening asymmetric responses (economic sanctions, conventional strikes on ground infrastructure) may be more credible but escalates horizontally — introducing new domains into the conflict.

Deterrence by denial vs. deterrence by punishment: Denial requires investing in resilient architecture; punishment requires offensive capabilities. Both are expensive; the right balance depends on assumptions about adversary risk tolerance that are difficult to verify.

Short-run deterrence vs. long-run competition: Deterring immediate attacks may require reassurances that constrain long-run competition. Maintaining maximum competitive pressure in the long run may undermine short-run deterrence by inducing adversary perception of U.S. hostility.

Unilateral vs. coalition deterrence: Unilateral deterrence is controllable but limited in scope; coalition deterrence is more powerful but depends on allied cohesion that adversaries will actively try to undermine.

None of these dilemmas has a clean solution. The contribution of ML-based behavioral analysis is not to resolve them — it is to provide better information for decision-makers navigating them. If you can characterize an adversary maneuver as consistent with a preparation-for-attack pattern rather than station-keeping, you provide evidence that informs where on the deterrence-reassurance trade-off the current situation sits.

ISR blinding as an escalation accelerant

Todd Harrison's research on battle networks makes a counterintuitive point that is critical for understanding the space escalation problem:

"Blinding an opponent's intelligence, surveillance, and reconnaissance (ISR) or severing command and control links among its forces during a crisis could increase the odds of miscalculation and escalation if adversary forces begin acting without accurate information. Moreover, without adequate situational awareness, an opponent may not be able to detect signs of de-escalation or could confuse benign or defensive actions with offensive or escalatory behavior."

The intuitive argument for counterspace operations at the start of a conflict is: degrade the adversary's ISR first, so they can't see your forces. Harrison's argument flips this: if you blind the adversary's ISR, they don't know where your forces are, they don't know what's happening, and they are more likely to mistake defensive actions for offensive ones — escalating on the basis of confusion rather than actual threat.

This has a direct implication for what stable deterrence in space looks like: mutual ISR capability is stabilizing, not destabilizing. If both sides can see each other, they can detect de-escalation signals, verify that threatening actions are not occurring, and avoid the miscalculation that Harrison describes. The first-strike incentive to degrade adversary ISR is real but it trades short-term tactical advantage for increased long-term escalation risk.

This is the theoretical foundation for the thesis argument this curriculum is building toward: SDA ML capabilities that give both sides better visibility into orbital behavior are stabilizing. A world in which China knows that U.S. SDA AI can detect and attribute its gray zone orbital maneuvers is a world in which those maneuvers are more costly and therefore less likely to be executed.

The crisis communication problem

Kurt Campbell's "The U.S.-China Crisis Waiting to Happen" identifies a specific structural problem in U.S.-China deterrence that compounds all of the above:

"The two great powers of the twenty-first century must create channels of crisis communication."

Unlike the U.S.-Soviet relationship, which developed a crisis communication infrastructure over decades (hotline, incident-at-sea agreements, arms control verification protocols), the U.S.-China relationship has invested little in this infrastructure. Chinese strategists have actively avoided it: "Beijing seems to see it as a benefit. While Washington generally opts to telegraph its military acumen, in the hope that its strength gives its adversaries pause, Beijing largely elects to foster uncertainty in its deployments, diplomacy, and doctrine — hoping that it increases U.S. forces' anxiety about operating in proximity."

Applied to space: China's deliberate opacity about its orbital activities — what its co-orbital inspection satellites are doing, what its near-space vehicles are testing, what targets its ground-based lasers are calibrated against — is a strategic choice, not a transparency failure. The opacity serves Chinese deterrence by denial (you can't prevent what you can't see coming) and Chinese deterrence by punishment (you can't be confident our ASAT won't work because you don't know how it works).

The absence of crisis communication channels means that even minor orbital incidents — a close approach that triggers automated collision avoidance, a temporary loss of satellite signal, a maneuver pattern that is ambiguous to SDA sensors — can generate a perception of hostile action without any channel for rapid de-escalation.

The space escalation ladder: rungs, firebreaks, and historical thresholds

Herman Kahn's original escalation ladder (1965) had 44 rungs between "subcrisis maneuvering" and "spasm war." No equivalent framework exists for space — the field is too young and operational experience too limited. But the cases in Lesson 3 and the strategic frameworks above allow us to sketch the rungs that matter, and more importantly, to identify where the firebreaks are.

The rungs as they have been operationalized:

Rung 1 — Peacetime competitive positioning: Co-orbital inspection and proximity operations (Luch at GEO). Satellite constellation buildout for dual-use ISR. Near-space legal claiming. ASAT test against own satellites. All of these have happened. None triggered military response. The threshold from Rung 1 to Rung 2 is currently well below what Western powers have treated as actionable.

Rung 2 — Gray zone operations below attribution threshold: Jamming over a theater of operations (Russia has done this in Ukraine and Syria). Spoofing GPS in contested areas (Iran, Russia, various actors in Eastern Mediterranean). Deniable proximity operations to commercial or dual-use satellites. Limited cyber probes of satellite ground infrastructure. These have happened. Responses have been diplomatic, not military.

Rung 3 — Attributable but reversible counterspace attack: An unambiguously hostile electronic attack on a military communication or ISR satellite — jammed, spoofed, or temporarily disabled. This has not been confirmed in the public record as a deliberate hostile act (the line between Rung 2 and Rung 3 is blurry). The Viasat hack is close to Rung 3 but against commercial infrastructure and attributed after the fact rather than in real time.

Rung 4 — Coercive positioning / threat of irreversible attack: Maneuvering a co-orbital vehicle to within intercept proximity of a high-value military satellite (nuclear early warning, nuclear command-and-control relay). This is "Luch near a nuclear asset" — qualitatively different from commercial intelligence collection. The "Ghost in the Orbit" quote from the lesson opening is about this rung. No public confirmation that this has occurred against nuclear assets specifically.

Rung 5 — Irreversible non-kinetic counterspace attack: High-power laser permanently blinding a military reconnaissance satellite's sensors. Cyber attack that permanently disables satellite bus control (bricking). These would be irreversible acts of war against military assets. They have not occurred in the public record.

Rung 6 — Kinetic counterspace against military assets: Direct-ascent or co-orbital ASAT strike against an adversary military satellite. This is the first unambiguous act of war in the space domain. It has not happened between great powers. India's 2019 test was against its own satellite. The 2021 Russian NUDOL test was against its own satellite.

Rung 7 — Debris-generating attacks / Kessler trigger: Kinetic attacks at LEO densities sufficient to start a cascade. This is essentially nuclear deterrence applied to the orbital environment — both sides lose access to the orbital bands affected. Not happened. Kessler deters this rung specifically.

Rung 8 — Attacks on nuclear C2 space assets: Attacking early warning satellites, nuclear relay satellites, or GPS in a way that degrades confidence in nuclear command-and-control. This is the rung that compresses the escalation ladder to near-nuclear. Current space architecture places nuclear C2 assets in heavily trafficked orbital regimes without clear firebreaks from conventional counterspace attacks.

The key firebreaks:

The transition from Rung 2 to Rung 3 is the first firebreak — the line between deniable harassment and attributed hostile action. Everything in Rungs 1 and 2 has happened without military response. Nothing in Rungs 3–8 has happened between great powers.

The transition from Rung 5 to Rung 6 is the second firebreak — the line between non-kinetic and kinetic attack on military assets. Kinetic attack on a military satellite is universally recognized as an act of war; this provides deterrent pressure that non-kinetic attacks do not trigger.

The transition from Rung 6 to Rung 8 is the most dangerous transition: once kinetic attacks on military satellites begin, the compressed nature of the ladder (from "conventional military satellite" to "nuclear C2 satellite" in a small number of steps) means escalation to nuclear-relevant effects may be rapid and uncontrolled.

Harrison's ISR blinding finding locates the critical instability: ISR blinding attacks are likely to happen at Rungs 2–3, before kinetic conflict, intended as preparation. But the effect of ISR blinding at those rungs may be to trigger Rung 4–6 responses from a blinded adversary who cannot distinguish blinding-for-invasion from blinding-for-nuclear-strike. The firebreaks don't hold if the blinded party can't see them.

Implication for the ML deterrence thesis: The deterrence framework requires behavioral visibility that allows decision-makers to identify which rung they're on before they respond at the wrong level. A defender who cannot distinguish Rung 2 from Rung 4 will either underrespond (leaving gray zone operations unopposed) or overrespond (escalating to Rung 6 in response to a Rung 2 action). ML-enabled behavioral attribution provides the rung-identification capability that the compressed space escalation ladder requires.

Space law and norms: the existing framework and its limits

The 1967 Outer Space Treaty (OST) is the foundational document of international space law. Its core provisions:

• Space is the "province of all mankind" — res communis (no state can claim sovereignty)
• States may not place nuclear weapons or other WMD in orbit, on celestial bodies, or in space
• The Moon and other celestial bodies shall be used for peaceful purposes only
• States are liable for damage caused by their space objects
• States shall register space objects with the UN

The OST has been ratified by the spacefaring nations. Its limits are equally important:

WMD ban ≠ weapons ban: The treaty prohibits nuclear weapons and WMD in orbit. It does not prohibit conventional weapons, anti-satellite systems, electronic warfare, cyber attacks on satellites, or co-orbital inspection vehicles. Everything in the counterspace taxonomy from Lesson 2 is technically legal under the OST.

"Peaceful purposes" is contested: The United States has always interpreted "peaceful" to mean "non-aggressive," permitting military reconnaissance satellites and eventually military space operations. The Soviet Union initially argued for "non-military," but this position could not survive the reality that both superpowers needed reconnaissance satellites to verify arms control. The U.S. interpretation prevailed.

No verification mechanism: The OST has no inspection regime, no verification protocol, and no enforcement mechanism beyond the liability provisions and political pressure. China can conduct proximity operations near U.S. satellites, develop ground-based lasers, and test co-orbital vehicles without violating the OST.

The Liability Convention (1972): States are absolutely liable for damage caused by their space objects in non-orbit phases (launch), and at fault for damage in orbit. The Cosmos 954 incident (Soviet nuclear-powered satellite crashing in Canada, 1978) was resolved under this convention — the Soviet Union paid. But the liability regime only applies to physical damage, not to espionage, signal interference, or orbital intimidation.

Emerging responsible behavior norms: The United States adopted a unilateral moratorium on debris-generating ASAT tests in 2022. Canada and others have followed. This is not legally binding, but it establishes a norm that debris-generating tests are irresponsible. China and Russia have not adopted the moratorium — Russia conducted a debris-generating test in 2021, the year before the U.S. moratorium. The norm is real but unevenly observed.

The SCP instructs U.S. Space Force to "make every effort to promote responsible norms of behavior that perpetuate space as a safe and open environment in accordance with the Laws of Armed Conflict, the Outer Space Treaty, and international law." The tension: the OST and current international law permit most of what China is doing in the gray zone. Promoting "responsible norms" requires creating new norms that go beyond the existing legal framework — which requires international agreement that the adversaries have little incentive to reach.

Competing frameworks: Artemis Accords vs. PPWT

Two competing international frameworks are now contending to define the next layer of space governance — and the competition between them is itself an instance of legal warfare (Lesson 4's Three Warfares concept applies here directly).

The Artemis Accords (2020) are bilateral agreements initiated by the United States alongside the Artemis lunar program. They are not a multilateral treaty ratified through the UN — they are bilateral commitments that each country makes with the United States. More than 50 nations have signed as of 2025, including the UK, Japan, Australia, Canada, France, Germany, South Korea, UAE, and Ukraine. China and Russia have not signed and have publicly criticized the framework.

The Accords cover: transparency in space activities, interoperability of space systems, registration of space objects, release of scientific data, preservation of outer space heritage, deconfliction of space activities through "safety zones," and responsible orbital debris management. None of these provisions address counterspace weapons directly — the Accords are explicitly about civil and commercial space activity, not military competition.

The strategic function of the Accords is not primarily legal. It is coalition-building. By getting 50+ nations to endorse a U.S.-drafted norm framework, the U.S. establishes a "responsible spacefaring" standard that China and Russia are excluded from — making their orbital behavior appear as norm violations even where it doesn't technically violate the OST. The Artemis Accords are the legal warfare analog of the Artemis program itself: both build U.S.-led coalition architecture while systematically excluding China and Russia from the emerging governance framework.

The Chinese and Russian objection focuses on the "safety zones" provision, which they argue creates de facto territorial claims on lunar surface resources, violating the OST's non-appropriation principle. The U.S. position: safety zones are temporary operational areas, not territorial claims. This dispute mirrors the South China Sea dispute almost exactly — both sides are using legal language to assert positions whose real content is strategic.

The Prevention of the Placement of Weapons in Outer Space (PPWT) is a treaty proposal introduced by Russia and China at the UN Conference on Disarmament in 2008 and updated in 2014. It would prohibit placing weapons in space, using force against space objects, and threatening space objects.

The United States has consistently rejected PPWT on three grounds:

Unverifiable: The PPWT has no inspection or verification regime. Without on-site inspection or agreed monitoring protocols, compliance cannot be confirmed — which means the treaty constrains parties who comply and is irrelevant to those who don't.

Preserves ground-based ASAT advantage: PPWT prohibits weapons in space but explicitly does not prohibit ground-based ASAT systems. Russia (Nudol) and China (DN-3) have demonstrated their most capable counterspace weapons as ground-based interceptors. PPWT would constrain any future U.S. space-based interceptor capability while leaving the ground-based capabilities that have already been tested intact.

Legal warfare by other means: Carlson's assessment is direct: "their charade of good will is nothing more than a brazen act of lawfare; an attempt to trick the West into agreeing to forego defending our space systems upon which our militaries, economic centers, and information driven societies depend." PPWT positions Russia and China as advocates for arms control while preserving the asymmetric counterspace advantages they have already built.

The normative competition as strategic contest: Neither the Artemis Accords nor PPWT will create binding, verified arms control for space. The strategic value of each framework is reputational and coalitional — whichever norm regime achieves broader international acceptance makes the other side's behavior appear irresponsible, constraining it through diplomatic and economic costs rather than legal enforcement. This is the Three Warfares applied to the governance layer: the battle for the normative framework of space is itself a domain of competition.

Kessler Syndrome as structural deterrent — and its limits

The Kessler Syndrome (Donald Kessler, 1978) describes the cascade scenario: a debris-generating collision creates fragments that collide with other objects, generating more debris, until certain orbital altitude bands become operationally unusable. The scenario is "no longer a theoretical risk, but a real possibility" — particularly in certain LEO altitude bands where Starlink and other megaconstellations operate.

Kessler Syndrome functions as a partial structural deterrent against debris-generating kinetic attacks. An adversary who destroys a Starlink satellite in LEO generates debris that threatens their own satellites. If the cascade is significant enough, it threatens the orbital environment for everyone — including the attacker — for decades.

This deterrent is real but incomplete:

Altitude-specific: Kinetic attacks at higher altitudes (MEO, GEO) generate debris that persists much longer but is more diffuse. The Kessler cascade risk is highest in densely populated LEO bands. A kinetic attack in a less populated orbital regime has lower Kessler risk.

Time horizon dependent: A state willing to accept orbital degradation for tactical advantage in a short conflict — perhaps because it calculates the conflict will be brief and the political outcome will be achieved before the cascade develops — is not deterred by long-run Kessler consequences.

Irreversibility is not symmetric: Developed space powers with large commercial constellations have more to lose from orbital degradation than states with smaller commercial space sectors. China and Russia's space dependence is real but their calculation about acceptable Kessler risk may differ from the U.S. calculation.

The Kessler constraint is why Chinese counterspace strategy emphasizes non-kinetic reversible effects (jamming, spoofing, cyber, dazzling) and co-orbital positioning over kinetic ASAT employment. The gray zone strategy is Kessler-aware: you can threaten without destroying, and threatening is more useful anyway because it keeps your options open.

The nuclear-space nexus

The escalation ladder's most dangerous compression — from conventional counterspace at Rung 6 to nuclear-relevant effects at Rung 8 — is not a hypothetical worst case. It is a structural feature of the current space architecture. Understanding it is essential to understanding why the ML deterrence thesis matters at the highest strategic level.

Nuclear C2 satellites: The United States' nuclear command-and-control depends on three satellite systems:

• AEHF (Advanced Extremely High Frequency): The protected, jam-resistant, nuclear-hardened communications link that carries presidential nuclear command authority to strategic forces. AEHF is EMP-hardened, low-probability-of-intercept, and specifically designed to function in a nuclear environment. It is the survivable nuclear C2 link. If AEHF is attacked or disrupted in a crisis, the U.S. cannot reliably transmit launch or stand-down orders to nuclear forces.

• SBIRS (Space Based Infrared System): The nuclear early warning constellation — four satellites in GEO and two in highly elliptical Molniya orbits — that detects ballistic missile launches within seconds of ignition. The entire U.S. concept of "launch on warning" or "launch under attack" depends on SBIRS providing accurate, rapid, and continuous coverage. Degrading SBIRS degrades confidence in the nuclear deterrent itself.

• GPS Block III: Used in nuclear delivery systems including Trident II D5 submarine-launched ballistic missiles for terminal guidance. GPS degradation affects conventional precision strike and nuclear delivery accuracy.

The entanglement problem: James Acton's analysis of "entanglement" — where nuclear and conventional forces share the same C2 architecture — identifies a specific failure mode for strategic stability. When the same satellite that relays conventional military orders also carries nuclear command authority, a conventional counterspace attack on that satellite becomes ambiguous: is the attacker trying to degrade conventional operations, or is this the first move in a nuclear first strike?

The adversary receiving the attack cannot answer this question in real time. The decision window is minutes, not hours. And the "use it or lose it" logic of nuclear deterrence — strike before you lose the ability to retaliate — becomes more acute as nuclear C2 satellites are degraded. An adversary that has lost confidence in its ability to command and control nuclear forces has stronger incentives toward early nuclear use.

Able Archer 83 as structural analogy: In November 1983, a NATO exercise (Able Archer 83) simulating the transition from conventional to nuclear warfare was nearly interpreted by Soviet leadership as preparation for an actual NATO first strike. Soviet nuclear forces were placed on elevated alert. The exercise almost triggered a nuclear response. The structural parallel to current space operations: actions that are militarily legitimate from the attacker's perspective (degrading adversary C2 before conventional operations) look like first-strike preparation from the defender's perspective.

Space operations make this dynamic faster and less reversible. NATO had weeks to signal that Able Archer was an exercise. An adversary watching its nuclear early warning satellites degrade has minutes to decide.

The geographic proximity problem: SBIRS GEO satellites operate at the same altitude band where Russia's Luch co-orbital platform has been documented conducting proximity operations near commercial communication satellites. The distinction between "proximity operation near Intelsat" (Rung 1) and "proximity operation near SBIRS" (Rung 4) requires knowing which satellite the co-orbital vehicle is approaching — which requires the precise orbital element analysis that the maneuver detection pipeline is designed to provide. Human analysts reviewing orbital data with multi-day latency will not detect the distinction before the co-orbital vehicle is in position.

The ML deterrence thesis at maximum stakes: The deterrence-by-detection argument is not only about deterring gray zone operations against commercial or conventional military satellites. Its highest-value application is providing early detection of proximity operations near nuclear C2 assets — creating decision time for diplomatic escalation before a Rung 1 activity becomes a Rung 4 crisis. This is the case where detection latency has the most direct bearing on nuclear stability.

The NEXT-GEN OPIR (Next Generation Overhead Persistent Infrared) program — the Space Force replacement for SBIRS — will introduce a transition period of partial coverage. During that transition, SDA coverage of the legacy SBIRS constellation's neighborhood becomes more important for exactly this reason.

The Taiwan contingency: the escalation framework applied

The Taiwan contingency is the scenario that DoD planning most explicitly centers on, and it provides the clearest worked example of how the abstract escalation framework would actually sequence in a real crisis. Government customers evaluating any deterrence or SDA capability will be thinking about Taiwan. Understanding the scenario concretely is essential for those conversations.

Phase 0 — Pre-conflict preparation (weeks to months before kinetic operations):

China conducts systematic behavioral characterization of U.S. and allied space assets in the Indo-Pacific theater. TLE monitoring, electronic signature collection, and pattern-of-life analysis to identify which satellites are essential for Taiwan operations and what their operational rhythms are. This is Chinese SDA applied offensively — the same behavioral detection problem the thesis addresses, run by the adversary against U.S. assets. During this phase, China also pre-positions dual-use commercial and civilian satellites on trajectories that could be rapidly redirected, updates ITU filings for constellations with Taiwan-theater relevance, and exercises ground-based jamming systems in training scenarios that look identical to the operational deployment they are preparing for.

This phase is detectable in behavioral data — anomalous surveillance passes over U.S. Pacific Command assets, irregular maneuver sequences for dual-use satellites, constellation repositioning inconsistent with stated commercial missions. ML-based anomaly detection that flags this preparation provides strategic warning weeks before kinetic operations begin. This is Phase 0's most important implication for the thesis: early detection here creates response options that don't exist once Phase 1 begins.

Phase 1 — Space domain preparation (hours to days before the amphibious crossing):

GPS jamming over the Taiwan Strait and surrounding airspace (Rung 2 on the escalation ladder). Cyber probes — potentially escalating to attacks — against U.S. reconnaissance satellite ground stations in Japan and Guam (Rung 2-3). Activation of GEO communications suppression capabilities against commercial satellite links used by U.S. Pacific Command and commercial SDA providers. Co-orbital satellites previously positioned near high-value U.S. military communication or early warning satellites maneuver to threatening proximity — coercive positioning at Rung 4 — designed to deter U.S. space-based C2 response without triggering a kinetic counterspace exchange.

The goal is PLA informationized warfare doctrine's first objective: establish information dominance before armed conflict begins. A U.S. military that cannot see, navigate, or communicate effectively across the Taiwan Strait cannot coordinate the response operations that would sustain Taiwan's defense. Phase 1 is the space component of that degradation campaign.

Phase 2 — Kinetic operations and sustained space conflict:

As Chinese forces execute the amphibious crossing, space operations continue in support. Commercial satellite imagery providers serving U.S. government customers face cyber attacks on ground infrastructure (the KA-SAT template, targeted at providers with Pacific theater coverage). Starlink-type communications used by Taiwanese military face jamming campaigns with counter-jamming cycles. The Rung 4 co-orbital positions established in Phase 1 provide coercive leverage — any U.S. kinetic response in the space domain risks triggering Rung 5-6 counterspace exchanges that the U.S., with more space-dependent forces, would lose disproportionately.

The deterrence dilemmas made concrete:

The Brands/Cooper dilemmas are not abstract in a Taiwan scenario:

• Symmetric vs. asymmetric deterrence: The U.S. could threaten Chinese space assets in response (symmetric). But China's Taiwan campaign is designed to succeed quickly — the PLA calculates that if the island can be seized before U.S. reinforcements arrive, degraded space assets are an acceptable cost. China's risk tolerance for space degradation in a short, decisive campaign is higher than U.S. risk tolerance for the same degradation in a long operational dependency.

• Deterrence vs. de-escalation: Any U.S. demonstration of space combat capability in the Indo-Pacific (exercises, visible counterspace deployments) may trigger the Phase 0 preparation it is designed to deter — Chinese pre-positioning accelerates as the window before U.S. response capability is established narrows.

• Coalition vs. unilateral deterrence: Japan, Australia, and other Indo-Pacific allies have ground stations, satellite operators, and space assets whose disruption would be part of any Chinese Phase 1 campaign. A coalition deterrence posture (Five Eyes SSA, allied counterspace cooperation) is more powerful but requires Chinese confidence that the coalition will hold — which Chinese political warfare actively tries to undermine.

The ML deterrence thesis in the Taiwan scenario:

The detection latency problem is most acute here. The LSTM pipeline in Module 9 trains on Space-Track TLE data, with TLE epochs updated 1-4 times per day for most objects. Phase 1 space domain preparation could unfold in hours. A detection system with day-scale latency provides operational warning after the window for response has closed.

This is the honest limitation of the TLE-based thesis applied to Taiwan: the pipeline is useful for Phase 0 strategic warning (weeks-scale behavioral characterization is detectable at TLE cadences), less useful for Phase 1 tactical warning (hours-scale jamming activation and co-orbital maneuvers require higher-cadence commercial optical/radar data from providers like LeoLabs). The research agenda this generates: extending the behavioral detection pipeline to integrate commercial sensor data at sub-orbital-period cadences, not just the public TLE feed.

The capstone wargame (Module 8) explores whether the threat of detection — known to the attacker, even if not executed at Taiwan timescales — changes equilibrium strategy in Phase 0. If China knows that U.S. SDA ML can characterize Phase 0 behavioral preparation and provide strategic warning, does that change the preparation strategy or its timing? CFR answers this formally. The Taiwan scenario is the strategic motivation for that computation.

The ML deterrence framework: thesis argument

This is where the strategic theory connects directly to the work in this curriculum.

The standard deterrence tools in space — offensive counterspace, declaratory policy, alliance commitments — all have the dilemmas described above. There is, however, a category of deterrence that those dilemmas partially avoid: deterrence by detection.

The argument:

Premise 1: Gray zone orbital operations depend on ambiguity. The Chinese strategy works — as the Dugger wargame showed — because the adversary cannot distinguish civilian positioning from pre-attack preparation until it is too late to respond. Remove the ambiguity and the strategy loses its decisive advantage.

Premise 2: ML-enabled behavioral analysis can reduce orbital ambiguity faster and at larger scale than human analysts can. Maneuver detection from TLE history (Module 9), behavioral pattern-of-life analysis, anomaly detection against baseline station-keeping — these are tractable ML problems given the right training data and feature engineering.

Premise 3: If adversaries know that their orbital maneuvers will be rapidly characterized and publicly attributed, the cost of gray zone operations increases. Actions intended to be deniable become attributable. Actions intended to be subtle become visible. The "bodyguard satellite" positioning that worked in the Dugger wargame becomes detectable before it is complete.

Conclusion: Sufficiently capable, rapidly deployed SDA ML systems degrade the operational value of gray zone orbital tactics, contributing to deterrence stability without requiring offensive counterspace capabilities or contested arms control negotiations.

This argument is not equivalent to the claim that ML eliminates gray zone competition. It is the more modest claim that ML raises the cost of gray zone operations by reducing the information asymmetry on which those operations depend. Deterrence is not eliminated by attribution alone — the adversary also needs to believe the detecting party will respond. But attribution is a necessary condition for response, and it is currently the binding constraint.

Honest limitations of the thesis:

• Attribution does not equal political will to respond. If the U.S. can detect Chinese orbital positioning but lacks the political will to respond to civilian-designated spacecraft, detection alone doesn't deter.
• Adversaries can adapt. If ML systems can detect anomalous maneuvers, adversaries can design maneuvers that look like station-keeping up to the moment of threat. This is an adversarial ML problem, not just a detection problem.
• Scale and latency matter. Detection after the fact does not enable preemption. The useful deterrent effect requires detection fast enough to enable response before the threatening position is established — ideally during the maneuver sequence, not after.
• The thesis requires operationalization. "ML behavioral transparency contributes to deterrence" is a hypothesis. Demonstrating it requires: (a) building the ML capability, (b) showing it can detect the relevant behaviors, (c) demonstrating that adversary decision-makers update their behavior when they know detection is operating.

The curriculum builds the capability for (a) and (b). The capstone wargame (Module 8) provides a framework for exploring (c) computationally: does adding behavioral transparency to the defender's information set change the Nash equilibrium of the attacker's strategy? If yes, that is the formal result underlying the deterrence claim.

Connecting the curriculum to the thesis

Every module in this curriculum contributes something specific to the deterrence framework:

Module 0 (Orbital Mechanics): The physical basis for behavioral fingerprinting. A maneuver that changes orbital elements in a specific way has a physical signature that can be detected if you know what to look for. TLE history is the data; SGP4 is the baseline; deviations from baseline are the signal.

Module 1 (Foundations): The mathematical tools for behavioral inference. Bayesian updating (Module 1, Lesson 2) formalizes how you update beliefs about adversary intent as maneuver observations accumulate. Monte Carlo Pc (Module 1, Lesson 3) models the probability distribution over adversary behavioral hypotheses.

Modules 2–3 (Neural Networks, RL): The function approximation and decision-making frameworks for automated behavioral characterization. An LSTM trained on TLE history learns the statistical signatures of different maneuver types without requiring explicit feature engineering for every scenario.

Modules 4–5 (MCTS, CFR): The game-theoretic framework for analyzing equilibrium behaviors. Does the Nash equilibrium strategy for the attacker change when the defender has ML-based detection? CFR computes the answer directly.

Module 6 (MARL): The multi-actor framework for modeling coalition dynamics and heterogeneous actor behavior in the orbital competition.

Module 7 (Partial Observability): The formal framework for behavioral attribution under uncertainty. The particle filter maintains a belief distribution over adversary types; Bayesian opponent modeling updates that distribution as observations arrive. This is the formal version of the intelligence analyst's problem.

Module 9 (Applied SDA ML): The direct implementation of the maneuver detection capability that is the empirical foundation of the deterrence argument.

What you need to be able to do

After this lesson, you should be able to:

• Explain what makes space escalation different from terrestrial escalation: compressed rungs, attribution delay, the "satellites don't have mothers" threshold problem, and absence of norms
• Name at least five rungs of the space escalation ladder, identify the two major firebreaks, and explain which rungs have been operationally observed in the public record
• Explain why Harrison's ISR blinding finding locates the critical instability at the transition between Rungs 2–3 and Rungs 4–6
• Describe the Russian concept of calibrated escalation (strategic deterrence as cost imposition) and contrast it with U.S. deterrence-by-denial
• State at least three of the six deterrence dilemmas (Brands and Cooper) and explain why they apply to space
• Explain the Harrison argument: why ISR blinding is an escalation accelerant rather than an escalation suppressor
• Explain the crisis communication problem (Campbell) and why China's deliberate opacity is a strategic choice
• State the five core provisions of the Outer Space Treaty and identify what the treaty does not prohibit
• Describe the Taiwan contingency space sequence (Phases 0–2) and explain how each phase maps to specific rungs on the escalation ladder
• Explain why TLE-based detection latency is insufficient for Phase 1 tactical warning and what data sources would address it
• Name the three nuclear C2 satellite systems (AEHF, SBIRS, GPS) and explain the entanglement problem: why conventional counterspace attacks on these systems may be perceived as nuclear first-strike preparation
• Explain the Able Archer 83 structural analogy and why space operations make the timing problem more acute
• Describe the Artemis Accords — who signed, who didn't, what they cover — and explain their strategic function as coalition-building rather than arms control
• Explain why the United States rejects PPWT on three grounds and why Carlson characterizes it as lawfare
• Articulate the ML deterrence thesis (deterrence by detection) in one paragraph, including both the core argument and its honest limitations
• Trace how each module in this curriculum contributes a specific capability to the ML deterrence framework

Lesson 6: From Strategic Theory to Wargame Design

The wargame design problem

Every wargame makes modeling choices — what to include, what to abstract away, which actors are present, what actions are available, how outcomes are determined. Those choices are not neutral. They encode assumptions about the strategic problem.

A wargame that models the space domain as two-player zero-sum implicitly assumes that the strategic problem is bilateral and that one side's gain is the other's loss. This is a reasonable model for certain kinetic counterspace scenarios (one state attacks another state's satellite constellation). It is a poor model for deterrence stability analysis (where the interesting question is what happens with three or more actors, each with different risk tolerances), for gray zone operations (where attribution uncertainty makes the game imperfect-information in a fundamental way), or for commercial-military interactions (where a commercial satellite operator's decisions create strategic effects without being a party to the conflict).

This lesson connects the strategic frameworks from Lessons 1 and 2 to the specific game-theoretic tools you will build in Modules 4 through 8. The goal is not to tell you which tool to use for which problem — the goal is to make you able to explain to a government customer why your wargame design encodes the strategic assumptions it does.

Wargaming as analytical tool: the Mahnken/Marshall framework

Thomas Mahnken and Barry Watts, in Net Assessment and Military Strategy, describe wargaming as an analytical tool for testing strategic assumptions against adversary behavior — not a prediction engine, but a framework for exploring the implications of different strategic choices.

The net assessment tradition (associated with Andrew Marshall's Office of Net Assessment at the Pentagon) uses wargames to:

1. Test strategic concepts: Does the assumption that stealth aircraft negate Soviet air defenses hold when Soviet radar doctrine adapts?
2. Discover unknown unknowns: What aspects of the problem did the planning staff not anticipate? Games surface surprises in a low-cost environment.
3. Stress-test doctrine: Does the doctrine perform as expected when an adversary plays optimally, rather than playing as planners expect?
4. Generate data for modeling: Human wargames produce move sequences that can be analyzed statistically for patterns.

The computational approach adds a fourth capability: exploring strategy spaces too large for human wargamers. A human wargame might run for a week and generate 50 game histories. An AlphaZero-style system can generate millions of game histories in the same time. This changes what questions are tractable.

A 2023 academic study (Exploratory Wargaming with Superhuman Tactician, drawing on AlphaZero applied to a military air combat game) found that AlphaZero converged to Nash equilibrium strategies that human players did not discover — specifically, the computational agent found mixed strategies (deliberate randomization) that exploited human players' tendencies to follow fixed patterns. The strategic implication: in genuine zero-sum adversarial scenarios, Nash equilibrium is the right solution concept, and humans systematically fail to achieve it.

Mapping strategic questions to game structures

Different strategic questions map to different game structures. Choosing the wrong structure does not just give you the wrong answer — it gives you a non-answer, because the structural assumptions of the game do not match the strategic reality being modeled.

Zero-sum kinetic conflict → two-player perfect-information or minimax

When the strategic question is "given that both sides know each other's capabilities and are in direct military conflict, what is the optimal force allocation?" the game is approximately two-player zero-sum with near-complete information. Minimax and alpha-beta pruning (Module 4, Lesson 1) are the right tools.

Example: How should an attacker allocate kinetic ASAT strikes against a defender's satellite constellation to maximally degrade ISR capability? This is a combinatorial optimization problem with a clear zero-sum structure and no hidden information beyond noise.

Orbital gray zone → imperfect-information extensive-form game

When the strategic question involves hidden intent (is that maneuver station-keeping or approach to a target?), incomplete information about adversary capabilities, or attribution uncertainty, the game has private information that belongs in the information set of one player but not the other. Information Set MCTS (Module 4, Lesson 5) and CFR (Module 5) are designed precisely for this structure.

The conjunction-masking capstone game is an imperfect-information game: the attacker knows whether the maneuver is offensive or defensive, but the defender only observes noisy orbital data. CFR finds the Nash equilibrium strategy for both players given this information structure — the attacker learns the optimal concealment pattern, the defender learns the optimal sensor allocation to detect it.

The strategic insight embedded in CFR: at Nash equilibrium, the attacker does not always choose the most plausible cover story and the defender does not always surveil the most suspicious object. Mixed strategies (probabilistic action selection) prevent the adversary from exploiting a fixed pattern.

Multi-actor deterrence → PSRO and population-level solution concepts

When the strategic question involves three or more actors with heterogeneous capabilities, doctrines, and objectives — the realistic space competition landscape — standard two-player Nash equilibrium is inadequate. A three-player game rarely has a pure Nash equilibrium; when it does, it is not necessarily the right solution concept (because side-payments and coalition formation become relevant).

Policy Space Response Oracles (Module 6, Lesson 3) addresses this by building a meta-game over a population of strategies and finding the Nash equilibrium of the meta-game. This is more tractable than solving the full three-plus-player game and captures the key dynamics: the right strategy against the United States is different from the right strategy against China, and both are different from the optimal strategy in an environment where both adversaries are present.

Alpha-rank (Module 6, Lesson 4) provides an alternative solution concept based on evolutionary dynamics — which strategies survive in a population of competing agents over time? Alpha-rank is more robust to the mixed equilibrium problem and produces a tractable ranking of strategies by their evolutionary fitness.

Behavioral attribution under incomplete observation → particle filters and opponent modeling

When the strategic question is "what is the adversary's type (doctrine, objective, risk tolerance) given the sequence of observed actions?" — the opponent modeling problem — the right framework is Bayesian inference. The particle filter (Module 7, Lesson 2) maintains a belief state over adversary type and updates it as new observations arrive.

This maps to the actual intelligence problem in SDA: you observe a sequence of orbital maneuvers (or the absence of expected station-keeping maneuvers) and want to infer whether the satellite is:

• A commercial operator doing routine operations
• A military satellite doing routine station-keeping
• A military satellite conducting an intelligence-gathering approach to a target
• A satellite that has been disabled and is drifting

Each hypothesis implies a different future trajectory. Bayesian opponent modeling (Module 7, Lesson 4) formalizes this as type inference: you maintain a distribution over "adversary types" (where a type encodes a policy — a mapping from states to actions) and update the distribution as observations arrive.

The information asymmetry at the center of orbital conflict

The most important structural feature of space conflict for wargame design is asymmetric information about intent.

In terrestrial military conflict, the presence of armed soldiers on your territory has an unambiguous meaning. In space, a maneuvering satellite near your critical satellite might be:

• An inspection satellite gathering intelligence (hostile, non-destructive)
• A satellite on a rendezvous trajectory for on-orbit servicing (benign)
• A kinetic kill vehicle positioning for an attack (hostile, destructive)
• A satellite that has suffered a navigation failure (benign, accidental)

The defender cannot distinguish between these until the action occurs — and some actions are irreversible on short timescales. This is not a failure of intelligence; it is a structural feature of the orbital environment. Orbital mechanics severely limits what you can infer about future intent from observed position and velocity.

This structural feature has a game-theoretic implication: the game is not merely imperfect information due to fog of war (which could be resolved with better ISR). It is fundamentally imperfect information because intent is not observable even in principle from kinematics alone. The right mathematical framework is not perfect-information game theory with noise, but imperfect-information game theory where intent belongs to a private information set.

CFR and IS-MCTS are correct here not because they are sophisticated tools but because they model the correct information structure.

What computational wargaming adds over human wargaming

Human wargames have significant limitations as analytical tools:

Small sample sizes: Even a week-long wargame generates tens or hundreds of game histories, not thousands. Statistical conclusions from such samples are unreliable.

Human cognitive biases: Human players systematically deviate from Nash equilibrium. They overweight recent events, avoid mixed strategies because pure strategies "feel" more decisive, and are influenced by social dynamics within the wargame team.

Discovery of Nash equilibrium strategies: As the Exploratory Wargaming study showed, AlphaZero-style systems discover mixed equilibrium strategies that human players miss — specifically, the probabilistic patterns that exploit predictable adversary behavior.

Scale: A game with a large state space (many satellites, many sensors, long time horizons) is computationally tractable for distributed RL (Module 3, Lesson 8: IMPALA) but not for human wargamers.

What human wargaming adds over computational: Scenario validity ("is this game capturing the real strategic problem?"), doctrine elicitation ("what do planners actually believe about adversary capabilities?"), and norm-setting ("what are the unwritten rules about what actions are acceptable?"). The best wargaming programs combine both: human subject-matter experts define scenarios and action spaces, computational methods explore those spaces exhaustively.

Sandra Erwin's reporting on Slingshot Aerospace's wargame training program (SpaceNews, 2024) describes this hybrid approach: human operators define the strategic scenario and initial conditions, AI agents trained on orbital mechanics explore the strategy space, and human analysts interpret the resulting strategy profiles. The AI finds equilibria; the humans decide whether the game modeled the right problem.

The LLM-in-the-loop connection

Module 8, Lesson 7 covers LLM-in-the-loop wargame adjudication: using a locally deployed language model as an umpire to adjudicate the realism and consequences of proposed actions, rather than having a hard-coded rule system or human umpires.

The strategic theory context for that lesson: LLM adjudication is appropriate when the action space is too large or too ambiguous for hard-coded rules (a satellite maneuver could be routine or hostile depending on context), and when the cost of a human umpire is too high for the scale of runs needed (thousands of game episodes for RL training). The LLM serves as an imperfect but tractable model of the "umpire's assessment" — encoding domain knowledge about what is plausible in the space environment.

The limitation: LLMs encode the training distribution, which reflects the documented operational doctrine of the past. They do not model adversarial adaptation (an adversary who learns that a specific action triggers a specific umpire ruling and exploits that pattern). For production wargaming, LLM adjudication is best combined with CFR or RL training so the agent learns to play against the umpire's model, including any exploitable patterns in that model.

The capstone game design, explained

The Module 8 capstone is: a two-player extensive-form game where the attacker tries to mask a maneuver and the defender allocates sensors to detect it.

The strategic theory that justifies each design choice:

Two-player: Models the bilateral conflict between a single adversary satellite and a U.S./allied SSA capability. Simplified from the realistic multi-actor environment for tractability — a deliberate scoping choice, not an assumption that the real environment is bilateral.

Extensive-form (sequential moves): Orbital operations are sequential — maneuvers happen in sequence, sensor observations arrive in sequence, the attacker decides when and how to maneuver based on what the defender is observing. Perfect simultaneous action would miss the temporal dynamics.

Attacker's private information (intent): The attacker knows the maneuver is offensive; the defender does not. This is not modeled as noise — it is a fundamental information asymmetry encoded in the information set structure. This is why CFR is the appropriate solver.

Sensor allocation as defender action: The defender's resource constraint (limited sensor dwell time) is the binding constraint in real SDA operations. The action space — how to allocate scarce observation time across multiple tracked objects — reflects the real operational problem.

Conjunction as cover: The attacker uses a conjunction event (a close approach that is plausible given orbital mechanics) to mask the maneuver. This is not invented — co-orbital inspection satellites have been documented approaching adversary assets under conditions that create ambiguity about whether the approach is intentional or a forced coincidence of orbital geometry.

Every design choice encodes a strategic assumption. The contribution of this module is making those assumptions visible — so you can defend them to a customer, revise them when a new threat scenario emerges, and extend the game to new strategic questions without starting from scratch.

What you need to be able to do

After this lesson, you should be able to:

• Explain why wargame design choices are not neutral and how they encode strategic assumptions
• Map a strategic question to the appropriate game structure: zero-sum kinetic conflict → minimax; gray zone with hidden intent → IS-MCTS or CFR; multi-actor deterrence → PSRO; behavioral attribution → particle filters and opponent modeling
• Explain why CFR produces the right solution concept for the conjunction-masking game specifically (private information about intent, mixed strategy equilibria prevent exploitation of fixed patterns)
• Describe what computational wargaming adds over human wargaming and what human wargaming adds over computational
• Explain each design choice in the Module 8 capstone game in terms of the strategic assumption it encodes

Lesson 7: Battle Networks, Space Battle Management, and the AI-Enabled Decision Loop

Module: Spacepower Theory and Strategic Context — Module SP Source: Todd Harrison, "Battle Networks and the Future Force" (CSIS, 2020); Todd Harrison, "Space Threat Assessment 2020" (CSIS); Alan T. Dugger, "Space as a Gray Zone: The Future of Orbital Warfare" (2024); USSF Space Capstone Publication (2020); Andrew Krepinevich, "Protracted Great-Power War: A Preliminary Assessment"; Bowen & Johnson, "From SSA to SDA: Operational Intelligence in the Space Domain" (2024); Space News, "Kronos Program Overview" (2024); RAND, "Resilience of the U.S. Defense Information Infrastructure" (2023)

Where this fits

The previous six lessons built the strategic theory foundation: Dolman's high ground argument, counterspace taxonomy, historical cases, Chinese doctrine, the escalation ladder, and the wargame design rationale. Every lesson has implicitly assumed a context for the tools it describes — but that context, the operational architecture those tools live inside, has never been stated directly.

That architecture is the battle network.

This lesson states it explicitly. A battle network is the integrated system of sensors, communications, computing, and decision authorities that connects what military forces can see to what they can do. Modern battle networks are space-dependent at every layer. SDA/SSA is the space-facing sensing component of those networks, evolving from cataloging objects to producing real-time operational intelligence. AI is the mechanism that makes this integration fast enough to matter. And orbital dominance — the strategic goal Dolman theorized and China and the United States are competing for — is, operationally, the ability to build and preserve a battle network that outperforms the adversary's.

The ML tools this curriculum builds are not research prototypes. They are components of this network. This lesson establishes the frame that makes that claim defensible.

The battle network: sensing to action

Harrison's "Battle Networks and the Future Force" provides the foundational framework. A battle network consists of:

1. Sensors — the distributed systems that observe the operational environment (radar, optical, signals intelligence, space-based ISR, orbital tracking)
2. Networks — the communications infrastructure that moves sensor data to processors and processed intelligence to decision-makers (satellite communications, tactical data links, ground networks)
3. Processing — the systems that turn raw sensor data into actionable intelligence (fusion algorithms, anomaly detectors, intent classifiers, track managers)
4. Decision authorities — the humans and automated systems that act on processed intelligence (operators, command authorities, engagement systems)
5. Effects — the actions taken based on decisions (maneuvering satellites, executing counterspace operations, diplomatic signaling, kinetic or non-kinetic strikes)

The OODA loop (Observe, Orient, Decide, Act) is the battle network's operating cycle. The side that can execute this loop faster and more accurately than its adversary wins engagements — not because it has more assets, but because it can see what the adversary is doing, understand its implications, and act on that understanding before the adversary can respond.

This is the operational frame for Harrison's "force exponent" argument. Adding sensors, communications nodes, or processing capacity to a battle network does not just add capability additively — AI at each stage multiplies the effectiveness of every other node. An additional radar is a force increment. An AI-enabled data fusion system that integrates that radar with ten other sensors and delivers actionable anomaly alerts in seconds rather than hours is a force exponent: it makes the entire network more effective, not just one component.

Space as the decisive substrate

Modern battle networks are not merely supported by space — they run through space at every critical layer.

Navigation and timing: GPS provides the precision navigation and timing that enables precision-guided munitions, coordinated joint operations, and network synchronization. Degrading GPS timing does not just affect satellite navigation — it desynchronizes the entire network, preventing communication protocols from maintaining timing relationships and causing data fusion to fail.

Intelligence, Surveillance, and Reconnaissance: Satellite ISR provides broad-area coverage no ground-based system can replicate. Synthetic aperture radar satellites image through clouds; optical satellites provide high-resolution imagery of denied areas; SIGINT satellites collect electronic emissions. The ISR layer of the battle network is overwhelmingly space-dependent for global peer competition.

Communications: Satellite communications provide the backbone for long-range, mobile, and maritime communications. AEHF (Advanced Extremely High Frequency) provides nuclear C2 communications; MUOS (Mobile User Objective System) provides UHF mobile communications; commercial SATCOM (including Starlink) provides high-bandwidth broadband. Severing satellite communications severs the network itself.

Space Battle Management: The USSF SCP identifies Space Battle Management (SBM) as one of seven core spacepower disciplines. SBM is the C2 layer specifically for the space domain — the systems and processes that enable operators to maintain awareness of the space environment, coordinate responses, and execute space operations as part of a joint campaign. This is the layer that connects SDA outputs to operational decisions.

The implication: an adversary who can degrade the space layer degrades the entire battle network simultaneously. This is why Harrison frames adversary ASAT systems as tools designed to "disrupt U.S. and allied battle networks that depend upon or transit through space" — the target is not individual satellites, it is the network coherence that makes those satellites militarily effective.

From SSA to SDA to operational intelligence

Space Situational Awareness was the original framework: catalog objects in orbit, maintain their tracks, provide conjunction warnings. This is a cataloging function — it tells you what is in orbit and where.

Space Domain Awareness expanded this: not just "where is the object" but "what is it doing, what is its purpose, and what does its behavior imply?" The SSA-to-SDA transition is conceptually equivalent to the intelligence community's distinction between collection and analysis: SSA collects, SDA analyzes.

The operational intelligence evolution takes this a step further. In this framing, SDA outputs are not just intelligence products that an analyst reviews — they are real-time inputs to a Space Battle Management system that uses them to maintain the common operating picture, support planning and deconfliction, and enable fast decisions about orbital operations. The "Planetary Neural Network" concept — proposed as an integration vision for global SDA — describes this explicitly: a system that fuses telemetry, ground sensor data, electromagnetic spectrum data, and publicly available information into a continuously updated orbital operational picture. That is not an intelligence archive. That is a battle network node.

Kronos is the current programmatic embodiment of this vision for U.S. and allied operations. Described as "a modernized suite for space battle management and intelligence," Kronos fuses data in real time, supports planning and deconfliction, and provides shared awareness for U.S. and allied operators. The Space Force has also opened access to classified tracking data for commercial firms explicitly described as supporting "battle management, command and control... to see what is happening in orbit." The commercial SDA ecosystem — LeoLabs, Slingshot, ExoAnalytic, and eventually the products this curriculum is building toward — feeds into this same architecture.

The ML maneuver detection, fleet tracking, and intent inference tools built in Module 9 are not independent products. They are the sensing and processing layers of a larger battle network architecture whose C2 layer is Kronos, whose human decision layer is Space Command, and whose effects layer is both diplomatic (attributing gray zone behavior) and operational (maneuvering protected assets, executing space battle management decisions).

The USSF doctrine: orbital warfare and space battle management

The USSF SCP distinguishes two disciplines directly relevant to orbital dominance:

Orbital Warfare is defined as "the military operations conducted to seize, retain, and exploit freedom of action in the space domain and to deny the same to an adversary." It encompasses offensive and defensive fires in the orbital environment — the capability to maneuver, protect, and if necessary, degrade adversary orbital systems. Orbital warfare is the kinetic and maneuvering component of space control.

Space Battle Management is the C2 complement to orbital warfare: "the art and science of assigning and directing Space Force assets to accomplish operations, missions, and tasks." SBM provides the situational awareness, planning, and coordination that enables orbital warfare to be executed coherently. Without SBM, orbital warfare is uncoordinated asset employment. With SBM, it is a synchronized campaign.

The distinction matters for understanding where the curriculum's tools fit. Maneuver detection, intent inference, and adversarial game theory are SBM functions — they inform the decision layer that coordinates the battle network. Orbital warfare (maneuvering to defend an asset, executing a proximity operations response) is the effects layer that SBM directs.

Space Domain Awareness is the third relevant discipline, positioned as the sensing foundation that both orbital warfare and SBM depend on. The SCP defines SDA as "the identification, characterization, and understanding of factors associated with the space domain that could affect space operations." The curriculum's entire ML pipeline — from Module 0's TLE processing through Module 9's intent inference — is an SDA capability.

AI as the force exponent in space battle networks

Harrison's force exponent argument is most important at the intersection of SDA and SBM, where AI accelerates the sensing-to-decision loop:

Sensing layer: AI reduces the latency between an event occurring and an alert being generated. A human analyst reviewing TLE data manually might detect a significant maneuver in hours or days. An LSTM maneuver detector with a daily TLE batch update generates the alert within minutes of the batch arriving. For a fleet of 200 watched objects, no human analyst team can maintain this cadence. AI can.

Processing layer: AI enables inference that no human analyst can perform at scale. Intent classification — "is this approach trajectory consistent with RPO toward AEHF-6?" — requires simultaneous analysis of conjunction geometry, orbital history, approach rate, and game-theoretic context. The Module 9 intent inference pipeline does this for every watched object on every update cycle. A human analyst team might do it for three high-priority objects.

Decision layer: AI decision support systems compress the time from alert to decision. When the SBM system flags a high-probability RPO approach with a 77% intent confidence toward a specific asset, the Space Battle Manager has a structured alert with supporting evidence rather than a raw TLE batch requiring manual analysis. The decision cycle shortens from "analyst reviews data, writes report, briefs commander" to "system presents structured alert with confidence and recommended action, commander acts."

The force exponent effect: as AI nodes are added at each layer — better sensing, faster processing, structured decision support — the entire battle network becomes more effective, not just its individual components. This is the thesis-level claim for why SDA ML investment by the United States matters strategically: it is not building a detection product, it is accelerating the battle network cycle time relative to adversaries.

The latency requirement: AI's force exponent effect is conditional on having timely access to sensor data. Harrison is explicit: "AI/ML algorithms depend on having timely access to large volumes of sensor data, as well as reliable communications links to move that data." A maneuver detector that runs on 24-hour-delayed TLE data cannot support decisions that need to be made in hours. The commercial SDA integration argument — why Space Force opened classified tracking to commercial firms — is partly about sensor latency: higher-cadence commercial sensors fill the detection gaps that TLE cadence creates.

Resilience: the battle network that survives first strike

A battle network that cannot absorb adversary counterspace attacks is brittle regardless of its AI capability. The resilience of the sensing and C2 architecture is a prerequisite for the force exponent to function under adversarial conditions.

Graceful degradation is the design principle: the network should degrade predictably under attack rather than collapsing at a single point of failure. A ground-based command network with a single fusion node is not graceful — sever the node and the network fails. A mesh architecture with distributed processing and multiple redundant paths degrades gracefully: losing one node reduces capacity but preserves function.

Disaggregation and diversification: The PWSA (Proliferated Warfighter Space Architecture) and SDA Tranche architecture are both responses to the fragility of the traditional model of a few exquisite satellites. Hundreds of lower-cost satellites on diverse orbital planes make it prohibitively expensive for an adversary to take down the full constellation. Disaggregation trades per-asset capability for network resilience.

Dynamic space operations: An adversary executing a co-orbital approach against a defended asset changes the tactical calculation if the defended asset can maneuver — becoming a moving target rather than a fixed one. The concept of "sustained space maneuver" (satellites that move frequently and unpredictably to enable evasion, deception, and responsive actions) is the orbital equivalent of dispersal and hardening. It connects directly to the game-theoretic framing of Module 8: if the Defender can move its assets, the Adversary's conjunction-masking strategy becomes much harder to execute against a target whose position is uncertain.

Commercial backup paths: Starlink in Ukraine demonstrated that commercial satellite communications can substitute for dedicated military communications under adversarial conditions. The resilience value of commercial space is not just cost — it is the proliferation of communication pathways that no adversary can target comprehensively. The CASR (Commercial Augmentation Space Reserve) framework is the institutional mechanism for formalizing this backup path.

Adversary approaches to space battle management

Chinese approach: The PLA frames AI as the backbone of its space operations architecture. AI manages the PLA's satellite constellation networks in real time, automates threat analysis, and accelerates orbital decision-making cycles. Chinese doctrine treats information dominance as the first objective of conflict — "seizing command of space network dominance" — and AI-enabled space battle management as the enabling mechanism for information dominance. This is not a distant capability goal; the PLA has been fielding AI-enabled ground control systems for its satellite constellation across LEO, MEO, and GEO.

Russian approach: Russia's strategy is asymmetric degradation rather than parity-building. Rather than constructing a space battle management architecture comparable to U.S. and allied systems, Russia invests in capabilities specifically designed to degrade the U.S. battle network's space layer: Peresvet to blind optical ISR, Tirada-2 to jam GEO communications, Krasukha-4 for ground-based electronic warfare against satellite downlinks, Nudol for direct physical destruction. The objective is not to win a battle network competition but to prevent the U.S. battle network from functioning. This is the asymmetric degradation strategy: if you cannot match the adversary's battle network, degrade it to the point where you are competing on more level terms.

The implications for resilience architecture: The adversary's strategy determines what resilience must protect against. Against China, which is building toward battle network parity, resilience requires that the U.S. network maintains sufficient capability advantage that China cannot overtake it before conflict — the "race to the top" problem. Against Russia, which is executing asymmetric degradation, resilience requires that the network survives the specific attack vectors Russia has developed: blinding, jamming, and targeted kinetic destruction. These require different architectural responses — disaggregation for survivability against targeted strikes, spectrum diversity for resilience against jamming, alternative ISR paths for resilience against optical blinding.

The cislunar gap in existing battle networks

The entire battle network architecture described above — PWSA, SDA constellation, Kronos, commercial SDA integration — is oriented toward LEO/MEO/GEO. Existing tracking infrastructure has poor coverage above GEO. Existing SSA systems cannot provide adequate situational awareness in the Earth-Moon system at current sensor densities.

As Module SP Lesson 1 notes, the Earth-Moon Lagrange points (EML1, EML2) provide persistent surveillance positions in cislunar space that Earth-based sensors cannot monitor continuously. The lunar south pole represents a strategic logistics node. The Chinese ILRS program and U.S. Artemis architecture are competing to establish the first operational presence at these positions.

For battle network planners, the cislunar gap means: if conflict extends to cislunar space, the SDA infrastructure that enables Space Battle Management in near-Earth orbit does not exist for the cislunar theater. There is no cislunar equivalent of Space-Track, no cislunar Kronos, and no AI-enabled maneuver detection pipeline for objects transiting Earth-Moon space. The strategic gap is not just physical presence — it is the sensing and C2 architecture for the expanded battlespace.

This is the forward research frontier that the Module 9 pipeline points toward: extending the sensing and decision loop from LEO/MEO/GEO to the cislunar theater.

The curriculum as a battle network component

Assembling this into the thesis argument:

The curriculum's ML tools occupy specific layers of the space battle network:

• Module 0 (TLEs, SGP4, conjunction analysis): the data infrastructure layer — the raw material the sensing layer consumes
• Module 9, Lessons 1–2 (LSTM/transformer maneuver detection): the sensing layer — converting raw orbital data into maneuver alerts
• Module 9, Lesson 3 (fleet tracking, anomaly scoring): the track management layer — maintaining situational awareness across the full watched catalog
• Module 9, Lesson 4 (intent inference): the processing/intelligence layer — converting "this object maneuvered" into "this approach is consistent with RPO toward this asset at this confidence level"
• Modules 5–8 (CFR, PSRO, OpenSpiel, Rust capstone): the adversary modeling layer — game-theoretic reasoning about what adversary strategies look like, enabling both better intent inference and wargame-based assessment of adversary options
• Module 8, Lesson 6 (SBIR and government contracting): the integration path — how this capability reaches Kronos, Space Command, and allied operators

The deterrence-by-detection thesis from Module SP Lesson 5 can now be stated in battle network terms: SDA ML capabilities that feed into Space Battle Management shorten the Defender's OODA loop, increasing the cost of gray zone operations that depend on ambiguity and slow attribution. An adversary who knows that an AI-enabled battle network will detect, classify, and attribute their orbital behavior within the day-scale latency of Space-Track updates faces a higher-cost operating environment than one who believes their maneuvers will be attributed only after the fact, if at all.

This is the operational claim behind the strategic thesis. It is testable, it is bounded (honest about what TLE latency can and cannot support), and it is the argument that connects this curriculum to the DoD customers, government contracts, and research funding mechanisms described in Module 8.

Key Takeaways

• A battle network is the integrated sensing-processing-decision-action system that connects what forces can see to what they can do. Modern battle networks are space-dependent at every critical layer: navigation/timing, ISR, communications, and space battle management itself. Adversary counterspace capabilities are designed to degrade the network, not just individual satellites.
• AI provides a force exponent, not a force multiplier. Adding an AI-enabled processing node to a battle network multiplies the effectiveness of every other node — accelerating sensing, enabling inference at scale, and compressing the decision cycle. Harrison's framework frames AI-enabled battle network superiority as the decisive asymmetric advantage in peer competition.
• Space Battle Management (SBM) and Orbital Warfare are distinct but complementary USSF disciplines. SBM is the C2 layer that connects SDA outputs to operational decisions; Orbital Warfare is the effects layer that SBM coordinates. The curriculum's ML tools are SDA and SBM functions, not Orbital Warfare functions.
• The SSA → SDA → operational intelligence evolution positions SDA as a battle network node, not an intelligence archive. Kronos is the programmatic embodiment: real-time data fusion, planning and deconfliction support, shared awareness for U.S. and allied operators. Products that can feed into Kronos have a direct commercial and operational path.
• Resilience architecture is a prerequisite for AI force exponent effects to survive adversarial conditions. Graceful degradation (mesh architecture), disaggregation (PWSA/SDA Tranche), dynamic space operations (maneuvering satellites), and commercial backup paths (CASR, Starlink) are the defensive countermeasures against adversary strategies designed to degrade the battle network.
• Adversary strategies diverge: China is building toward battle network parity; Russia is executing asymmetric degradation. These require different resilience responses — parity competition requires sustained investment in capability superiority; asymmetric degradation requires survivability against specific attack vectors (blinding, jamming, kinetic).
• The cislunar theater is a battle network gap. Existing SDA architecture is oriented toward LEO/MEO/GEO. There is no cislunar equivalent of Space-Track, no cislunar Kronos, and no AI-enabled decision loop for the expanded battlespace that Artemis and ILRS competition is opening.
• The curriculum builds the sensing and processing layers of the space battle network. Maneuver detection, fleet tracking, and intent inference are SDA functions that feed SBM. The game-theoretic tools model the adversary strategies that SBM must counter. The connection to Kronos and government contracting is the path from research tool to operational battle network component.

Quiz

Module SP Project: Wargame Design Brief and Deterrence-by-Detection Assessment

What you are building

This module has no code and no math. The project is analytical: you will produce a structured design brief for a computational wargame addressing a specific adversarial SSA scenario, then evaluate whether the ML deterrence-by-detection thesis actually holds for that scenario. The output is a written document — the kind you could put in front of a government customer, a thesis committee, or a conference reviewer.

The point of writing this down is to force precision. It is easy to say "game-theoretic reasoning applies to orbital conflict." It is harder to say: "for this scenario, the correct game structure is an imperfect-information sequential game, solved with CFR, where the defender's information set encodes these specific observables, and the Nash equilibrium tells us the attacker will mix these specific maneuver intensities." The project asks for the harder version.

The scenario

Choose one of the following. Pick the one most relevant to your thesis direction.

Option A: Luch co-orbital positioning near nuclear C2. A co-orbital inspection platform (modeled on Russia's Luch) maneuvers to within 50 km of a U.S. nuclear early warning satellite in GEO. The maneuvering platform is registered as a communications relay satellite. The approach geometry is consistent with either routine orbital adjustment or deliberate coercive positioning.

Option B: Chinese dual-use satellite pre-positioning (Taiwan Phase 0). A constellation of satellites registered under civilian operators executes a series of orbital adjustments over three weeks, resulting in coverage geometry optimized for the Taiwan Strait theater. Each individual maneuver is within normal station-keeping variance. The pattern across the constellation is not.

Option C: Conjunction-masking approach to a commercial SDA asset. An adversary satellite maneuvers to a position whose conjunction geometry with a piece of tracked debris makes it ambiguous whether a subsequent close approach to a commercial SDA satellite is deliberate RPO or incidental. This is the Module 8 capstone game as a real-world scenario.

The structure of the project is the same regardless of which option you choose. Option C is the most computationally tractable. Options A and B have higher strategic stakes and connect more directly to the deterrence-by-detection thesis at the nuclear and coalition levels.

Part 1: Escalation ladder placement

Place your chosen scenario on the 8-rung space escalation ladder from Lesson 5. For each of the following, write 2-4 sentences:

1a. Current rung. Which rung does the scenario currently occupy? Cite specific features of the scenario that locate it on this rung rather than adjacent ones. If the scenario spans multiple rungs depending on how the attacker's intent is interpreted, say so explicitly.

1b. Rung transition triggers. What specific action would move the scenario up to the next rung? What would move it back down? Be concrete: not "further escalation" but "if the co-orbital vehicle maneuvers to within 5 km and activates its RF payload, that transitions from Rung 1 to Rung 4 because..."

1c. Firebreak analysis. Does your scenario sit near one of the two major firebreaks (Rung 2 to 3, or Rung 5 to 6)? If so, what determines whether the firebreak holds? If the scenario involves nuclear C2 assets, identify the specific compression of the escalation ladder and what decision time that implies.

1d. Harrison ISR blinding problem. Does ISR blinding make the scenario more or less stable? Apply Harrison's finding directly: if the defender cannot see the scenario developing, does that increase or decrease the probability of miscalculated response?

Part 2: Wargame design brief

Design the computational wargame for your scenario. Every design choice below has a strategic assumption behind it. State both.

2a. Players and interests. Who are the players? (Not just "attacker" and "defender" — be specific about what each player wants and why those interests conflict.) Is this two-player zero-sum, two-player non-zero-sum, or multi-actor? Justify your answer.

Example of what is expected: "Two players, zero-sum. The Adversary wants to establish co-orbital proximity without triggering a response; the Defender wants to detect and characterize any approach. Zero-sum is justified because the Adversary's primary goal (undetected positioning) is achieved exactly to the degree the Defender's primary goal (detection) is not. Commercial satellite operators are not modeled as separate players because their decisions are not strategically reactive to the adversary's actions — they are part of the environment, not the game."

2b. Information structure. What does each player observe? What do they not observe? Map this to the game-theoretic vocabulary from Lessons 1 and 6: perfect information, imperfect information, incomplete information. For imperfect-information games, enumerate the information sets for each player.

The information structure is not cosmetic. "The Adversary observes the defender's sensor allocation" vs. "the Adversary does not observe the defender's sensor allocation" produces qualitatively different equilibria. State which assumption you are making and why it matches the actual operational situation.

2c. Action space. What actions are available to each player? Use the module's vocabulary: not "the attacker can attack" but specific, enumerated options with physical meaning. What actions are you excluding and why?

2d. Chance nodes and stochastic outcomes. What outcomes are determined by noise or Nature rather than player choice? What probability distributions govern them? Where do those probabilities come from (physics, calibrated estimates, assumptions)?

2e. Payoff structure. What is each player's payoff in each terminal outcome? If zero-sum, state the Adversary's payoff; the Defender's is its negation. Map each payoff value to a specific operational consequence.

2f. Solution concept. Which solution concept is appropriate for your game? Choose from: minimax/backward induction (perfect information), Nash equilibrium via CFR (imperfect-information two-player zero-sum), PSRO (multi-actor or iterative best response), alpha-rank (evolutionary stability in a population), Bayesian opponent modeling (type inference). Justify the choice based on the game's structure, not on which tool you know how to build.

Part 3: Computational tool audit

Map your game design to the specific tools built in Modules 4 through 9. For each module below, answer the question:

Module 4 (Search and Planning): Does your game require a tree search component? If the game is multi-step rather than single-shot, which variant of MCTS applies — standard MCTS (perfect information) or IS-MCTS (imperfect information)? What depth does the game tree realistically require?

Module 5 (CFR and equilibrium computation): Is CFR the right solver for your game? If yes: how many information sets does your game have? Is vanilla CFR tractable or do you need MCCFR or deep CFR? What does the resulting Nash equilibrium actually say about attacker strategy?

Module 6 (MARL): If your scenario has more than two strategic actors, or if the "game" is really a sequence of episodes where both sides adapt, does PSRO or alpha-rank apply? What population of strategies would the meta-game include?

Module 7 (Partial observability): What is the defender's belief state? What observables update it? Which belief representation is appropriate — discrete Bayesian update, Kalman filter, or particle filter? What is the adversary type distribution the defender maintains?

Module 9 (Applied SDA ML): What features from the TLE history would the Module 9 pipeline extract to generate the defender's observables? What is the realistic detection latency given TLE update cadence? Is that latency short enough to matter operationally for your scenario?

Part 4: Deterrence-by-detection assessment

Apply the ML deterrence thesis from Lesson 5 to your specific scenario. Work through each step of the argument:

4a. Does detection change the equilibrium? In your CFR or PSRO game, what happens to the attacker's equilibrium strategy when the defender's detection capability improves? Does better detection cause the attacker to shift toward lower-intensity maneuvers, toward higher-intensity maneuvers (accepting detection risk for higher payoff), or toward a different timing strategy? If you ran the CFR solver from Module 5 (or the capstone from Module 8) against your game's payoff table, what direction would the Nash equilibrium shift?

You do not need to run the actual computation. Reason qualitatively from the payoff structure: if detection probability increases, which of the attacker's actions becomes less attractive and which becomes more attractive?

4b. Required detection latency. At what timescale must detection occur for the deterrent effect to operate? If detection takes 48 hours but the threatening maneuver completes in 6 hours, detection provides forensic value but no deterrent value. State the operational tempo of your scenario and whether the TLE-based pipeline's latency (1-4 day update cadence for most objects) is sufficient, or whether sub-orbital-period cadence data from commercial optical/radar sensors is required.

4c. Attribution chain. Detection is not attribution. Walk through the attribution chain for your scenario: (1) anomaly detected; (2) maneuver characterized; (3) intent inferred; (4) actor attributed; (5) response authorized. Where does the ML pipeline contribute? Where does it hand off to human intelligence analysis? Where does the chain break down?

4d. Adversary adaptation. If the adversary knows the detection pipeline exists and understands its features, how does their optimal strategy change? This is the adversarial ML problem: the attacker designs maneuvers to minimize detection probability while achieving the positioning objective. Does the Nash equilibrium strategy (from your answer to 4a) already account for this? If not, what would the adapted attacker strategy look like?

4e. Honest limitations for your scenario. List at least three specific limitations of the deterrence-by-detection argument as applied to your chosen scenario. Use the Lesson 5 list as a starting point but make them specific: not "adversaries can adapt" but "in the Luch scenario, the adversary can achieve the same coercive positioning with a sequence of small station-keeping maneuvers each of which is individually sub-threshold, defeating the Mahalanobis scoring in the Module 9 pipeline because..."

Part 5: Thesis position statement

Write a 3-4 paragraph position statement making the ML deterrence argument for your specific scenario. This is the kind of text that would appear in a thesis proposal, a conference paper abstract, or a research brief for a government customer.

The statement must:

• Open with the specific strategic problem (not "space is important" but the specific scenario you analyzed)
• State the deterrence mechanism precisely (what changes in adversary behavior when ML detection capability is present)
• Cite at least three specific computational tools from the curriculum as the technical foundation of the claim
• Acknowledge the primary counterargument and explain why the argument holds despite it
• Close with the research gap or next step — what would need to be demonstrated to operationalize this claim

Length: 3-4 paragraphs, 300-500 words. No more. Brevity forces precision.

Audience: A program manager at AFRL or a Space Force acquisitions office who has technical fluency but is not a researcher. They want to know: what does this capability do, how does it work in principle, and why should they care.

Part 6: Reflect

After completing Parts 1-5, answer these questions briefly (one paragraph each):

6a. Which design choice in Part 2 were you most uncertain about? What would you need to know about the actual operational scenario to resolve that uncertainty?

6b. Your wargame design encodes strategic assumptions. If one of those assumptions is wrong — if the scenario is not zero-sum, or if the attacker has more information than you assumed, or if the payoffs are miscalibrated — how does the Nash equilibrium you described in Part 4a change? Is the deterrence argument fragile to that assumption, or robust?

6c. The overview of this module says: "Every wargame is a theory in disguise." Looking at your design brief, what theory of space conflict is your wargame a disguise for? State it in one sentence.

What you have built

• A precise placement of a real-world SSA scenario on the space escalation ladder with firebreak analysis
• A complete wargame design brief with every assumption stated explicitly
• A mapping from the game's structure to the specific modules' computational tools
• A deterrence-by-detection assessment that distinguishes what the ML pipeline can and cannot contribute
• A thesis position statement suitable for a research proposal or government brief

The discipline of the exercise is the point. The gap between "game-theoretic reasoning is relevant to orbital conflict" and "this specific game structure, solved with CFR, produces this Nash equilibrium strategy, which implies this change in attacker behavior when detection capability improves" is where the thesis argument either holds up or falls apart. Writing it out is how you find out which.

Module 1: Foundations

Where this module fits

Everything you'll build later in this curriculum (value functions, policy gradients, MCTS rollouts, CFR regret updates, neural network forward passes) reduces to three operations: pushing numbers through matrices, taking derivatives of those numbers with respect to other numbers, and reasoning about what those numbers mean when they're random. This module gives you working intuition for those three things and nothing else.

This is not a math course. We are picking exactly the pieces of probability, linear algebra, and calculus that show up when you read OpenSpiel source code, and skipping everything else. If a topic feels truncated, that's because the rest doesn't matter for our goal. When we hit a later algorithm that genuinely needs more (eigenvectors for alpha-rank, for instance), we'll handle it then, in context.

What we cover

Probability (lessons 1-4). Distributions, expectation, conditional probability, Monte Carlo sampling, and the information-theoretic quantities (entropy, cross-entropy, KL divergence) that show up everywhere from policy gradients to regret matching. The MCTS, MCCFR, and policy gradient methods later in the curriculum are, deep down, ways of making smart estimates from random samples. If you internalize "expectation under a distribution, estimated by sampling," you've already got the shape of half the algorithms in OpenSpiel.

Linear algebra (lessons 5-6). Vectors as state representations (an orbital state vector is, mechanically, just a vector). Dot products as similarity and projection. Matrix-vector multiplication as the operation that defines a single neural network layer. That's it for now. We're skipping eigendecomposition, determinants, matrix inverses, and rank, because they don't show up until later (and some never do).

Calculus (lesson 7). Derivatives as slopes, partial derivatives as slopes-along-one-axis, gradients as the vector pointing uphill, and the chain rule. The chain rule is the entire mathematical content of backpropagation; if you can see it visually, the rest of "how neural nets learn" is bookkeeping.

Lessons

1. Probability, distributions, and expectation
2. Conditional probability and Bayes' rule
3. Sampling and Monte Carlo estimation
4. Entropy, cross-entropy, and KL divergence
5. Vectors and dot products
6. Matrices and matrix-vector multiplication
7. Derivatives, gradients, and the chain rule

Module project: Monte Carlo conjunction probability

You'll write a small Python program that estimates the probability of a collision between two satellites whose positions and velocities are known only to within some uncertainty. It uses every concept in this module: state vectors (linear algebra), uncertainty distributions (probability), Monte Carlo sampling (expectation under randomness), and a small sensitivity analysis that previews what gradients are good for.

This is a real problem in your field. JSpOC and the commercial conjunction services do something more sophisticated, but the bones are the same: simulate possible futures, average over them, use the average to make a decision. It is also a microcosm of the rest of the curriculum: every algorithm we build later is, in some way, doing exactly this with more structure on top.

What this module is not

We are not doing epsilon-delta proofs. We are not deriving Cauchy-Schwarz. We are not classifying matrices into normal forms. We are not covering measure-theoretic probability. If you came in hoping this would be the time you finally Get linear algebra, this module will frustrate you. It exists to make you fluent enough to read RL and game-theory code without bouncing off the notation, and that is the entire bar.

How to read the lessons

Every lesson follows the same shape: where it fits, the concept (intuition first), the math (only when load-bearing), code, a worked example small enough to verify by hand, and a quiz. If you find yourself stuck on math notation, that's a signal to reread the symbol-decoding paragraph rather than to push through. The notation is a compression of the intuition; if the intuition isn't there, the notation will not magically install it.

Lesson 1: Probability, Distributions, and Expectation

Module: ML and Game Theory for Space Power — M01: Foundations Source: Math for Deep Learning — Ronald T. Kneusel, Chapters 2–3 (Probability Fundamentals); Bayesian Statistics the Fun Way — Will Kurt, Chapters 1–2 (Bayesian Thinking and Probability)

Where this fits

Every algorithm in this curriculum, from MCTS rollouts to CFR regret minimization to policy gradient training, is answering one core question: given that I am uncertain about the world, what should I expect? That question has a precise mathematical answer, and this lesson is that answer. Once you understand expectation, you understand the conceptual shape of half the algorithms in OpenSpiel. The rest is detail.

A space scenario to motivate everything

Imagine you are working a conjunction assessment shift at a space operations center. Your ground radar just detected a new Resident Space Object (RSO) in low Earth orbit. Based on the radar cross-section measurement and preliminary orbital elements, your analyst has assigned probabilities to what this object might be:

You cannot wait for perfect information. You need to decide right now how much sensor time to allocate to continued tracking, which operators to notify, and how urgently to treat this object. Different object types require different responses. This situation — having to reason and act when you do not know the truth for certain — is exactly the problem probability is designed for.

What is a random variable?

A random variable is a number (or category) whose value you do not know yet, but where you know something about what values it could take.

The object type in your scenario is a random variable. It could be active satellite, debris, or dead satellite. Right now, before you have more sensor data, you are uncertain which it is. The "random" part just means you are uncertain. The "variable" part means it is a slot waiting to be filled with a value.

You will constantly encounter random variables in this curriculum:

• The action an adversary's satellite takes during a conjunction (uncertain because you cannot read their intentions)
• The reward an RL agent receives after making a move (uncertain because the environment is stochastic)
• The object type of a newly detected RSO (uncertain because your sensor is imperfect)
• The exact position of a satellite given imperfect tracking data (uncertain because measurement errors exist)

They are all the same idea. A quantity that depends on something you have not fully observed yet.

What is a distribution?

A distribution is the complete description of your uncertainty. It lists every possible value the random variable could take, and the probability of each one.

Your RSO analysis produced a distribution:

Notice the probabilities sum to 1.00. This is always required. The distribution has to account for all possibilities. One of these outcomes will happen (or already has happened, you just do not know which yet). The probabilities just describe how likely each one is.

Two distributions you will see constantly

Categorical distribution: a distribution over a finite list of named categories. The object-type example above is categorical. In reinforcement learning, your policy is a categorical distribution over actions: "there are four possible moves, with these probabilities."

Gaussian (Normal) distribution: a distribution over all real numbers, shaped like a bell curve. The position of a satellite you are tracking is often modeled as Gaussian: you have a best estimate of where it is, and uncertainty spreads symmetrically around that estimate. A satellite with position uncertainty of 0.2 km is much more precisely tracked than one with uncertainty of 5 km, even if both have the same best estimate.

The rules of probability

Will Kurt opens Bayesian Statistics the Fun Way with a deceptively simple point: before you can update beliefs with evidence, you need to know the two rules that govern how probabilities combine. These rules are the grammar of the language. Everything else — Bayes' rule, belief updates, joint distributions — is written in this grammar.

The sum rule: combining probabilities of alternatives

When events are mutually exclusive (at most one can happen at a time):

$$P(A\cup B)=P(A)+P(B)$$

Decoding:

• $P(A\cup B)$: "the probability that A or B occurs." The $\cup$ symbol is the set-theory union: "either A, or B, or both."
• For mutually exclusive events, "both" is impossible, so the formula simplifies to straight addition.

SSA example: RSO Alpha is either an active satellite (0.80) or debris (0.15) or a dead satellite (0.05). These categories are mutually exclusive — an object cannot be two types at once. So the probability it is "active satellite or debris" is simply 0.80 + 0.15 = 0.95.

When events are not mutually exclusive (both can happen simultaneously):

$$P(A\cup B)=P(A)+P(B)-P(A\cap B)$$

Decoding:

• $P(A\cap B)$: the probability that both A and B occur. The $\cap$ symbol is the intersection: "both A and B."
• You subtract $P(A\cap B)$ because you would otherwise count the overlap twice — once when you add $P(A)$ and once when you add $P(B)$.

SSA example: You want to know the probability that at least one of two RSOs — Alpha or Beta — experiences a conjunction event in the next 24 hours. Say $P(\text{Alpha conjunction})=0.30$ and $P(\text{Beta conjunction})=0.25$. If the two RSOs are in different orbital planes and their events are independent, $P(\text{both})=0.30\times 0.25=0.075$. So:

$$P(\text{Alpha or Beta})=0.30+0.25-0.075=0.475$$

Without subtracting the overlap, you would overcount the scenarios where both have conjunctions.

The product rule: combining probabilities of simultaneous events

For independent events (the outcome of one does not change the probability of the other):

$$P(A\cap B)=P(A)\times P(B)$$

Decoding:

• This says: if A and B have nothing to do with each other, the probability they both occur is the product of their individual probabilities.
• Independence is a model assumption. It is often approximately right (two RSOs in different planes) and sometimes dangerously wrong (two sensors sharing the same atmospheric perturbation).

import torch

# Sum rule: mutually exclusive (object type categories)
p_active = torch.tensor(0.80)
p_debris = torch.tensor(0.15)
p_active_or_debris = p_active + p_debris
print(f"P(active or debris): {p_active_or_debris.item():.2f}")  # 0.95

# Sum rule: non-mutually-exclusive (conjunction events for two RSOs)
p_alpha_conj = torch.tensor(0.30)
p_beta_conj  = torch.tensor(0.25)

# Assuming independence, compute the overlap first
p_both_conj  = p_alpha_conj * p_beta_conj  # product rule
p_either_conj = p_alpha_conj + p_beta_conj - p_both_conj
print(f"P(Alpha or Beta conjunction): {p_either_conj.item():.3f}")  # 0.475

# Verify: P(neither) = (1 - 0.30) * (1 - 0.25) = 0.525, so P(at least one) = 0.475
p_neither = (1 - p_alpha_conj) * (1 - p_beta_conj)
print(f"P(neither): {p_neither.item():.3f}")          # 0.525
print(f"Sum check:  {(p_either_conj + p_neither).item():.3f}")  # 1.000

Joint and marginal probability

Distributions over single variables are only the beginning. In SSA, most interesting questions involve two or more variables together: "what type of object is it and what orbital regime is it in?" The tools for this are joint and marginal probability.

Joint probability

Joint probability $P(X=x,Y=y)$ is the probability that two random variables simultaneously take specific values. The comma means "and."

Here is a joint distribution over object type (X) and orbit regime (Y) for the objects in a hypothetical SSA catalog:

Each cell is a joint probability. $P(\text{active satellite, GEO})=0.23$: 23% of tracked objects are active satellites in GEO. The sum of the entire table equals 1.

Marginal probability

Marginal probability is what you get when you collapse (sum out) one variable to focus on the other.

The row totals give you the marginal distribution over object type: $P(\text{active satellite})=0.50$, $P(\text{debris})=0.35$, $P(\text{dead satellite})=0.15$. These are called "marginals" because, in printed tables, they traditionally appear in the margins.

The column totals give you the marginal distribution over orbit regime: $P(\text{LEO})=0.56$, $P(\text{MEO})=0.18$, $P(\text{GEO})=0.26$.

The relationship is:

$$P(X=x)=\sum _{y}P(X=x,Y=y)$$

"Sum over all values of Y to get the probability that X takes value x."

import torch

# Joint distribution as a 2D tensor: rows = object type, cols = orbit regime
# Rows: [active satellite, debris, dead satellite]
# Cols: [LEO, MEO, GEO]
joint = torch.tensor([
    [0.18, 0.09, 0.23],   # active satellite
    [0.28, 0.06, 0.01],   # debris
    [0.10, 0.03, 0.02],   # dead satellite
])

# Verify it sums to 1
print(f"Total probability mass: {joint.sum().item():.2f}")  # 1.00

# Marginal over object type: sum across orbit regimes (dim=1 collapses columns)
marginal_type = joint.sum(dim=1)
print(f"P(object type): {marginal_type.tolist()}")
# [0.50, 0.35, 0.15] — active sat, debris, dead sat

# Marginal over orbit regime: sum across object types (dim=0 collapses rows)
marginal_orbit = joint.sum(dim=0)
print(f"P(orbit regime): {marginal_orbit.tolist()}")
# [0.56, 0.18, 0.26] — LEO, MEO, GEO

# Conditional distribution: P(orbit | object type = debris)
# = joint[debris, :] / P(debris)
p_orbit_given_debris = joint[1, :] / marginal_type[1]
print(f"P(orbit | debris): {p_orbit_given_debris.tolist()}")
# Mostly LEO — debris concentrates in low orbits

You will use joint distributions heavily when you study POMDPs: the joint distribution over (hidden state, observation) is the raw material from which belief states are computed.

What is expectation? Building it from arithmetic

Now suppose each object type has an associated sensor priority score:

Question: what is the average priority score for this object, given your uncertainty about its type?

Here is how to think about it without any formulas yet. Suppose you processed 1,000 similar radar detections using this same probability model. Based on those probabilities, you would expect:

• About 800 to be active satellites (priority score 30)
• About 150 to be debris (priority score 90)
• About 50 to be dead satellites (priority score 80)

To find the average priority score across all 1,000 detections:

Total priority points from active satellites: 800 × 30 = 24,000
Total priority points from debris:            150 × 90 = 13,500
Total priority points from dead satellites:    50 × 80 =  4,000
                                              ─────────────────
Total priority points:                                   41,500

Average = 41,500 / 1,000 = 41.5

Now look at what those 800, 150, and 50 are. Divide each by 1,000 and you get 0.80, 0.15, and 0.05. Those are the probabilities. So the exact same arithmetic can be written more directly:

(0.80 × 30) + (0.15 × 90) + (0.05 × 80)
= 24.0 + 13.5 + 4.0
= 41.5

That is expectation. Multiply each value by its probability, then add up the products. The result is the probability-weighted average, called the expected value or expectation.

A few things to notice:

• The expected value (41.5) is not one of the possible values (30, 90, 80). That is fine. Expectation is a property of the distribution, not a prediction of any single outcome.
• If you actually processed that radar contact, you would see a priority score of 30, 90, or 80, nothing else. The 41.5 is what you should plan around on average, before you know which one you got.
• If the debris probability were much higher (say, 0.95), the expected priority would be much higher too. The expected value follows the probability mass.

The formula, built from the arithmetic you just did

Here is the same calculation written compactly. Let us use symbols to represent the quantities:

• Let $n$ be the number of possible outcomes (in our case, 3)
• Let $p_i$ be the probability of outcome $i$
• Let $x_i$ be the value (priority score) for outcome $i$

The expected value is written:

$$\mathbb{E}[X]=\sum _{i=1}^n{p}_i\cdot x_i$$

Decoding every symbol, one at a time:

$\mathbb{E}[X]$: Read this as "the expected value of X" or just "E of X." The double-struck capital E is a conventional notation for "take the expectation of." X is the random variable (our priority score). The brackets just mean we are asking for the expectation of that particular thing.

${\sum }_{i=1}^n$: This is the capital Greek letter sigma, used here as a summation sign. Read it as "add up the following thing for every i, starting at i = 1 and ending at i = n." It is literally a for loop:

total = 0
for i in range(1, n + 1):
    total += p_i * x_i

$p_i$: The probability of outcome i. The subscript i (written below and slightly to the right of p) connects this probability to the i-th outcome. When i = 1, this is the probability of outcome 1 (active satellite, 0.80). When i = 2, it is the probability of outcome 2 (debris, 0.15). And so on.

$x_i$: The value (priority score) for outcome i. Same subscript convention: x with subscript 1 is the priority score when outcome 1 occurs (30), x with subscript 2 is the score when outcome 2 occurs (90), and so on.

$p_i\cdot x_i$: The dot means multiplication. This is "probability of outcome i times value of outcome i."

Reading the whole formula in English: "For each possible outcome (from i = 1 to i = n), multiply its probability by its value. Add up all those products. That total is the expected value."

That is the calculation you already did by hand.

Expectation of a function

One more version you will see often. Instead of taking the expectation of a raw value, sometimes you take the expectation of a function applied to the outcome:

$$\mathbb{E}[f(X)]=\sum _{i=1}^n{p}_i\cdot f(x_i)$$

Here $f(x_i)$ means "apply the function f to outcome i, then use that result." For example, if $f(x)=x^2$, then $f(x_i)$ is the priority score squared.

In RL, $f$ is usually "the total reward you collect starting from this state." In CFR, $f$ is "the regret from taking this action." The structure is always the same: for each outcome, compute f of that outcome, weight by probability, sum up.

Variance: how spread out is the distribution?

Expectation gives you the average. But two distributions can have the same average while behaving very differently.

Scenario A: You always track active satellites, every single contact. Priority score is always 30. Expected priority: 30. Variance: zero. Your planning is perfectly predictable.

Scenario B: 50% chance of a priority-10 object, 50% chance of a priority-50 object. Expected priority: (0.5 × 10) + (0.5 × 50) = 30. Same average, but your actual experience swings between 10 and 50.

Variance measures the average squared distance from the expected value. "Squared distance" means you take the difference between an outcome and the expected value, then square it.

For Scenario B:

• Outcome 1 is priority 10. Distance from expected (30) is 10 - 30 = -20. Squared: 400.
• Outcome 2 is priority 50. Distance from expected (30) is 50 - 30 = +20. Squared: 400.
• Expected squared distance: (0.5 × 400) + (0.5 × 400) = 400.

So variance is 400. The square root of variance is the standard deviation: √400 = 20. A typical sample lands about 20 priority points away from the mean. In Scenario A, standard deviation is zero: you always land exactly on the mean.

Variance will come back in lesson 3 when it determines how noisy your Monte Carlo estimates are. High variance means you need more samples to get a reliable estimate.

The Law of Large Numbers

The connection between probability and long-run frequency is formalized by the Law of Large Numbers (LLN). Kneusel emphasizes this in Math for Deep Learning Chapter 2 as the justification for why sample-based methods work at all.

Formal statement: Let $X_1,X_2,\dots ,X_N$ be independent, identically distributed random variables, each with expected value $\mu$. Define the sample mean:

$${\bar{X}}_N=\frac{1}{N}\sum _{i=1}^N{X}_i$$

As $N\to \infty$, the sample mean converges to the true mean:

$${\bar{X}}_N\to \mu$$

Decoding:

• ${\bar{X}}_N$: the average of N actual observed values. This is a number you can compute from data.
• $\mu$: the true expected value $\mathbb{E}[X]$. This is a property of the distribution.
• The arrow means: as you draw more samples, the sample mean gets closer and closer to the true mean.

Why this matters for SSA: if you run a simulation of 100 conjunction events sampled from your uncertainty distribution, the average outcome (say, expected dwell time) will be close to but not exactly equal to the true expected dwell time. If you run 100,000 simulations, it will be much closer. The LLN guarantees convergence; the convergence rate (which depends on variance) determines how many samples you actually need.

Important contrast with Monte Carlo: the LLN tells you that the sample mean converges. It does not tell you how fast. Lesson 3 will show that Monte Carlo estimates converge at rate $1/\sqrt{N}$ — halving your error requires quadrupling your sample count. This slow convergence rate is both the limitation and the operational reality of simulation-based planning.

import torch

# Demonstrate LLN: priority score samples converging to the true expectation
probs           = torch.tensor([0.80, 0.15, 0.05])
priority_scores = torch.tensor([30.0, 90.0, 80.0])

# True expected value
true_mean = (probs * priority_scores).sum()
print(f"True expected priority: {true_mean.item():.2f}")  # 41.50

# Draw increasingly large samples and watch the sample mean converge
from torch.distributions import Categorical
dist = Categorical(probs=probs)

for n in [10, 100, 1_000, 10_000, 100_000]:
    indices = dist.sample((n,))                    # sample n object type indices
    scores  = priority_scores[indices]             # map indices to priority scores
    sample_mean = scores.mean()
    error = (sample_mean - true_mean).abs()
    print(f"  N={n:>7}: sample mean = {sample_mean.item():.3f}, "
          f"error = {error.item():.3f}")

# Typical output (results vary):
# N=     10: sample mean = 38.000, error = 3.500
# N=    100: sample mean = 40.200, error = 1.300
# N=  1,000: sample mean = 41.620, error = 0.120
# N= 10,000: sample mean = 41.491, error = 0.009
# N=100,000: sample mean = 41.502, error = 0.002

The sample mean gets steadily closer to 41.50 as N grows. Note that the improvement is not linear — going from N=10 to N=100 (10×) does not give 10× the accuracy. That $1/\sqrt{N}$ convergence rate is the reason large-scale simulations are expensive.

Continuous distributions: the Gaussian in depth

The Gaussian distribution is the dominant model for continuous uncertainty in SSA. Every sensor has measurement noise; every satellite position estimate comes with an uncertainty covariance. Understanding the Gaussian's structure is not optional.

The 68-95-99.7 rule

For a Gaussian with mean $\mu$ and standard deviation $\sigma$:

• 68% of outcomes fall within $\mu \pm 1\sigma$
• 95% of outcomes fall within $\mu \pm 2\sigma$
• 99.7% of outcomes fall within $\mu \pm 3\sigma$

This rule lets you translate between "standard deviations" and "probability." If your conjunction analysis says the miss distance is Gaussian with mean 5.0 km and $\sigma =1.5$ km, then:

• 68% of conjunction geometries will have miss distance between 3.5 and 6.5 km
• 95% will be between 2.0 and 8.0 km
• 99.7% will be between 0.5 and 9.5 km

If the hard-body radius of the two objects sums to 0.01 km, the probability of a collision is the probability mass below that threshold — far out in the left tail. That is a numerical computation, but the 68-95-99.7 rule gives you the right intuition before you do the math.

Satellite position uncertainty as a Gaussian covariance

In three-dimensional space, position uncertainty is not captured by a single number. A satellite tracked by two radar sites will have better cross-track than along-track precision, and better range precision than angular precision. The full description is a covariance matrix — a 3×3 symmetric positive-definite matrix where the diagonal entries give per-axis variance and the off-diagonal entries capture correlations between axes.

When you read the standard conjunction message format (CCSDS CDM), the position covariance is one of the first data fields. The 1-sigma ellipsoid defined by that covariance is the Gaussian uncertainty region. The probability of collision is the integral of the combined position uncertainty distribution over the combined hard-body volume — a Gaussian integral in 6D position space.

For a 1D version, the Gaussian probability density function is:

$$f(x)=\frac{1}{\sigma \sqrt{2\pi }}\exp \left(-\frac{(x-\mu {)}^2}{2{\sigma }^2}\right)$$

Decoding:

• $\mu$: the mean (center of the bell curve). For a satellite position, this is the best-estimated position.
• $\sigma$: the standard deviation. Larger $\sigma$ means wider uncertainty.
• $\exp (\cdot )$: the exponential function $e^{(\cdot )}$. It is always positive, which keeps the density positive.
• $\frac{1}{\sigma \sqrt{2\pi }}$: a normalizing constant that ensures the total area under the curve equals 1.

import torch
from torch.distributions import Normal

# Model along-track position uncertainty for a tracked RSO
# mu: best-estimated along-track position offset from predicted (km)
# sigma: 1-sigma position uncertainty (km)
mu    = torch.tensor(0.0)    # centered on the prediction
sigma = torch.tensor(1.5)    # 1.5 km 1-sigma uncertainty

dist = Normal(loc=mu, scale=sigma)

# Demonstrate 68-95-99.7 rule by sampling
samples = dist.sample((100_000,))

within_1sigma = ((samples - mu).abs() <= sigma).float().mean()
within_2sigma = ((samples - mu).abs() <= 2 * sigma).float().mean()
within_3sigma = ((samples - mu).abs() <= 3 * sigma).float().mean()

print(f"Fraction within 1σ: {within_1sigma.item():.3f}  (expected: 0.683)")
print(f"Fraction within 2σ: {within_2sigma.item():.3f}  (expected: 0.954)")
print(f"Fraction within 3σ: {within_3sigma.item():.3f}  (expected: 0.997)")

# Compute log-probability (useful for training neural networks)
# A position measurement of 1.0 km from the predicted position:
measurement = torch.tensor(1.0)
log_prob = dist.log_prob(measurement)
print(f"\nLog-probability of 1.0 km offset: {log_prob.item():.3f}")
print(f"Probability density at 1.0 km:    {log_prob.exp().item():.4f}")

# Compare two objects with different uncertainty levels
tight_dist = Normal(0.0, 0.2)   # well-tracked object, 0.2 km 1-sigma
loose_dist = Normal(0.0, 5.0)   # poorly tracked, 5 km 1-sigma

# Probability of being within 0.1 km of predicted position (rough collision zone)
from torch.distributions import Normal
tight_prob = tight_dist.cdf(torch.tensor(0.1)) - tight_dist.cdf(torch.tensor(-0.1))
loose_prob = loose_dist.cdf(torch.tensor(0.1)) - loose_dist.cdf(torch.tensor(-0.1))
print(f"\nP(within 0.1 km): tight track = {tight_prob.item():.4f}, "
      f"loose track = {loose_prob.item():.4f}")
# The tightly tracked object has much higher probability density at any specific point

The torch.distributions.Normal class is the building block for many ML loss functions — Gaussian negative log-likelihood is the MSE loss in disguise. When you later train a neural network to predict position estimates with uncertainty, you will be maximizing exactly this log-probability.

Code

import torch
from torch.distributions import Categorical

# Our RSO probability estimate.
probs = torch.tensor([0.80, 0.15, 0.05])
dist = Categorical(probs=probs)

# Sample from the distribution: returns 0 (active sat), 1 (debris), or 2 (dead sat).
sample = dist.sample()
print(f"Sampled object type index: {sample.item()}")

# Sample many times to see the frequencies.
many_samples = dist.sample(sample_shape=(10_000,))
for i, label in enumerate(["Active sat", "Debris", "Dead sat"]):
    freq = (many_samples == i).float().mean()
    print(f"  {label}: {freq:.3f}  (expected: {probs[i]:.3f})")

Computing expected priority directly:

import torch

probs           = torch.tensor([0.80, 0.15, 0.05])
priority_scores = torch.tensor([30.0, 90.0, 80.0])

# E[priority] = sum of (p_i * x_i).
# Step 1: multiply each probability by its priority score.
products = probs * priority_scores
print(f"Products:        {products.tolist()}")  # [24.0, 13.5, 4.0]

# Step 2: sum the products.
expected = products.sum()
print(f"Expected priority: {expected.item()}")  # 41.5

Notice how the Python arithmetic directly mirrors the formula. probs * priority_scores is the elementwise multiplication of all the $p_i\cdot x_i$ terms. .sum() is the $\sum$ symbol.

Worked example: dwell time planning across two RSOs

You are planning sensor dwell time for two simultaneously tracked RSOs on an upcoming pass. Each object type requires different dwell times:

Your current probability estimates:

Expected dwell for RSO Alpha:

Step 1, for each object type, multiply probability by dwell time:

• Active satellite: 0.70 × 5 = 3.50 seconds
• Debris: 0.20 × 15 = 3.00 seconds
• Dead satellite: 0.10 × 10 = 1.00 second

Step 2, sum:

• 3.50 + 3.00 + 1.00 = 7.5 seconds expected dwell

Expected dwell for RSO Beta:

Step 1:

• Active satellite: 0.10 × 5 = 0.50 seconds
• Debris: 0.80 × 15 = 12.00 seconds
• Dead satellite: 0.10 × 10 = 1.00 second

Step 2:

• 0.50 + 12.00 + 1.00 = 13.5 seconds expected dwell

Total expected dwell: 7.5 + 13.5 = 21 seconds for this pass.

If your radar has 30 seconds of dwell capacity, you are comfortable. If it has 15 seconds, you have a prioritization problem to solve. Expectation gives you the planning number.

import torch

dwell_times = torch.tensor([5.0, 15.0, 10.0])
alpha_probs = torch.tensor([0.70, 0.20, 0.10])
beta_probs  = torch.tensor([0.10, 0.80, 0.10])

alpha_dwell = (alpha_probs * dwell_times).sum()
beta_dwell  = (beta_probs  * dwell_times).sum()

print(f"Alpha expected dwell: {alpha_dwell.item():.1f}s")  # 7.5s
print(f"Beta expected dwell:  {beta_dwell.item():.1f}s")   # 13.5s
print(f"Total:                {(alpha_dwell + beta_dwell).item():.1f}s")  # 21.0s

Key Takeaways

• Probability is a complete description of uncertainty, not just a single number. A distribution over object types, orbit regimes, or sensor readings tells you the full range of what could be true and how likely each possibility is. Every algorithm in this curriculum manipulates distributions, not point guesses.
• The sum and product rules are the foundation. $P(A\cup B)=P(A)+P(B)-P(A\cap B)$ and $P(A\cap B)=P(A)\times P(B)$ for independent events. Before you can do Bayes' rule or compute likelihoods, you need these two rules working fluently.
• Joint distributions capture correlations between variables. $P(\text{object type, orbit regime})$ is more informative than either marginal alone. Marginalizing (summing over one variable) recovers the individual distributions. In SSA, ignoring joint structure means treating orbital regime and object type as independent when they may not be.
• Expectation is a planning tool, not a prediction. The expected priority score (41.5) is not a value you will ever observe. It is the average you should plan around when facing many decisions under the same uncertainty. RL value functions are expectations; so are the cost estimates in dwell time planning.
• The Law of Large Numbers guarantees that sample averages converge to expectations, but slowly. Error shrinks at rate $1/\sqrt{N}$: to halve the error you must quadruple the sample count. This is why Monte Carlo methods require careful variance management — lesson 3 picks this up directly.
• Gaussian uncertainty is the default model for satellite position and sensor noise. The 68-95-99.7 rule gives you fast intuition about what any $\sigma$ value means in practice. When you see a conjunction probability computed from a covariance matrix, it is computing the integral of a Gaussian over the collision zone — the same math as Normal.cdf() in PyTorch.

Quiz

Lesson 2: Conditional Probability and Bayes' Rule

Module: ML and Game Theory for Space Power — M01: Foundations Source: Bayesian Statistics the Fun Way — Will Kurt, Chapters 3–5 (Conditional Probability, Bayes' Rule, and Sequential Updates); Math for Deep Learning — Ronald T. Kneusel, Chapter 2 (Probability and Conditional Probability)

Where this fits

In partially observable settings, which describes almost every real SSA scenario and every game with hidden information, an agent maintains a belief: a probability distribution over what it cannot directly observe. Every time a new observation arrives, that belief gets updated. The mechanism for that update is Bayes' rule. When you later read about belief states in POMDPs, reach probabilities in CFR, or opponent modeling in multi-agent RL, you are reading about Bayes' rule with domain-specific packaging. This lesson is the unpackaged version.

A scenario: classifying an unknown radar contact

Your ground radar just flagged a new contact. You can measure the object's radar cross-section (RCS), which gives you some evidence about what type of object it might be. But RCS is noisy and imperfect: a debris fragment and a small satellite can produce similar returns.

Before the measurement, your catalog tells you that in this particular orbital regime, the objects are distributed like this:

This is your starting belief. You believe there is a 60% chance the contact is a satellite, 30% chance it is debris, 10% chance it is a rocket body. You have not seen the RCS measurement yet.

Then the RCS measurement comes in. It shows a medium-small return. Your sensor physics models tell you how likely that specific measurement is for each object type:

Now you have new evidence. The question is: given that measurement, how should your beliefs change?

That question is Bayes' rule.

What is conditional probability?

Conditional probability is the probability of one thing given that you know another thing has happened.

The notation is $P(A\mid B)$, read as "probability of A given B." The vertical bar means "given that."

For your RCS example:

• $P(\text{debris}\mid \text{medium-small RCS})$ means: "what is the probability that this is debris, given that we observed a medium-small RCS return?"
• $P(\text{medium-small RCS}\mid \text{debris})$ means: "if this were debris, how likely is this particular RCS reading?"

These look similar but they are answering completely different questions. The first is what you want to know. The second is what your sensor model gives you. Bayes' rule connects them.

Conditioning means restricting your universe

Here is a concrete way to think about conditional probability.

Imagine you have a catalog of 1,000 past contacts in this orbital regime:

• 600 active satellites
• 300 debris
• 100 rocket bodies

Of those 600 active satellites, suppose 420 produced a medium-small RCS reading (that is 70% of 600). Of those 300 debris, suppose 60 produced a medium-small RCS reading (that is 20% of 300). Of those 100 rocket bodies, suppose 40 produced a medium-small RCS reading (that is 40% of 100).

Now your sensor reports a medium-small RCS. How many objects in the catalog showed that reading?

420 + 60 + 40 = 520 objects produced a medium-small RCS reading.

Of those 520 objects, how many were active satellites? 420. So:

$P(\text{active sat}\mid \text{medium-small RCS})=420/520\approx 0.808$

How many were debris? 60. So:

$P(\text{debris}\mid \text{medium-small RCS})=60/520\approx 0.115$

How many were rocket bodies? 40. So:

$P(\text{rocket body}\mid \text{medium-small RCS})=40/520\approx 0.077$

Your belief shifted. You started at 60% / 30% / 10%. After seeing the medium-small RCS, you are now at 80.8% / 11.5% / 7.7%. The measurement strongly favored active satellites (because satellites produce this return 70% of the time, while debris produce it only 20% of the time), so the satellite probability went up and debris went down.

Independence

Independence is the special case where knowing one thing tells you nothing about another thing.

Formal definition: events A and B are independent if and only if:

$$P(A\mid B)=P(A)$$

Decoding: "the probability of A, given that B happened, is the same as the probability of A before you knew about B." B is irrelevant to A. You can also write independence as $P(A\cap B)=P(A)\times P(B)$ — which is where the product rule from lesson 1 comes from. Both formulations say the same thing.

Conditional dependence

The opposite of independence is conditional dependence: knowing B changes your belief about A. In the RCS scenario, object type and RCS reading are dependent — knowing the type changes how likely you think a given RCS reading is, and knowing the reading changes how likely you think a given type is.

Dependence is the normal situation. Independence is a simplifying assumption you make when the dependence is negligible or when you lack the data to model it properly.

The SSA independence question: two radars vs. one atmosphere

Consider two independent radar sites, Site A (Colorado) and Site B (Alaska), each measuring the same RSO. If their noise processes are independent, you can use the product rule: the probability of both sites producing measurement errors above threshold is $P(\text{A error})\times P(\text{B error})$. That product is small, which is why multi-site fusion reduces false alarm rates.

But independence fails when both sites share a common cause. Correlated noise from the same atmospheric layer is a real failure mode: if a large ionospheric disturbance affects the entire continental US, both Site A and Site B will experience elevated range errors simultaneously. Their errors are now dependent — $P(\text{B error}\mid \text{A error})>P(\text{B error})$ — and treating them as independent will underestimate the probability of simultaneous bad measurements at both sites.

The operational implication is significant: if you design a conjunction assessment protocol that requires "two independent radar confirmations" to flag a high-priority conjunction, and your two radars are correlated by shared atmosphere, you are getting less confirmation than you think. The assumption of independence is a model choice, and it should be tested rather than assumed.

import torch

# Independent radars: P(both error) = product of marginal error rates
p_site_a_error = torch.tensor(0.05)
p_site_b_error = torch.tensor(0.04)

# Independence assumption: product rule
p_both_error_independent = p_site_a_error * p_site_b_error
print(f"P(both error | independent): {p_both_error_independent.item():.4f}")  # 0.0020

# Correlated radars: during ionospheric storm, P(B error | A error) is elevated
# Suppose during an ionospheric event, if A has an error, B has 40% error rate
p_b_given_a_error_correlated = torch.tensor(0.40)
p_both_error_correlated = p_site_a_error * p_b_given_a_error_correlated
print(f"P(both error | correlated):  {p_both_error_correlated.item():.4f}")   # 0.0200

# The correlated scenario produces 10x more simultaneous errors — a meaningful difference
# in a protocol that requires both radars to agree
ratio = p_both_error_correlated / p_both_error_independent
print(f"Ratio (correlated / independent): {ratio.item():.1f}x more simultaneous errors")

When independence fails and you do not know it, your probability estimates are wrong in a systematic direction — usually overconfident. This is the failure mode Will Kurt calls "naively combining evidence" in Bayesian Statistics the Fun Way Chapter 5.

The total probability formula

Bayes' rule has a denominator — $P(E)$ — that often looks mysterious. The law of total probability makes it concrete.

The formula:

$$P(E)=\sum _{i}P(E\mid H_i)\cdot P(H_i)$$

Decoding:

• $H_1,H_2,\dots$: a complete, mutually exclusive set of hypotheses. "Complete" means at least one is true. "Mutually exclusive" means at most one is true. Together they partition the space of possibilities.
• $P(E\mid H_i)$: the likelihood of the evidence under hypothesis $i$.
• $P(H_i)$: the prior probability of hypothesis $i$.
• The sum adds up contributions to $P(E)$ from each hypothesis, weighted by how probable that hypothesis is.

The law of total probability is the denominator in Bayes' rule because it answers: "what is the probability of seeing this evidence at all, summed over every possible explanation?" When you normalize the unnormalized posteriors, you are dividing by exactly this sum.

Worked example with a third sensor type

Extend the catalog scenario. Now there are three object types in the catalog, and you have received a specific RCS reading. What is the total probability of that reading?

$P(E)=0.420+0.060+0.040=0.520$

This says: if you sampled a random contact from this orbital regime and ran the RCS sensor, you would get a medium-small reading 52% of the time — across all the different object types combined.

Now add a fourth object type, "rocket body fragment," that your updated catalog recently identified with prior probability 0.05. When you add a new hypothesis, you have to renormalize the priors (they must sum to 1) and include the new type's likelihood in the total probability sum.

import torch

# Extended catalog with four object types
# Priors (must sum to 1 — renormalized to add rocket body fragment at 5%)
prior = torch.tensor([0.57, 0.285, 0.095, 0.05])
# Likelihoods P(medium-small RCS | each type)
# Rocket body fragments: small, tumbling — medium-small RCS is fairly common
likelihood = torch.tensor([0.70, 0.20, 0.40, 0.55])

# Joint probabilities P(E, H_i) = P(E|H_i) * P(H_i)
joint = prior * likelihood
print(f"Joint probabilities: {joint.tolist()}")

# Total probability of the evidence (denominator of Bayes' rule)
p_evidence = joint.sum()
print(f"P(evidence) = {p_evidence.item():.4f}")

# Posteriors
posterior = joint / p_evidence
labels = ["Active sat", "Debris", "Rocket body", "RB fragment"]
print("\nPosterior beliefs:")
for label, p in zip(labels, posterior.tolist()):
    print(f"  {label}: {p:.3f}")

# Note: the total probability changes when you add a new hypothesis type.
# If you had computed P(E) with only 3 types and now have 4, your normalization
# constant is different. This is why it matters to have a complete hypothesis set.

The practical lesson: the denominator of Bayes' rule is only correct when your hypothesis set is complete. If your catalog is missing a category of objects (say, fractured rocket body debris is not yet cataloged), your posteriors will be systematically wrong — they will distribute probability among the known types even when the true answer is "none of the above."

Bayes' rule: the formula

Bayes' rule is just the efficient way to do the catalog calculation you just did, without needing an actual catalog.

Here it is, first in words:

Updated belief = (how well the evidence fits this hypothesis) × (prior belief) / (total probability of this evidence)

Now with symbols. We call the hypothesis H (e.g., "this is debris") and the evidence E (e.g., "medium-small RCS reading"):

$$P(H\mid E)=\frac{P(E\mid H)\cdot P(H)}{P(E)}$$

Decoding each piece:

$P(H\mid E)$: The posterior. This is what we want: the probability of hypothesis H after seeing evidence E. "Posterior" means "after." Before the evidence, we had a prior. After the evidence, we have a posterior.

$P(H)$: The prior. This is what we believed about H before seeing the evidence. In the catalog example, this was 0.60 for active satellite, 0.30 for debris, 0.10 for rocket body. The word "prior" means "before."

$P(E\mid H)$: The likelihood. This is how probable the evidence is, assuming H is true. Your sensor model gives you this. "If this contact is debris, how likely is this RCS reading?" That is a likelihood.

$P(E)$: The marginal probability of the evidence, sometimes called the normalizing constant. This is the total probability of seeing this evidence, regardless of which hypothesis is true. In the catalog, it was 520/1000 = 0.52 (the fraction of contacts that produced a medium-small reading at all).

You calculate $P(E)$ by summing over all hypotheses: $$P(E)=P(E\mid H_1)\cdot P(H_1)+P(E\mid H_2)\cdot P(H_2)+P(E\mid H_3)\cdot P(H_3)+\dots$$

This just says: the total probability of seeing this evidence is the sum over each possible explanation, weighted by how likely each explanation was.

The shortcut: you usually do not compute $P(E)$ directly. Instead, compute the numerator ($P(E\mid H)\cdot P(H)$) for every hypothesis, then divide each by the sum. That sum is $P(E)$, and you get it for free as a byproduct of normalization.

Applying Bayes' rule step by step

Let us walk through the calculation systematically.

Step 1: Write down your priors.

Step 2: Write down the likelihoods. For each hypothesis, how probable is the evidence (medium-small RCS)?

Step 3: Multiply prior by likelihood for each hypothesis. This gives you the unnormalized posterior.

Step 4: Divide each unnormalized posterior by the total. The total (0.520) is $P(E)$. Dividing by it makes the posteriors sum to 1.

These match the catalog calculation from before. Active satellite went from 60% to 81%. Debris dropped from 30% to 12%. The RCS measurement was informative: it was much more likely under "active satellite" than under "debris," so it pushed probability mass toward the satellite hypothesis.

Code

import torch

# Step 1: Priors
prior = torch.tensor([0.60, 0.30, 0.10])  # active sat, debris, rocket body

# Step 2: Likelihoods P(medium-small RCS | each hypothesis)
likelihood = torch.tensor([0.70, 0.20, 0.40])

# Step 3: Unnormalized posterior = prior * likelihood
unnormalized = prior * likelihood
print(f"Unnormalized: {unnormalized.tolist()}")  # [0.42, 0.06, 0.04]

# Step 4: Normalize so they sum to 1
posterior = unnormalized / unnormalized.sum()
print(f"Posterior:    {posterior.tolist()}")
# approximately [0.808, 0.115, 0.077]

labels = ["Active sat", "Debris    ", "Rocket body"]
for label, p in zip(labels, posterior.tolist()):
    print(f"  {label}: {p:.3f}")

That four-line calculation is the complete Bayes update. Every belief update you will see in POMDPs and multi-agent RL follows this same structure.

Sequential updates: learning from multiple observations

Bayes' rule can be applied repeatedly. Each posterior becomes the new prior for the next observation.

Suppose after the RCS reading, you also get a photometric brightness measurement. Your sensor model says that this specific brightness reading would be observed with these probabilities:

Use the previous posterior as the new prior:

# Previous posterior becomes the new prior
new_prior = posterior  # [0.808, 0.115, 0.077]

# New likelihood from brightness measurement
likelihood_2 = torch.tensor([0.30, 0.50, 0.40])

# Bayes update (same four steps as before)
unnormalized_2 = new_prior * likelihood_2
posterior_2 = unnormalized_2 / unnormalized_2.sum()

for label, p in zip(labels, posterior_2.tolist()):
    print(f"  {label}: {p:.3f}")

The brightness reading favored debris (50% likely for debris vs 30% for active satellite), so the active satellite probability will drop somewhat and debris will recover. Two observations have nudged our belief, and we could apply a third, fourth, and so on.

Three measurements: order independence of Bayesian updates

Now add a third measurement: the albedo reading from a photometric sensor. Albedo measures how reflective the object is. Your sensor model provides:

A key property of Bayes' rule is that the order in which you apply measurements does not change the final result. Whether you apply RCS first, then brightness, then albedo — or albedo first, then RCS, then brightness — you will arrive at the same posterior. This is not obvious but follows directly from the commutativity of multiplication: the joint probability of all measurements and the hypothesis is the same product regardless of the order you write the terms.

import torch

# Starting prior
prior = torch.tensor([0.60, 0.30, 0.10])
labels = ["Active sat", "Debris    ", "Rocket body"]

# Three measurement likelihoods
likelihood_rcs        = torch.tensor([0.70, 0.20, 0.40])
likelihood_brightness = torch.tensor([0.30, 0.50, 0.40])
likelihood_albedo     = torch.tensor([0.60, 0.25, 0.50])

def bayes_update(prior, likelihood):
    """One step of Bayes update: multiply, normalize, return posterior."""
    unnorm = prior * likelihood
    return unnorm / unnorm.sum()

# Order 1: RCS -> brightness -> albedo
p_order1 = prior
p_order1 = bayes_update(p_order1, likelihood_rcs)
p_order1 = bayes_update(p_order1, likelihood_brightness)
p_order1 = bayes_update(p_order1, likelihood_albedo)

# Order 2: albedo -> brightness -> RCS
p_order2 = prior
p_order2 = bayes_update(p_order2, likelihood_albedo)
p_order2 = bayes_update(p_order2, likelihood_brightness)
p_order2 = bayes_update(p_order2, likelihood_rcs)

# Order 3: all three likelihoods multiplied at once, then normalized
# This is mathematically equivalent to doing them in any sequence
unnorm_all = prior * likelihood_rcs * likelihood_brightness * likelihood_albedo
p_order3   = unnorm_all / unnorm_all.sum()

print("Posterior after all three measurements:")
print(f"  Order (RCS, bright, albedo):  {p_order1.tolist()}")
print(f"  Order (albedo, bright, RCS):  {p_order2.tolist()}")
print(f"  All at once:                  {p_order3.tolist()}")
# All three should be identical (up to floating point rounding)

print("\nMax difference between orders:", (p_order1 - p_order2).abs().max().item())
# Should be < 1e-6

print("\nFinal belief state:")
for label, p in zip(labels, p_order1.tolist()):
    print(f"  {label}: {p:.4f}")

Order independence has a practical consequence for SSA pipelines: you do not need to wait for all sensors to report before starting to update your belief. Each sensor measurement can be processed as it arrives, and the running posterior reflects all evidence received so far. A tracking filter that receives RCS from Radar A, then albedo from an optical telescope, then a second RCS from Radar B produces the same final belief as one that batches all three.

The only caveat: each measurement must be conditionally independent given the hypothesis — meaning the measurement noise of one sensor does not depend on the measurement noise of another, once you know the object type. When sensors share common-mode errors (same atmosphere, same timing reference), this conditional independence breaks down and order independence no longer holds cleanly.

When Bayes is hard: strong priors dominate

Bayes' rule always works correctly. But it can produce results that feel wrong until you understand the mechanism.

The problem: when the prior is very strong, a small number of observations cannot overcome it. This is not a bug — it is the mathematically correct behavior. But it has serious operational implications.

A numerical demonstration

Suppose your catalog assigns a 99% prior probability that an object is an active satellite and only 1% prior probability that it is debris. This is a strong prior. Now you receive an RCS measurement that is much more consistent with debris than with satellites:

Posterior: Active satellite = 0.0495 / 0.0575 ≈ 86%, Debris ≈ 14%.

Even though the likelihood ratio strongly favors debris (0.80 vs 0.05 — a 16-to-1 ratio), the strong prior keeps the satellite hypothesis in front. The prior was 99-to-1 for satellite; the likelihood is 16-to-1 for debris; the posterior is about 6-to-1 for satellite. The prior dominated.

How many observations to overcome a strong prior

To overcome a prior of 99:1 ($P(H)=0.99$), you need evidence strong enough that the cumulative likelihood ratio exceeds 99. If each observation has a likelihood ratio of 16:1 in favor of debris, you need approximately:

$$\text{number of observations}\approx \frac{\log (99)}{\log (16)}\approx \frac{4.6}{2.8}\approx 1.6$$

So about two observations with that likelihood ratio would flip the belief. But if the likelihood ratio per observation is weaker — say 2:1 — you need:

$$\frac{\log (99)}{\log (2)}\approx \frac{4.6}{0.69}\approx 6.6$$

About seven observations with a modest 2:1 likelihood ratio are needed.

The catalog-is-wrong failure mode

This has an immediate operational consequence: if your SSA catalog is wrong, sensors cannot easily correct it.

Suppose a satellite has been mislabeled as an active satellite in the catalog when it actually went dead (stopped maneuvering) two years ago. The catalog entry has been reinforced by thousands of routine observations. The prior on "active satellite" is effectively 0.9999 — extremely strong, because the catalog entry has been confirmed so many times.

Now a new observation comes in that looks inconsistent with an active satellite (no RF emission detected, unexpected brightness change). Bayes' rule will update the belief, but the update will be tiny. It takes many anomalous observations, processed by an analyst who is looking for the anomaly, to overcome a deeply entrenched catalog entry. This is not an algorithmic failure — it is Bayes' rule working correctly given the evidence history. The fix is not a different algorithm; it is a process that actively hunts for inconsistencies rather than waiting for the posterior to shift organically.

import torch

def bayes_update(prior, likelihood):
    unnorm = prior * likelihood
    return unnorm / unnorm.sum()

# Strong prior: catalog says 99% active satellite
prior = torch.tensor([0.99, 0.01])
labels = ["Active sat", "Debris"]

# Each observation: likelihood ratio 2-to-1 in favor of debris
# P(this observation | active sat) = 0.33, P(this observation | debris) = 0.67
likelihood_per_obs = torch.tensor([0.33, 0.67])

print("Belief evolution with strong prior (99% active sat):")
print(f"  Start:           Active={prior[0]:.4f}, Debris={prior[1]:.4f}")

belief = prior.clone()
for obs_count in range(1, 15):
    belief = bayes_update(belief, likelihood_per_obs)
    if obs_count in [1, 2, 3, 5, 7, 10, 14]:
        print(f"  After {obs_count:2d} obs:    Active={belief[0]:.4f}, Debris={belief[1]:.4f}")

# Show how a much stronger likelihood ratio accelerates the update
print("\nSame prior, but stronger likelihood ratio (16:1 for debris):")
belief_strong = prior.clone()
likelihood_strong = torch.tensor([0.05, 0.80])
# Renormalize: we only care about the ratio, not the absolute values
# (the normalization step handles this)
for obs_count in range(1, 5):
    belief_strong = bayes_update(belief_strong, likelihood_strong)
    print(f"  After {obs_count} obs:    Active={belief_strong[0]:.4f}, Debris={belief_strong[1]:.4f}")

The output shows slow convergence with weak evidence and fast convergence with strong evidence — both are correct Bayesian behavior. The implication for system design: if you want sensors to correct catalog errors quickly, you need either very informative sensor models (high likelihood ratios) or active outlier detection that flags objects whose posterior is evolving rapidly away from their catalog entry.

The base rate trap: the most common mistake in probabilistic reasoning

There is one error so common and so important that it deserves its own section.

The mistake: ignoring the prior and treating the likelihood as if it were the posterior.

Suppose someone tells you "our sensor has a 90% detection rate for rocket bodies" and you detect a signal. A naive interpretation: "90% chance this is a rocket body."

This is almost always wrong. The correct interpretation requires the prior.

If rocket bodies represent only 1% of all objects in this orbital regime (prior = 0.01), then even with a 90% detection rate, most signals will not be rocket bodies. The vast majority of the time, the sensor is detecting one of the 99% non-rocket-body objects at whatever rate that detection applies.

Bayes' rule mechanically prevents this error because the prior appears explicitly in the formula. The moment you write down $P(H)=0.01$ before doing the calculation, you cannot forget it.

For SSA, this matters practically. If you are looking for adversarial satellite maneuvers and only 1 in 1,000 maneuvers is adversarial (with 999 being routine station-keeping), a detector that is 95% accurate at identifying adversarial maneuvers will still produce many false positives if you ignore the base rate.

Why this matters going forward

In partially observable games, an agent cannot see the full game state. All it has is its own actions and the observations it has received. At each step it maintains a belief over what the hidden state might be, and it updates that belief using Bayes' rule every time a new observation arrives. This is the belief state in a POMDP.

CFR in extensive-form games uses "reach probabilities" that track, for each decision point, how likely it is that the game reached this point under a particular strategy. These are a form of conditional probability, and updating them follows the same logic you just practiced.

When you eventually read code that says belief_state.update(observation) or reach_prob *= policy[action], you will know what is happening inside those lines.

Key Takeaways

• Conditional probability restricts your universe. $P(A\mid B)$ asks: among all worlds where B is true, how many also have A? This mental model — filtering down to the relevant subset — is the right way to reason about any sensor measurement or game observation that updates your beliefs.
• Independence is a model choice, not a fact. Two sensors may be independent under normal conditions and highly correlated during atmospheric events. Treating correlated measurements as independent underestimates the probability of simultaneous failures. Always ask what shared causes could violate your independence assumptions.
• The law of total probability makes the Bayes denominator concrete. $P(E)={\sum }_{i}P(E\mid H_i)P(H_i)$ is not a formula to memorize — it is the answer to "what fraction of all contacts would produce this reading?" If your hypothesis set is incomplete, your denominator is wrong, and so are all your posteriors.
• Sequential Bayesian updates are order-independent (given conditionally independent measurements). You can apply observations as they arrive without waiting to batch them. This is what makes online tracking filters practical: each new sensor report is a Bayes step, and the running posterior is always the best current estimate.
• Strong priors resist correction. A catalog entry reinforced by thousands of observations may take dozens of anomalous readings to overturn. This is mathematically correct but operationally dangerous: catalog errors persist. Active anomaly detection — looking for objects whose posterior is drifting unexpectedly — matters more than assuming the catalog will self-correct through routine observations.
• The base-rate error is the most common mistake. Likelihoods are not posteriors. A sensor that is "90% accurate" does not produce 90% correct classifications if the prior for the target class is 1%. Bayes' rule with an explicit prior is the only reliable protection against this mistake.

Quiz

Lesson 3: Sampling and Monte Carlo Estimation

Module: Foundations — M01: Mathematical Foundations for ML and Game Theory Source: Reinforcement Learning: An Introduction — Sutton & Barto, Chapter 5 (Monte Carlo Methods); Probabilistic Theory of Pattern Recognition — Devroye, Györfi, Lugosi, Chapter 2 (Concentration Inequalities); Monte Carlo Statistical Methods — Robert & Casella, Chapter 3 (Monte Carlo Integration)

Where this fits

In lesson 1 you learned that expectation is a weighted sum over all possible outcomes. That works perfectly when there are three object types or six dice faces. It becomes completely impossible when there are millions of possible game trajectories, or when the quantity you want to average does not have a tidy formula. Monte Carlo estimation is how you compute expectations when direct computation is hopeless. MCTS, MCCFR, and the REINFORCE policy gradient estimator are all, at their core, Monte Carlo estimation with extra structure on top. This lesson is where those algorithms get their conceptual foundation.

The problem: some expectations cannot be computed directly

Consider a simple version of an SSA planning problem. You are deciding whether to maneuver a satellite now or wait. The outcome depends on:

• Whether an approaching RSO turns out to be debris or an active satellite (two possibilities)
• What orbital regime it settles into after the next atmospheric drag update (many possibilities)
• What other operators in the region decide to do (unknown)
• Small stochastic perturbations from solar radiation pressure (continuous, infinite possibilities)

The exact expected cost of maneuvering versus not maneuvering involves averaging over all combinations of these factors. If each factor has only 10 possible values, you have 10 × 10 × 10 × 10 = 10,000 combinations to sum over. With 20 factors, you have 10^20 combinations, which is more than the number of atoms in a gram of carbon. With continuous values, it is literally infinite.

In game theory the situation is similar. A chess game has roughly 10^120 possible game states. Computing the exact expected value of a move by summing over all of them is not possible in any practical sense.

Monte Carlo estimation is the answer: instead of summing over all possibilities, you draw a random sample, compute the quantity for that sample, and repeat. The average of many samples is a reliable estimate of the true expectation.

The core idea: sampling and averaging

Here is the key insight, stated plainly:

If you cannot enumerate all outcomes, simulate some of them and average the results.

The average of your simulated outcomes will be close to the true expectation. The more samples you take, the closer it will be.

Let us see this concretely with a simple SSA-flavored example before we look at any formulas.

Scenario: Your satellite is about to pass through a debris field. You estimate there is a 30% chance of a collision with a piece of debris large enough to cause damage. If there is a collision, the mission cost is 1,000 (arbitrary units). If there is no collision, the cost is 0.

The expected cost is straightforward here: 0.30 × 1,000 + 0.70 × 0 = 300. You can compute it directly.

But suppose you did not know how to compute it directly, and instead you simulated 10 passes through the debris field:

• Pass 1: no collision (cost 0)
• Pass 2: no collision (cost 0)
• Pass 3: collision (cost 1,000)
• Pass 4: no collision (cost 0)
• Pass 5: no collision (cost 0)
• Pass 6: no collision (cost 0)
• Pass 7: collision (cost 1,000)
• Pass 8: no collision (cost 0)
• Pass 9: no collision (cost 0)
• Pass 10: no collision (cost 0)

Average cost: (0 + 0 + 1000 + 0 + 0 + 0 + 1000 + 0 + 0 + 0) / 10 = 2000 / 10 = 200.

That is not exactly 300, but it is in the right ballpark. With 10 samples, you got 2 collisions instead of the "expected" 3. With 1,000 samples you would typically get something much closer to 300.

The formula for Monte Carlo estimation

Suppose you want to estimate $\mathbb{E}[f(X)]$, the expected value of a function $f$ applied to a random variable $X$.

Instead of computing the infinite (or intractable) sum, you:

1. Draw $N$ samples $x_1,x_2,\dots ,x_N$ from the distribution of $X$
2. Compute $f(x_i)$ for each sample
3. Average the results

The Monte Carlo estimate is written:

$$\hat{\mu }=\frac{1}{N}\sum _{i=1}^{N}f(x_i)$$

Decoding the symbols:

$\hat{\mu }$: Read as "mu hat." The Greek letter mu ($\mu$) is conventional notation for a mean or expected value. The hat ($\hat{}$) means "estimated." So $\hat{\mu }$ is "our estimate of the true mean." The hat distinguishes the estimate (which we computed from samples) from the true value (which we might never know exactly).

$\frac{1}{N}$: Divide by $N$, the number of samples. This is just computing an average.

${\sum }_{i=1}^N$: Add up the following thing for i from 1 to N. Same summation sign as in lesson 1, now looping over samples rather than outcomes.

$f(x_i)$: Apply function $f$ to the i-th sample. In the debris example, f(x) = the cost of that pass (1,000 if collision, 0 if not).

Reading it in English: "Draw N samples, compute f for each one, add them all up, divide by N to get the average." That is the entire thing.

Two properties that make this useful

Property 1: The estimate is unbiased.

"Unbiased" means that if you ran your Monte Carlo estimator many times (each time drawing a fresh set of N samples), the average of your estimates would equal the true expectation. There is no systematic error in one direction or the other. Individual runs might be too high or too low, but they are wrong in a random, symmetric way.

Property 2: The error shrinks as $1/\sqrt{N}$.

The standard error (a measure of how wrong a typical estimate is) follows this formula:

$$\text{standard error}=\frac{\sigma }{\sqrt{N}}$$

Where $\sigma$ (sigma, the Greek lowercase letter for standard deviation) describes how spread out your samples are, and $N$ is the number of samples.

Decoding: the standard error gets smaller as N gets bigger. But it shrinks by a square root factor. To get twice as accurate, you need four times as many samples. To get ten times as accurate, you need one hundred times as many samples.

Let us see what that looks like numerically for the debris example:

At 10 samples, your estimate of a 30% probability might range from 15% to 45%. At 100,000 samples, it is accurate to within a tenth of a percent. The cost of that accuracy is 10,000 times more computation.

This 1/√N trade-off is fundamental. It is why MCTS does many rollouts to improve its value estimates. It is why MCCFR accumulates regret over many iterations rather than converging in a handful. Samples are cheap compared to exact computation, but they are not free.

The Central Limit Theorem: why uncertainty quantification works

The 1/√N trade-off tells us the error shrinks. But what is the shape of that error? Could estimates be wildly skewed in one direction? The Central Limit Theorem (CLT) answers this — and the answer is what makes MC estimation not just useful, but scientifically rigorous.

The CLT, stated plainly:

Take N independent random variables $X_1,X_2,\dots ,X_N$, all drawn from the same distribution with mean $\mu$ and variance ${\sigma }^2$. Their average

$${\bar{X}}_N=\frac{1}{N}\sum _{i=1}^N{X}_i$$

is itself a random variable. As N grows, the distribution of ${\bar{X}}_N$ approaches a Normal distribution centered at $\mu$ with standard deviation $\sigma /\sqrt{N}$, regardless of what the original distribution looks like.

Decoding:

${\bar{X}}_N$: The sample mean of N draws — our Monte Carlo estimate $\hat{\mu }$. It is random because different draws produce different averages.

"Approaches a Normal distribution": The bell curve. Even if each individual sample comes from a wildly non-Normal distribution (like a Bernoulli, which only takes values 0 or 1), the average of many such samples looks Normal.

"Regardless of the original distribution shape": This is the remarkable part. It does not matter whether you are averaging collision indicators (Bernoulli), damage costs (heavy-tailed), or orbital period perturbations (roughly Normal). The sample mean is always approximately Normal for large N.

Why this validates MC estimation. Our MC estimate $\hat{\mu }$ is the sample mean. The CLT tells us that $\hat{\mu }$ is approximately Normally distributed around the true mean $\mu$. This means we can write:

$$\hat{\mu }\approx \mathcal{N}\left(\mu ,\frac{{\sigma }^2}{N}\right)$$

And because Normal distributions are well-understood, we can compute confidence intervals directly:

$$\mu \in \left[\hat{\mu }-1.96\frac{\hat{\sigma }}{\sqrt{N}},\hat{\mu }+1.96\frac{\hat{\sigma }}{\sqrt{N}}\right]\text{with 95\% confidence}$$

where $\hat{\sigma }$ is the sample standard deviation, estimated from the same N samples. You do not need to know the true $\sigma$ in advance.

Practical consequence: after running your MC estimator, you can quote not just the estimate but its uncertainty. In SSA terms: "our MC estimate of conjunction probability is 0.0043, with a 95% CI of [0.0038, 0.0048] based on 10,000 simulations." That kind of statement is only possible because of the CLT.

import torch

torch.manual_seed(0)

# Demonstrate the CLT: sample means from a Bernoulli(0.3) distribution
# are approximately Normal, regardless of the binary shape of individual samples.

p_true = 0.30          # true collision probability
N_per_estimate = 500   # samples per MC estimate
n_estimates = 10_000   # how many estimates to draw

# Each row: one MC experiment of N_per_estimate coin flips
samples = torch.bernoulli(torch.full((n_estimates, N_per_estimate), p_true))

# Each MC estimate is the mean of one row
sample_means = samples.mean(dim=1)   # shape: (10_000,)

# Expected distribution: Normal(mu=0.30, sigma=sqrt(p*(1-p)/N))
theoretical_std = (p_true * (1 - p_true) / N_per_estimate) ** 0.5

print(f"True mean:                {p_true:.4f}")
print(f"Mean of MC estimates:     {sample_means.mean().item():.4f}")  # ≈ 0.30
print(f"Std of MC estimates:      {sample_means.std().item():.6f}")   # ≈ theoretical_std
print(f"Theoretical std (CLT):    {theoretical_std:.6f}")

# Verify normality: check that 95% of estimates fall within 1.96 std of the mean
z_scores = (sample_means - p_true) / theoretical_std
within_95 = ((z_scores.abs() <= 1.96).float().mean().item())
print(f"Fraction within 1.96σ:    {within_95:.4f}")  # should be ≈ 0.95

# Compute a confidence interval for one MC run
single_run = samples[0]
estimate = single_run.mean().item()
std_est = single_run.std().item()
ci_lo = estimate - 1.96 * std_est / N_per_estimate ** 0.5
ci_hi = estimate + 1.96 * std_est / N_per_estimate ** 0.5
print(f"\nSingle run estimate:      {estimate:.4f}")
print(f"95% CI:                   [{ci_lo:.4f}, {ci_hi:.4f}]")
print(f"True value inside CI:     {ci_lo <= p_true <= ci_hi}")

The Bernoulli distribution could not look less Normal — it only ever takes values 0 or 1. Yet when you average 500 of them, the distribution of those averages is essentially a bell curve. That is the CLT in action.

The same demonstration in Rust. Cargo dependencies for every Rust example in this lesson (versions chosen to match the Rust Playground's catalog so the mdbook "play" button works):

[dependencies]
ndarray = "0.17"
rand = "0.10"
rand_distr = "0.6"

A wrinkle if you copy the code into a fresh playground tab outside mdbook: the playground has these crates built and ready, but they aren't pre-declared in Cargo.toml, so use ndarray::... on its own won't resolve. You need a stray extern crate ndarray; (and the same for rand, rand_distr) at the top of the file. mdbook's # line-prefix trick hides those declarations from the rendered page but still includes them when the "play" button ships the code to the playground, which is what the leading hidden lines in each block below are doing.

extern crate ndarray;
extern crate rand;
use ndarray::{Array1, Array2, Axis};
use rand::{Rng, RngExt, SeedableRng};
use rand::rngs::StdRng;

fn main() {
    let mut rng = StdRng::seed_from_u64(0);

    let p_true = 0.30_f64;
    let n_per_estimate = 500;
    let n_estimates = 10_000;

    // Each row: one MC experiment of n_per_estimate Bernoulli(p_true) flips.
    // 1.0 = collision, 0.0 = no collision. rand_distr has a Bernoulli type,
    // but rolling it by hand here keeps the example self-contained.
    let samples = Array2::<f64>::from_shape_fn(
        (n_estimates, n_per_estimate),
        |_| if rng.random::<f64>() < p_true { 1.0 } else { 0.0 },
    );

    // Each MC estimate is the mean of one row.
    let sample_means: Array1<f64> = samples.mean_axis(Axis(1)).unwrap();

    let theoretical_std = (p_true * (1.0 - p_true) / n_per_estimate as f64).sqrt();

    // ndarray's .std(ddof) takes the degrees-of-freedom correction. Pass 1.0
    // to match PyTorch and NumPy (Bessel's correction). 0.0 gives population std.
    let mc_mean = sample_means.mean().unwrap();
    let mc_std  = sample_means.std(1.0);
    println!("True mean:                {p_true:.4}");
    println!("Mean of MC estimates:     {mc_mean:.4}");
    println!("Std of MC estimates:      {mc_std:.6}");
    println!("Theoretical std (CLT):    {theoretical_std:.6}");

    let within_95 = sample_means
        .iter()
        .filter(|&&m| ((m - p_true) / theoretical_std).abs() <= 1.96)
        .count() as f64
        / n_estimates as f64;
    println!("Fraction within 1.96σ:    {within_95:.4}");

    // 95% confidence interval from a single MC run.
    let single_run = samples.row(0);
    let estimate = single_run.mean().unwrap();
    let std_est  = single_run.std(1.0);
    let ci_lo = estimate - 1.96 * std_est / (n_per_estimate as f64).sqrt();
    let ci_hi = estimate + 1.96 * std_est / (n_per_estimate as f64).sqrt();
    println!("\nSingle run estimate:      {estimate:.4}");
    println!("95% CI:                   [{ci_lo:.4}, {ci_hi:.4}]");
    println!("True value inside CI:     {}", ci_lo <= p_true && p_true <= ci_hi);
}

One thing worth flagging about the imports: rand::Rng is the base RNG trait (formerly RngCore), and rand::RngExt is the extension trait that gives you .random(), .random_range(), and friends. You import both: Rng to use as a trait bound in function signatures, RngExt to call the convenience methods. This is a recent rearrangement (rand 0.10); older code you'll find online uses rng.gen() directly.

Watching the convergence happen

Here is a Monte Carlo estimation of a simple orbital probability: the fraction of a 95-minute low Earth orbit that a satellite spends in eclipse (behind Earth's shadow). We do not need to derive the analytic answer; we just simulate orbital positions and count how many are in shadow.

We will use an extremely simplified model: a circular orbit at 400 km altitude. A position is "in eclipse" if the angle from the Sun direction is more than about 90 + a few degrees (accounting for Earth's radius). We will approximate this with a random position on a circle.

import torch

def estimate_eclipse_fraction(N):
    """Estimate fraction of orbit spent in eclipse via Monte Carlo."""
    # Sample N random positions along a circular orbit (uniform angles).
    angles = torch.rand(N) * 2 * torch.pi  # uniform in [0, 2*pi]
    
    # An extremely simplified eclipse model: in eclipse if angle
    # from sun direction (0 radians) is between 110 and 250 degrees.
    # (This is a rough approximation; real eclipse geometry is more complex.)
    angle_deg = torch.rad2deg(angles)
    in_eclipse = (angle_deg >= 110) & (angle_deg <= 250)
    
    return in_eclipse.float().mean().item()

# True fraction for this simplified model: (250 - 110) / 360 ≈ 0.389
true_fraction = (250 - 110) / 360
print(f"True fraction (simplified model): {true_fraction:.4f}")
print()

# Watch convergence with increasing N
for N in [10, 100, 1_000, 10_000, 100_000]:
    # Run 5 times to see the spread
    runs = [estimate_eclipse_fraction(N) for _ in range(5)]
    runs_t = torch.tensor(runs)
    mean = runs_t.mean().item()
    std  = runs_t.std().item()
    error = abs(mean - true_fraction)
    print(f"N={N:>6}: mean={mean:.4f}, std={std:.4f}, error={error:.4f}")

When you run this, you will see the error and standard deviation shrink roughly by a factor of 3 each time N increases by a factor of 10 (because √10 ≈ 3.16). That is the 1/√N convergence, made visible.

And in Rust:

extern crate ndarray;
extern crate rand;
use ndarray::Array1;
use rand::{Rng, RngExt, SeedableRng};
use rand::rngs::StdRng;
use std::f64::consts::PI;

fn estimate_eclipse_fraction(n: usize, rng: &mut impl Rng) -> f64 {
    // Sample n random positions along a circular orbit (uniform angles in [0, 2π)).
    let angles = Array1::<f64>::from_shape_fn(n, |_| rng.random::<f64>() * 2.0 * PI);
    let angle_deg = angles.mapv(|a| a.to_degrees());
    let in_eclipse = angle_deg.mapv(|d| if (110.0..=250.0).contains(&d) { 1.0 } else { 0.0 });
    in_eclipse.mean().unwrap()
}

fn main() {
    let mut rng = StdRng::seed_from_u64(42);

    let true_fraction = (250.0_f64 - 110.0) / 360.0;
    println!("True fraction (simplified model): {true_fraction:.4}");
    println!();

    for n in [10, 100, 1_000, 10_000, 100_000] {
        // Run 5 times to see the spread.
        let runs: Vec<f64> = (0..5).map(|_| estimate_eclipse_fraction(n, &mut rng)).collect();
        let runs = Array1::from(runs);
        let mean  = runs.mean().unwrap();
        let std   = runs.std(1.0);
        let error = (mean - true_fraction).abs();
        println!("N={n:>6}: mean={mean:.4}, std={std:.4}, error={error:.4}");
    }
}

The pattern from_shape_fn(n, |_| ...) is the workhorse for building random arrays without pulling in ndarray-rand. You'll see it again in every subsequent example.

The canonical Monte Carlo example: estimating pi

This example appears in virtually every introduction to Monte Carlo methods because it makes the sampling process visually obvious.

Imagine a unit square (width 1, height 1) with a quarter-circle of radius 1 inscribed in it. The area of the square is 1. The area of the quarter-circle is π/4. So the fraction of random points that fall inside the quarter-circle is π/4, and we can estimate π by multiplying that fraction by 4.

import torch

torch.manual_seed(42)  # makes results reproducible

def estimate_pi(N):
    # Draw N random points uniformly in the unit square [0,1] x [0,1].
    points = torch.rand(N, 2)
    
    # A point (x, y) is inside the quarter-circle if x^2 + y^2 <= 1.
    # points**2 squares each coordinate. .sum(dim=1) sums x^2 + y^2 per point.
    distance_squared = (points ** 2).sum(dim=1)
    inside = distance_squared <= 1.0
    
    # Fraction inside * 4 estimates pi.
    return 4 * inside.float().mean().item()

print(f"True pi:  {torch.pi:.6f}")
print()
for N in [100, 1_000, 10_000, 100_000, 1_000_000]:
    estimate = estimate_pi(N)
    error = abs(estimate - torch.pi.item())
    print(f"N={N:>7}: estimate={estimate:.5f}, error={error:.5f}")

With N = 100, you might get 3.08 or 3.24, off by a noticeable amount. With N = 1,000,000, you will reliably get something like 3.14163, accurate to five decimal places.

Notice that going from 100 samples to 1,000,000 samples is a factor of 10,000 increase in computation, but the accuracy only improved from roughly ±0.05 to roughly ±0.002, a factor of 25. That is the 1/√N scaling at work. Getting two more decimal places of pi costs 10,000 times more samples.

extern crate ndarray;
extern crate rand;
use ndarray::{Array2, Axis};
use rand::{Rng, RngExt, SeedableRng};
use rand::rngs::StdRng;
use std::f64::consts::PI;

fn estimate_pi(n: usize, rng: &mut impl Rng) -> f64 {
    // n points uniform in [0,1] x [0,1]. Each call to rng draws one coordinate.
    let points = Array2::<f64>::from_shape_fn((n, 2), |_| rng.random::<f64>());
    let distance_squared = points.mapv(|x| x * x).sum_axis(Axis(1));
    let inside = distance_squared.mapv(|d| if d <= 1.0 { 1.0 } else { 0.0 });
    4.0 * inside.mean().unwrap()
}

fn main() {
    let mut rng = StdRng::seed_from_u64(42);

    println!("True pi:  {PI:.6}");
    println!();
    for n in [100, 1_000, 10_000, 100_000, 1_000_000] {
        let estimate = estimate_pi(n, &mut rng);
        let error = (estimate - PI).abs();
        println!("N={n:>7}: estimate={estimate:.5}, error={error:.5}");
    }
}

sum_axis(Axis(1)) is the direct equivalent of PyTorch's sum(dim=1). The Axis(1) newtype is ndarray being explicit about which dimension you mean, so you can't accidentally collapse the wrong one. You'll see this everywhere from here on.

Variance reduction: getting more accuracy without more samples

Because standard error = σ/√N, there are two ways to get a more accurate estimate:

1. Take more samples (increase N)
2. Reduce how spread out the samples are (decrease σ)

Techniques that reduce σ without changing what you are estimating are called variance reduction methods. You will meet several of them later:

• Baselines in policy gradient methods: subtract a fixed value from each reward before computing the gradient estimate. Does not change the expected gradient but reduces how much it varies from estimate to estimate.
• Outcome sampling in MCCFR: choose which game trajectories to sample based on their importance rather than uniformly at random.
• Importance sampling: sample from a different distribution that has lower variance, then correct for the bias.

You do not need to understand these yet. Just file away that "variance reduction" means "same answer, less noise per sample," and it is an active area of research precisely because 1/√N is expensive.

Importance sampling: sampling where it matters

Variance reduction techniques all ask the same question: can we gather information more efficiently than uniform random sampling? Importance sampling is the most conceptually fundamental answer.

The problem: rare events under uniform sampling

Suppose you want to estimate the probability of a close-approach conjunction event between two satellites where the miss distance is below 100 meters — a rare but catastrophically dangerous scenario. Under a realistic orbital uncertainty distribution, such close approaches might occur with probability 1 in 10,000. To estimate this probability to 10% relative accuracy, you need on the order of 1,000,000 samples. That is expensive.

The problem is structural: you are drawing most of your samples from the vast region of orbital state space where nothing interesting happens, and only a tiny fraction of samples land in the dangerous region you actually care about.

The intuition: sample more where the function is large

If the integrand (the thing you are averaging) is concentrated in a small region, draw more samples from that region and then correct for having over-sampled it. The correction is a weight that accounts for how much more often you sampled each point than you would have under the original distribution.

The formula

Suppose you want to estimate ${\mathbb{E}}_p[f(X)]=\int f(x)p(x)dx$, but sampling from $p$ is inefficient because $f(x)$ is large only in a small region.

Choose a proposal distribution $q$ that assigns higher probability to the region where $f(x)$ is large. Then:

$${\mathbb{E}}_p[f(X)]=\int f(x)p(x)dx=\int f(x)\frac{p(x)}{q(x)}q(x)dx={\mathbb{E}}_q\left[f(X)\frac{p(x)}{q(x)}\right]$$

The importance sampling estimator is:

$${\hat{\mu }}_{\text{IS}}=\frac{1}{N}\sum _{i=1}^{N}f(x_i)\cdot \frac{p(x_i)}{q(x_i)},x_i\sim q$$

Decoding the symbols:

$q(x)$: The proposal distribution — the distribution you actually sample from. You choose $q$; the art of importance sampling is choosing it well.

$p(x)$: The original distribution you want to average under.

$p(x_i)/q(x_i)$: The importance weight for sample $x_i$. If $q$ over-samples a region relative to $p$, the weight is less than 1 (down-weighting the over-sampled points). If $q$ under-samples a region, the weight is greater than 1.

Reading in English: "Draw samples from a smarter distribution $q$, then multiply each sample's contribution by a correction factor that accounts for how $q$ distorts the sampling."

The estimator is still unbiased: ${\mathbb{E}}_q[{\hat{\mu }}_{\text{IS}}]={\mathbb{E}}_p[f(X)]$.

SSA example: estimating conjunction probability for rare close approaches

import torch
import torch.distributions as dist

torch.manual_seed(7)

# --- Problem setup ---
# Two satellites. The relative position uncertainty is modeled as a 1D Gaussian
# with mean 500m and std 200m (separation in the conjunction plane).
# We want P(miss distance < 100m) — a "dangerous conjunction."
#
# True answer: P(X < 100) where X ~ Normal(500, 200^2)
# = Phi((100 - 500) / 200) = Phi(-2.0) ≈ 0.0228

mu_sep = 500.0    # mean separation in meters
sigma_sep = 200.0 # std of separation
threshold = 100.0 # dangerous miss distance

p_dist = dist.Normal(mu_sep, sigma_sep)
true_prob = p_dist.cdf(torch.tensor(threshold)).item()
print(f"True conjunction probability: {true_prob:.6f}")

# --- Naive Monte Carlo ---
# Sample from p (the real distribution) and check if < threshold.
N = 50_000
samples_naive = p_dist.sample((N,))
mc_naive = (samples_naive < threshold).float().mean().item()
print(f"\nNaive MC (N={N}):   estimate={mc_naive:.6f}")
print(f"  Relative error: {abs(mc_naive - true_prob)/true_prob:.2%}")
# With P ≈ 0.023, most samples are misses. Very few useful samples.

# --- Importance Sampling ---
# Proposal q: Normal centered on the dangerous region (mean = 0, std = 50).
# This distribution almost entirely generates samples below the threshold.
q_dist = dist.Normal(0.0, 50.0)

samples_is = q_dist.sample((N,))
# Importance weights: p(x) / q(x)
log_w = p_dist.log_prob(samples_is) - q_dist.log_prob(samples_is)
w = torch.exp(log_w)
# f(x) = indicator that x < threshold
f_x = (samples_is < threshold).float()
mc_is = (f_x * w).mean().item()
print(f"\nImportance sampling (N={N}):   estimate={mc_is:.6f}")
print(f"  Relative error: {abs(mc_is - true_prob)/true_prob:.2%}")

# --- Compare variance ---
# Run each estimator 200 times and measure std of estimates
n_runs = 200
naive_runs = []
is_runs = []
for _ in range(n_runs):
    s = p_dist.sample((N,))
    naive_runs.append((s < threshold).float().mean().item())
    s_q = q_dist.sample((N,))
    lw = p_dist.log_prob(s_q) - q_dist.log_prob(s_q)
    is_runs.append(((s_q < threshold).float() * torch.exp(lw)).mean().item())

print(f"\nStd of naive MC estimates:   {torch.tensor(naive_runs).std().item():.6f}")
print(f"Std of IS estimates:         {torch.tensor(is_runs).std().item():.6f}")
# IS should show substantially lower variance

The importance sampling estimator concentrates its computational budget on the dangerous region, dramatically reducing variance for the same N.

The Rust translation is more interesting than the others because rand_distr::Normal gives you sampling but not log-density. You have to roll the log-PDF yourself, which is a useful exercise:

extern crate ndarray;
extern crate rand;
extern crate rand_distr;
use ndarray::Array1;
use rand::SeedableRng;
use rand::rngs::StdRng;
use rand_distr::{Distribution, Normal};
use std::f64::consts::PI;

// Log-PDF of a univariate Normal(mu, sigma). PyTorch's Normal.log_prob does
// this; rand_distr deliberately separates "sample from this distribution"
// (its job) from "evaluate this density" (statrs's job or yours).
fn normal_log_prob(x: f64, mu: f64, sigma: f64) -> f64 {
    let z = (x - mu) / sigma;
    -0.5 * z * z - sigma.ln() - 0.5 * (2.0 * PI).ln()
}

fn main() {
    let mut rng = StdRng::seed_from_u64(7);

    let mu_sep    = 500.0_f64;
    let sigma_sep = 200.0_f64;
    let threshold = 100.0_f64;

    // True answer: Φ((threshold - μ)/σ) = Φ(-2.0). Computing the Normal CDF
    // in Rust requires the error function, which isn't in std. statrs would
    // give it, but we already know the answer for this example.
    let true_prob = 0.02275_f64;
    println!("True conjunction probability: {true_prob:.6}");

    // --- Naive Monte Carlo: sample from p, check below threshold. ---
    let n = 50_000;
    let p_dist = Normal::new(mu_sep, sigma_sep).unwrap();
    let samples_naive = Array1::<f64>::from_shape_fn(n, |_| p_dist.sample(&mut rng));
    let mc_naive = samples_naive
        .mapv(|x| if x < threshold { 1.0 } else { 0.0 })
        .mean()
        .unwrap();
    println!("\nNaive MC (N={n}):   estimate={mc_naive:.6}");
    println!("  Relative error: {:.2}%", 100.0 * (mc_naive - true_prob).abs() / true_prob);

    // --- Importance sampling: draw from q centered on the dangerous region. ---
    let q_mu    = 0.0_f64;
    let q_sigma = 50.0_f64;
    let q_dist  = Normal::new(q_mu, q_sigma).unwrap();
    let samples_is = Array1::<f64>::from_shape_fn(n, |_| q_dist.sample(&mut rng));

    // Importance weights: p(x) / q(x), computed in log-space for stability.
    let log_w = samples_is.mapv(|x|
        normal_log_prob(x, mu_sep, sigma_sep) - normal_log_prob(x, q_mu, q_sigma));
    let w   = log_w.mapv(f64::exp);
    let f_x = samples_is.mapv(|x| if x < threshold { 1.0 } else { 0.0 });
    let mc_is = (&f_x * &w).mean().unwrap();
    println!("\nImportance sampling (N={n}):   estimate={mc_is:.6}");
    println!("  Relative error: {:.2}%", 100.0 * (mc_is - true_prob).abs() / true_prob);

    // --- Compare variance across many independent runs. ---
    let n_runs = 200;
    let mut naive_runs = Vec::with_capacity(n_runs);
    let mut is_runs    = Vec::with_capacity(n_runs);
    for _ in 0..n_runs {
        let s = Array1::<f64>::from_shape_fn(n, |_| p_dist.sample(&mut rng));
        naive_runs.push(s.mapv(|x| if x < threshold { 1.0 } else { 0.0 }).mean().unwrap());

        let sq = Array1::<f64>::from_shape_fn(n, |_| q_dist.sample(&mut rng));
        let lw = sq.mapv(|x| normal_log_prob(x, mu_sep, sigma_sep) - normal_log_prob(x, q_mu, q_sigma));
        let f  = sq.mapv(|x| if x < threshold { 1.0 } else { 0.0 });
        is_runs.push((&f * &lw.mapv(f64::exp)).mean().unwrap());
    }
    let naive = Array1::from(naive_runs);
    let is    = Array1::from(is_runs);
    println!("\nStd of naive MC estimates:   {:.6}", naive.std(1.0));
    println!("Std of IS estimates:         {:.6}", is.std(1.0));
}

Two things worth flagging here. First, &f_x * &w (using references) is how you do elementwise multiplication of two ndarrays without consuming them. Drop the references and the arrays get moved into the operation, which usually isn't what you want. Second, hand-rolling normal_log_prob made the math explicit: this is just -z²/2 - log σ - ½ log(2π), with z = (x - μ)/σ. PyTorch's log_prob is doing exactly that arithmetic for you.

The critical warning: coverage

Importance sampling can fail catastrophically if the proposal $q$ does not cover the full support of $p$. Specifically, wherever $p(x)>0$ but $q(x)=0$, the weight $p(x)/q(x)$ is infinite — those samples can never be drawn, so their contribution is permanently lost, and the estimator is biased (no longer corrects to the true expectation).

The practical rule: $q$ should have heavier tails than $p$, not lighter. A proposal with lighter tails will create regions where $p(x)/q(x)$ is astronomically large — and the few samples that land there will dominate the estimate, causing high variance and instability. In SSA terms: if your proposal distribution only covers "near-nominal" conjunction geometries, you will miss the contribution of extreme-approach scenarios entirely.

How this connects to game-playing algorithms

When MCTS evaluates a game position, it cannot sum over all possible continuations of the game (there are too many). Instead, it runs random rollouts: simulations of a complete game from that position to the end, following some approximate policy. The fraction of those rollouts that end in a win is the Monte Carlo estimate of the winning probability from that position.

Each rollout is one sample. The winning probability estimate improves as more rollouts are run. The estimate is noisy with few rollouts and reliable with many. That is exactly the convergence behavior you just saw with pi and eclipse fraction.

The MCTS value estimate as a Monte Carlo average

In MCTS, each node in the search tree tracks two quantities: $W$ (total wins accumulated from rollouts through this node) and $N$ (total visits). The value estimate is simply:

$$\hat{V}(\text{node})=\frac{W}{N}$$

This is exactly a Monte Carlo average of rollout outcomes (each rollout returns 1 for a win and 0 for a loss). By the CLT, this estimate is approximately Normal around the true win probability, with standard deviation $\sim 1/(2\sqrt{N})$ (for win probabilities near 0.5). With 40 rollouts, the standard error is about 0.079; with 400 rollouts it falls to 0.025 — a 3× improvement for a 10× cost.

The UCB exploration-exploitation tradeoff

MCTS does not distribute rollouts uniformly across all child nodes. It uses the Upper Confidence Bound (UCB) formula to balance exploration and exploitation:

$$\text{UCB}(\text{node})=\frac{W_i}{N_i}+c\sqrt{\frac{\ln N_{\text{parent}}}{N_i}}$$

Decoding:

$W_i/N_i$: The exploitation term — the current value estimate for child $i$. Prefer nodes with high estimated value.

$c\sqrt{\ln N_{\text{parent}}/N_i}$: The exploration term. When $N_i$ is small, this term is large — under-visited nodes get a bonus. The $\ln N_{\text{parent}}$ in the numerator grows slowly, preventing the exploration bonus from dominating forever.

$c$: A hyperparameter controlling the exploration-exploitation trade-off. Common values are $\sqrt{2}$ or 1.0; in practice it is tuned per domain.

The UCB formula is optimal in the bandit setting (proven by Auer, Cesa-Bianchi, and Fischer, 2002): it minimizes regret (the gap between UCB's cumulative reward and that of always choosing the best arm) at a logarithmic rate. In a game tree, this means MCTS concentrates rollouts on the most promising lines while guaranteeing no subtree is permanently neglected.

import torch
import math

torch.manual_seed(3)

# A toy MCTS on a single parent node with 3 child nodes.
# True win probabilities for the children (unknown to the algorithm).
true_win_probs = torch.tensor([0.45, 0.60, 0.35])
n_children = len(true_win_probs)

W = torch.zeros(n_children)   # wins per child
N = torch.zeros(n_children)   # visits per child
N_total = 0
c = math.sqrt(2)

def ucb_score(w, n, n_total, c):
    if n == 0:
        return float('inf')  # unvisited nodes get infinite priority
    return w / n + c * math.sqrt(math.log(n_total) / n)

print(f"True win probs: {true_win_probs.tolist()}")
print(f"Best child: {true_win_probs.argmax().item()} (prob={true_win_probs.max().item():.2f})")
print()

for rollout in range(1, 401):
    # Select child with highest UCB score
    scores = [ucb_score(W[i].item(), N[i].item(), N_total + 1, c)
              for i in range(n_children)]
    selected = scores.index(max(scores))
    
    # Simulate a rollout: draw outcome from true win probability
    outcome = torch.bernoulli(true_win_probs[selected]).item()
    W[selected] += outcome
    N[selected] += 1
    N_total += 1
    
    if rollout in [10, 40, 100, 200, 400]:
        estimates = [W[i].item() / N[i].item() if N[i] > 0 else 0.0
                     for i in range(n_children)]
        best = estimates.index(max(estimates))
        print(f"After {rollout:>3} rollouts: estimates={[f'{e:.3f}' for e in estimates]}, "
              f"visits={N.int().tolist()}, best={best}")

After 40 rollouts the estimates are noisy; after 400, they have converged close to the true values and the algorithm reliably identifies child 1 as the best. This is the 1/√N improvement made concrete in a game-tree context.

The Rust version. Note how the per-node stats become a couple of Vec<f64>s; you'll see this same shape (visit counts, accumulated values) in the real MCTS implementation in Module 4, just wrapped in a proper tree.

extern crate rand;
use rand::{RngExt, SeedableRng};
use rand::rngs::StdRng;

fn ucb_score(w: f64, n: f64, n_total: f64, c: f64) -> f64 {
    if n == 0.0 {
        f64::INFINITY            // unvisited nodes get infinite priority
    } else {
        w / n + c * (n_total.ln() / n).sqrt()
    }
}

fn main() {
    let mut rng = StdRng::seed_from_u64(3);

    let true_win_probs = [0.45_f64, 0.60, 0.35];
    let n_children = true_win_probs.len();

    let mut w = vec![0.0_f64; n_children];
    let mut n = vec![0.0_f64; n_children];
    let mut n_total = 0_u32;
    let c = 2.0_f64.sqrt();

    let (best_idx, &best_prob) = true_win_probs
        .iter()
        .enumerate()
        .max_by(|a, b| a.1.partial_cmp(b.1).unwrap())
        .unwrap();
    println!("True win probs: {:?}", true_win_probs);
    println!("Best child: {best_idx} (prob={best_prob:.2})");
    println!();

    let checkpoints = [10, 40, 100, 200, 400];

    for rollout in 1..=400 {
        // Select child with highest UCB score.
        let (selected, _) = (0..n_children)
            .map(|i| (i, ucb_score(w[i], n[i], (n_total + 1) as f64, c)))
            .max_by(|a, b| a.1.partial_cmp(&b.1).unwrap())
            .unwrap();

        // Rollout: Bernoulli draw from this child's true win probability.
        let outcome = if rng.random::<f64>() < true_win_probs[selected] { 1.0 } else { 0.0 };
        w[selected] += outcome;
        n[selected] += 1.0;
        n_total += 1;

        if checkpoints.contains(&rollout) {
            let estimates: Vec<f64> = (0..n_children)
                .map(|i| if n[i] > 0.0 { w[i] / n[i] } else { 0.0 })
                .collect();
            let (best, _) = estimates
                .iter()
                .enumerate()
                .max_by(|a, b| a.1.partial_cmp(b.1).unwrap())
                .unwrap();
            let visits: Vec<i64> = n.iter().map(|&x| x as i64).collect();
            let est_str: Vec<String> = estimates.iter().map(|e| format!("{:.3}", e)).collect();
            println!(
                "After {rollout:>3} rollouts: estimates=[{}], visits={:?}, best={best}",
                est_str.join(", "),
                visits
            );
        }
    }
}

The repeated partial_cmp(...).unwrap() is the Rust tax for working with floats: f64 doesn't implement Ord because of NaN, so you can't just call .max() on an iterator of floats. In production code you'd wrap this in a helper. For now, see it for what it is and move on.

The first M in MCCFR (Monte Carlo Counterfactual Regret Minimization) refers to the same idea. Instead of computing counterfactual regret over all possible game trajectories, MCCFR samples trajectories and estimates the regret from those samples. It converges to the correct solution as the number of samples grows, at the 1/√N rate.

Numerical stability: log-space Monte Carlo

So far we have been accumulating MC estimates in linear probability space. For many SSA applications this is fine. But consider a conjunction probability estimate that involves multiplying together many independent uncertain factors — orbital uncertainty, atmospheric drag uncertainty, sensor accuracy uncertainty — each with probability < 1. The product of 50 small probabilities will underflow to exactly zero in standard 32-bit floating point, even if the true product is a meaningful number like 10^{-15}.

The log-sum-exp trick

The standard fix is to work in log-space and use the log-sum-exp identity to safely aggregate:

$$\log \left(\sum _i{e}^{a_i}\right)=a_{\max }+\log \left(\sum _i{e}^{a_i-a_{\max }}\right)$$

Decoding:

$a_{\max }$: The maximum of the $a_i$ values. Shifting all values down by $a_{\max }$ before exponentiating keeps the numbers in a safe range — the largest term becomes $e^0=1$ and all others are smaller.

Why it works: The two forms are mathematically equal; the second just avoids numerical overflow/underflow by keeping all exponentials near 1.

For Monte Carlo in log-space, the pattern is: compute $\log f(x_i)$ for each sample, then use torch.logsumexp to aggregate.

When to accumulate in log-space vs. linear space

• Use linear space when individual sample values are not extremely small or large (roughly in the range 10^{-6} to 10^6 in float32). Most MCTS value estimates, policy entropy computations, and reward averaging fall here.
• Use log-space when multiplying many probabilities together, computing likelihoods of long sequences, or working with probabilities below roughly 10^{-7}.

import torch
import math

torch.manual_seed(11)

# Scenario: estimate the probability that a satellite survives 50 consecutive
# orbital passes through a debris field, each with survival probability 0.97.
# True answer: 0.97^50 ≈ 0.2181

p_survive_one_pass = 0.97
n_passes = 50
n_simulations = 10_000

# --- Naive approach: multiply probabilities together in linear space ---
# Each simulation: draw 50 Bernoulli(0.97) samples, check all survived
outcomes = torch.bernoulli(
    torch.full((n_simulations, n_passes), p_survive_one_pass)
)
# Product of all outcomes per simulation (1 if all survived, 0 if any collision)
# But: even the product in float32 won't underflow here because individual
# values are 0 or 1. The underflow problem arises when multiplying small floats.
survived_all = outcomes.prod(dim=1)   # 1.0 or 0.0 per simulation
mc_linear = survived_all.mean().item()

# --- Demonstrate the underflow problem ---
# Instead, multiply the *probabilities* directly (simulating a different
# quantity: the probability-weighted integral, not a Bernoulli draw).
# With 100 factors of 0.97, in float32:
probs_100 = torch.full((100,), 0.97, dtype=torch.float32)
product_linear = probs_100.prod().item()
log_sum_true = 100 * math.log(0.97)

# With 500 factors:
probs_500 = torch.full((500,), 0.97, dtype=torch.float32)
product_500 = probs_500.prod().item()    # This will underflow to 0.0 in float32

print(f"True 50-pass survival probability: {p_survive_one_pass**n_passes:.6f}")
print(f"MC estimate (Bernoulli draws):     {mc_linear:.6f}")
print()
print(f"100-factor product in float32:     {product_linear:.8f}")
print(f"100-factor log-sum (exact):        {math.exp(log_sum_true):.8f}")
print()
print(f"500-factor product in float32:     {product_500}")  # → 0.0 (underflow!)
log_sum_500 = 500 * math.log(0.97)
print(f"500-factor log-space result:       {math.exp(log_sum_500):.8e}")  # ≈ 5.2e-7

# --- Log-space MC accumulation ---
# When each sample contributes a log-probability, use logsumexp to aggregate
log_contributions = torch.full((n_simulations,), math.log(p_survive_one_pass) * n_passes)
# Add noise to simulate MC variation
log_contributions += torch.randn(n_simulations) * 0.05
log_mean_estimate = torch.logsumexp(log_contributions, dim=0) - math.log(n_simulations)
print(f"\nLog-space MC estimate:             {math.exp(log_mean_estimate):.6f}")

The underflow from 500 factors of 0.97 to exactly 0.0 is the silent-OOM equivalent for numerical computation: the program runs, returns an answer, and the answer is completely wrong. Log-space accumulation prevents this.

The Rust version. There's no torch.logsumexp here, but writing one yourself is six lines and shows exactly what the trick is doing:

extern crate ndarray;
extern crate rand;
extern crate rand_distr;
use ndarray::{Array1, Array2, Axis};
use rand::{RngExt, SeedableRng};
use rand::rngs::StdRng;
use rand_distr::{Distribution, StandardNormal};

// Numerically safe log(sum(exp(x_i))). Subtract the max before exponentiating
// so the largest term is e^0 = 1 and everything else is smaller. PyTorch's
// torch.logsumexp does the same thing under the hood.
fn logsumexp(xs: &Array1<f64>) -> f64 {
    let max = xs.iter().cloned().fold(f64::NEG_INFINITY, f64::max);
    let s: f64 = xs.iter().map(|&x| (x - max).exp()).sum();
    max + s.ln()
}

fn main() {
    let mut rng = StdRng::seed_from_u64(11);

    let p_survive = 0.97_f64;
    let n_passes = 50_usize;
    let n_simulations = 10_000;

    // --- Naive Bernoulli MC: 1 if all passes survived, 0 if any collision. ---
    let outcomes = Array2::<f64>::from_shape_fn(
        (n_simulations, n_passes),
        |_| if rng.random::<f64>() < p_survive { 1.0 } else { 0.0 },
    );
    let survived_all = outcomes.map_axis(Axis(1), |row| row.iter().product::<f64>());
    let mc_linear = survived_all.mean().unwrap();

    // --- Demonstrate underflow in f32. ---
    // 100 factors of 0.97 is fine; 500 factors collapses to exactly 0.0.
    let product_100: f32 = (0..100).map(|_| 0.97_f32).product();
    let product_500: f32 = (0..500).map(|_| 0.97_f32).product();
    let log_sum_100 = 100.0 * 0.97_f64.ln();
    let log_sum_500 = 500.0 * 0.97_f64.ln();

    println!("True 50-pass survival probability: {:.6}", p_survive.powi(n_passes as i32));
    println!("MC estimate (Bernoulli draws):     {mc_linear:.6}");
    println!();
    println!("100-factor product in f32:         {product_100:.8}");
    println!("100-factor log-sum (exact):        {:.8}", log_sum_100.exp());
    println!();
    println!("500-factor product in f32:         {product_500}");          // 0.0
    println!("500-factor log-space result:       {:.8e}", log_sum_500.exp());

    // --- Log-space MC accumulation with the logsumexp helper. ---
    // Each "sample" is a log-probability that 50 passes survived, plus a bit
    // of Gaussian noise to simulate MC variation across simulations.
    let log_contributions = Array1::<f64>::from_shape_fn(n_simulations, |_| {
        p_survive.ln() * n_passes as f64 + StandardNormal.sample(&mut rng) * 0.05
    });
    let log_mean = logsumexp(&log_contributions) - (n_simulations as f64).ln();
    println!("\nLog-space MC estimate:             {:.6}", log_mean.exp());
}

The f64::max fold pattern (fold(f64::NEG_INFINITY, f64::max)) is the canonical Rust way to take a max over floats; the same NaN-ordering issue from the MCTS example is why this exists. You will see this fold throughout numerical Rust code.

Common pitfalls

Pitfall 1: Treating a single MC run as reliable. A single estimate from N=100 samples has a standard error that may be 30-50% of the true value for low-probability events. Always run multiple independent estimates and report the spread.

Pitfall 2: Forgetting the 1/√N cost. Going from ±5% error to ±0.5% error requires 100× more samples, not 10×. MC is powerful but the variance reduction is sublinear.

Pitfall 3: Importance sampling with thin-tailed proposals. If $q$ has lighter tails than $p$, importance weights in the tails blow up. The estimator becomes dominated by a handful of extreme samples. Always verify that $q$ covers the support of $p$ and has heavier tails.

Pitfall 4: Ignoring numerical underflow. Multiplying together many probabilities in linear float32 will silently underflow to 0. Use log-space accumulation whenever you are multiplying more than ~50 independent probabilities.

Pitfall 5: Using MC where direct computation is feasible. MC is for intractable expectations. If your distribution has 10 outcomes, just enumerate them. The 1/√N convergence is strictly worse than direct summation for small, discrete problems.

Key Takeaways

• Monte Carlo estimation replaces an intractable sum or integral with an average over N random samples: $\hat{\mu }=\frac{1}{N}\sum f(x_i)$. The estimate is unbiased and converges at rate $\sigma /\sqrt{N}$.
• The Central Limit Theorem guarantees that the sample mean is approximately Normally distributed around the true mean for large N, regardless of the underlying distribution shape. This is why confidence intervals on MC estimates work, and why you can quote uncertainty alongside any MC result.
• Importance sampling corrects for sampling from a non-uniform proposal $q$ by reweighting each sample by $p(x_i)/q(x_i)$. It is a powerful variance reducer for rare-event estimation (like dangerous conjunctions) but catastrophically fails if $q$ does not cover the support of $p$.
• MCTS value estimates are Monte Carlo averages of rollout outcomes. The UCB formula (exploitation + exploration bonus) directs rollouts efficiently across the tree, providing logarithmic regret in the bandit sense. More rollouts give better estimates at the 1/√N rate.
• Log-space accumulation (via the log-sum-exp trick) is essential when multiplying together many small probabilities. Naive linear-space products silently underflow to 0 in float32, producing wrong answers with no error signal.
• The 1/√N trade-off is fundamental and unavoidable for plain MC. All variance reduction techniques (baselines, importance sampling, control variates) reduce $\sigma$, not the √N denominator — they get you more accuracy per sample, but the rate of improvement remains sublinear.

Lesson 4: Entropy, Cross-Entropy, and KL Divergence

Module: Foundations — M01: Mathematical Foundations for ML and Game Theory Source: Elements of Information Theory — Cover & Thomas, Chapters 2 and 3 (Entropy, Relative Entropy, and Mutual Information); Pattern Recognition and Machine Learning — Bishop, Chapter 1.6 (Information Theory); Deep Learning — Goodfellow, Bengio, Courville, Chapter 3.13 (Information Theory)

Where this fits

Three quantities, all measuring something about probability distributions. They show up in specific and important places downstream. Policy gradient methods add entropy bonuses to encourage exploration. PPO and TRPO constrain policy updates using KL divergence. Cross-entropy is the training loss for nearly every classification network. If you have ever seen a training log print "cross-entropy loss = 0.43" or a paper say "we constrain the KL between old and new policy," this lesson is where those terms become concrete.

The good news: all three quantities reduce to one idea, which we will build up from an SSA scenario.

Starting from scratch: what is surprise?

Your space operations center receives automated alerts whenever the catalog detects a significant event. These alerts are categorized:

When a routine conjunction warning comes in (probability 0.70), you are barely surprised. This happens all the time. When an adversarial maneuver alert comes in (probability 0.02), you are very surprised. This almost never happens.

Surprise is inversely related to probability. Common events are unsurprising. Rare events are surprising.

We can make this precise. The mathematical definition of surprise for an event with probability $p$ is:

$$\text{surprise}(p)=-\log (p)$$

Let us compute surprise for each alert type and see if it matches our intuition:

Rare events (low probability) get high surprise scores. Common events (high probability) get low surprise scores. A guaranteed event (probability 1.0) gets a surprise of −log(1) = 0 (no surprise at all).

Why the negative sign? Because log(p) is negative when p < 1 (log of a fraction is negative), and we want surprise to be a positive number. The negative sign flips it to positive.

Why a logarithm? Two reasons. First, independent events should have additive surprise. If two independent events each occur, you should be exactly as surprised as the sum of surprises for each individually. Logarithms turn multiplication into addition: −log(p₁ × p₂) = −log(p₁) + (−log(p₂)). Second, the logarithm grows slowly at first then quickly, capturing the intuition that going from 50% to 10% feels less dramatic than going from 2% to 0.1%, even though both are 5× reductions in probability.

Bits vs. nats: two choices of logarithm base

The surprise formula $-\log (p)$ leaves one choice open: which base of logarithm? This choice determines the unit of information.

Bits (base 2): If you use ${\log }_2$, surprise is measured in bits. This is the unit from classical information theory and digital communication. A fair coin flip carries exactly 1 bit of information: $-{\log }_2(0.5)=1$. A message drawn uniformly from an alphabet of 8 symbols carries 3 bits per symbol: $-{\log }_2(1/8)=3$. Bits are the natural unit when you think about how many binary digits you need to encode something.

Nats (natural log): If you use $\ln$ (the natural logarithm, base $e$), surprise is measured in nats. This is the unit used in machine learning, statistics, and physics. The reason ML uses nats is practical: gradient computation is cleaner with natural logarithm because $\frac{d}{dx}\ln (x)=1/x$, without any prefactor. When you compute ${\nabla }_{\theta }\ln {\pi }_{\theta }(a|s)$ in the policy gradient theorem, you want that clean derivative.

The conversion: 1 nat = ${\log }_2(e)\approx 1.4427$ bits. A fair coin flip in nats: $-\ln (0.5)=\ln (2)\approx 0.693$ nats. Multiplying by 1.4427 gives 1 bit, as expected.

Which should you use? Always use the same base consistently within a calculation. When reading papers: if entropy values are around 0.69 for a fair coin, they are in nats. If entropy values are 1.0 for a fair coin, they are in bits. In PyTorch: torch.log is natural log (nats); torch.log2 gives bits.

import torch
import math

# Alert distribution from the SSA operations center
probs = torch.tensor([0.70, 0.20, 0.08, 0.02])
labels = ["Routine conj.", "Debris cloud", "Reentry", "Adversarial"]

print(f"{'Alert type':<18} {'p':>6}  {'Surprise (nats)':>16}  {'Surprise (bits)':>16}")
print("-" * 62)
for label, p in zip(labels, probs.tolist()):
    surprise_nats = -math.log(p)
    surprise_bits = -math.log2(p)
    print(f"{label:<18} {p:>6.2f}  {surprise_nats:>16.3f}  {surprise_bits:>16.3f}")

# Entropy in both units
entropy_nats = -(probs * torch.log(probs)).sum().item()
entropy_bits = -(probs * torch.log2(probs)).sum().item()
print(f"\nEntropy in nats: {entropy_nats:.4f}")
print(f"Entropy in bits: {entropy_bits:.4f}")
print(f"Conversion check: {entropy_nats * math.log2(math.e):.4f} bits  (= nats × log2(e))")

# Fair coin: should be 1 bit, ln(2) nats
print(f"\nFair coin entropy: {math.log(2):.4f} nats = {1.0:.4f} bit")

Entropy: average surprise

Now here is the key question: how surprising is your alert system, on average?

You do not know which alert will come next. But you know the probabilities. The expected surprise is the average amount of surprise per alert, weighted by how often each alert type occurs.

Using the expectation formula from lesson 1:

$$\text{average surprise}=\sum _{\text{all types}}P(\text{type})\times \text{surprise}(\text{type})$$

Let us compute it:

The average surprise is 0.852. This quantity is the entropy of the alert distribution.

Entropy measures how uncertain a distribution is. High entropy means you are often surprised (the distribution is spread out, unpredictable). Low entropy means you are rarely surprised (one or a few outcomes dominate and you almost always know what is coming).

The entropy formula

Entropy of a distribution P is written:

$$H(P)=-\sum _{x}P(x)\log P(x)$$

Decoding each symbol:

$H(P)$: The entropy of distribution P. H stands for "Hartley" (an early information theorist), and P is the distribution. The parentheses just mean "the entropy of P."

$-$: The negative sign. Without it, the expression would be negative (since log of a probability < 1 is negative). The negative sign makes entropy positive.

${\sum }_x$: Sum over all possible outcomes x. In our alert example, x ranges over the four alert types.

$P(x)$: The probability of outcome x under distribution P.

$\log P(x)$: The logarithm of that probability.

$P(x)\log P(x)$: Probability times log-probability. Note that this is different from the surprise calculation: surprise is $-\log P(x)$, but the contribution to entropy is $P(x)\times (-\log P(x))$, the surprise weighted by how often it occurs.

Reading in English: "For each possible outcome, multiply its probability by its log-probability, sum all those products, and negate the result."

This is just the expectation of surprise: $H(P)=\mathbb{E}[-\log P(X)]$.

Maximum and minimum entropy

Minimum entropy (zero) occurs when one outcome has probability 1 and all others have probability 0. A completely determined distribution. A deterministic policy has zero entropy; you know exactly which action it will take.

Maximum entropy occurs when the distribution is uniform: all outcomes equally likely. For four outcomes, maximum entropy would be $-4\times (0.25\times \log 0.25)=\log 4\approx 1.386$. A uniform policy over actions is maximally uncertain; you have no idea which action the agent will take.

Your alert distribution (entropy ≈ 0.852) is between these extremes, closer to the minimum. You are not completely surprised on average, because most alerts are routine.

The maximum entropy principle

Why does a uniform distribution maximize entropy, and what does this mean in practice?

Entropy is maximized by the distribution that is "as spread out as possible" subject to known constraints. If you have no information beyond "there are four alert types," the uniform distribution is the honest representation of your ignorance: it encodes no preference for one outcome over another.

This is the maximum entropy principle in Bayesian reasoning: among all distributions consistent with the constraints you actually know, use the one with highest entropy. Using a lower-entropy distribution means claiming knowledge you do not have.

The principle gives concrete answers for common constraint types:

• No constraints beyond valid probability: use the uniform distribution.
• Known mean (e.g., average alert rate = 10/hour): if alerts arrive as a Poisson process, the maximum entropy distribution for inter-arrival times subject to "known mean rate" is the Exponential distribution. In SSA terms: if you only know that your sensor generates 10 conjunction alerts per hour on average, and you want the least-informative model of the time between consecutive alerts, use Exponential(rate=10). Any other distribution would be claiming structure you do not have.
• Known mean and variance: the maximum entropy distribution is the Gaussian.

import torch
from torch.distributions import Categorical, Exponential

# Maximum entropy for N outcomes = log(N) (uniform)
for n_outcomes in [2, 4, 8, 16]:
    max_h = math.log(n_outcomes)
    uniform_h = Categorical(probs=torch.ones(n_outcomes) / n_outcomes).entropy().item()
    print(f"N={n_outcomes}: max entropy = {max_h:.4f} nats, "
          f"uniform entropy = {uniform_h:.4f} nats")

print()
# Maximum entropy distribution for inter-arrival times with known mean rate
# = Exponential. Verify it has higher entropy than a same-mean truncated distribution.
rate = 10.0  # alerts per hour
exp_dist = Exponential(rate=torch.tensor(rate))
print(f"Exponential(rate=10) entropy: {exp_dist.entropy().item():.4f} nats")
print(f"  (This is the max-entropy distribution for inter-arrival times with mean=0.1 hr)")

In RL, the maximum entropy principle motivates entropy regularization: adding $\alpha H(\pi )$ to the reward to encourage exploration. The agent is pushed toward the maximum entropy policy that still achieves high expected reward — uncertain unless it has a good reason to be certain.

Cross-entropy: surprise when using the wrong model

Now suppose a new analyst joins your team. Based on their prior experience at a different space ops center, they have a different model of alert probabilities:

The analyst thinks adversarial maneuvers are much more common than they actually are (10% vs 2%), and underestimates routine conjunctions (40% vs 70%).

When alerts actually arrive (following the true distribution P), how surprised will the analyst be on average?

The analyst's surprise when alert type x occurs is $-\log Q(x)$, because they are using their model Q to form expectations. The actual frequency of each alert type follows P. So the analyst's average surprise is:

$$\sum _{x}P(x)\times (-\log Q(x))$$

This is the cross-entropy of P and Q:

$$H(P,Q)=-\sum _{x}P(x)\log Q(x)$$

Let us compute it for your analyst:

The analyst's average surprise is 1.057, compared to 0.852 for someone who knows the true distribution. The analyst experiences more surprise than necessary because their model is wrong.

Notice: when Q = P (the analyst's model matches reality perfectly), cross-entropy equals entropy. The cross-entropy is always at least as large as the entropy, and the gap tells you how much extra surprise the wrong model causes.

Binary cross-entropy: the special case for classification

The most common loss function in ML is a special case of cross-entropy for two-class (binary) problems: binary cross-entropy (BCE).

When there are only two outcomes — conjunction risk above threshold (positive) or below (negative) — every true label is a degenerate distribution: either 100% probability on the positive class, or 100% on the negative class. The neural network outputs a scalar $p\in (0,1)$ predicting the probability of the positive class.

The BCE loss for a single example with true label $y\in \{0,1\}$ and predicted probability $\hat{p}$ is:

$$L_{\text{BCE}}=-\left[y\log \hat{p}+(1-y)\log (1-\hat{p})\right]$$

Decoding:

$y\log \hat{p}$: When $y=1$ (positive class), this term is $\log \hat{p}$ — the log-probability the model assigned to the correct class. We want this large (close to 0), which means we want $\hat{p}$ close to 1.

$(1-y)\log (1-\hat{p})$: When $y=0$ (negative class), this term is $\log (1-\hat{p})$ — the log-probability of the negative class. We want $\hat{p}$ close to 0.

Why only one term is active at a time: when $y=1$, the $(1-y)$ factor zeroes out the second term. When $y=0$, the $y$ factor zeroes out the first. You are always computing the cross-entropy between the degenerate true distribution and the model's prediction.

Why this is cross-entropy: The true label $y=1$ represents a degenerate distribution $P=[0,1]$ over {negative, positive}. The model's output represents $Q=[1-\hat{p},\hat{p}]$. The cross-entropy is $H(P,Q)=-[0\cdot \log (1-\hat{p})+1\cdot \log \hat{p}]=-\log \hat{p}$, which is the BCE formula with $y=1$. The full two-term formula handles both cases compactly.

In SSA terms: a conjunction-risk binary classifier predicts whether a given RSO pair poses a collision risk above the 1-in-10,000 threshold. The BCE loss is the natural training objective — it penalizes the model proportionally to how surprised it would be by the true label, given its prediction.

import torch
import torch.nn as nn

# Manual BCE for SSA conjunction-risk prediction
# Scenario: a batch of 6 RSO pairs with true risk labels
y_true = torch.tensor([1.0, 0.0, 1.0, 0.0, 0.0, 1.0])  # 1 = high-risk conjunction
y_pred = torch.tensor([0.85, 0.10, 0.60, 0.40, 0.05, 0.92])  # model predictions

# Manual BCE
eps = 1e-8  # avoid log(0)
bce_manual = -(y_true * torch.log(y_pred + eps) + (1 - y_true) * torch.log(1 - y_pred + eps))
print("Per-sample BCE loss (manual):")
for i, (yt, yp, loss) in enumerate(zip(y_true.tolist(), y_pred.tolist(), bce_manual.tolist())):
    print(f"  Pair {i+1}: y={yt:.0f}, p_hat={yp:.2f}, BCE={loss:.4f}")

print(f"\nMean BCE loss (manual): {bce_manual.mean().item():.4f}")

# PyTorch's BCELoss should give the same result
bce_torch = nn.BCELoss(reduction='none')(y_pred, y_true)
print(f"\nPer-sample BCE (torch.nn.BCELoss):")
print(f"  {bce_torch.tolist()}")
print(f"Mean BCE (torch):        {bce_torch.mean().item():.4f}")

# Verify they match (up to numerical precision)
print(f"\nMax difference: {(bce_manual - bce_torch).abs().max().item():.2e}")

# Note: conjunction risk 3 (high-risk, predicted 0.60) contributes more loss
# than conjunction risk 1 (high-risk, predicted 0.85) — the model is less
# confident about a true positive, so it is penalized more.

KL divergence: the extra surprise from being wrong

The extra surprise caused by using model Q instead of the true distribution P is:

$$\text{KL}(P\Vert Q)=H(P,Q)-H(P)$$

Or expanded:

$$\text{KL}(P\Vert Q)=\sum _{x}P(x)\log \frac{P(x)}{Q(x)}$$

For your analyst: KL = 1.057 − 0.852 = 0.205. The analyst experiences 0.205 extra units of surprise per alert because their model is miscalibrated.

Decoding the expanded formula:

$\text{KL}(P\Vert Q)$: The KL divergence from P to Q. The double bars and the order matter. $\text{KL}(P\Vert Q)$ asks: "if reality is P, how much extra surprise does using model Q cause?"

${\sum }_x$: Sum over all outcomes.

$P(x)$: Weight by the actual frequency (what really happens).

$\log \frac{P(x)}{Q(x)}$: The log-ratio. When $Q(x)=P(x)$, this is $\log 1=0$: no extra surprise for that outcome. When $Q(x)<P(x)$, you underestimated how often x occurs, and your surprise for that outcome is higher than it should be.

Key properties:

• KL divergence is always ≥ 0. It equals 0 only when P and Q are identical.
• KL divergence is asymmetric: $\text{KL}(P\Vert Q)\ne \text{KL}(Q\Vert P)$ in general. "How surprised is the analyst when reality is P and model is Q" is a different question from "how surprised is the analyst when reality is Q and model is P."

Forward vs. reverse KL: mode-covering and mode-seeking

The asymmetry of KL divergence is not just a mathematical curiosity — it has profound practical consequences for how an approximating distribution $Q$ behaves when fitted to a target $P$.

Forward KL: KL(P || Q) — mode-covering

$\text{KL}(P\Vert Q)={\sum }_{x}P(x)\log \frac{P(x)}{Q(x)}$

This averages the log-ratio weighted by P. Wherever $P(x)>0$, any terms with $Q(x)\approx 0$ contribute enormous positive values (since $\log P/Q\to \infty$). To minimize $\text{KL}(P\Vert Q)$, the approximation $Q$ must cover all modes of P — it cannot afford to assign zero probability to any region where P is significant.

The result: minimizing forward KL produces a Q that is spread out (over-dispersed relative to any single mode of P). If P is bimodal, Q tries to cover both modes, which may mean Q is high between the modes even where P is low. This is the "mode-covering" (or zero-avoiding) behavior.

Reverse KL: KL(Q || P) — mode-seeking

$\text{KL}(Q\Vert P)={\sum }_{x}Q(x)\log \frac{Q(x)}{P(x)}$

This averages the log-ratio weighted by Q. Now, wherever $P(x)\approx 0$, having $Q(x)>0$ contributes large positive values (since $\log Q/P\to \infty$). To minimize $\text{KL}(Q\Vert P)$, the approximation Q avoids placing mass where P is small. Q concentrates on regions where P is large — one mode at a time.

The result: minimizing reverse KL produces a Q that is concentrated (under-dispersed, hugging one mode of P). If P is bimodal, Q typically collapses onto whichever mode it found first. This is the "mode-seeking" (or zero-forcing) behavior.

Why this matters for RL: how PPO uses KL

PPO (Proximal Policy Optimization) uses forward KL as its trust-region constraint — or equivalently, a clipped surrogate that approximates it. The constraint is:

$$\text{KL}({\pi }_{\text{old}}\Vert {\pi }_{\text{new}})\le \delta$$