Checklists Catch Human Failure

A checklist is not proof that someone forgot how to do the job.

It is an engineering control for a predictable human limitation: people skip steps when they are rushed, interrupted, overconfident, tired, distracted, or working from memory.

Good checklists move critical knowledge out of memory and into a shared, inspectable process.

Memory is not a reliable safety system

Imagine a crew has performed the same simulated preflight 20 times.

On attempt 21, someone interrupts during setup. The team resumes one step later than where they stopped and never notices that the payload latch was not verified.

Nobody lacked knowledge.

The failure was sequence recovery after interruption.

A checklist can make the missing step visible.

Checklists should control decisions, not decorate them

A weak checklist says:

□ Battery
□ Props
□ Weather
□ GPS
□ Ready

What does “Battery” mean?

• present?
• charged?
• correct pack?
• normal condition?
• securely installed?
• documented status?

A useful item states an observable condition.

Better:

□ Installed battery ID matches mission configuration record.
□ Supplied battery inspection evidence shows no no-go condition.

Now another person can tell what “complete” means.

Use challenge–response for critical items

Some procedures become stronger when one crew member reads the item and another verifies or responds.

Example classroom pattern:

CHECKER:  Recovery point?
OPERATOR: Verified against current mission record.
CHECKER:  Geofence/recovery configuration?
OPERATOR: Matches approved simulation configuration.

The exact crew procedure depends on the operation. The human-factors idea is that verbal confirmation can reduce silent assumptions for critical steps.

Order matters

Checklist sequence should follow dependency.

This order is weak:

□ Start mission
□ Verify payload
□ Check current site condition
□ Confirm recovery area

The last three items are preconditions for the first.

A stronger sequence groups checks by phase:

Before mission readiness

• current airspace/restriction evidence;
• site/weather state;
• aircraft/payload configuration;
• crew roles and recovery plan.

Immediately before approved operation

• current condition rechecks;
• operating area clear;
• aircraft condition and control/link checks under procedure;
• mission and recovery configuration confirmed.

After operation

• aircraft/payload condition;
• data product preserved;
• anomalies logged;
• configuration or maintenance status updated.

The checklist should follow the system lifecycle.

Stop items are different from normal items

A checklist needs a response when something fails.

Weak:

□ Weather acceptable

Stronger:

□ Current weather remains inside approved mission limits.
   If NO → mission status becomes NO-GO until reevaluated.

That second line prevents someone from checking the box, noticing a problem, and continuing because the checklist never said what the problem means.

Checklist design needs version control

Suppose an aircraft configuration changes and the new payload requires a different calibration check.

If the team keeps using an old checklist, the document becomes a failure source.

Useful checklist metadata includes:

• title;
• version/revision;
• configuration or mission type it applies to;
• owner;
• last review date;
• source/requirement that changed it.

The goal is not bureaucracy. The goal is to prevent “the checklist says we’re done” when the checklist belongs to last month’s system.

Worked failure: the checkbox was true but the system was wrong

A fictional checklist says:

□ Home point set

The box is checked.

Later review shows the recorded home point is the wrong location.

The checklist item controlled completion, not correctness.

A better item is:

□ Recorded recovery/home location matches the approved mission map and configuration record.

Now the verification has an external reference.

This is a major checklist-design principle:

Critical items should verify against evidence, not only against memory.

Do not make the checklist infinite

A checklist that contains every detail of the training manual becomes hard to use.

Use checklists for:

• critical sequence;
• high-consequence omissions;
• configuration verification;
• go/no-go gates;
• handoffs;
• emergency memory aids where appropriate.

Use manuals, diagrams, and procedures for deeper explanation.

A checklist is an interface to the procedure, not the entire knowledge base.

Build a checklist from failure modes

Start with five fictional failures:

• wrong battery/configuration;
• stale airspace/restriction check;
• payload not calibrated for current configuration;
• recovery zone occupied;
• crew unsure who can call abort.

For each, write one checklist item that would catch the failure before the mission reaches the affected state.

Then add:

• the evidence/reference;
• the response if the item fails;
• the phase where the check belongs.

Misconception: experienced people do not need checklists

Experience helps people recognize patterns and make judgments.

It does not make memory perfect.

High-reliability systems use procedures precisely because experts also get interrupted, rushed, and overloaded.

The checklist protects the team from normal human behavior.

The design standard

A strong checklist item answers four questions:

1. What exact condition are we checking?
2. What evidence proves it?
3. When in the sequence must it happen?
4. What happens if it fails?

If an item cannot answer those questions, it may be a reminder—but it is not yet a strong control.