Sometimes a capability spreads before what it needs is ready. The readiness profile shows it as a pair in the urgent or critical cells. At that point there are only two things to do: slow the capability where it matters, and build the missing readiness faster. Slowing it is only worth anything if the time is used to build.

Pace by domain, not by blanket halt

A general halt on AI development is neither possible for any one society nor desirable: most uses carry little risk, and many help build readiness itself. Commensurate pace works domain by domain instead. The question is not “should AI slow down?” but “should this capability, in this domain, wait until this readiness is in place?”

The answer depends on whether the harm can be undone:

Kind of harm Example What pace means
Reversible a tool that drafts letters badly let it spread; fix as it goes
Costly to reverse scoring used for hiring with no appeal deployment in that domain waits on contestability
Irreversible data gathered and joined across domains; a skill lost for a generation; a system that resists shutdown deployment waits on the readiness pair, and the burden is on those deploying to show it is in place

This is the framework’s general rule on irreversibility applied to pace: the less a harm can be undone, the more readiness must come first.

Where pace can actually be applied

Pace is not a matter of asking firms to be patient. It is applied where the public still holds levers:

  1. Licences and public inputs. Grid connections, spectrum, permits, public data. A condition attached at renewal can require a readiness item, such as a human appeal process or a fallback, before a capability is deployed in a sensitive domain.
  2. Public procurement. Governments are among the largest buyers. Buying only systems that are contestable, disclosed, and multi-provider sets the standard for everyone.
  3. Sector rules. Hiring, lending, housing, health, and education already have regulators. Each can require the readiness pair for its own domain.
  4. Liability. Those who deploy a capability before its readiness is in place carry the cost of the harm it causes. That makes waiting the cheaper choice.

Rivals who will not slow

The hardest objection: if one society paces a capability and a rival does not, the rival gains. This is the core of strategic competition, and it does not have an easy answer. Three things help:

  1. Most pacing costs no advantage. Requiring an appeal process for automated hiring, or disclosure in companionship, does not slow anyone’s frontier research. The race is real at the highest capability levels; it is not real for most readiness pairs.
  2. Readiness is itself strength. A society with preserved alternatives, competent people, and a secure population recovers from failures and attacks that would break a society without them.
  3. Verification makes mutual pace possible. Where the race is real, rivals can slow together only if each can check the other. Readiness at the highest levels includes the means of verification: inspection that does not become surveillance, and recovery capability shown before deployment.

Once a window has closed

Sometimes a capability becomes ordinary before its readiness exists. The framework does not pretend this can always be undone, but there is usually something left to do:

  • Build the alternative anyway. A second provider is harder after lock-in but not impossible, especially with public procurement behind it.
  • Restore the skill where it can still be taught. Find the people who still hold it and fund them to teach before they leave.
  • Contain what cannot be reversed. Data that cannot be ungathered can still be barred from use in decisions.
  • Record it in the register. Every closed window is a lesson for the next capability, and the irreversibility register keeps the lesson.

The aim is to need this section rarely. Every pair built in time is a window that never has to be pried open again.