{
  "schema_version": "1.2.0",
  "rubric_version": "1.1",
  "license": "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)",
  "record": {
    "id": "C-0007",
    "slug": "training-within-declared-limits",
    "title": "A training run stayed within declared limits",
    "aliases": [
      "training compute limits",
      "proof of training"
    ],
    "status": "published",
    "last_reviewed": "2026-09-25",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": [
        "codex-review"
      ]
    },
    "risk_flags": [],
    "flags": [],
    "one_liner": "A declared training run used no more compute than permitted and had its declared properties, such as data, hyperparameters and resulting weights.",
    "summary": "The claim is that a declared training run used no more compute than permitted and had its declared properties, such as its data, hyperparameters and resulting weights. Many proposed rules on frontier AI limit training, often through a threshold on total training compute measured in floating-point operations, sometimes combined with limits on data or methods. Verifying that a run stayed within them would let a regulator or treaty partner rely on something other than self-reporting. It is hard because training is long, distributed and expensive to repeat. Exact replay is complicated by numerical noise, the data and weights are sensitive, and work could be split across declared and undeclared hardware. Proposals include on-chip logging of weight snapshots with sampled recomputation of training segments, proof-of-learning protocols, zero-knowledge proofs and telemetry-based accounting. Published attacks show that the original proof-of-learning protocol can be spoofed.",
    "claim_class": "mixed",
    "editors_synthesis": {
      "assessment": true,
      "markdown": "Proof-based checks of training remain far below frontier-scale runs. Proof-of-learning and zero-knowledge proofs of training are both demonstrated (R2); hardware enforcement remains proposed (R1).\n\n[[M-0006|Proof-of-learning and transcript verification]] (R2) re-runs sampled training segments between logged weight snapshots [[S-0029]], and [[M-0005|zero-knowledge proofs of training]] (R2) prove that training followed a committed specification without revealing data or weights [[S-1110]]. [[M-0009|Guarantee processors such as flexHEG]] and [[M-0011|licensing]] (both R1) could enforce compute limits in hardware [[S-0035]] [[S-0057]].\n\nChoi and colleagues report proof-of-training-data experiments on language models of up to 1 billion parameters [[S-0030]], and Kaizen proves training iterations of a 10-million-parameter image model at about 15 minutes of proving per iteration [[S-1110]]. VeriLoRA proves individual low-rank fine-tuning steps on language models of up to 13 billion parameters [[S-3080]].\n\nPublished attacks spoof the original proof-of-learning protocol, and the attack's authors argue that a provably robust version needs a better understanding of deep-learning optimisation [[S-0027]]. Governance analyses have judged zero-knowledge proofs impractical at frontier scale, and one 2026 proposal argues this is a limit of current approaches, not a fundamental one [[S-0025]]. A compute limit bounds a run only if all the chips used are known, so this claim depends on [[C-0001]] and [[C-0010]].",
      "text": "Proof-based checks of training remain far below frontier-scale runs. Proof-of-learning and zero-knowledge proofs of training are both demonstrated (R2); hardware enforcement remains proposed (R1). Proof-of-learning and transcript verification (R2) re-runs sampled training segments between logged weight snapshots [S-0029], and zero-knowledge proofs of training (R2) prove that training followed a committed specification without revealing data or weights [S-1110]. Guarantee processors such as flexHEG and licensing (both R1) could enforce compute limits in hardware [S-0035] [S-0057]. Choi and colleagues report proof-of-training-data experiments on language models of up to 1 billion parameters [S-0030], and Kaizen proves training iterations of a 10-million-parameter image model at about 15 minutes of proving per iteration [S-1110]. VeriLoRA proves individual low-rank fine-tuning steps on language models of up to 13 billion parameters [S-3080]. Published attacks spoof the original proof-of-learning protocol, and the attack's authors argue that a provably robust version needs a better understanding of deep-learning optimisation [S-0027]. Governance analyses have judged zero-knowledge proofs impractical at frontier scale, and one 2026 proposal argues this is a limit of current approaches, not a fundamental one [S-0025]. A compute limit bounds a run only if all the chips used are known, so this claim depends on Compute stock is at most a declared amount and There is no undeclared relevant compute."
    },
    "sources": [
      {
        "source": "S-0029",
        "supports": "goal and example rules; weight snapshots; sampled segment recomputation; reasons full re-run is infeasible; PoTT harder than PoL; open problems (online RL, thresholds)",
        "locator": "abstract; §2–§3; open problems"
      },
      {
        "source": "S-0053",
        "supports": "EO 14110 threshold; compute as a high-level proxy; thresholds must change with progress",
        "locator": "thresholds; limitations"
      },
      {
        "source": "S-0069",
        "supports": "revocation of EO 14110 on 20 January 2025",
        "locator": "Sec. 2(ggg)"
      },
      {
        "source": "S-0063",
        "supports": "training above 10^24 FLOP prohibited; runs above 10^22 FLOP approved and monitored",
        "locator": "§4"
      },
      {
        "source": "S-0062",
        "supports": "unauthorised training above a FLOP threshold as a violation type",
        "locator": "What to verify"
      },
      {
        "source": "S-0002",
        "supports": "Subgoal 1.A.1 verifying declared training",
        "locator": "§3.2"
      },
      {
        "source": "S-0025",
        "supports": "enforcement rests on self-reporting; governance analyses judge ZKPs impractical at frontier scale, which the authors argue is paradigm-bound; proposed architecture; ~36-month estimate",
        "locator": "abstract"
      },
      {
        "source": "S-0027",
        "supports": "reproducible PoL spoofing at a fraction of prior cost; provably robust PoL requires advances in understanding deep-learning optimisation",
        "locator": "abstract"
      },
      {
        "source": "S-0018",
        "supports": "monitoring training needs larger perimeters or compute-fabric taps; back-end traffic harder to capture",
        "locator": "§5.1.1; inference vs training"
      },
      {
        "source": "S-0035",
        "supports": "flexHEG compute limits for training",
        "locator": "abstract; Executive Summary"
      },
      {
        "source": "S-0057",
        "supports": "offline licensing with a compute budget",
        "locator": "p. viii"
      },
      {
        "source": "S-0030",
        "supports": "training-data verification experiments on GPT-2 and Pythia models up to 1B parameters",
        "locator": "§4"
      },
      {
        "source": "S-1110",
        "supports": "Kaizen zero-knowledge proofs of training; VGG-11 (10M parameters) at about 15 minutes per iteration",
        "locator": "abstract; evaluation"
      },
      {
        "source": "S-3080",
        "supports": "VeriLoRA proofs of individual LoRA fine-tuning steps on language models up to 13B parameters",
        "locator": "§VI-B–VI-D"
      },
      {
        "source": "S-3542",
        "supports": "Art. 51(2) presumption of high-impact capabilities above 10^25 FLOP; Art. 52(1) notification within two weeks; Art. 113(b) Chapter V applies from 2 August 2025",
        "locator": "Arts 51, 52, 113"
      },
      {
        "source": "S-3543",
        "supports": "10^25 FLOP presumption and two-week notification; entry into application on 2 August 2025",
        "locator": "§2.3.1–2.3.2; landing page"
      },
      {
        "source": "S-3544",
        "supports": "frontier model defined by more than 10^26 integer or floating-point operations including fine-tuning; transparency duties",
        "locator": "§22757.11(i); §22757.12"
      },
      {
        "source": "S-0059",
        "supports": "compute structuring: splitting or modifying workloads to avoid regulation",
        "locator": "abstract"
      }
    ],
    "concepts": [
      "K-0023",
      "K-0009",
      "K-0020",
      "K-0010",
      "K-0024",
      "K-0008"
    ],
    "order": 7,
    "type": "claim",
    "url": "https://trustbutveri.fyi/claims/training-within-declared-limits/",
    "source_file": "content/claims/training-within-declared-limits.md",
    "flags_all": [],
    "body_markdown": "## Why it matters\nLimits on training are a common rule in compute-governance proposals [[S-0062]].\n\n- **Shavit's framework** aims to give governments high confidence that no actor uses large quantities of specialised ML chips for a training run that violates agreed rules [[S-0029]]. Its example rules include total training compute, properties of the training data, hyperparameters such as the share of reinforcement-learning steps, and combinations of these with benchmark performance [[S-0029]].\n- **US Executive Order 14110** required reporting for models trained with more than 10^26 operations [[S-0053]]. It was revoked in January 2025 [[S-0069]].\n- **The EU AI Act and California's SB 53** both set training-compute thresholds. The AI Act presumes that a general-purpose AI model trained with more than 10^25 FLOP has high-impact capabilities, one of the conditions for classing it as a model with systemic risk [[S-3542]]. Its provider must notify the European Commission within two weeks of meeting the threshold or learning that it will, an obligation that has applied since 2 August 2025 [[S-3542]] [[S-3543]]. SB 53, enacted in September 2025, sets transparency duties for developers of frontier models, defined as models trained with more than 10^26 integer or floating-point operations, including later fine-tuning and other material modifications [[S-3544]].\n- **A draft international agreement** prohibits training runs above 10^24 FLOP, and requires runs above 10^22 FLOP to be approved and monitored [[S-0063]].\n- **Wasil and colleagues** treat training above an agreed FLOP threshold as one of two main violation types to be detected [[S-0062]]. RAND lists verifying declared training as its own subgoal [[S-0002]].\n\nWithout technical verification, such limits rest on self-reporting, a gap the authors of a 2026 zero-knowledge proposal identify in current frontier AI governance frameworks [[S-0025]].\n\n## Why it is hard\n- **Training cannot simply be re-run.** Shavit gives three reasons: hardware noise makes training irreproducible, the compute cost is very large, and the training data may be confidential [[S-0029]]. His framework instead has chips save weight snapshots at random times, and the verifier re-runs short segments between reported checkpoints, accepting results within a tolerance [[S-0029]].\n- **Transcripts can be spoofed.** Shavit notes that proving a transcript is the original one is harder than proof-of-learning, because the adversary knows the true transcript and has more compute time to construct a spoof [[S-0029]]. Fang and colleagues introduced spoofing strategies against proof-of-learning that reproduce across verification configurations at a fraction of the cost of earlier attacks [[S-0027]]. They conclude that a provably robust proof-of-learning mechanism cannot be built without further understanding of optimisation in deep learning [[S-0027]].\n- **Coverage.** A limit on one run means little if other hardware contributes undeclared work, so Shavit pairs run verification with supply-chain monitoring [[S-0029]]. A developer could also split a run into workloads that each stay below a threshold, which Seferis and Fist call compute structuring [[S-0059]]. Training traffic runs over high-bandwidth back-end fabric that is harder to capture than inference traffic [[S-0018]].\n- **Open design problems.** Shavit lists extending pre-commitment to online reinforcement learning, where training data cannot be known in advance, and choosing principled thresholds when scaling laws do not reliably predict downstream capabilities [[S-0029]].\n- **Cryptographic cost.** A 2026 proposal notes that governance analyses judge zero-knowledge proofs currently impractical at frontier scale, and argues that this is a limit of current approaches rather than a fundamental one [[S-0025]]. It sets out an architecture combining a pre-committed training specification, network observations and Merkle commitments, and estimates a proof of concept within about 36 months [[S-0025]].\n- **Compute is a proxy.** Training compute is only a high-level proxy for capability, and thresholds may need to change as algorithms improve [[S-0053]].",
    "body_text": "Why it matters Limits on training are a common rule in compute-governance proposals [S-0062]. - Shavit's framework aims to give governments high confidence that no actor uses large quantities of specialised ML chips for a training run that violates agreed rules [S-0029]. Its example rules include total training compute, properties of the training data, hyperparameters such as the share of reinforcement-learning steps, and combinations of these with benchmark performance [S-0029]. - US Executive Order 14110 required reporting for models trained with more than 10^26 operations [S-0053]. It was revoked in January 2025 [S-0069]. - The EU AI Act and California's SB 53 both set training-compute thresholds. The AI Act presumes that a general-purpose AI model trained with more than 10^25 FLOP has high-impact capabilities, one of the conditions for classing it as a model with systemic risk [S-3542]. Its provider must notify the European Commission within two weeks of meeting the threshold or learning that it will, an obligation that has applied since 2 August 2025 [S-3542] [S-3543]. SB 53, enacted in September 2025, sets transparency duties for developers of frontier models, defined as models trained with more than 10^26 integer or floating-point operations, including later fine-tuning and other material modifications [S-3544]. - A draft international agreement prohibits training runs above 10^24 FLOP, and requires runs above 10^22 FLOP to be approved and monitored [S-0063]. - Wasil and colleagues treat training above an agreed FLOP threshold as one of two main violation types to be detected [S-0062]. RAND lists verifying declared training as its own subgoal [S-0002]. Without technical verification, such limits rest on self-reporting, a gap the authors of a 2026 zero-knowledge proposal identify in current frontier AI governance frameworks [S-0025]. Why it is hard - Training cannot simply be re-run. Shavit gives three reasons: hardware noise makes training irreproducible, the compute cost is very large, and the training data may be confidential [S-0029]. His framework instead has chips save weight snapshots at random times, and the verifier re-runs short segments between reported checkpoints, accepting results within a tolerance [S-0029]. - Transcripts can be spoofed. Shavit notes that proving a transcript is the original one is harder than proof-of-learning, because the adversary knows the true transcript and has more compute time to construct a spoof [S-0029]. Fang and colleagues introduced spoofing strategies against proof-of-learning that reproduce across verification configurations at a fraction of the cost of earlier attacks [S-0027]. They conclude that a provably robust proof-of-learning mechanism cannot be built without further understanding of optimisation in deep learning [S-0027]. - Coverage. A limit on one run means little if other hardware contributes undeclared work, so Shavit pairs run verification with supply-chain monitoring [S-0029]. A developer could also split a run into workloads that each stay below a threshold, which Seferis and Fist call compute structuring [S-0059]. Training traffic runs over high-bandwidth back-end fabric that is harder to capture than inference traffic [S-0018]. - Open design problems. Shavit lists extending pre-commitment to online reinforcement learning, where training data cannot be known in advance, and choosing principled thresholds when scaling laws do not reliably predict downstream capabilities [S-0029]. - Cryptographic cost. A 2026 proposal notes that governance analyses judge zero-knowledge proofs currently impractical at frontier scale, and argues that this is a limit of current approaches rather than a fundamental one [S-0025]. It sets out an architecture combining a pre-committed training specification, network observations and Merkle commitments, and estimates a proof of concept within about 36 months [S-0025]. - Compute is a proxy. Training compute is only a high-level proxy for capability, and thresholds may need to change as algorithms improve [S-0053].",
    "addressed_by": [
      {
        "id": "M-0014",
        "title": "Bandwidth limits and compartmentalization",
        "url": "https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/",
        "role": "supporting",
        "note": "Bounds the size of model that can be trained efficiently across pods (S-1301)."
      },
      {
        "id": "M-0025",
        "title": "Confidential multi-party verification",
        "url": "https://trustbutveri.fyi/mechanisms/confidential-multi-party-verification/",
        "role": "supporting",
        "note": "Zero-knowledge audits can prove properties of committed training data and weights (S-0022)."
      },
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/",
        "role": "primary",
        "note": "Verifiable claims about total training compute, and enforcement of compute thresholds (S-0035)."
      },
      {
        "id": "M-0011",
        "title": "Hardware performance throttling and licensing",
        "url": "https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/",
        "role": "supporting",
        "note": "Licenses that authorize a fixed amount of work would bound compute per license period (S-0057, S-0006)."
      },
      {
        "id": "M-0010",
        "title": "On-chip telemetry from timing, memory and performance counters",
        "url": "https://trustbutveri.fyi/mechanisms/on-chip-telemetry/",
        "role": "supporting",
        "note": "Counters for FLOP, memory and interconnect traffic are proposed as meters for compute accounting (S-0057, S-0006)."
      },
      {
        "id": "M-0006",
        "title": "Training-transcript verification (proof-of-learning)",
        "url": "https://trustbutveri.fyi/mechanisms/proof-of-learning/",
        "role": "primary",
        "note": "Transcript checks for rules on training compute, data and hyperparameters (Shavit; Choi et al.)."
      },
      {
        "id": "M-0003",
        "title": "Whole-workload recomputation (reproducible packets)",
        "url": "https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/",
        "role": "supporting",
        "note": "Proposed for later R&D verification by treating training steps as packets (S-0067, S-0017)."
      },
      {
        "id": "M-0008",
        "title": "TEE remote attestation for AI workloads",
        "url": "https://trustbutveri.fyi/mechanisms/tee-remote-attestation/",
        "role": "supporting",
        "note": "PAL*M attests single-node training and fine-tuning operations (S-0012). Distributed training is left open."
      },
      {
        "id": "M-0021",
        "title": "Workload classification from telemetry and side channels",
        "url": "https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/",
        "role": "supporting",
        "note": "Can flag training on hardware declared for other uses; does not measure training size by itself."
      },
      {
        "id": "M-0005",
        "title": "Zero-knowledge proofs of training constraints",
        "url": "https://trustbutveri.fyi/mechanisms/zk-proofs-of-training-constraints/",
        "role": "primary",
        "note": "Proves training followed a committed specification and data; the frontier design adds compute-threshold attestations."
      },
      {
        "id": "I-0015",
        "title": "Verde and RepOps (Gensyn)",
        "url": "https://trustbutveri.fyi/implementations/gensyn-verde-repops/",
        "role": "supporting",
        "note": "Also covers training and fine-tuning jobs delegated to several providers (S-1809)."
      }
    ],
    "referenced_by": [
      {
        "id": "M-0014",
        "title": "Bandwidth limits and compartmentalization",
        "url": "https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/"
      },
      {
        "id": "M-0025",
        "title": "Confidential multi-party verification",
        "url": "https://trustbutveri.fyi/mechanisms/confidential-multi-party-verification/"
      },
      {
        "id": "M-0009",
        "title": "Hardware-enabled guarantees (flexHEG) and guarantee processors",
        "url": "https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/"
      },
      {
        "id": "M-0011",
        "title": "Hardware performance throttling and licensing",
        "url": "https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/"
      },
      {
        "id": "M-0010",
        "title": "On-chip telemetry from timing, memory and performance counters",
        "url": "https://trustbutveri.fyi/mechanisms/on-chip-telemetry/"
      },
      {
        "id": "M-0006",
        "title": "Training-transcript verification (proof-of-learning)",
        "url": "https://trustbutveri.fyi/mechanisms/proof-of-learning/"
      },
      {
        "id": "M-0003",
        "title": "Whole-workload recomputation (reproducible packets)",
        "url": "https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/"
      },
      {
        "id": "M-0008",
        "title": "TEE remote attestation for AI workloads",
        "url": "https://trustbutveri.fyi/mechanisms/tee-remote-attestation/"
      },
      {
        "id": "M-0021",
        "title": "Workload classification from telemetry and side channels",
        "url": "https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/"
      },
      {
        "id": "M-0005",
        "title": "Zero-knowledge proofs of training constraints",
        "url": "https://trustbutveri.fyi/mechanisms/zk-proofs-of-training-constraints/"
      },
      {
        "id": "I-0015",
        "title": "Verde and RepOps (Gensyn)",
        "url": "https://trustbutveri.fyi/implementations/gensyn-verde-repops/"
      },
      {
        "id": "C-0003",
        "title": "Declared hardware is idle or shut down",
        "url": "https://trustbutveri.fyi/claims/declared-hardware-is-idle/"
      }
    ]
  }
}