Error Log Mindset

Reconstruct the chain first

Before you change the unit, you need to know why your hand went to the wrong drawer. Was the vial labeled similarly? Was the drawer unlabeled? Were you interrupted mid-task? Write down the judgment you made at the moment of grabbing—not just "I grabbed wrong."

Push to the system layer

Your personal notebook is a start, but it dies with you. Bring this to your unit's next huddle as a blameless case review. Say: "This happened, here's the context, here's what I was thinking." No apologies needed—just data. Then run Five Whys until you hit a process gap. "Careless" is not a root cause. "Two insulin vials with similar packaging sit in adjacent drawers" is.

Land one process change

Pick a single, verifiable fix. Best options: add a physical separation (different shelves or colored bins), or add a double-check step where a second nurse verifies dose and vial before administration. Do not add five changes—one that sticks beats five that don't.

Close the loop

Log the error, root cause, and change in a shared unit log. Set a 30-day review: count how many times the new verification step was skipped. If it's skipped, the process is too heavy—simplify it. If it holds, you've turned one mistake into a permanent guardrail.

Stop saying "be more careful"

That phrase is a dead end. It names an attitude, not a fix. You need an Issue Log like Bridgewater's: every failure gets logged, rated, and assigned—no blame, just facts.

Build the log with four fields

1. What happened — the symptom and impact.
2. The judgment at the time — what you assumed when shipping.
3. Root cause — keep asking "why" until you hit a process gap, not a person.
4. Process change — one specific action: add a test, add a code review gate, add a feature flag.

The bug that recurred is your gold

The same bug twice means your first fix patched a symptom. Go back to the first incident and re-run the Five Whys. Did you fix the display layer but not the data model? Did you skip a regression test because you were shipping fast? That missed step is your real root cause.

Make it a ritual

Every Friday, review the log for 30 minutes. Sort by frequency. The top pattern is your weakest process. Change that one thing, and re-measure in a month. If the bug count drops, you've closed the loop. If not, your root cause was wrong—dig deeper. Logging without analysis is just a diary.

Reframe the problem

Your students aren't careless—they have a pattern. "Not" questions require a mental flip: find the exception, not the rule. Telling them to "read carefully" doesn't give them a strategy. Give them a tool.

Create a simple error log

Give each student a one-page form with three columns:

• Question type — e.g., "not," "except," "least likely."
• My answer vs. correct answer — write both.
• What I missed — one sentence: "I picked the true statement instead of the false one."

Teach them to spot the pattern

After five logged errors, have them sort by question type. Most will see "not" questions cluster. Then teach one tactic: when you see "not," underline it and rephrase the question in your head—"Which one is NOT true?" becomes "Which one is false?" That single step forces the flip.

Close the loop with a pre-test ritual

Before each practice test, have them write "check for NOT/EXCEPT/LEAST" at the top of the page. That's their process change. After two weeks, compare error rates on "not" questions. If they drop, the log worked. If not, your tactic needs adjusting—maybe they need to eliminate wrong answers first. Log, review, adjust.