The Verifiable Compute Commons

Founding Architecture & Governance Charter (v0.1, working draft)

Mission. A platform that makes a coordinated AI slowdown credible, verifiable to participants, legible to the world, and cheap to switch on.

Working name. "Verifiable Compute Commons" (VCC) is a placeholder. Alternatives to decide later: Cadence, Open Compute Verification Foundation (OCVF), Concord. The name matters for neutrality (see §6), avoid anything that reads as US-, China-, or single-lab-aligned.

1. The one-paragraph thesis

Rival frontier developers do not race because they want to. They race because each fears the other will not stop. That is a defect-dominant equilibrium, and the only thing that flips it is verifiable common knowledge: everyone knowing that everyone knows that everyone is in compliance. The VCC's product is therefore not a brake and not a lock, it is a common-knowledge machine. Everything downstream is engineering in service of that one epistemic good, produced at the minimum possible disclosure of anyone's secrets.

2. What this is, and is not

This discipline is the difference between a real institution and vaporware.

The VCC is a verification and transparency layer. It converts unverifiable promises ("we paused") into checkable, privacy-preserving, world-legible claims, and it lets a coordinated slowdown be switched on as a parameter change rather than negotiated from a cold start.

The VCC is not an enforcement mechanism. It cannot make a sovereign stop. Enforcement lives above the platform (export controls, sanctions, treaty, domestic regulation); raw compute lives below it (the chips and datacenters). The platform sits in the middle and does exactly one thing well: it makes both compliance and defection legible. A defector is not blocked by the VCC; a defector is seen.

Internalize the layer you operate at. Most failed "pause button" projects fail because they quietly assume they can enforce. We assume we can only illuminate, and we design to make illumination so cheap, so private-preserving, and so credible that illumination becomes politically decisive.

3. Design principles (non-negotiable)

Open source is the trust substrate, not an ideology. A competitor or a foreign government will never trust a black-box verifier built by a rival. They will trust code and math they can read. All verification logic is open and auditable. (This is the same reasoning the flexHEG designers give for their open-source stance, auditability is what rules out backdoors.)
Privacy-preserving by construction. The reason labs won't open their books is IP and national security. Verification must reveal that a claim holds without revealing what the party is actually doing, via trusted execution environments (TEEs), zero-knowledge proofs where tractable, and compute-accounting that proves bounds rather than contents.
Neutrality is existential. If any one lab or state controls the platform, adoption dies. Governance, hosting, and the authority to change rules must be multi-stakeholder and capture-resistant from commit #1 (see §6).
Peacetime-first / dormant gear. The slowdown capability must be a latent feature of a system already adopted for everyday, independently valuable reasons. A pause button invented during the crisis arrives too late (see §5).
Ratchet, never weaken. The platform's update rules permit increasing transparency and tightening verification, but weakening either requires a supermajority of mutually-distrusting parties. No single actor can quietly soften the regime.

4. Platform architecture

A layered stack. Each layer is independently useful, which is what makes incremental adoption possible.

4.1 Policy layer

Machine-readable commitments. What is being agreed to: training-compute thresholds (FLOP ceilings), architecture or dataset restrictions, deployment conditions. Critically, it also encodes the three things a credible pause must specify and that almost everyone omits: what triggers it, what lifts it, and who adjudicates. A commitment that cannot answer those three is theater.

4.2 Attestation layer

How each participant emits evidence about its own compute. Pluggable backends, in order of what's deployable today vs. later:

Today: TEE-based attestation on existing accelerators (e.g., confidential-computing modes on current datacenter GPUs) and TPM-anchored training attestation (the approach the open-source AICert prototype demonstrated for fine-tuning).
Near term: Proof-of-Training-Transcript (periodic signed weight-snapshot logs + compute accounting).
Later: hardware-enabled guarantees (flexHEG-class: a guarantee processor in a tamper-evident enclosure with an interlock on the accelerator data path). The VCC consumes these signals; it does not need to build the silicon.

4.3 Verification layer

Checks attestations against policy. The hard problem here is the negative claim, proving "I did not run anything above N FLOPs," not "here is the run I did." Negative claims require compute accounting with double-counting prevention and, ideally, coverage guarantees over a party's entire equipped fleet. This layer is also where the published attacks on Proof-of-Learning matter: any scheme we adopt must survive an open adversarial test suite (see §7.2). Verification logic ships open; verification inputs stay private.

4.4 Adjudication layer

Anomaly detection, discrepancy handling, escalation. When two parties' attestations are inconsistent, or when a party's declared fleet doesn't reconcile with independent signals (chip-registry, power/datacenter footprint), this layer flags it and routes it to the neutral adjudication body defined in governance.

4.5 Transparency layer

Lets non-signatories, the public, other states, civil society, see that participants are in compliance, without seeing secrets. This is the layer that makes the whole thing politically real: it turns private mutual verification into a public good. A slowdown nobody can confirm has no deterrent or reassurance value.

4.6 The reciprocal reveal escrow (new mechanism)

The deepest adoption blocker is "nobody wants to open their books first." Symmetric disclosure solves it. Each participant continuously deposits encrypted compliance evidence into a neutral escrow that no one, including the foundation, can read in peacetime. The evidence becomes simultaneously decryptable to all participants only when a slowdown trigger fires (a threshold-cryptography / time-locked "break-glass" condition agreed in the policy layer). Properties:

In calm weather, the escrow leaks nothing; each party only emits a privacy-preserving "compliance heartbeat" (a proof that bounds are respected).
When the agreed trigger fires, everyone's detailed compliance state becomes checkable at the same instant. No party reveals first; no party can condition its reveal on having peeked at another's.
Defection becomes a dead-man's-switch problem: to cheat, you'd have to have been depositing falsified evidence continuously, against an open verifier, while independent signals (§4.4) cross-check you.

This converts "trust me, I stopped" into "we all simultaneously prove we stopped, or the failure to do so is instantly and symmetrically visible." It is the cryptographic answer to the oldest problem in arms control: who disarms first.

5. The peacetime adoption strategy (why the gear must be dormant)

A verification regime that only matters during a pause has no users until the worst possible moment to recruit them. Historical regimes (the INF Treaty is the standard example) took decades to build infrastructure and trust, and the timeline pressure here is the opposite of decades.

So we do not sell "the slowdown platform." We ship a substrate that frontier labs, cloud providers, and regulators want for their own peacetime reasons, with the slowdown capability latent inside it:

Model & training provenance, "prove this model was trained as claimed" (provenance, copyright, supply-chain integrity).
Export-control & regulatory compliance, privacy-preserving attestation that a deployment respects jurisdictional rules; useful to chipmakers, clouds, and governments now.
IP-preserving audit trails, a lab proves properties to an auditor or insurer without exposing weights or data.

Each of these is independently fundable and adoptable. The slowdown is then a configuration of rails everyone is already running on, a flag flip, not a treaty from scratch. This is the single most important strategic bet in the whole project: win adoption in peacetime; make the pause a latent capability of an already-trusted system.

6. Governance & the foundation

6.1 Legal form

A neutral, non-profit foundation, model on CERN, the IETF, the Linux Foundation, or a standards body, not a startup and not a single-lab project. Jurisdiction is a strategic decision; a neutral or multi-jurisdictional seat (e.g., Switzerland-style neutrality) aids credibility with rival states.

6.2 Multi-stakeholder board, adversarial by design

Seats deliberately span mutually-distrusting constituencies: multiple frontier labs, multiple governments (ideally across geopolitical blocs), academic cryptographers and security researchers, and civil-society / public-interest representatives. The point is not harmony; it is that no single faction can capture the rule-set.

6.3 Rule-update authority (the ratchet, enforced)

Borrow the flexHEG pattern: the system only accepts policy/verification updates approved by a defined quorum of stakeholders. Increasing transparency or tightening verification is easier to pass; weakening either requires a supermajority. This prevents both a capturing state and the foundation itself from quietly defanging the platform.

6.4 Funding model

Diversify deliberately to protect neutrality: philanthropic capital is available now and aimed squarely at this space (e.g., Longview's hardware-enabled-mechanisms RFP, sized in the millions, explicitly wants red-teaming and field-building), plus government/standards grants and eventually membership dues from participating organizations. Avoid majority dependence on any single lab or state, funding concentration is capture by another name.

6.5 Licensing as a governance decision

The license is not boilerplate. Verification logic should be permissively licensed for maximum auditability and adoption. The adversarial / attack-tooling components (see §7.2) need a different regime, controlled or staged release with coordinated disclosure, because an open cookbook for spoofing verification is precisely what a defector wants. Decide these separately and deliberately.

7. Threat model

7.1 Off-the-books compute (the coverage hole)

Hardware-enabled and attestation-based approaches govern only the equipped frontier. Motivated actors can find unequipped compute, and falling FLOP thresholds (from algorithmic efficiency gains) erode coverage over time. Mitigation: pair on-platform attestation with independent signals (chip supply-chain registry, datacenter power/footprint analytics) so that un-attested large-scale compute is itself anomalous and visible. We make the absence of a heartbeat suspicious.

7.2 Spoofing & the brokenness of existing schemes

Proof-of-Learning, as published, is more broken than commonly assumed, adversaries can forge cheaper transcripts that pass. Strategic consequence: before we endorse any verification primitive, it must survive an open, reproducible adversarial test suite, a "Pwn2Own / MITRE ATT&CK of compute verification." This red-team harness is also a credibility flywheel: in security, only what survives public attack is trusted. We build the adversary alongside the verifier, under coordinated disclosure (§6.5).

7.3 Neutrality capture

A single state or lab gaining effective control over hosting, funding, or rule-updates. Mitigations: §6.2–6.4 (adversarial board, ratchet, diversified funding, multi-jurisdictional seat).

7.4 The legitimacy trap

If a "coordinated slowdown" merely lets the least cautious actor catch up, it makes everyone less safe rather than more. The platform must therefore be valuable even if a slowdown never triggers (hence §5), and it must never be framed as unilateral disarmament. Its job is to create the option for a credible, mutual, verifiable pause, not to advocate that any single party stop alone.

v0.1 working draft. This is a living document; the architecture is intended to be revised against the published threat model and adversarial test results, never weakened without quorum.