Scattered tips do not scale. You can read a hundred safety articles and still freeze when facing a new deployment, because a pile of advice is not a process. What you need is a model: a small number of named stages you apply in order, every time, so safety becomes a repeatable practice rather than a series of improvised decisions.
This article introduces one such framework, SCALE, that organizes the whole discipline into five stages: Specify, Contain, Authorize, Limit, Evaluate. It is deliberately small enough to remember and ordered so each stage depends on the one before. The point is not that this acronym is sacred; it is that having any disciplined sequence beats reacting case by case.
If you have read our other pieces, you will recognize the components. This article is what ties them into a single reusable model. For the raw principles, see our complete guide; this is the structure that organizes them.
Why a Framework Beats a Checklist
A checklist tells you what to verify. A framework tells you how to think, which means it generalizes to situations the checklist author never anticipated. When you hit a novel deployment, an agent with a new tool, a new untrusted data source, a checklist may have no item for it. A framework tells you which stage the new thing belongs to and what that stage demands.
Use both: the framework for reasoning, our checklist for verification. They are complementary, not competing.
Stage 1: Specify
Everything begins with a clear statement of what the system must do and, more importantly, must never do.
- Write the concrete forbidden behaviors for this use case.
- State the real goal separately from any metric you will measure, so you can catch proxy gaming.
- Classify each action by stakes and reversibility.
When to apply: First, always, and revisit whenever the product changes. A vague spec makes every later stage unenforceable because there is nothing precise to enforce against. Specification gaming, the model satisfying the letter while violating the intent, lives or dies here.
Stage 2: Contain
Assume untrusted input is hostile and stop it from issuing instructions.
- Map every channel where content the user did not write reaches the model.
- Separate that content from your instructions structurally, with labeled delimiters and a system prompt that treats it as data only.
- Validate and length-limit inputs before they reach the model.
When to apply: Whenever the model reads anything from outside a fully trusted source, which is almost always. This stage is your primary defense against prompt injection, the risk our examples article shows breaking real deployments.
Stage 3: Authorize
The model proposes; deterministic code decides whether to act.
- Have the model return intent, not actions.
- Authorize each intent against policy, ownership, and limits in code before executing.
- Require human approval for irreversible or high-cost actions.
When to apply: Whenever the model can trigger a consequential action. This is the stage that contains the damage when Specify and Contain fail, and our case study credits it with permanently closing an incident class. If your system only answers questions, this stage is lighter, but the principle still governs anything that leaves the system.
Stage 4: Limit
Constrain what the model can produce and what it can touch.
- Validate output shape in code; reject what does not conform.
- Grant the model least privilege, only the access it strictly needs.
- Sanitize and, where possible, ground output so fabrication is visible rather than camouflaged.
When to apply: Always, scaled to stakes. Limit and Authorize work together: Authorize gates actions, Limit constrains outputs and access. Skipping Limit is how a hallucinated value or an injected payload flows downstream unchecked.
Stage 5: Evaluate
Measure behavior continuously, or none of the above stays true.
- Build an evaluation set with normal, edge, and attack cases.
- Track both harmful outputs and false refusals.
- Gate every change on the eval set, log consequential paths, and red-team on a schedule.
When to apply: Continuously, forever. Evaluate is what converts the first four stages from a one-time setup into a maintained property. Without it, your system drifts as prompts change, models update, and threats evolve. This is the stage teams skip and the one that, per our common mistakes guide, causes silent regressions.
Applying SCALE to a New Deployment
Faced with anything new, walk the stages in order. What must it never do (Specify)? Where does untrusted input enter (Contain)? What can it cause to happen (Authorize)? What can it output and access (Limit)? How will I know it still behaves (Evaluate)? Five questions, answered in order, take you from a blank deployment to a defensible one. That is the entire value of having a framework: it turns a daunting open question into a sequence you already know how to run.
Where Teams Misapply the Framework
A framework is only as good as the discipline of applying it honestly. Three failure patterns recur.
Treating the stages as independent
The stages reinforce each other; they are not a buffet. A team that does Specify and Evaluate but skips Contain has a measured, well-specified system that still gets injected. The stages were ordered because each assumes the prior ones are in place. Skipping a middle stage leaves a hole that the later stages cannot cover.
Stopping after the visible work
Specify, Contain, Authorize, and Limit produce visible artifacts, prompts, code, config, so they feel like completion. Evaluate produces a process, which is easy to defer indefinitely. A framework applied through stage four and abandoned at stage five decays silently, which is the worst outcome because it looks finished.
Applying it once
SCALE is not a launch ritual. It is a lens you re-apply whenever the deployment changes: a new tool, a new data source, a model upgrade. Each change can reopen a stage you thought was settled. The model upgrade that loosens injection resistance reopens Contain; the new tool reopens Authorize. Re-walk the affected stages, not the whole thing, on every meaningful change.
A Quick Self-Test
You can pressure-test any deployment against SCALE in five questions. If you cannot answer one crisply, that stage is where your risk concentrates.
- Can I state in one sentence what this system must never do? (Specify)
- Where does content the user did not write enter, and is it isolated? (Contain)
- What can the model cause to actually happen, and who authorizes it? (Authorize)
- What can the model output and access, and is either constrained? (Limit)
- How would I know tomorrow if this system started misbehaving? (Evaluate)
A deployment that answers all five cleanly is defensible. A deployment that stumbles on one has just told you exactly where to spend your next hour. That diagnostic speed is the practical payoff of carrying a framework instead of a pile of tips.
Frequently Asked Questions
Is the SCALE acronym the important part?
No. The important part is having any disciplined, ordered sequence you apply to every deployment. The acronym is a memory aid. If you prefer a different mnemonic, use it, as long as it covers specification, input containment, action authorization, output and privilege limits, and continuous evaluation.
How is this different from just following the checklist?
The checklist verifies known items; the framework tells you how to reason about new situations the checklist never anticipated. Use the framework to think and the checklist to verify. They are complementary, and serious teams keep both.
Which stage do teams most often shortchange?
Evaluate. The first four stages are visible setup work; evaluation is ongoing discipline that is easy to defer. But without it, the other stages silently decay as the system changes, which is why it anchors the framework rather than trailing it.
Can I apply only some stages?
For answer-only or low-stakes systems, Authorize is lighter and you lean on Specify, Contain, and Evaluate. But every stage maps to a real failure mode, so dropping one means accepting that failure mode consciously rather than by oversight.
Key Takeaways
- A framework generalizes to novel deployments in a way a checklist cannot; use both.
- SCALE orders safety into Specify, Contain, Authorize, Limit, Evaluate, each depending on the prior.
- Specify defines what to enforce; Contain stops injection; Authorize gates actions; Limit constrains outputs and access.
- Evaluate is continuous and is what keeps the other stages true as the system changes.
- For any new deployment, walk the five stages in order to go from blank to defensible.