How to Choose a Framework, Procedure, or Checklist

Choose a Framework, Procedure, or Checklist

Use a framework when people must diagnose and choose within legitimate variation. Use a procedure when the path, control, authorization, or evidence must be repeatable. Use a checklist when trained people need a concise prompt at critical moments. Combine them when the task contains both stable work and real exceptions.

The selection should come from the task's consequence, variability, expertise, time pressure, auditability, exception frequency, recovery, and change rate.

flowchart TD
    A["Define one task and its outcome"] --> B["Identify mandatory controls"]
    B --> C{"Is the normal sequence stable?"}
    C -->|Yes| D["Write or retain a procedure"]
    C -->|No| E["Define a decision framework"]
    D --> F{"Can critical items be missed?"}
    E --> F
    F -->|Yes| G["Add a short checklist"]
    F -->|No| H["Test the guidance"]
    G --> H
    H --> I["Add exception, escalation, owner, and review"]

1. Define one task and one outcome

Name the work at a grain that one person or team can recognize. "Handle customer issues" is too broad. "Resolve a billing discrepancy after the standard evidence does not match" is a task.

State the outcome without assuming the format. Identify the person affected, the evidence that proves completion, the acceptable time window, and the result that must be avoided.

Do not begin by deciding that the organization needs a framework or an SOP. The form follows the operating job.

2. Identify mandatory controls and authority

Before assigning discretion, determine which law, regulation, contract, policy, safety system, professional standard, approval, segregation of duties, or record controls the work.

Some steps cannot be optional. Some decisions belong only to a qualified or authorized person. Some evidence must be preserved even when the outcome appears obvious.

OSHA's process-safety standard offers a high-consequence example. For covered processes, written procedures must provide clear instructions and address operating phases, limits, consequences of deviation, corrective action, safety considerations, access, review, training, and changes.

That standard should not be copied outside its domain or treated as legal advice. It demonstrates the questions that become important when procedure quality affects safety.

3. Measure variation

Ask which facts change from case to case and whether those changes legitimately alter the decision.

Low variation supports a procedure. The inputs, order, tools, authorization, and evidence remain stable enough for one path to be reliable.

High variation supports a framework when the operator must compare facts, balance constraints, or choose among several valid routes.

Separate real variation from weak process design. If cases differ only because information is missing, systems are inconsistent, or ownership is unclear, a framework may conceal a fixable operating problem.

4. Measure consequence and recovery

Identify what happens when the work is missed, delayed, or performed incorrectly. Consider safety, privacy, money, rights, compliance, service interruption, reputation, reversibility, and the number of people affected.

Then examine recovery. Can the error be detected before it matters? Can the action be reversed? Is there time to consult someone? Will the evidence still exist?

High consequence and weak recovery require stronger controls, clearer authority, explicit safe stops, maintained procedures, and qualified review. Variation does not remove those needs.

5. Decide whether the task needs a framework

A framework is appropriate when the outcome is stable but the route legitimately changes.

Define the outcome, decision factors, constraints, prohibited actions, evidence standard, authority boundary, and escalation trigger.

NIST's Cybersecurity Framework 2.0 illustrates the form. NIST defines high-level cybersecurity outcomes while stating that the CSF does not prescribe how those outcomes must be achieved.

The example shows both the value and limit. A framework can provide a common result language across different organizations. It does not select or implement the organization's controls.

If the framework cannot help two qualified people explain why they chose different valid routes, it may be too vague.

6. Decide whether the task needs a procedure

A procedure is appropriate when sequence, authorization, consistency, handoff, or evidence must be repeatable.

Define applicability, prerequisites, inputs, responsible role, steps, operating limits, expected evidence, deviations, safe stop, recovery, escalation, owner, version, and review trigger.

Write for the person performing the task under real conditions. A technically correct document can still fail if the operator cannot find the right step, distinguish a warning from a required stop, or understand what evidence to preserve.

Do not include every possible explanation in the procedure body. Put background and training where they can support the operator without hiding the action.

7. Decide whether the task needs a checklist

A checklist is appropriate when the operator understands the work but may miss a critical item because of workload, interruption, familiarity, handoff, or time pressure.

Each item should connect to a meaningful failure. The checklist should appear at the moment of use and make participation clear.

WHO's clinical checklist record describes short tools that guide decisions, support consistency, and reduce errors. The WHO Surgical Safety Checklist uses team pauses around critical phases and is intentionally not comprehensive.

That does not mean every task should copy a medical checklist. It shows why a checklist can protect a few critical points without trying to become the whole procedure.

If the checklist needs paragraphs of explanation at the moment of use, the training, procedure, interface, or checklist design may need to change.

8. Build the combination

Many tasks need all three forms.

The framework can define outcomes and authorized decision factors. The procedure can define the normal sequence and required controls. The checklist can protect critical pauses, handoffs, or completion evidence.

The forms should not contradict one another. A framework should not imply discretion that the procedure prohibits. A checklist should not omit a critical control simply because it appears elsewhere. A procedure should not require a step after the exception path says work must stop.

Write the relationships explicitly.

9. Design the exception path

State what makes the standard route invalid. Name the signals that require pause, stop, escalation, or specialist review.

Define what the operator may decide, what remains prohibited, who owns the next decision, what evidence travels with the case, how urgency changes the route, and how the result returns to the operating record.

An escalation path must be usable. A named role that is unavailable during the task is not a functioning control.

Avoid turning every deviation into an exception. If the same case appears repeatedly, the normal procedure or framework may need to change.

10. Test real use

Test the guidance with representative users and realistic conditions. Include the normal case, missing information, an interruption, a changed system, a boundary case, a plausible failure, and recovery.

Observe behavior. Can the operator determine which document applies? Can they find the critical control? Do they recognize when the procedure no longer fits? Do they stop or escalate at the right point? Does the record show what happened?

Testing should include accessibility and language. The person must be able to perceive, navigate, understand, and use the guidance in the actual environment.

11. Assign maintenance

Give the guidance an owner, version, review date, change trigger, and retirement rule.

Review it after incidents, near misses, repeated exceptions, system changes, policy changes, new evidence, material user confusion, and shifts in the operating environment.

Do not keep obsolete guidance available beside the current version without a clear status. A precise document about an old process can create more confidence than it deserves.

Make the final choice inspectable

Record the task, outcome, consequence, variation, expertise, time pressure, auditability, exception frequency, recovery, change rate, mandatory controls, chosen forms, reason, test result, owner, and next review.

The decision may be one framework, one procedure, one checklist, or a linked set. What matters is that the form matches the work and exposes its limits.

E006 provides the source-era distinction. E020 adds bounded commitments. E025 and E073 cover operating and pilot boundaries. E117 and E119 add physical-system and real-use testing.

Read [[Frameworks Prepare People for Exceptions Better Than Scripts]] for the evidence-led argument and [[What The Daily Stoic Taught Me About Judgment]] for the personal origin.

This guide was developed with AI assistance from the preserved E006 transcript and the linked NIST, OSHA, and WHO records. It is a general selection method, not a replacement for a law, regulation, standard, safety system, professional duty, qualified review, or organization-specific procedure. Method, safety, compliance, editorial, accessibility, and founder review remain required. Publication is unauthorized.