UNGA Pivot: From Model Rules to Compute Transparency

The week compute got a seat at the table

This week in New York, during the United Nations General Assembly, a quiet but consequential pivot took shape. Instead of arguing about what models should or should not do, delegations and labs converged on something more measurable: where, how, and on what chips powerful models get trained. The phrase compute transparency moved from panel talk to action items. Chip-level attestation. Receipts for big training runs. Public registries you can query.

It sounds technical because it is. Yet the idea is simple enough to explain at a dinner table. When a vaccine is made, regulators do not just test the final vial. They also watch the production line. For generative models, the production line is a cluster of accelerators and the orchestration software that runs them. If that line can vouch for itself, the world gains a new lever for safety, security, and fair competition that does not rely on guessing what a model might do.

Compute is the measurable part of modern artificial intelligence. You can put a clock on it, compare it across borders, and regulate it without inspecting every line of code. That is why the conversation is shifting from model rules to compute tracing.

What proof-of-training actually means

Proof-of-training is a package of three ideas that fit together like a chain of custody for a model’s birth.

Attested hardware. Each accelerator, from data center GPUs to specialized AI chips, has a cryptographic identity baked into the silicon. When the chip boots into a measured, known-good state, it can prove what firmware it is running and who manufactured it. Think of it as a passport and a customs stamp bundled together.
Run receipts. During a training job, the chips and the cluster scheduler produce a signed log that says which resources were used, for how long, with what software environment, and within what boundaries. This log is not a movie of your data. It is more like a shipping manifest with fuel, route, and container counts.
Public registries. Receipts for large runs get published to an append-only transparency log. Watchers can monitor these logs the way browsers monitor certificate transparency logs for the web. If a big model appears without a corresponding receipt, that becomes a story in itself.

Put together, proof-of-training is less like a warranty card and more like a flight recorder. It does not tell you everything about the model. It does give independent auditors enough structure to reconstruct the training flight and decide if the risk matches the scale.

Why the pivot makes sense now

Rules about model behavior are brittle. Models change with a fine-tune. Guardrails can be bypassed. Evaluations are important, but they are snapshots. Compute, on the other hand, leaves a trail. Chips consume power. Schedulers allocate jobs. Bills get paid. This trail can be hardened with cryptography so it is costly to forge and easy to check.

There is also a policy backdrop. The United States already requires reporting certain high-compute training runs. Europe is building standardization paths under its new rules. The United Kingdom’s safety agenda has emphasized testing at scale. The private sector is converging on confidential computing. And chip makers have been adding the ingredients you need for attestation for years.

The new part is agreement to connect those ingredients into a product that the whole ecosystem can use.

What the hardware has to add

Modern accelerators are close, but not quite there. Here is the short list the chips need to make attested training practical at scale:

Device identity and certificates. Each chip needs a unique keypair burned at the factory and a manufacturer-signed certificate chain that can be verified without phone-home dependence. Nvidia’s data center GPUs, for example, already ship with secure boot and device-level identity. AMD and Intel have similar roots of trust on CPUs. The gap is consistent, documented interfaces for accelerators so the cloud can verify whole clusters.
Remote attestation with session keys. Before a training job starts, the chip should establish an encrypted session with the host and prove its firmware hash and security mode. The session should bind to the specific job. The result is a per-run key that signs telemetry. This is common in CPU trusted execution environments like Intel TDX and AMD SEV-SNP. It needs to be first-class on accelerators.
Measured performance counters. Chips must expose a minimal, non-spoofable set of counters that let you estimate floating point operations within a known error band. You do not need perfect FLOP counts. You do need consistent, vendor-calibrated counters for tensor operations, memory throughput, and power draw sampled at predictable intervals.
Lockable runtime modes. When a chip is in attested mode, certain developer features must be off. No arbitrary firmware loading. No debug hooks that can fake counters. Clocking and power modes should be pinned so that one run receipt is comparable to another.
Secure upgrade paths. Firmware updates must keep the chain of trust intact so that fixes for side channels or bugs do not break compatibility with proof-of-training software.

None of this requires exotic research. It is product work. The chip roadmaps already include variants of these features. The point is to harden them for training jobs and to expose them in a common way across vendors.

What the clouds need to wire up

Chips cannot vouch for a run alone. The cloud or cluster orchestrator is the conductor. Here is what hyperscalers and private clusters need to add:

Attestation stitched end-to-end. A user request enters the scheduler, which selects nodes where the host CPUs are in trusted execution environments and the accelerators attest into secure mode. The scheduler binds a global job ID to a set of per-node session keys and records the cluster layout. All of this gets signed by the cloud’s key infrastructure.
Immutable job envelopes. The code package, container image, and key hyperparameters get hashed and sealed into a job envelope. The scheduler records the envelope hash in the run receipt. If the user changes the code mid-run, the receipt shows the change and who authorized it.
Cross-checking power and time. The cloud should log not just chip counters but also independent power measurements from rack power distribution units and time records from the orchestration layer. Cross-checking makes spoofing harder and produces better carbon accounting.
Log pipelines with clear privacy redaction. Run receipts must avoid leaking training data or proprietary weights. The cloud should define a narrow schema that captures resource use, environment fingerprints, and coarse dataset provenance without copying any payloads.
One-click publishing to registries. For runs that cross a threshold set by policy or internal rules, the cloud should let the customer publish a signed receipt to a public registry with a single toggle, much like enabling public container images today.

A cloud that does this will not only satisfy policy pressure. It will also sell more training jobs to customers who need to prove compliance to their boards, insurers, and partners.

What MLOps and training stacks must change

The training loop itself needs to speak the language of receipts. This layer is where the practical friction is lowest and the productivity upside is highest.

Framework fingerprints. PyTorch, JAX, and TensorFlow can expose a stable fingerprint of the operator set used in a run. The receipt should record these fingerprints so auditors can tell if the run uses custom kernels or known libraries.
Checkpoint commitments. Each checkpoint file gets a hash that is appended to the log as the run progresses. The chain of checkpoint hashes forms a measurable timeline and makes it harder to swap in weights from another run without leaving a trail.
Dataset lineage without leakage. You do not publish your dataset. You do publish dataset fingerprints. For example, a salted, per-run hash of file lists, counts by source, and sampling strategies. Over time, shared fingerprints will make it easier to spot recycled datasets or mislabeled provenance.
TBOMs. A training bill of materials is the natural sibling of a software bill of materials. It lists major components that went into the run: chip type and count, host type, framework versions, kernel versions, compiler flags, and major dependencies. Tools like MLflow or Weights and Biases can generate a TBOM automatically.
Evaluations tied to receipts. If you run red-team tests or safety evaluations during training, bind the results to the same run ID and publish the hashes. The registry will then show not just how big a model is, but also which tests accompanied it.

The community will build this into the usual developer ergonomics. You should not have to write scripts. Start a training job, and the stack emits a clean TBOM and a clean receipt by default.

The registry: what gets published and why it matters

A public registry is not a data dump. It is a transparency log with a narrow schema and strong signatures. Here is what a realistic first version might include for runs that cross a policy threshold:

Publisher identity. Who is attesting to this receipt. A lab, a cloud, or the two together.
Run ID and time range. A globally unique job identifier, start time, end time.
Resource summary. Total accelerator type and count, host types, aggregate chip-hours, mean power draw, and a vendor-calibrated compute estimate with an error band.
Environment fingerprints. Hashes of container images, framework fingerprints, kernel and driver versions.
Checkpoint chain. Hashes of major checkpoints and final weights. Not the weights themselves.
Dataset lineage summary. High-level fingerprints and redacted provenance statements. For example, synthetic, licensed, web-sourced with filtering, or enterprise-provided.
Evaluation attachments. Hashes of red-team or capability tests and the dates they ran.
Signatures. Manufacturer-issued device attestations, cloud or cluster attestations, and the publisher’s signature all cross-signed.

The log should be append-only and available for mirroring so that civil society, researchers, and companies can run their own monitors. Think browser-style certificate transparency, not a social feed.

This matters because it drives three market effects. First, it reduces information asymmetry. Investors, insurers, and partners can price risk better. Second, it levels the playing field for smaller labs that do things right but have trouble proving it. Third, it makes evasion harder. If a state actor or rogue lab trains a model at scale without receipts, the absence itself is detectable, especially if cloud regions and chip shipments are tracked.

A 12-month path from pledge to product

You do not need to wait for new laws to ship this. Here is a realistic sequence that could make proof-of-training common by the next General Assembly week.

Quarter 4

Chip makers publish attestation interface guides for current data center accelerators, including code samples for session key establishment and counter sampling.
Two major clouds and one large on-prem provider release preview support for attested training clusters. Limited regions, specific instance types, clear performance overhead numbers.
An open spec for run receipts and TBOMs lands in a vendor-neutral forum. Engineers from several labs align on field names and signature formats.

Quarter 1

Popular MLOps tools add native TBOM generation and receipt export. Frameworks add stable operator fingerprints.
A pilot public registry launches with mirrored nodes at a university, a safety institute, and a cloud. Early entries include voluntary receipts from several labs and open source projects training medium-scale models.
Insurance carriers announce discounts or preferred terms for customers who publish receipts and follow attested training practices.

Quarter 2

More regions, more instance types. Attested mode becomes a standard toggle in job schedulers like Kubernetes, Slurm, and Ray.
Dataset providers publish fingerprint packs so that customers can include clear lineage references without revealing content.
National labs and research funders start to require receipts for grant-funded training runs above a certain cost or scale.

Quarter 3

The registry gains a watchdog ecosystem. Think simple bot accounts that alert on outlier runs or missing receipts relative to import and export data for chips.
First audits close that rely on receipts instead of ad hoc evidence, cutting weeks off enterprise compliance cycles.

By next fall, the norm could be simple: if you are training above a known scale, a receipt exists. If you do not have one, you are either very small or you are hiding something. Both are informative.

Startup opportunities hiding in plain sight

There is a full stack to build here. Several products could be companies.

Attestation gateways. A vendor-agnostic control plane that speaks to Nvidia, AMD, and future accelerators, stitches in CPU trusted execution, and hands a clean receipt to your MLOps tools. The product differentiator is reliability across odd clusters and fast incident response when firmware changes.
Registry as a service. A hosted transparency log with mirroring, key management, and redaction workflows tuned for legal and policy needs. Think certificate transparency meets SOC 2 and export control.
TBOM compilers. Developer-first tools that instrument training code, infer environment details, and produce receipts without cognitive load. A linter for missing fields. A dashboard that compares runs and flags anomalies.
Dataset fingerprinting. Services that generate compact, privacy-preserving fingerprints for large corpora. Vendors could offer enterprise data watermarking so customers can prove their own content was or was not used.
Energy and carbon verifiers. Hardware and software that sample rack power, reconcile it with chip counters, and produce trusted carbon reports tied to a run ID. This will matter for sustainability disclosures and procurement.
ZK-lite attestations. Practical cryptographic proofs that certain properties hold without revealing secrets. For example, proving you stayed below a compute cap or that you used only approved operator sets. This does not need heavy zero-knowledge machinery to be useful. Start with selective disclosure backed by signatures.
Compliance copilots for labs. Workflow tools that translate receipts and TBOMs into the documents regulators and insurers want. Prebuilt policies, auto-filled forms, and alerts before you cross a threshold.

Each of these is a wedge product that can expand as standards settle and the market widens.

Trade-offs you should face now

Compute tracing is not a magic shield. It introduces new responsibilities and some real risks.

Privacy and intellectual property. Receipts must be useful without exposing datasets or model weights. This requires disciplined redaction, clear schemas, and sometimes third-party escrow for sensitive details. Get lawyers and security engineers in the same room early.
Measurement gaming. If receipts become a badge of virtue, incentives to cheat appear. Counter this with cross checks between chip counters, power draw, and scheduler timelines. Use random spot checks and firmware attestation that can be verified by registries.
Open source friction. Independent researchers will worry about overhead and disclosure. Keep thresholds high enough to avoid burdening small runs. Offer grants and credits for attested training so the open community benefits.
Geopolitics. Transparency intersects with export controls and national strategies. The registry design should be global and neutral. Do not bake policy judgments into the schema. Publish facts and let jurisdictions act on them.
Cost. Confidential modes and logging add overhead. Early numbers from CPU trusted execution suggest single digit performance hits are achievable. Treat overhead as a feature to optimize away with smarter batching and hardware support.

None of these are fatal. They are normal engineering and governance work. Clear standards and visible wins will shrink the fear.

What to do Monday morning

If you run a lab

Ask your cloud and hardware vendors for a roadmap on attested training. Put it into your vendor scorecards.
Add TBOM generation to every large run. Verify that your MLOps tools can export a machine-readable receipt, even if you are not publishing it yet.
Pilot dataset fingerprinting. Establish a policy for what you will disclose and how you will redact.

If you build infrastructure

Ship a developer preview of attested training on a single cluster type with a stable schema and a one-click export to a public test registry.
Document performance overhead. Make it boring. Developers will accept a small hit for a big reduction in compliance friction.

If you are a policymaker or funder

Tie grants and procurement to receipts above a scale threshold. Offer credits for small labs to offset any overhead.
Seed a neutral registry and a mirror network with clear governance. Require open schemas and independent audit.

If you are an investor

Map the stack. Pick a wedge where standards are emerging and where you can sell to both builders and auditors.
Expect regulation to push faster than usual. The customers will be ready because the engineering is straightforward.

The new default

The second era of artificial intelligence governance will look less like policy memos and more like receipts. Not because receipts are glamorous, but because they are operational. They can be built, verified, and automated.

When a model arrives on the scene next year, the first question should be simple: where is the training receipt. If that question becomes a reflex across industry, academia, and government, the field gets a new baseline of trust. Builders gain a way to prove good practice without revealing special sauce. Policymakers gain a dial they can turn without freezing the stack. Users gain a clearer map of the world’s AI capacity.

The week compute got a seat at the table might read like a footnote now. In a year, it could feel like the moment artificial intelligence governance finally found the lever that moves the machine.