This supplement is a work-in-progress. The modeling documentation below was drafted by Claude from a close reading of the simulation code (plan_a_covert_proj/ in the ai-futures-calculator repository) and reflects the current default configuration. Framing text, elicitation numbers, and headline statistics are still subject to revision.

Working title: Takeoff Supplement (alternatively: "Takeoff in Plan A").

This supplement is the home for the interactive takeoff megamodel above. The megamodel shows four situations in one place:

1. Default takeoff — the unconstrained AI Futures Model trajectory (no deal).
2. Legal scaling — the consortium's post-deal glidepath toward TED-AI plus the safety tax.
3. Covert project — a hidden project racing the consortium on diverted compute and leaked software.
4. Deal dissolution — the deal collapses and the leading company continues alone.

Why a separate supplement: the megamodel is a useful tool in its own right, and it felt wrong to cram it into Section 7 of the Covert AI Projects supplement with the details explained in an appendix there.

The document follows that structure: Section 2 covers the changes to the AI Futures Model itself — the machinery every situation shares — and Sections 3–6 cover the four situations one at a time, each with its mechanics followed by its default parameters. Section 7 discusses qualitative dynamics.

Section 1: The megamodel

The explorer at the top of this page is a live interface to the same simulation code that produces this supplement's Monte-Carlo results — every slider change re-runs the actual model on the server, so what you see is the model, not a cached approximation of it.

The headline chart plots each project's AI software R&D uplift over time — the model's main capability metric, defined as the speedup an AI of that capability level would give to software R&D if it were dropped into the reference present day.¹ Up to four trajectories appear:

• Default takeoff (gray) — the unconstrained AI Futures Model run. This run also defines the milestones everything else is measured against: AC (Autonomous Coder), TED-AI (Top-Expert-Dominating AI, the race target), and ASI, each pinned to a level of effective compute (in OOMs) and a calendar date.
• Consortium (navy) — the legal project's deployed capability (the "used" glidepath; see Section 4.2). The chart can also show the discovered track, which runs ahead of deployed by the safety tax.
• Covert project (red) — the hidden project, starting from the same at-pause state with far less compute but a stream of stolen algorithms.
• Leading company (olive) — appears only when deal collapse is enabled: the leading company's solo trajectory after the consortium dissolves.

Readouts above the chart give the key dates: when the consortium's deployed capability reaches TED-AI, when the covert project does, and (if enabled) when the post-collapse leading company does.

Parameter tabs group the knobs by which situation they belong to — Takeoff Parameters (the underlying AI Futures Model timeline), Consortium Scaling Parameters (setup pause, windfall, scaling duration, safety tax, software floor), Covert Project Parameters (leakage fraction, dormancy, construction time, compute sizing), and Deal Collapse Parameters (when the deal breaks, what compute the leading company keeps, how fast it regrows). A Detection section exposes the facility-detection and "silver bullet" settings.

Per-metric mini-charts below the headline chart show each project on every internal model quantity: effective compute, uplift, coding-automation fraction, ETSP, software efficiency, training system performance, realized and indigenous research effort, coding-labor multiplier, research taste, the input compute series (training and total R&D H100e), the safety tax actually paid over time, and the covert project's detection-survival curve. Everything is exportable as CSV.

Section 2: Modifications to the AI Futures Model

This section documents the changes to the AI Futures Model (AIFM) itself — the machinery shared by every situation. Beyond one structural change to the model's physics (Section 2.1), the design principle is that the AIFM is reused unchanged: each situation in Sections 3–6 is the same equations fed different inputs, initial conditions, and controls.

Section 2.1: The continuous training run

The trajectories here are simulated by a modified version of the published AI Futures Model. The modification is explicit modeling of the training run. The published model composes capability multiplicatively — with effective compute in 2025-FLOP, training compute in FLOP, and software efficiency in 2025-FLOP per FLOP:

$$\text{effective compute} = \text{training compute} \times \text{software efficiency},$$

whereas the modified model defines an effective training system performance (2025-FLOP/s, from training system performance in FLOP/s),

$$\text{effective TSP} = \text{training system performance} \times \text{software efficiency},$$

and effective compute is the cumulative time integral of effective training system performance. In the log units used throughout (TSP in $\log_{10}$ FLOP/yr, software efficiency SW in OOMs), linear effective compute $E_{\mathrm{lin}}$ evolves as

$$\frac{dE_{\mathrm{lin}}}{dt} = 10^{\,\mathrm{TSP}(t) + \mathrm{SW}(t)}, \qquad \mathrm{SW} = r_{\mathrm{software}} \cdot \log_{10}(RS / RS_0).$$

Why make this change? The published AIFM (like Tom Davidson's FTM and Epoch AI's GATE) assumes you can pull software efficiency outside the integral. This is normally fine (though it does make fast takeoffs more likely than if you explicitly modeled retraining), but it becomes problematic for a heavily compute-constrained covert project which, rather than starting from scratch, starts with a copy of the pre-deal (Chinese) SOTA model weights and all the pre-deal algorithmic secrets. There are two ways to model that situation in the vanilla AIFM, and neither is good:

1. Reduce training compute proportionally to the overall covert compute reduction (e.g. by 100× if the covert project has 100× less compute than the previous leading AI company). This effectively assumes they start with no model weights and must train from scratch. But that isn't true — they can apply further RL to the pre-deal model, and they will use their best available model to accelerate AI R&D — so you would at minimum need to track their "best model" separately from their "best trainable-from-scratch model". This underestimates covert capability progress.
2. Freeze training compute at the pre-deal SOTA level (or grow it 100× slower). To first order this only slows progress by about half or less, holding the software-efficiency growth rate constant (e.g. because the consortium's algorithms are transparent and being copied). It ignores that the covert project needs to actually run those algorithms, which proceeds at a rate proportional to how much compute it has — it is as if the stolen algorithms magically applied retroactively to the training already done for the pre-deal model. This overestimates covert capability progress.

The integral form gets this right: a stolen algorithm raises a project's effective training rate from now on, and that rate is scaled by the training hardware it actually operates — past training is never retroactively upgraded.

The remaining simplification is assuming AI progress consists of a single continuous training run that has been in progress since the beginning of time (mathematically, the effective-compute integral runs from minus infinity to the current time). In reality, frontier training runs sometimes start from scratch (but not always), have different lengths, and may only be underway during parts of the year (requiring some unclear amortization for "H100e dedicated to training"). We think this is still an improvement on the published AIFM's treatment of training runs and captures most of the dynamics relevant to covert projects. My [BH's] best guess is that it directionally advantages covert projects more than is realistic, since certain capabilities may require architectural changes or otherwise require starting from scratch, and this model assumes you never need to do that.

Section 2.2: What is reused unchanged

Everything else is the AIFM. The model integrates a two-dimensional state — log effective compute $E$ (per Section 2.1) and research stock $RS$ — where research stock grows at the model's research effort: a production function of the project's capability (via coding automation and research taste, both functions of $E$) and its resources (experiment compute, inference compute, human labor). Every project in this supplement — consortium, covert, post-collapse leading company — is integrated with this exact right-hand side, differing only in its inputs, initial conditions, and controls. The capability-indexed metrics (uplift, automation fraction, coding-labor multiplier, research taste) are likewise computed by the AIFM's own metrics pass, so a given capability level means the same thing on every trajectory.²

Per Monte-Carlo draw, the pipeline first runs the unmodified (single-project) model once (the reference run). This defines the milestone levels and dates (AC, TED-AI, ASI) and the state every project branches from at the pause.

Section 2.3: Scenario timing is anchored to AC, not the calendar

Nothing in the scenario is pinned to a calendar year. The deal lands years_before_ac years before that rollout's AC date (default 0.838 yr — compute declarations on Jan 1, the pause starting Mar 1, and AC on Jan 1 of the following year in the median world where AC = 2030.0). The consortium's target date is pause + setup_period + scaling_duration, and the deal-collapse hazard clock also starts at the pause. This keeps the scenario well-posed as takeoff-timing uncertainty moves AC across worlds: a world with AC in 2033 gets the same relative scenario as one with AC in 2029.

Relatedly, quantities specified as stocks of 2025-progress-time (the alignment tax, the transparency windfall) are converted to OOMs of effective compute per rollout via the reference run's anchor progress rate — the OOMs one year of 2025-level progress is worth in that world — rather than at a fixed exchange rate.

Section 2.4: The two input compute series

The world's compute follows two series. The default series (input_data.csv) is the no-deal counterfactual: it drives the reference run and therefore AC, the pause date, and the milestone levels. The Plan-A series (inputs/plan-a.csv) is the post-deal world: a harder compute ramp beginning after the deal. The two are verified identical at every grid point through the shared pre-deal region, and Plan A's divergence is relativized to the pause: each rollout follows the default series up to its own pause, then Plan A's growth ramp time-shifted so the median world's pause-end maps to this rollout's pause-end, and scaled by the ratio of this rollout's at-pause compute to the median's. All post-deal projects live in this Plan-A world; the milestone targets they race toward come from the default counterfactual.

Section 2.5: Monte-Carlo machinery

Each draw samples the AIFM parameters (Section 3) and the scenario knobs from their configured distributions — every knob in Sections 4–6 is distribution-capable, and "fixed" below just means its current distribution is a point mass. Model parameters can be correlated via a Gaussian copula calibrated to a target Spearman matrix. The parameter stream, scenario-knob stream, detection draw, compute-sizing draw, and deal-breakdown draw are independent per-rollout RNG streams, so adding or removing a knob never perturbs the others. The pipeline is content-hashed end to end (configs + code + input series), and each run's dataset stores everything downstream figures need, so figures never re-run the model.

Section 3: Default takeoff

The default takeoff is the unmodified AIFM run on the no-deal compute series — the reference every other situation branches from and is measured against (Section 2.2). It samples the AI Futures Model's parameter distributions (inheriting the main model's sampling config), with the timeline pinned so the median world reaches AC on 2030.0:

Parameter	Value
AC time horizon	fixed ≈ 1.23M minutes (~9.9 work-years)
Horizon extrapolation	decaying doubling time; present doubling time 0.333 yr; difficulty growth factor 0.92
Present day / present horizon	2026.10 / 69.9 min
Horizon–AC gap	included, 1.10 yr (tuned so median AC = 2030.0)
AI research taste slope	lognormal, 80% CI [1.16, 10.45] (takeoff speed)
Median-to-top taste multiplier	shifted lognormal (shift 1), median ≈ 5.28
TED-AI level (ted_ai_m2b)	lognormal, 80% CI [0.41, 5.77]
All other AIFM parameters	inherited from the main model's sampling distributions

Input compute series: input_data.csv (the no-deal counterfactual). Simulation horizon for the race: 2017–2100 (the race resolves within a few years of AC; there is no need to integrate the post-takeoff explosion further).

Section 4: The legal project

The consortium's post-deal scaling toward TED-AI. Its trajectory is not free-running AIFM physics: the consortium chooses how fast to go, subject to what the physics allows. This section describes that control problem — the setup pause, the two glidepaths, and the constraints on them — then gives the default parameters.

Section 4.1: The setup pause and the radical-transparency windfall

For setup_period_years after the pause (default 0.838 yr), no training occurs: effective compute is exactly flat ($dE/dt = 0$). But the deal forces the labs to pool their algorithms publicly, so a one-time windfall of software efficiency accrues smoothly across the window. The windfall is specified as a stock of 2025-progress-time (default 4 progress-months) and converted to OOMs per rollout via the anchor progress rate (Section 2.3). Because the windfall enters the consortium's research stock, it is exposed to leakage like everything else the consortium discovers (Section 5.2).

Section 4.2: Two glidepaths — the alignment tax

The alignment tax is research the consortium must spend on alignment rather than capability. It is specified as a stock of 2025-progress-years (default 0.6) and converted to OOMs via the anchor progress rate. It splits the consortium into two tracks that share the same hardware, pause, and windfall, and differ only in their software target:

• Discovered — the consortium's full research output, solved to reach TED-AI + tax at the target date. This track's research stock is the consortium's complete body of algorithmic knowledge — including the alignment research (relevant for leakage, Section 5.2).
• Used — the consortium's deployed capability, solved to reach bare TED-AI at the date the discovered track actually arrives. This construction guarantees the invariant that the tax equals the gap between discovered and deployed effective compute at the moment deployed capability reaches TED-AI, and that the deployed track can never arrive before the discovered track has finished paying the tax.

The race is scored against the used track: the consortium "arrives" when its deployed capability reaches TED-AI.

Section 4.3: Software as the control variable

Along a consortium glidepath, software efficiency is treated as an exogenous policy rather than integrated from the effort ODE: a constant post-windfall software rate (OOM/yr) is chosen, research stock is back-derived from it ($RS = RS_0 \cdot 10^{\mathrm{SW}/r_{\mathrm{software}}}$), and effective compute is accumulated from TSP + SW. The rate itself is set by a one-dimensional root-find: the smallest constant rate that reaches the track's target at its target date, given the hardware path. If hardware plus windfall alone would arrive early, the solved rate is zero.

Section 4.4: The research-effort ceiling — a physics-capped consortium

A back-solved software rate answers "what rate would be needed" — it can silently imply more research effort than the consortium's capability and resources could physically produce under the AIFM's own production function. In an earlier 500-run check, the sustained back-solved ramp exceeded the AIFM effort ceiling in roughly half of rollouts, and by large factors in slow-takeoff worlds. The default mode therefore forward-integrates the consortium with its per-step research effort clamped at the AIFM ceiling — the research effort the model itself would grant a project with that capability and those resources.³ The controller tracks the minimal-software glidepath of Section 4.3 from below: in feasible worlds it reproduces the back-solve exactly (minimal software, on-time arrival); in infeasible worlds effort pins at the ceiling and the arrival slips late — the consortium never gets software it couldn't have produced, and never overshoots the minimal glidepath. The acausal back-solve is retained as an optional mode (legal_mode: backsolve) for comparison.

Section 4.5: Hardware strategies

Three options for the consortium's training-compute (TSP) path after the pause; the default is the first:

• Actual series (target_year_actual_hw, default) — the consortium's training compute follows the actual post-pause compute series (the Plan-A ramp of Section 2.4). Software is the only free control, and the effort ceiling is evaluated on the real resource trajectory.
• Solved ramp (target_year) — hardware grows at a constant solved rate up to a cap (max_hw_rate), chosen jointly with software: if hardware at the cap plus the windfall alone would arrive early, hardware is throttled down and software is zero; otherwise hardware sits at the cap and software fills the gap.
• Capped software (target_year_capped_sw) — like the solved ramp, but the tuned software rate has a flat ceiling (the windfall is exempt); the consortium arrives late if the cap binds.

Once a track reaches its target it sits: training and software R&D stop, and all its series freeze (subject to the post-scaling externalities of Section 4.7).

Section 4.6: The mandatory-minimum software floor

Under the actual-series strategy, while a track is scaling, its software efficiency is guaranteed to grow at at least min_sw_frac_of_tsp times the TSP (hardware) growth rate (default 0.2), regardless of the effort ceiling — a floor with the same "guaranteed" status as the transparency windfall, reflecting that you cannot scale hardware by an OOM without some accompanying algorithmic progress. The floor accrues only while that track is actually scaling and freezes when it arrives (the consortium halts training then), which matters for decompositions: the simulation emits the floor as its own series precisely so downstream charts attribute it correctly.

Section 4.7: Post-scaling externalities

After the discovered track reaches TED-AI + tax, ongoing alignment research keeps discovering software efficiency as an unavoidable capabilities side-effect, at a flat rate (post_scaling_externalities_rate, default 0.25 OOM/yr). None of it is deployed — it only inflates the discovered research stock (relevant for leakage, Section 5.2). The discovered track's hardware term also keeps following the real compute series (the consortium froze its own deployed runs, not the world's compute), so the discovered ceiling keeps rising after arrival. The used/deployed track gets none of this: it freezes at arrival.

Section 4.8: Parameters

Knob	Default	Meaning
years_before_ac	0.838 yr	Deal lands this long before the rollout's AC date
setup_period_years	0.838 yr	Training-R&D pause; no training, windfall accrues
setup_sw_gain_progress_months	4 progress-months	Radical-transparency windfall (converted to OOMs per rollout)
legal_scaling_duration	5 yr	Pause-end → target date for TED-AI + tax
alignment_tax_progress_years	0.6 progress-years	Discovered − deployed gap (converted to OOMs per rollout)
legal_strategy	target_year_actual_hw	Hardware follows the actual Plan-A training series
legal_mode	capped	Research effort clamped at the AIFM physics ceiling
min_sw_frac_of_tsp	0.2	Mandatory software floor as a fraction of TSP growth
post_scaling_externalities_rate	0.25 OOM/yr	Discovered-only software from post-arrival alignment research

Section 5: The covert project

A hidden project racing the consortium to TED-AI on diverted compute and leaked software. It pays no alignment tax — it needs only bare TED-AI — and wins a rollout if it gets there strictly before the consortium's deployed capability does, or if the consortium never arrives within the horizon.

Section 5.1: Starting state and compute

The covert project branches from the reference run's state at the pause — same capability $E$, same research stock — but with its own, much smaller, flat compute: a total H100e budget (sized per Section 5.4) split into inference/experiment/training in the frontier's at-pause mix, with human labor scaled by the same fraction.

Section 5.2: Leakage — stealing the consortium's software

The covert project is integrated with the standard AIFM right-hand side plus a theft term. With $f$ = frac_stolen and the consortium's (discovered) research stock $RS_L(t)$:

$$\frac{dRS_{\mathrm{cov}}}{dt} \;=\; b(t)\cdot RE_{\mathrm{own}} \;+\; f\cdot \frac{\dot{RS}_L}{RS_L}\, RS_{\mathrm{cov}}, \qquad b(t) = \left(\frac{RS_L(t)}{RS_L(t_{\mathrm{pause}})}\right)^{f}.$$

The second term is proportional theft: in log space, the covert's research stock captures a fraction $f$ of the consortium's relative research-stock growth — equivalently, the covert gets $f$ of every OOM of software efficiency the consortium discovers (the transparency windfall, the scaling-phase software, and the post-arrival externalities alike; Sections 4.1, 4.3, 4.7). The first term is the covert's indigenous R&D, boosted by $b(t)$: having the consortium's algorithms makes the covert's own researchers more productive, with the markup growing as the consortium pulls ahead of the at-pause state. Because theft is proportional to the consortium's research-stock growth, it dries up whenever the consortium stops producing software — after it arrives and sits (Section 4.5), or when the deal collapses (Section 6).

Section 5.3: Dormancy and construction

Before racing openly, the covert project passes through two sequential inactive phases: dormancy (dormancy_years, lying low before construction starts — default 0) and construction (construction_years, building the datacenter — default 2). For the training physics the two are identical — effective compute frozen, only stolen software accruing — but detection treats them very differently (Section 5.5): nothing is detectable during dormancy because no facility exists yet, while a facility under construction is already detectable.

Section 5.4: Sizing the compute

Three modes; the default scenario uses the bottom-up estimate:

• Bottom-up diversion estimate (bottom_up_estimate, default) — reconstructs how much compute China could plausibly divert covertly (Method #1 of the Covert AI Projects supplement, §2.3), as the sum of three sources with different natural bases. A diversion window ends at the compute declaration (default 0.16 yr before the pause — the Jan 1 books-close vs Mar 1 pause gap) and extends back diversion_duration (default 1 yr). Then: (1) false decommissioning takes a fraction of the world compute stock at the window start — feasibility Bernoulli × concealable fraction × China's share of world stock × the US-designed share of China's stock; (2) concealed domestic production takes a fraction of the flow of world compute produced during the window — feasibility Bernoulli × concealable fraction × China's domestic share; (3) smuggled Western flow takes smuggled-fraction × unidentifiable-fraction of the same window flow. The window tracks each rollout's pause, so worlds where the deal lands later divert from a correspondingly larger compute base (via the input series' world-compute column).
• Frontier-relative (frontier_relative) — a fixed fraction of the frontier's total compute at the pause (default 0.0126, calibrated to what 500k H100e was at the median pause). Holds the covert-vs-frontier reduction constant across worlds, removing the confounder that a fixed absolute size is a different handicap depending on when the pause lands.
• Absolute (absolute) — a fixed H100e count (default 500,000), pause-independent.

Section 5.5: Detection

Detection is a cheap post-processing stage, orthogonal to the race physics: each rollout draws one detection event from an independent random stream, and analyses combine the two dimensions at read time (e.g. "covert wins and was not detected first"). Two mechanisms multiply into one survival curve.

Facility signature (gamma-frailty). The covert program's total facility power (MW) is derived from its compute — total H100e × facility_w_per_h100e (default 600 W/H100e, so 500k H100e ≈ 300 MW) — and split across $n$ near-identical sites of a chosen per-site power. The probability the program is still undetected after its facilities have existed for $t$ years is

$$S(n, t) = \left[\pi + (1-\pi)\left(1 + \theta\, n\, H(t)\right)^{-1/\theta}\right] e^{-n r t}, \qquad H(t) = (t/\eta)^k,$$

a gamma-frailty survival model: $\pi$ is the never-detected-by-this-channel floor, $\theta$ the frailty dispersion, $\eta$ and $k$ the hazard's timescale and shape, and $r$ an optional constant per-site operational-mistake hazard (default 0). Crucially, $(\pi, \theta, \eta, k)$ are not inputs — they are fit, per site size, to the interpretable elicited inputs: expert grids of P(detected by 3 yr / 10 yr) versus number of sites, at 10/100/1000 MW per site (Section 5.6). Parameters are interpolated in log site-size between the elicited sizes. The detection clock starts when construction starts: during dormancy no facility exists, so survival is exactly 1 and the frailty clock is shifted by the dormancy length.

The "silver bullet". A program-level detection breakthrough (e.g. a universal lie detector or decisive interpretability tool) that, once it exists, exposes the covert project regardless of its facility signature. Its emergence probability is a ceiling-logistic $P(t) = C \cdot \sigma(k(t - t_{\mathrm{mid}}))$ — but anchored to the consortium's trajectory, not the calendar, since such a breakthrough is an output of the aligned frontier effort: the curve is pinned by a fixed probability at the midpoint between pause-end and the consortium's TED-AI arrival, a fixed probability shortly after that arrival, and a fixed asymptotic ceiling (defaults 0.20 / 0.55 / 0.70; Section 5.6). The silver-bullet clock is not shifted by dormancy — a breakthrough that emerged while the covert lay dormant bites the moment construction starts.

Unconditional survival is the product $S_{\mathrm{uncond}}(t) = G(t)\, S_{\mathrm{frailty}}(t - d)$ (with $G$ the no-silver-bullet-yet probability and $d$ the dormancy), and one detection time per rollout is drawn by exact inverse-CDF from it.

Section 5.6: Parameters

Compute sizing (bottom-up diversion estimate; the diversion window is [declaration − duration, declaration], declaration = pause − 0.16 yr):

Diversion knob	Default	Notes
False decommissioning feasible	Bernoulli, P = 0.60	Feasible to do deniably at all
Decommissionable fraction	beta, 80% CI [0.15, 0.30]	Of US-designed compute in China, given feasibility
China's share of world compute stock	6.7%	Composition ratio; US-designed share of China's stock derived ≈ 45%
China-designed share of world compute	3.7%	Also China's share of world production flow
Concealed domestic production feasible	Bernoulli, P = 0.25
Concealable fraction of domestic production	beta, 80% CI [0.02, 0.15]	Median ≈ 7%
Smuggled fraction of Western flow	lognormal, 80% CI [0.66%, 6.0%]	Median 2%
Unidentifiable fraction of smuggled	beta, 80% CI [2.5%, 70%]	End customer untraceable
Diversion duration	1 yr	High end, conditional on China going covert

Project knobs:

Knob	Default	Meaning
frac_stolen	beta, 80% CI [0.36, 0.90], median ≈ 0.67	Share of consortium algorithmic progress that leaks
dormancy_years	0	Lying low before construction; undetectable, no facility exists
construction_years	2	Build window; detectable, no training yet
facility_w_per_h100e	600 W	Converts compute to facility power for detection
optimal_site_mw	lognormal, 80% CI [50, 1000], median 300 MW	Per-site power the compute is split across
detection_reinspection_rate	0 /yr	Operational-mistake hazard (the $r$ in the frailty survival)

Detection elicitation — the interpretable inputs the frailty is fit to: P(detected | n near-identical sites, GPUs acquired undetected, no silver bullet) at 3-year and 10-year horizons. For a single site: 20%/26% (10 MW), 25%/35% (100 MW), 40%/50% (1000 MW), rising with site count (e.g. 100 × 100 MW sites: 65%/80%). Silver bullet (placeholder values, to be re-elicited): P(emerged) = 0.20 at the midpoint between pause-end and the consortium's TED-AI arrival, 0.55 two years after that arrival, ceiling 0.70.

Section 6: Deal dissolution

The deal collapses and the leading company continues alone. This situation is gated off by default in the Monte Carlo (the deal holds unless a breakdown block is configured) and toggled explicitly in the explorer.

Section 6.1: When the deal breaks

When the deal collapses is sampled from an explicit hazard curve: a per-year breakdown hazard specified as knots linearly interpolated over years-since-deal-start, with an exponentially decaying tail (default: 0.12/yr at the start, easing to 0.02/yr by year 16, decaying 5%/yr thereafter). The tail integral is finite, so a fraction of worlds never break down (~28% at the defaults; median breakdown ~9 years in). The curve can be conditioned on the deal surviving at least $N$ years (draws come from the truncated survival curve). A collapse sampled inside the setup pause clamps to the moment the pause ends.

Section 6.2: What happens at the breakdown

• The consortium dissolves. Both glidepaths freeze at their breakdown values (a track that hadn't arrived never does), and — with the consortium's research effort zeroed — the covert project's stolen-software stream stops (Section 5.2). The safety tax stops being paid.
• The leading company spins out and continues alone, integrated with the same physics as the covert project but no stealing (there is no consortium left to steal from) and no tax. Its starting state is deliberately asymmetric: capability (effective compute) starts from the used/deployed track — that is what it actually runs — while research stock starts from the discovered track, because the deploy restrictions holding that research back die with the deal. Its software efficiency therefore jumps up discontinuously at the collapse by the withheld tax plus accumulated externality software.
• Its compute is breakdown_compute_reduction × a reference mix, growing at post_breakdown_compute_growth_rate OOM/yr, with labor scaled by the same reduction and held flat. The reference mix is set by breakdown_compute_mode: frontier_at_pause (the pre-deal frontier — deal-era compute is effectively destroyed at dissolution) or world_at_breakdown (the world's compute at the collapse, carried through the deal by the Plan-A series — nothing is destroyed, and the company runs the largest post-dissolution project on that share).

The detection model is currently unchanged by a breakdown — an acknowledged open question.

Section 6.3: Parameters

Knob	Default	Meaning
Breakdown hazard	0.12/yr at deal start → 0.06 (yr 6) → 0.03 (yr 11) → 0.02 (yr 16), then ×0.95/yr	~28% of deals never break; median breakdown ~9 yr in
min_survival_years	0	Optional conditioning: deal survives at least this long
breakdown_compute_reduction	0.1	Leading company's share of the reference compute mix
breakdown_compute_mode	frontier_at_pause	Reference mix: pre-deal frontier vs world-at-collapse
post_breakdown_compute_growth_rate	1.0 OOM/yr	Leading company's compute regrowth
Leading company start state	—	Capability from the deployed track; research stock from the discovered track (deploy restrictions die with the deal)

In the interactive explorer the collapse time is a slider (default 6.5 years after the pause ends — deliberately after the consortium's 5-year scaling window, so the default collapse lands after the consortium reaches its target); in the Monte Carlo it is sampled from the hazard curve above.

Section 7: Qualitative dynamics

Section 7.1: How "N" works

A companion experiment (the pause-reduction experiment, run on the same AIFM machinery) asks the cleanest version of the question underlying this supplement: per sampled world, how much longer does it take to get from a pause to ASI if the pause cuts compute and labor by a factor R = 10 and freezes them versus merely freezing them? Call the ratio of the two remaining times N — the extra slowdown bought by the cut, on top of stopping growth.

Empirically and then analytically, N follows a per-world constant-elasticity power law, $N \approx R^{k}$, where $k$ is a weighted average of the returns to experiment compute and the returns to hardware:

$$k = \frac{r_{\mathrm{software}} \cdot e + 1}{r_{\mathrm{software}} + 1},$$

with $e$ the experiment-compute exponent of the research production function and $r_{\mathrm{software}}$ the software-efficiency returns parameter (the weights are $r_{\mathrm{software}} : 1$, software vs pure hardware). Intuition: a compute cut slows research by $R^{e}$ directly, but the slowed project also accumulates more research stock by the time it reaches any given capability level (it travels slower through the same terrain), which partially compensates; the quasi-equilibrium of that compensation yields the exponent above. Typical sampled worlds have $e < 1$ (diminishing returns to experiment compute) and $N \approx 5$: a 10× cut buys roughly a 5× slowdown. The heavy upper tail is the interesting part: worlds with $e > 1$ (increasing returns, i.e. a high experiment-compute anchor cap) have $N > 10$ — there, software compounds instead of compensating, and the cut is more than proportionally effective. The single dominant driver of N across sampled worlds is that experiment-compute elasticity parameter; conditioning on AC timing and the AC→ASI gap collapses most of the remaining spread for late pauses but little of it for early ones.

Section 7.2: Other sensitivities

Structurally, the covert race is a contest between two software streams over a shared hardware backdrop, and its outcome is most sensitive to the knobs that set those streams' relative sizes:

• frac_stolen is the covert side's master lever — it scales the stolen share of the windfall, the scaling-phase software, and the post-arrival externalities all at once, and additionally sets the indigenous-R&D boost exponent.
• The consortium's realized software rate (scaling duration, alignment tax, windfall, and the software floor together) matters twice: it sets when the consortium arrives and how much there is to steal. Notably, a more cautious consortium (longer duration, bigger tax) both arrives later and leaks longer.
• Takeoff-speed parameters (taste slope, TED-AI level) act mainly through the AC→TED-AI gap: slow-takeoff worlds stretch the race, bind the consortium's effort ceiling (arrival slips), and give the covert project more time — covert wins concentrate there.
• Covert compute size matters less than intuition suggests for the race itself (software dominates near takeoff, and the covert inherits the frontier's at-pause capability), but it is decisive for detection, which keys on facility power: the surviving covert worlds skew small and slow.
• Timing knobs (dormancy, construction) trade progress against detection: lying dormant delays the covert's own R&D while the detection clock stays at zero but the silver-bullet clock keeps running.

Headline statistics (covert win rates, detection-conditioned capability distributions) depend on the specific run configuration and are reported alongside each run's figures rather than here.