📉 Why unrecorded knowledge gets lost
Every professional has experienced this: a success that disappeared. You found the right way to do something, it worked better than expected — and three months later you can't replicate it. It's not a lack of talent. It's system failure.
The win that got lost
You published a post that performed 10× better than average. Saves, shares, DMs. Three months later, someone on the team asks: “How did you make that one?” You try to replicate it. The result is mediocre.
The prompt was right. The intent was clear. The context was configured well. But none of these layers was recorded. The knowledge existed for 24 hours—and evaporated. This module teaches you how to close that gap.
✗ Without a record—what happens
- ✗ Every success starts from scratch next time
- ✗ The team can’t replicate what you did
- ✗ Errors recur because the cause was not documented
- ✗ Progress exists, but doesn’t accumulate
✓ With logging — what changes
- ✓ Successes become reusable templates
- ✓ The team replicates it without needing you
- ✓ Errors become documented adjustment rules
- ✓ Every repetition improves the process
💡 The mindset shift
Recording isn’t bureaucracy — it’s install memory in your process. A system that learns builds an advantage. A system that forgets always starts from the same point.
📝 What to record — and what isn’t worth the effort
Recording everything is impractical and useless. The discipline lies in knowing how to distinguish what has reuse value than what was circumstantial. Use the filter below before deciding whether something belongs in your library.
✓ Record
- ✓ Prompt that produced a result without editing
- ✓ Structure that performed above average
- ✓ Error that happened more than once
- ✓ Process you’ve done the same way 3+ times
- ✓ Response approved on the first try by the client/manager
✗ Not worth recording
- ✗ Prompt you used once and discarded
- ✗ A result specific to a one-of-a-kind context
- ✗ "Looks good" with no measurable criteria
- ✗ Process that depends on data that changes every week
- ✗ Answer you edited by more than 50% before using
The 3-run rule
If you’ve done the same process in a similar way 3 times or more, it deserves a playbook. Below 3, it’s too early — you’re still discovering the pattern. Above 3 without a record, you’re losing what you learn with every repetition.
🔍 Reverse-engineering a winning piece of content
Take any post, email, or deliverable that worked better than expected and go through the 5 steps below. The goal is to extract the invisible structure behind the win — the anatomy: Pain → Explanation → Example → Benefit → CTA.
Identify the pain point being addressed
What reader problem did this content address? Not what you meant to say—what the reader felt was being said to them.
Capture question: "What pain point did this content solve or name?"
Map the central explanation
In one sentence: what was the main argument? Not the topic—the argument. What was said that changed the perspective?
Capture question: "In one sentence, what was the central insight?"
Extract the example used
What was the specific case, analogy, or data point that made the argument credible? Specific example > generic abstraction—always.
Capture question: "What example or case anchored the argument?"
Name the clear benefit
What does the reader gain by applying this? The benefit needs to be specific and immediate—not “it’ll get better,” but “it’ll save X or prevent Y.”
Capture question: "What concrete benefit does the reader get from this?"
Record the CTA (or its absence)
What was the reader asked to do at the end? Save, comment, apply, click? Or was there no CTA—and that’s also a clue about why it worked.
Capture question: "What was the reader encouraged to do?"
Result of the 5 steps
You now have the structure D → E → E → B → CTA extracted from what worked. That’s the template. Next time, you start here—not from scratch.
🔄 A success becomes a template · an error becomes an adjustment · repetition becomes a process
The maturity cycle starts with improvisation and ends with a living library. Each step represents a transformation: tacit knowledge (in your head) gradually becomes explicit (in the system). See where you are and what it takes to move up a step.
Success → Template
When something works: extract the structure using the 5 steps from the previous topic. Document the pattern, not the specific case.
Error → Adjustment
When something fails: record the diagnosis. “What went wrong and why” is more valuable than hiding the failure and trying something else.
Repetition → Process
When you repeat something 3+ times, it’s time to formalize it in a playbook. Repetition signals that the process is worth scaling.
📋 Your first playbook (1 page)
A one-page playbook isn’t a limitation — it’s a design constraint. A process that doesn't fit on one page hasn't been distilled enough. If you need more, split it into two smaller playbooks. The constraint is what ensures it survives and gets used.
# [NOME DO PROCESSO] — Playbook v1
## Quando usar
[Situação específica que dispara este processo]
## Passo a passo
1. [Etapa 1 — ação concreta]
2. [Etapa 2 — ação concreta]
3. [Etapa 3 — ação concreta]
4. [Etapa 4 — opcional se necessário]
## Prompt padrão
"""
[Cole aqui o prompt testado — com variáveis em [COLCHETES]]
"""
## Exemplo de resultado esperado
[Descreva em 2-3 linhas como fica a saída quando funciona bem]
## Métricas de sucesso
- [ ] [Critério 1 — ex.: aprovado sem edição]
- [ ] [Critério 2 — ex.: tempo < X minutos]
## Quando não está funcionando
[O que ajustar — prompt? contexto? estrutura?]
## Versão: v1 · Criado: [data] · Campeão atual: simConnection T1 → T4
In Track 1, you learned to name and version prompts. Here, that becomes the playbook’s “Standard Prompt” field. The seed planted in T1 takes root in the T4 method.
💡 Tip: start with it filled in, not blank
Don’t wait for the perfect process to create the playbook. Create it with what you know today—version 1. An imperfect playbook that gets used is more valuable than a perfect playbook that never existed.
📊 Simple metrics: what counts as “success”
The metric needs to be stated before of using the process, not made up afterward to justify the result. If you don't know what "success" looks like, anything seems reasonable—and you never improve anything.
✓ Useful metrics
- ✓ Used without editing → metric: 0 edits
- ✓ Approved on the first try → metric: 0 revisions
- ✓ Saved time → metric: X minutes saved
- ✓ Reuse rate → metric: % of times applied
✗ Misleading metrics
- ✗ "Looks good" — subjective, not comparable
- ✗ "Better than before" — before when? Compared with what?
- ✗ "The client liked it" — once? Always? Which client?
- ✗ A sense of productivity without concrete data
The “Success metrics” field in the playbook
Each playbook has a metrics field. Fill it with 2–3 criteria before using it for the first time. After 5 runs, review them: do the criteria still make sense? Is the process meeting them?
If the process isn’t meeting its stated metrics, it’s time to adjust the playbook, not ignore the numbers.
⏱️ Capture routine: 5 min at the end of the day
The most valuable context exists right after you finish. Not in a monthly retrospective, not in a team meeting—now, while the session is still fresh in your memory. It takes just 5 minutes, but it needs to happen every day.
⏰ The 3 daily capture questions
- 1. What worked today that’s worth repeating?
- 2. What did I repeat from yesterday without realizing it?
- 3. What would you adjust before doing it again tomorrow?
📍 Where and how to record it
- → A note in the app you already use (don’t create a new one)
- → Simple text file with the date in its name
- → Weekly: promote the best into a playbook
- → Monthly: review and archive what’s irrelevant
💡 The freshness window
The context starts to degrade within hours. What seems obvious now ("of course it worked because I used that angle...") is gone by tomorrow. The 5 minutes at the end of the day are the only reliable window to capture what matters.
Module 4.1 Summary
- ✓ Unrecorded knowledge evaporated — it’s not a memory failure, it’s a system failure.
- ✓ Record what can be reused: 3+ similar runs = playbook. Fewer than that, and it’s still an emerging pattern.
- ✓ DEEBC structure: the anatomy behind any high-performing content.
- ✓ Reverse engineering in 5 steps—applicable today to any recent success.
- ✓ 1-page playbook: the size constraint is what ensures it stays in use.
- ✓ Metrics stated in advance, not made up afterward.
- ✓ 5-minute daily routine: fresh context, consistent capture.
📦 Module deliverable:
Choose a process you already do with AI (summarize meetings, write emails, create posts). Use the template from topic 5, fill in the 7 fields, and name it with a version. This is your playbook 1.0.
Next Module:
In 4.2, you organize these playbooks into a Living Library — with a system for naming, versioning, and curation, plus the latecomer’s shortcut to start with 3 items and grow sustainably.