Frameworks vs Scripts for Handling Exceptions

Frameworks Prepare People for Exceptions Better Than Scripts

A framework prepares a person to recognize and reason through changed conditions. A procedure protects work that needs a defined sequence. A checklist makes critical verification visible at the moment it matters. Variable, consequential work usually needs a deliberate combination rather than a choice between freedom and control.

The central operating question is not whether people should use judgment. It is where judgment belongs, what constrains it, and what happens when the standard path no longer fits.

flowchart TD
    A["Task begins"] --> B{"Does a maintained procedure apply?"}
    B -->|Yes| C["Follow the defined path"]
    C --> D["Use checklist at critical points"]
    D --> E{"Conditions still within limits?"}
    E -->|Yes| F["Complete and preserve evidence"]
    E -->|No| G["Stop or escalate"]
    B -->|No| G
    G --> H["Use framework within authorized discretion"]
    H --> I["Resolve, recover, and update guidance"]

Scripts fail silently when assumptions change

A script can look reliable because the first several steps still work. The failure becomes visible only when a missing fact, changed system, unusual customer, new hazard, conflicting requirement, or unavailable dependency invalidates the next step.

Someone trained only to reproduce the sequence may continue, freeze, or improvise without understanding the risk.

The E006 transcript connects this problem to an early manager. Instead of supplying a new instruction for every case, the manager tried to teach ways to frame the problem. That story is first-person evidence of Dalton Anderson's interpretation. It is not a general study of training.

The durable insight is that transfer requires more than remembering what happened last time. The operator needs to recognize which conditions matter and what makes the current case different.

A framework defines the decision space

A useful framework names outcomes, constraints, decision factors, boundaries, and escalation triggers without prescribing one implementation for every context.

NIST's Cybersecurity Framework 2.0 offers a concrete example. NIST describes the CSF as a taxonomy of high-level cybersecurity outcomes and states that it does not prescribe how those outcomes must be achieved.

That flexibility supports organizations with different sizes, sectors, systems, and maturity. It also means the framework does not implement itself. An organization still needs controls, procedures, owners, evidence, and review.

A weak framework names attractive values without helping someone choose. "Use good judgment" fails if the operator cannot identify relevant facts, prohibited actions, authority limits, or a safe escalation path.

A procedure protects repeatability

A procedure is strongest when a task has a known process, a meaningful order, required controls, defined authorization, or evidence that must be preserved.

OSHA's process-safety standard provides a domain-specific example for covered processes involving highly hazardous chemicals. It requires written operating procedures with clear instructions and addresses operating phases, limits, consequences of deviation, corrective steps, safety considerations, access, review, training, and process changes.

The standard does not support a generic office procedure template. It shows what procedure design looks like when an error can have serious consequences and the operating state can change.

The procedure must say more than what to do when everything is normal. It must identify deviation, correction, safe shutdown, emergency operation, and change control.

That is not the suppression of judgment. It is the careful assignment of judgment to qualified people at defined points.

A checklist protects critical attention

A checklist is not a compressed manual. It is a prompt or verification tool for critical items that trained people might otherwise miss under workload, interruption, familiarity, or time pressure.

WHO's clinical checklist record describes tools that guide clinical decisions, support consistent care, and reduce errors. The WHO Surgical Safety Checklist creates team pauses around critical phases and checks.

WHO also states that the surgical checklist is not comprehensive and allows adaptation to local practice. That boundary matters. A checklist operates inside a larger system of professional knowledge, procedures, communication, equipment, and accountability.

Making a checklist longer can reduce its usefulness. If it tries to teach the entire job, the critical items become difficult to see and the operator may stop using it at the intended moment.

Judgment should be designed, not romanticized

Leaders sometimes use framework language because it sounds empowering. The result can be vague expectations, hidden risk, inconsistent decisions, and blame when an employee guesses incorrectly.

Real discretion needs a defined area. The operator should know the intended outcome, the evidence to consider, the constraints, which actions are prohibited, what authority they possess, and when the decision must move to someone else.

The philosophical language in E006 also needs this boundary. The Stanford Encyclopedia of Philosophy's discussion of Stoic assent distinguishes an impression from the critical judgment a person makes about it. That can illuminate reflection, but it does not turn Stoicism into an operating standard.

Professional competence, organizational authority, regulation, safety engineering, human factors, and domain evidence still control the work.

Procedures should not erase diagnosis

The opposite failure occurs when a procedure is treated as valid after its assumptions have broken.

A detailed sequence can create false confidence if it describes an old system, omits a plausible exception, or gives no way to stop. An operator may follow every written step and still produce the wrong result because the procedure no longer matches reality.

A maintained procedure should state when it applies. It should expose inputs, prerequisites, limits, expected evidence, and invalidating conditions. It should distinguish a recoverable deviation from a condition that requires immediate stop or escalation.

Training should include boundary cases, not only the happy path.

The combination is the operating system

Consider a recurring task with both stable and variable parts.

The framework defines the outcome, decision factors, and boundaries. The procedure defines the normal sequence, required controls, authorization, and records. The checklist protects critical pauses or handoffs. The exception path explains what invalidates the standard route and who owns the next decision.

None of the forms is complete alone.

A framework without implementation can become a poster. A procedure without context can become brittle. A checklist without trained users and a larger process can become ritual. An exception path without authority can become unauthorized improvisation.

The system becomes useful when the forms agree.

Consequence and variability shape the mix

High variation increases the need for diagnosis and a framework. High consequence increases the need for explicit controls, qualifications, evidence, safe stops, and escalation.

Low-variation, low-consequence work may need only a simple procedure. High-variation, low-consequence work may allow broad discretion with a lightweight review. Low-variation, high-consequence work may depend heavily on procedures and critical checklists.

High-variation, high-consequence work is the hardest case. It requires qualified judgment inside strong boundaries, with specialist review and an operating system designed for uncertainty.

Auditability also matters. A task may permit several valid choices while still requiring the evidence and reason for the decision to be preserved.

Test guidance against exceptions

Do not validate guidance by asking whether the author approves it. Put it in front of representative users and realistic conditions.

Test the normal case, missing information, interruption, changed systems, conflicting inputs, a boundary condition, a plausible failure, and recovery. Observe what people notice, where they hesitate, when they continue incorrectly, and whether they can find the escalation path.

Then revise the guidance form. A failure may require clearer steps, a shorter checklist, a better framework question, a new control, additional training, or a decision that the task belongs to someone more qualified.

E020 adds bounded commitments. E025 and E073 cover operating and pilot boundaries. E117 examines physical-system evidence. E119 adds testing at real duration and intensity.

Read [[What The Daily Stoic Taught Me About Judgment]] for the source-era story and [[Choose a Framework Procedure or Checklist]] for the task-level selection process.

This essay was developed with AI assistance from the preserved E006 transcript and the linked NIST, OSHA, WHO, and Stanford records. The regulatory, clinical, cybersecurity, philosophical, and management examples remain in their own domains. This page cannot override a law, standard, procedure, safety system, professional duty, or qualified authority. Method, safety, compliance, editorial, accessibility, and founder review remain required. Publication is unauthorized.