{
  "schema_version": "1.0.0",
  "rubric_version": "1.0",
  "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": "draft",
    "last_reviewed": "2026-09-23",
    "review_interval_days": 90,
    "steward": null,
    "provenance": {
      "drafted_by": "ai",
      "reviewed_by": []
    },
    "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": "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. The claim is mixed: the declared run happened as described, and it did not exceed its limits. 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": "Training limits can so far be checked only far below frontier scale. The two proof-based mechanisms, both demonstrated (R2), have results on models of at most 1 billion parameters, and hardware enforcement is proposed (R1).\n\n[[M-0006|Proof-of-learning and transcript verification]] (R2) re-runs sampled training segments between logged weight snapshots [[S-0029]]. [[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]]. Kaizen proves training iterations of a 10-million-parameter image model, at about 15 minutes of proving per iteration [[S-1110]].\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; 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": "Training limits can so far be checked only far below frontier scale. The two proof-based mechanisms, both demonstrated (R2), have results on models of at most 1 billion parameters, and hardware enforcement is proposed (R1). Proof-of-learning and transcript verification (R2) re-runs sampled training segments between logged weight snapshots [S-0029]. 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]. Kaizen proves training iterations of a 10-million-parameter image model, at about 15 minutes of proving per iteration [S-1110]. 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; 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"
      }
    ],
    "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": [
      "ai-drafted"
    ],
    "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- **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]]. 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]. - 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]. 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": "Proof-of-learning and training-transcript verification",
        "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": "Reproducible computation 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."
      }
    ],
    "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": "Proof-of-learning and training-transcript verification",
        "url": "https://trustbutveri.fyi/mechanisms/proof-of-learning/"
      },
      {
        "id": "M-0003",
        "title": "Reproducible computation 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": "C-0003",
        "title": "Declared hardware is idle or shut down",
        "url": "https://trustbutveri.fyi/claims/declared-hardware-is-idle/"
      }
    ]
  }
}