Plan A is predicated on the ability to enforce an international deal to slow down AI progress without relying on trust. We are confident that verification measures can make this possible, by providing sufficient assurance to both the US and China that defection by the other would either be caught or small enough to be inconsequential.

There is a spectrum of how costly and how trustworthy our best verification solutions are, which we can think of as a verification frontier. Today, the verification frontier is not mature. Currently the only way of verifying an AI development pause with extremely high assurance between the US and China would probably require datacenters to be powered down, and anything less costly than this might have significant risk of being violated. That being said, we believe the verification problem is inherently defense dominant, and AI verification is also an extremely young and so far tiny field, so it should be highly tractable to make significant progress in the next few years.

This supplement provides a summary of the verification plan that we think should be followed to make Plan A viable, and then is followed by a more detailed walkthrough of how the verification story unfolds in our specific Plan A scenario.

Want to help build this? See the Get Involved tab: what needs to be done, who the field needs, an expression of interest form, and open opportunities across the verification field.

Summary of the Plan

We recommend an international deal to avoid a catastrophic race to superintelligence, spearheaded by the US and China. This deal needs to be enforceable without relying on trust, because the US and China will be unlikely to make an agreement that cannot be verified; and they are much less likely to defect on the agreement if any defection is likely to be caught.

We can break up the verification problem into two key components:

Our recommended solutions come in three phases.

Phase 1. Prepare Deal Optionality. The US and China take actions to make a deal more likely to be enforceable and durable, by preparing the ability to do inference-only verification, and keeping close tabs on how much AI compute exists and who owns it.

Phase 2. Implement a Deal. The US and China perform a mutual compute declaration (spreading to third countries and ideally reaching >99% of world compute); inference-only verification retrofit to ~99% of world AI datacenter compute, and then sprint towards setting up secure R&D verification that will use new post-deal compute production.

Phase 3. Improve robustness. Over time the US and China improve the stability and durability of the verification regime, especially through hardware security, verification robustness, and more.

Phase 1. Prepare Deal Optionality

We recommend focusing pre-deal effort on sprinting towards a minimal verification package that can be used to securely retrofit 99% of the world's AI compute to be verified as inference-only, and for at least 99% of the world's AI compute to be known-to-exist (at least to intelligence agencies) with low uncertainty, so that it can’t be hidden from a future compute declaration (and therefore verification regime) with plausible deniability.

Top priority recommendations:

Phase 2. Implement the deal

To set up a stable deal, we recommend immediately carrying out a mutual compute declaration and supply chain records audit to maximize the amount of compute that is brought under the deal. Then implementing the best available inference-only verification solution to this compute to enforce a brief pause on training and experiments. In parallel, we recommend a sprint to set up a verification regime for resumed training and experiments.

Top priority recommendations:

Phase 3. Improve Robustness

Once a deal has been set up, we expect many improvements to its robustness will be possible. We recommend investing heavily in hardware security; improving the verification regime; pursuing favorable trade-offs in hardware design that favor deal robustness (e.g., by making verification easier, improving various security properties, differentially favoring the actors in the deal over covert projects, etc.); and reducing incentives to pull out of the deal (e.g., through mutually assured compute destruction, and balancing deal dissolution outcomes between actors).

Verifying the deal in our Plan A scenario

In our Plan A scenario, we follow the high level verification plan sketched out in the previous section. This part of the verification supplement will walk through the implementation and verification story with more concrete detail. Because it is a scenario about the future, in a very young field with ongoing R&D, we are not confident in the specific details. That being said, we hope to establish a useful concrete baseline for how the verification plan we sketched out above could actually be implemented.

2026-2028: Preparing deal optionality

2026: Chip tracking begins

The intelligence agencies in the US begin internally keeping tabs on AI compute smuggling into China, and their domestic production levels, reaching a 10% uncertainty over how much AI compute Chinese entities own in total by the end of the year. They don’t do anything with this information yet (i.e., they don’t share smuggling information with the BIS). China learns that the US intelligence community is doing this, and begins doing it as well by leveraging existing assets mostly out of TSMC in Taiwan to get accurate counts and records of total production. They reach 10% uncertainty on US total AI compute, mostly due to uncertainty over pre-existing compute and production outside of Taiwan (e.g., South Korea and the US). Uncertainty over new compute production is much lower (on the order of 1%).

2027: Verification R&D gets funding

The US executive branch starts expressing interest in deal optionality and verification measures that could enable this. After a series of RFIs they choose to focus efforts on a network-tap and recomputation centered approach for an inference-only retrofitting solution. The prospect of installing devices in each other’s datacenters raises initial alarm bells but it's a tractable security problem to work on. Ultimately due to the sheer simplicity of some of the possible network tap designs (essentially a piece of glass splitting optical signals), and parallel investment into various physical security agendas, it becomes a palpable possibility that these taps might actually be worth producing en-masse in case they were to be needed. Unilaterally trusted recomputation servers (that the network taps redirect traffic to and are responsible for actually performing the verification) are more complicated and thus harder to trust by default, but there are large investments made here. The R&D programs are purposely transparent and open sourced to build trust. China also sees the incentive to develop and build their own symmetrical solution in a similarly transparent way. In the latter half of the year, they agree to mutual information sharing about important verification-relevant information which is otherwise not sensitive, especially about each other’s networking and computing paradigms, which is necessary in order to build compatible network taps and recomputation servers. Several pilots from different sources of funding and different places around the world are carried out over the course of the year, improvements to the designs are iterated on, and preparations are made to increase production scales. Ultimately the US and China end up opting for network tap solutions with extremely simple optical splitting designs that have minimal room for any vulnerabilities, rather than some of the more ambitious designs that we propose in the box below, or different cryptographic based-approaches, which are more uncertain, but if they work (at sufficiently low cost) they might be even better and easier to trust.

On top of this key effort to build the network-tap and recomputation centered approach, there is also significant funding (order of $100M) mobilized into R&D for other approaches, including software-only and cryptography-centric (e.g., ZKPs) approaches, and a similar pool for physical security R&D (order of $100M) that supplements the inference-only retrofitting solution.

2028: Chip tracking is mature

The intelligence agencies have been keeping close track of new compute production, and have been partially successful in narrowing down their uncertainty over how much AI compute pre-dated their tracking efforts. By the end of the year, China has around 2% uncertainty over the US’ total compute, and the US has around 4% uncertainty over China’s. This means from China’s perspective, they are 80% confident that the US owns somewhere between 222M and 226M H100-equivalents. From the US’ perspective, they are 80% confident that China has somewhere between 25M and 27M H100-equivalents.

2029-2030: Deal Implementation

Jan 2029: Mutual Chip Declaration and Inspection

Within a week of starting Plan A negotiations, the US and China have carried out a compute declaration and supply chain record audit, allowing each other to send a few hundred people into each other’s countries to inspect and audit records. This lets them reduce their already relatively small uncertainties over each other’s compute. Each side’s best guess is now that the other could have hidden at most around 1.5M H100e from the declaration (with the 80% CI reaching about 4M), which is about 4% of the leading AI company’s R&D compute and about 0.5% of total world compute. For our estimates and reasoning on how much compute a covert project could probably hide see the covert projects supplement.

More detail on the suggested interventions by cluster size bucket below:

The chip declaration also involves keeping extremely close tabs on all new compute production, and any chips above certain performance metrics of AI-relevance need to either be directed to known locations to be included under the verification measures. While lower powered consumer compute production can likely remain unrestricted.

Feb 2029: Inference-only retrofit begins

After the US and China have carried out the compute declaration and inspection, and are relatively confident that they know about the vast majority of each other’s compute, they handshake on a brief AI R&D moratorium and announce it to the world. AI companies are supposed to stop doing R&D immediately for now, including pausing in-process training runs. While they roll out the inference-only verification solution to each other’s largest datacenters, they agree to a 100% power-off of small clusters (anything under 10K H100e, because it will take a while to get to retrofitting these) and a 80% power-off of all larger datacenters because only around 20% of the compute should be sufficient to keep all AI products and services running properly, simply at slightly reduced rates. This limits the extent to which anyone can defect and make differential gains while the deal is being set up and then just going back to racing from a better position than they were in before.

The US has about 95% of its compute in around 200,000 total AI server racks (with just over 1K H100e per server rack on average), and China has about 95% of its compute in 100,000 AI server racks (with about 250 H100e per server rack on average).

Luckily the US has a stock of around 10,000 network taps and 100 (unilaterally) trusted recomputation servers. China has a stock of around 20,000 taps and 200 servers, and they can each purchase another 10,000 per month from various third parties. As a result of China having less compute, the US can retrofit China’s compute faster, but they agree to a proportional retrofitting schedule determined by China’s achievable pace, which is retrofitting 40% of the US compute into inference units of 4 server racks (or 4K H100e) with their existing stock of network taps in 1 month. So they will both follow this pace, and then ramp up to 80% by the 3 month mark and then to >95% and/or smaller inference-units beyond that.

March 2029: R&D cluster construction begins

While the inference-only retrofit is being carried out, the US and China then agree on the high level regulatory plan and transparency regime they will be aiming for (some of the options are highlighted in our transparency supplement). Given the relatively small perceived risk from illegal projects and various other considerations, they decide to aim for the Total Research Transparency approach. This involves setting up R&D datacenters with SL5 model weights security and SL5 verification integrity. They want these to not be defendable so that it's difficult to try to pull out of the deal and start racing again using these new R&D clusters, so they aim for mutual deterrence by locating the US R&D clusters in Mongolia and the Chinese ones in Canada. The US has guards at their Mongolia cluster that have robust ‘scorched earth’ mechanisms to destroy the compute if China or someone else tries to seize it, and symmetrical measures are in place for the Chinese compute in Canada. They get started on these infrastructure projects immediately in March with high urgency, aiming to have a small amount of capacity online within 6 months so that a verified R&D pilot can start. The verification approach they plan to follow is similar to the inference verification approach, with network taps being used as evidence collection, and partial recomputation being used to verify correctness of the packets that make up the workload.

April - May 2029: Third party countries begin joining the deal

Starting in April and through the rest of 2029, most of the richest 20 countries in the world, and important semiconductor supply chain countries join the deal by doing a compute declaration and allowing the inference-only retrofitting to their datacenters, including: Germany, Japan, UK, India, France, Brazil, Canada, Mexico, Italy, Australia, South Korea, Spain, UAE, Saudi Arabia, Taiwan, Netherlands, Switzerland.

June - July 2029: Construction of new highly secure (SL5) inference-only clusters begins

As part of the transparency regime, the plan is to do broad public deployment of approved frontier models, but under SL5 model weights security achieved through SL5 output verification and distillation mitigations. The plan is to offer a mixture of Zero Data Retention (ZDR) inference for consumers, and transparent inference for higher-risk deployments. More on this in our transparency supplement. We think these clusters probably need to be built from scratch to reach SL5 model weights security and verification integrity.

August - September 2029: Inference-only ready on 95% of world compute

With several of the largest compute owners joining the deal over the summer, 95% of the compute in the world is now under inference-only verification, and it has now scaled to higher granularity (smaller inference units) and improved physical security (side channel reductions and high effort physical guarding and monitoring).

Late 2029: Pilot R&D verification begins coming online

In both Canada and Mongolia, mutually constructed datacenters come online at around 1GW in Canada and 2GW scale in Mongolia by September (around 2% of world compute) scaling to around 15% of global compute by the end of the year. Companies are allowed to start hosting compute in these clusters and bid over space as it comes online. Initially, only very small experiments get approved and there is red teaming and iteration on the verification and security measures to test and improve their efficacy.

Early 2030: Full R&D verification underway

There are now around 100M H100-equivalents in the verified R&D clusters in either Canada or Mongolia (which is about 20% of world compute at the time and equal to 35% of the compute that existed at the start of the deal). These clusters have the transparency measures in place and now companies are approved to do the first major post-deal training runs using combined algorithms. In a few months these training runs complete and several of the models are around the automated coder milestone (AC). The models get broadly tested and red-teamed, including by many third party groups and auditors that rent small amounts of compute in the R&D clusters for this purpose.

There is now a big regulatory question of how to control the speed of R&D progress to balance the risks (of going too quickly) and benefits (of improving capabilities). This will arguably be the hardest part of the deal to execute on competently. There is a complex set of dependencies, where going too fast incurs AI takeover risk and/or causes progress to diffuse to potential covert projects (reducing the slack the legal project has), while going too slow incurs risk of making less progress on alignment before the deal possibly breaks down, or indeed actually losing to an illegal project operating outside of the deal.

The high level capability schedule we recommend is to scale to the maximum capability you can reliably make control-based safety-cases for, ideally mostly with hardware scaling, and then pause until your marginal progress on alignment-based safety-cases (handoff risk) is lower than the risk being incurred by the deal.

But even with a desired high level capability schedule in mind it may be hard to actually enforce this level of capabilities progress, especially to the extent that capabilities progress is unpredictable from inputs (e.g., compute), hard to measure, or fast paced by default. Our best guess is that harsh compute caps, and then a mixture of quality ad-hoc rules will be sufficient, as explained in more detail in the below box.

With a particular set of rules on research in place, there is a separate problem of enforcing these rules are actually followed. We can divide the problem of enforcing the R&D rules into two parts:

1. Workload Approval. Workloads that companies declare actually meet the regulatory rules, whatever their implementation may be.

2. Workload Verification. Workloads that the companies declare match what they actually run.

Our view is that workload verification is solvable in a similar way to what we discussed previously (evidence collection via network taps, and then partial recomputation of randomly selected reproducible packets), whereas workload approval will be closely tied to the form of AI R&D rules that are in place (e.g., are they just experiment compute caps? Are there specific banned techniques? Are there specific required techniques?) and our overall baseline proposal for approval is for this to just be manually carried out by teams of auditors in the R&D clusters.

1. Declaration: AI companies declare the workload they want to run with full transparency on the code, algorithms, etc.

2. Approval: Auditors run checks per the Workload Approval implementation and if it passes they send back approval and provide necessary random seeds (removes a potential attack vector from AI companies gaming fake randomness).

3. Evidence collection: Auditors collect evidence from the workload (e.g., complete logging flow through network taps). In the diagram the evidence collection is depicted as low granularity, but in reality it could be happening at the level of individual servers, or GPUs or at even lower levels later on.

4. Verification: Auditors sample randomly and do partial recomputation and other checks to catch violations of workload correctness.

5. Evaluations and release: For workloads that consist of final training runs there can be an extra step that involves running evaluations that also get verified for correctness, and then final model approval for release leads to the model weights being downloaded from the opaque internal database and transported to the inference-only clusters. This process is extremely high stakes from a model weights theft perspective, so would need to be carefully designed and executed.

Late 2030: Secure inference-only clusters for post-deal model deployment come online

First SL5 inference-only clusters are online and start serving the first post-deal models that have been approved from the R&D clusters for broad public deployment. These clusters have the same basic verification approach as the retrofitted ones (network taps and partial recomputation) but with improved security properties. By the end of the year, around 40% of world compute (~370M of the global ~930M H100e) is in these new post-deal SL5 inference-only clusters.

Also by the end of 2030, the US and China have set up hardened cold storage facilities where they allow inspectors to verify each other’s stash of AI chips, sized to be bigger than any plausible covert projects (a 5M H100e US bank and a 500K H100e China bank, per our deal decline supplement), and of relative size to each other similar to pre-deal status quo. These are in places that either side can easily defend. These locations will also be home to verified model weights stashes, so that models that the US and China agree would be positive sum to approve for use in the case of deal dissolution (e.g., models that would be very helpful for safety research and have strong safety cases). Around 2033 there is a model around the automated coder capability milestone that gets approved for the weights stash, and then in 2037 there is a near-frontier (top expert AI) model approved for the cold weights storage.

2031-2036+ Improving the deal

2031: Restrictions for hardware R&D and other high-risk domains

The core problem the US-China deal sets out to address is the intelligence explosion. But the intelligence explosion isn’t the only threat to deal with. Another core concern is that AI could enable an industrial explosion, too much AI hardware progress, or other dangerous scientific progress.

The case for being worried about AI software progress was illustrated in AI 2027: superhuman AI researchers could bootstrap to a superintelligence that we might not be able to control and whose goals we haven’t figured out how to align. The case for being worried about too much hardware progress is superseded by this under a fast takeoff, but under the Plan A deal if we only slow down software progress a hardware driven takeover might actually be the majority of the takeover risk absent separate mitigations.

Three major reasons to be worried about unconstrained hardware progress:

Similarly we want other high risk scientific domains such as biology research to have R&D restricted. Our default proposal for this is to rely on inference refusals and monitoring on the majority of public deployment, and then potentially set up dedicated locations that allow high-stakes hardware and other scientific research to be carried out in mutually verified research labs, where we make some (not necessarily identical) security-transparency tradeoff choices, and mutually verify that the companies follow the titration rules on hardware R&D, which can also be some combination of safety cases, ad-hoc rules, human interpretability requirements and resource caps (similar to software research).

2032: Cap & Trade for Robots and Compute

As mentioned earlier, we want to stop an explosion in the number of robots and AI chips on earth from threatening the stability of the deal. By default, our current naive modelling predicts that even with current hardware designs, the AI and robot capabilities that we forecast to be reached during the Plan A scenario would lead to a huge discrepancy between the raw cost of producing more AI chips and Robots and their economic value. By default, we think this leads to a reinvestment spiral and very fast doubling times.

In Plan A we propose a cap starting in 2032 that limits the number of robots and AI chips on earth to doubling times around 6 months, through cap & trade regulation, where private companies need to bid on the finite robot and AI chip production permits in any given time period. This cap should be set in units of usefulness of the robots for industrial production and AI compute in AI workloads, measuring both of these, especially across tasks and form factors in the case of robots, might be difficult and muddied (e.g., fuzzy lines between robots and more traditional machines). We nonetheless think it should be feasible to measure these things reasonably well for different robot and hardware designs, and allocate the cap & trade limits accordingly.

Actually enforcing the cap & trade permit rules might be very difficult if robot and/or AI compute production happens all over the world, so we propose centralizing new built up industrial capacity and robots in special economic zones (SEZs) to make for easier enforcement of the cap & trade rules.

The same cap and trade principle is extended to other products and services that are destabilizing in unrestricted quantities, but can be safe in lower quantities. Two major examples are products with edge compute and unmonitored inference. Things that might particularly rely on edge compute include self-driving cars and consumer compute, while unmonitored inference might be particularly valuable to governments for military operations. Under cap and trade the regime can accommodate these activities being legal, under safe societal-scale caps that maintain the stability of the deal. Then there can be markets for the permits the people, firms and the government can bid between each other to have the rights for.

Putting together research titration and production capping, we have the following overview:

2033: Security improvements

By 2033 we expect significant hardware security, and more general security properties of the datacenters, verification regime and capabilities to have improved significantly. By the end of 2033, around 99.9% of the worlds’ compute is post-deal compute, meaning that it's trivial to just power down all pre-deal clusters and compute, and have the vast majority of compute be in new more secure locations built from scratch. Furthermore, by the end of 2034, around 90% of the compute that exists will have been produced during 2033 or 2034. This means that security improvements made by then can already be widely in place within just 1-2 years. Similar dynamics apply to the fabrication facilities.

Our uncertainty on what will be possible is high here, but some of the main ideas we have include:

• Datacenters built from scratch with extremely good side channel and airgapping properties.

• Huge progress in standardizing (for reproducibility) and improving security of software stacks for inference and R&D workloads more generally.

• New compute production facilities (fabs) built from scratch with mutual monitoring measures and being colocated with supply chain and potentially even with final centralized datacenters they will fill to minimize attack surface.

• The beginning of some hardware-software co-dependencies especially with architecture changes or number formats, so that optimization and progress in these paradigms is less applicable on pre-deal compute

• Increases to the logging / evidence collection granularity of the verification regime, especially of the R&D datacenters, with logging technology being compatible with extremely high bandwidth data paths on backend networking to reduce overhead.

• Generally improved hardware security properties with more robust trusted execution, secure boot, encryption, reproducibility, etc., which are especially important for recomputation servers. Some degree of standardization in hardware may also be helpful for reproducibility.

• Special hardware designs for automatic on-device verification of certain workloads, in particular, hardcoded weights on some chips to verify they're inference-only. This might be particularly useful for ‘edge verification’ allowing for more AI compute in consumer products without risk of use in covert projects.

2034: Verification improvements

Through the 2030s the total amount of AI compute in the world grows explosively. One important dynamic to note is that the verification burden (the need to have higher coverage) grows as the total compute under verification grows. In Plan A, we both forecast and recommend a significant hardware buildup (capped by the cap & trade regime to stay verifiable) for other reasons related to tradeoffs with deal stability (hardware is less likely to leak to illegal projects so differentially increases the legal projects affordances).

The verification assurance curve needs to improve such that any potential nonnegligible rogue internal deployment would have a high chance of detection. By 2034, with one packet collected per hour from each frontier GPU (~100 H100e each, so ~100 H100e-hour packets) and a 1% recomputation budget, the appendix math shows the verifier catches any rogue internal deployment at 99% confidence after it accumulates ~46,000 H100e-hours of unapproved work, so a sustained 10K H100e deployment is detected within ~4.6 hours, a 1K within ~46 hours, and so on.

This is an ambitious verification scale, and it also relies on extremely good integrity security on the verification regime. We think it will be possible to scale it this far, especially with AI assistance, but are not confident, and find it plausible that the compute cap should be set lower in order to not increase the verification burden this much.

2035: Moving the datacenters to the ocean

One of the biggest ongoing risks is that the deal breaks down and actors return to racing. Because of the vast increase in compute scale that has not been turned into capabilities progress (due to the safety regulations) the return to racing could be even more dangerous than the initial status quo, despite the alignment progress made up until this point, because things would now go faster. This motivates having measures in place to return to pre-deal compute levels, or even smaller compute scales if the deal breaks down.

We think the relative engineering and logistical costs involved in building new datacenter capacity on the ocean in international waters will be low enough due to robot and AI labor to make this worth it around 2035, because it would become much harder for any particular actor to defend and much less escalatory to destroy in the event of the deal breaking down. This is an intentional measure for mutually assured compute destruction to increase the deal’s stability.

2036+ Advanced robustness improvements

Later into Plan A we are increasingly uncertain about what robustness improvements will be possible in terms of security, verification and deal stability. Potentially extremely ambitious things will be possible, a brainstorm here included:

• Completely rewritten software stacks to be significantly or entirely formally verified.

• Huge red teaming efforts on the verification scheme or security measures using resources that dominate any potential covert actors.

• Using AI and robot labor to track down potential covert projects in mutually agreed, symmetrical ways, e.g., the ‘AI silver bullets’ explored in our covert project supplement: reliable lie detectors, privacy-preserving AI verification, and extreme industrial verification.

Appendix: Packet-Based Verification

This appendix works through the math on random sampling for use in partial recomputation to show why it scales so favourably for detecting incorrect workloads. A key simplifying assumption we make in this analysis is that the workload packets are perfectly reproducible.

A.1 Setup

In this analysis we treat verification as a sampling problem on a stream of packets. A packet is a reproducible unit of computation that the verifier can recompute: its inputs, instructions, and outputs are all collected at the evidence-collection point (e.g., a network tap). What the computation actually is (one forward pass, one training batch) doesn’t affect the math below. Further simplifying assumptions we make are:

1. Uniform size. Every packet represents the same amount of underlying compute. Non-uniform packets work too, with a weighted-sampling argument that doesn't change the qualitative results.

2. Independent random sampling. The verifier audits each packet independently with the same probability. In reality you would sample without replacement.

Let the verifier's pool be some collection of packets; it could be a single training run, every packet from every workload running under the deal in a given month, or one cluster's traffic. Let $N_{\text{packets}}$ be the total number of packets in that pool, $s = 1 / N_{\text{packets}}$ the packet size (the fraction of the pool each packet represents), $C$ the recomputation budget (the fraction of the pool the verifier can afford to recompute), and $N_{\text{verified}} = C \cdot N_{\text{packets}} = C / s$ the number of packets actually audited.

A.2 Detection by Random Sampling

The detection math in this section was independently derived but matches the analysis in Rinberg et al. (2025). Suppose an attacker substitutes $N_{\text{fake}}$ packets, replacing the declared computation in each with their own unauthorized one. Let

be the fraction of packets that are fake. If the verifier audits each packet independently with probability $C$, the exact probability that none of the $N_{\text{fake}}$ fakes is audited is

For small $C$ and modestly large $N_{\text{fake}}$, this is well approximated by a Poisson distribution on the number of caught fakes, with mean $\lambda = N_{\text{verified}} \cdot F_{\text{fake}} = C \cdot N_{\text{fake}}$:

so the probability of catching the attack (the detection confidence at attack size $F_{\text{fake}}$) is

We'll use the Poisson form throughout, since it's the cleanest expression of the scaling. It breaks down only when $C$ approaches 1 or $N_{\text{fake}}$ is single-digit, which is also when random sampling stops buying you anything (see the discussion at the end of §A.3).

A.3 The Assurance Curve

The assurance curve is determined by coverage and confidence which can be expressed in terms of $F^{*}_{\text{fake}}$, the largest fraction of fake packets we're willing to tolerate without detection:

• Coverage $\;=\; 1 - F^{*}_{\text{fake}}$, the fraction of the workload we're claiming is legitimate.

• Confidence $\;=\; 1 - e^{-N_{\text{verified}} \cdot F^{*}_{\text{fake}}}$, the probability we'd catch any actual violation at or above that threshold.

The confidence formula comes from §A.2: $P(\text{detected}) = 1 - e^{-N_{\text{verified}} \cdot F_{\text{fake}}}$, evaluated at the threshold $F^{*}_{\text{fake}}$. The recomputation budget shows up through $N_{\text{verified}} = C \cdot N_{\text{packets}}$, so more audited packets push the curve outward.

Plotting confidence against coverage for several verification budgets (i.e., different values of $N_{\text{verified}}$):