What does it mean that externalize your system itself?

Document your process for managing knowledge — not just the knowledge itself. Your system should be explicit enough that you could rebuild it from documentation alone.

Example: A software engineer keeps a Zettelkasten for technical notes, a task manager for projects, and a reading log for books. But none of these tools document how she decides what goes where, what her weekly review looks like, or what triggers her to archive versus delete. When her laptop dies, she recovers the data from backups — but spends three months recreating the invisible workflows that made the data useful. The knowledge survived. The system didn't.

Try this: Open a blank document titled 'How My System Works.' Write answers to these five questions: (1) Where does new information enter my system? (2) How do I decide what to keep versus discard? (3) What does my review cadence look like — daily, weekly, monthly? (4) How do I find something I captured three months ago? (5) When did I last change how my system works, and why? If you cannot answer any of these from memory, that is the gap this lesson addresses. The goal is a document that would let a motivated stranger — or your future self after a disruption — reconstruct your operating procedures.