An error-pattern library is a personal database of failures, mistakes, and misjudgements — each one processed into a brief entry that captures what happened, why it happened, and what a better response would look like. Over time, it becomes a searchable map of your own failure modes.
The goal is not self-criticism. It is extraction. A mistake you process and file has the highest possible return on its cost. A mistake you survive and move past costs you exactly what it cost — nothing more.
This is the Learning Rate made concrete. Practitioners with a high Learning Rate are not the ones who fail least. They are the ones who extract most from every failure.
Workflow
The Entry Format
Each entry has five fields. Keep them short — this is a working log, not an autopsy report.
## [Date] — [Brief description of the error]
**What happened:**
[Two to three sentences. What you did, what the result was.]
**Why it happened:**
[Your honest read on the root cause — not the proximate cause but the
underlying one. "I didn't have enough information" is a proximate cause.
"I moved too fast because I was anxious about the deadline" is a root cause.]
**What I would do differently:**
[Specific. Not "be more careful" — the exact decision or action that
would have produced a different outcome.]
**Tags:**
[Two to three keywords — e.g., assumptions, speed, communication, scope,
creed-test, judgement-call]
**Pattern flag:**
[Yes / No — if this error resembles something you have seen before,
name the pattern: e.g., "same as 2025-03-14 entry — moving before
assumptions are verified"]
Capturing Without Breaking Flow
The most common reason practitioners do not maintain an error-pattern library is friction at the capture stage. Something goes wrong, there is immediate pressure to fix it, and the reflection never happens. By the next day, the texture of what happened is already fading.
The solution is a two-step process: capture raw now, process later.
Step 1: Raw capture (immediate). The moment something goes wrong, open a scratchpad — a note on your phone, a line in a running document, a voice note — and record two things: what just happened, and what you felt in the moment. Do not structure it. Do not try to understand it yet. Just capture it before the day moves on.
Step 2: AI-assisted processing (later). Within twenty-four hours, take your raw capture to an AI assistant with this prompt:
"Help me process this error into a library entry. Here is my raw note: [paste raw capture]. Use these sections: What happened (two to three sentences), Why it happened (root cause not proximate), What I would do differently (specific action), Tags (two to three keywords). Also flag if this resembles a pattern I may have seen before."
The AI structures the entry. You review it for accuracy — the AI does not know what was actually happening inside your head, so the root cause section in particular may need correction. Amend and commit.
Querying the Library
The library is only useful if you return to it. Two moments where returning pays back well:
Before a decision that resembles a past failure. If you are about to move fast on an assumption that has not been verified, and you have an entry that reads "moving before assumptions are verified," the library is doing exactly what it should. Brief the AI:
"I am about to [describe decision]. Are there entries in my error-pattern library that are relevant? Here is the library: [paste]. Flag anything I should be thinking about before I proceed."
Periodically, to find patterns. Every quarter, run a brief pattern review:
"Here are my last [number] error entries. What patterns do you see? Group them by tag and flag any root causes that appear more than twice."
The pattern review is where the library earns its keep. Individual entries are data. Patterns are learning.
Using AI to Tag and Search
Once your library has more than twenty or thirty entries, manual pattern-finding becomes harder. AI makes this tractable.
For tagging consistency, maintain a small controlled vocabulary — five to ten tags — and ask the AI to apply them consistently. Tags like assumptions, speed, communication, scope, creed-test, stakeholder, process cover the most common failure categories for early-career practitioners.
For search, paste the relevant portion of your library into a session and ask specific questions:
"Have I made errors related to communication failures with stakeholders before? If so, what was the pattern?"
"What is the most common root cause in my library entries from the last six months?"
The AI is not replacing your judgement here — it is doing the indexing work that makes your own judgement retrievable.
What Makes It a Library, Not Just a Log
A log is linear. A library is retrievable. The difference is tagging and pattern-flagging. An entry that is tagged and reviewed is in the library. An entry that is written and never returned to is just a log.
If you only do one thing to maintain the library, make it this: before you commit each entry, ask yourself whether it resembles anything you have captured before. If it does, flag it explicitly and name the pattern. The pattern flag is what turns a collection of individual mistakes into a map of your specific failure modes — and a map of your specific failure modes is one of the most useful things a practitioner can have.
From Appendix D: Things They Should Have Told You on Day One — The Practitioner (Phil Rust, 2026). Part of the Practitioner companion resources.