Policy often needs a trigger that can be identified before a powerful system is released. Training compute is attractive because organizations plan hardware, runtime, and cost in advance, leaving auditable records. Yet compute is a proxy for potential capability, not a direct measurement of harm. A useful regime treats a compute threshold as an early notification and evidence trigger, then combines it with model evaluations, deployment controls, and the consequences of intended use.
For a dense autoregressive model, a rough planning estimate is $$C\approx 6ND,$$ where $C$ is training floating-point operations, $N$ is the number of actively trained non-embedding parameters, and $D$ is the number of training tokens. The factor six approximates forward and backward computation and changes with architecture, sparsity, sequence operations, precision, and implementation. A policy calculation should therefore use measured accelerator operations when available and document what the estimate includes.
One current regulatory framework uses cumulative training compute above $10^{25}$ floating-point operations as a rebuttable presumption of high-impact capability. A convenient margin is $$m=\log_{10}C-25.$$ Positive $m$ means the estimate is above that example threshold. The legal threshold can be amended as algorithms and hardware improve, so production systems must load the current rule from governed policy data rather than burying a permanent number in model code.
Estimate uncertainty before deciding whether a trigger applies. Represent planned compute as an interval $[C_L,C_U]$ and trigger advance review when $C_U$ crosses the applicable threshold. Define whether cumulative compute includes aborted runs, repeated pretraining, fine-tuning, architecture searches, and experiments that materially contribute to the final model. Without a written aggregation rule, a large program can appear small by splitting work across runs, teams, or legal entities.
Compute alone misses algorithmic efficiency, data quality, tool access, post-training, inference-time search, model copying, and deployment scale. Pair the ledger with capability evaluations tied to concrete hazards and with system-level exposure measures. A lower-compute model with dangerous tool permissions may warrant stricter controls than a larger model confined to a narrow offline task. Conversely, crossing a compute threshold should start evidence and reporting duties; it should not predetermine the final risk conclusion.
Maintain a compute ledger from project approval through release. Record model version, hardware type and count, utilization method, training duration, precision, parameter activity, token count, included runs, uncertainty bounds, accountable approver, and links to evaluation evidence. Reconcile planned and measured totals, protect logs from unilateral editing, and review material changes before resources are committed. Key diagnostics are unexplained compute gaps, runs outside the ledger, threshold margins, aggregation disagreements, and capability changes not predicted by compute.