Responsible Scaling Needs Measurement

Governance works at one moment: a measurement crosses a threshold and the release stops. Models keep scaling and the risks scale with them, so build that moment before you write another line of policy.

You Cannot Govern a Capability You Cannot Elicit

You cannot govern a capability you cannot elicit, measure, and track. A weak scaffold hides capability, and so does a lazy prompt. The model keeps what the test missed, and the first person outside your team with a better scaffold finds it.

Start by naming the dangerous capability in plain words. A vague worry has no eval and no threshold, so it never reaches a decision. Name the capability, then name how you elicit it.

Order decides whether the policy does any work. A policy written after the technical plan is fixed can only describe the plan. The measurement has to arrive early enough to change what ships.

Anthropic's Responsible Scaling Policy ties safety levels to capability thresholds and to the safeguards each level needs. The rule is a procedure: measure the capability, map it to a risk level, add the safeguards it needs. The threshold defines what changes behavior, and the mitigations must exist before deployment continues.

Elicitation Is a Stress Test

A weak evaluation misses a real capability because it asks badly. Strong elicitation gives the model its best reasonable shot: better prompts, more attempts, and expert-designed tasks. Tool access goes in when the task needs it.

A comfortable safety test measures your prompt. A strong one measures the model. You look for what the system can do before the world finds it for you.

The reasoning note kept verification outside the model. Elicitation is that verification, aimed at the ceiling of the model rather than at a single answer.

Measure the Model and the Deployed System

A model can be capable of a dangerous action and still be unlikely to take it inside a locked-down product. The same model can look harmless in a chat window and turn risky the moment you hand it tools.

So the policy carries two numbers. One is raw capability. The other is what the deployed system permits. That number moves with the scaffold, the permissions, the policy layer, the monitoring, and the human review path.

Tools move both numbers at once. Tool access raises what elicitation can show, and it raises what the product lets the model do. Hold both numbers, or you are guessing.

A Gate Has Four Pieces

A working gate has four pieces: a capability eval, a threshold, a mitigation, and an owner who can refuse. Take away the threshold and the measurement becomes trivia. A threshold with no required mitigation is theater. Without an owner, nobody pays a cost when someone says ship anyway.

I do not trust a gate until I can name the person who can refuse. The four pieces only work as a path, and the path ends at that name.

Agents Turn a Bad Answer Into a Bad Sequence

A chat model produces a bad answer. An agent produces a bad sequence. It gathers information, calls tools, makes irreversible changes, and adapts around weak guardrails.

So the safety review covers the whole sequence. You check four things in the trajectory: approval points, tool boundaries, stop conditions, and logs a human can follow. The stop condition carries the most weight, because uncertainty rises inside a run and the agent keeps acting.

Those logs carry the replayable trail from the enterprise note. The trail holds what the agent relied on, what it changed, and how a person undoes it. Without that trail, an incident review has nothing to replay.

Computer-use agents turn language into action on a screen, which is where the stakes rise. The capability and the risk come from the same mechanism. A gate for that system prices actions.

Governance Needs Layers Because Any Single Test Bends

Manual review alone cannot cover every release, so governance needs benchmarks. People can game a fully automated eval, and an automated eval can miss the risk that matters. Each test bends in a different direction, which is the argument for stacking them.

The working stack is automated benchmarks, red-team exercises, expert review, staged deployment, monitoring, and stop conditions a person can trigger. One decision procedure ties them to deployment limits, independent review, incident response, and public commitments.

Every layer produces a score, and the score expires. Treat a score as permanent and you are governing an old model. Capability moves with fine-tuning, tools, scaffolds, prompts, deployment context, and user incentives.

So write retest triggers into the policy. A new tool, a fine-tune, or a wider deployment voids the last score, and someone runs the eval again.

The Builder Test

Trace the stop path on a system you run now.

• Pick one eval whose result can stop your next release.
• A result crosses the threshold. Write down who hears about it first.
• Say which mitigation becomes mandatory before the release moves again.
• List what you examine a second time after the mitigation lands.
• Put a name on the person who can refuse, and say what refusing costs that person.

An empty line names the missing piece of your gate. Fill it before the model or the deployment changes again.

What Carries

Elicit hard, measure the model and the product it lives inside, then give one threshold authority over the release date. Everything else is documentation around a launch path someone already chose.

A gate decides what ships. The last note in this series meets the text that arrives after it ships.