The official Todd Michael Gori collectionIndependent mind · original work

2026-10-30 · By

A Retrieval Log for Projects You Cannot Keep in Your Head

When a project spans many tools, notes and decisions, a simple written log that asks you to recall before you look can reveal which parts of the system you actually understand.

Built by Blueprint: The Todd Michael Story of Reinvention, Systems, AI, Business, and the Next Machine — book cover
Explore Built by Blueprint

Why a Project Needs a Memory Test

Learning research describes retrieval practice as trying to recall material from memory before checking the source, then checking notes to correct gaps and misunderstandings. The same habit can work for a working project. When a system grows across several tools, drafts and decisions, it is easy to feel informed because the material looks familiar. Trying to recall the structure first shows whether the familiarity is real. This is an original application of that idea to project management, offered as a practical suggestion rather than a method the authors prescribe for projects.

A Worked Example

Imagine a hypothetical owner who runs a small publishing site with a book, a daily article feed and an email list. Each Monday, before opening any dashboard, they write three lines from memory: what is publishing this week, what feeds the email list, and which item has been stalled longest. They then check their actual notes and record mismatches. In one week they might discover they believed the email list updated daily when it updated only on Fridays. The log does not fix the schedule. It makes the gap visible so the owner can decide whether to change the schedule or the belief. Spacing the check across several weeks, rather than doing one long review, also keeps older parts of the system in view, which matches the research point that spaced study can revisit older material as well as the newest topic.

A Small Exercise for You

Take one project you are responsible for. Without looking, write the three things it depends on, the one decision you made last month that still shapes it, and the step you would take next. Then open your notes and compare. Write each mismatch as a single sentence starting with the words the notes say, not the words you remembered. Keep the log for two weeks. Count how many mismatches you find in week one and in week two. A falling count suggests your memory of the system is stabilizing; a flat count suggests the notes themselves need cleaning up.

Checklist and Limits

Use this checklist once a week: Write your recall before opening any source. Limit the recall to a few lines so it stays honest. Check notes only after writing. Record each mismatch in plain words. Decide whether the fix belongs in the project or in your memory. Revisit an older part of the project, not only the newest one. This approach has limits. It is a self-assessment tool, not a measure of project quality, and it cannot tell you whether the underlying plan is sound. It works best for personal tracking of your own systems and is not a substitute for review by collaborators or specialists when stakes are high.