On governance at the substrate level

Revision note, October 16, 2026. This essay was substantially revised to add primary references, narrow unsupported claims and distinguish proposals from measured results. The original address and publication date are retained.

Governance should examine decisions made during model development as well as the conditions of deployment. A useful proposal states what an existing institution can already do and identifies the specific gap it would address.

Begin with the existing baseline

Training-data documentation and external model evaluation already have institutional examples. In July 2025, the European Commission published a template for summaries of general-purpose AI training content. Public documentation differs from confidential inspection of a corpus and from a proposed approval process before training. Those differences matter when arguing that further oversight is needed. Commission announcement.

The UK AI Security Institute also described testing before and after deployment in its December 2025 factsheet. That establishes external technical evaluation work. It does not establish authority to block every release, access to every model or complete coverage of every risk. AISI factsheet.

Technical expertise, access, legal authority and enforcement capacity are separate questions. A proposal should identify which of them is missing rather than treating oversight as wholly absent.

Evaluate controls by the risks they address

A restriction can reduce access or consequences without deleting a capability from model weights. Documentation, access controls, monitoring, release evaluation and model interventions therefore need different measures of effectiveness. Calling all deployment controls cosmetic skips that comparison.

The same caution applies to claims about bypassing a restriction. Demonstrating a capability on one smaller or fine-tuned model is evidence about that model and task. It does not prove that every restricted capability can be reproduced at a particular cost or by every actor.

Three proposals to make concrete

First, require a reviewable account of consequential data decisions. The account could identify provenance, permitted uses, selection criteria and important exclusions, with a defined confidential review path where raw material cannot be made public. Any proposed requirement would need clear jurisdiction, scope and protections for legitimate sensitive information.

Second, define release evaluation around the access and consequences of the system being released. Specify evaluator access, tested capabilities, attack conditions and what a failed test changes. Publish conclusions at a level that supports scrutiny without assuming every underlying artifact can safely be released.

Third, document architectural assumptions that affect an assessment. An evaluator should know which design details are disclosed, which are unknown and which conclusions depend on access that has not been granted. Architectural transparency can support evaluation without being treated as a complete safety measure.

These are proposals, not claims that their effectiveness has been demonstrated here. Each needs an implementation path, a cost model, an appeal process and tests of whether the intervention changes the intended outcome.

Measure progress without inventing a deadline

Useful milestones include a working review protocol, documented evaluator access, reproducible assessments and evidence that findings affect a release decision. A proposed timeline should be labeled as a target and tied to those milestones. An unexplained twenty-four- or thirty-six-month deadline is not evidence of inevitable institutional lock-in.

There is no need to attribute private motives to unnamed policymakers or developers. The stronger argument identifies observable constraints, compares interventions and states what evidence would change the recommendation. This essay offers a structure for that analysis, not a universal account of existing law or a completed empirical study.