Build Your AI-Powered Second Brain

Knowledge Systems and the Principles Behind Them

What a second brain actually is

Strip away the mystique and a second brain is simple: a small, organized collection of plain-text documents that describe your work, your knowledge, and your preferences, written so that both you and an AI can use them.

That definition has four parts worth reading slowly:

• Small. A working system for a busy professional is typically 10 to 30 files. Anything larger has stopped being a system and started being an archive.
• Organized. Each file has one subject and one place. You can find any fact in under ten seconds.
• Plain text. Files any program can open, now and in twenty years. No proprietary format, no app dependency.
• Written for two readers. Future you, and an AI that knows nothing except what the file says.

Where the idea comes from

Personal knowledge management is an old discipline, and it helps to know the lineage, because every modern method is a variation on a few durable ideas.

The slip box. The sociologist Niklas Luhmann kept a card index of roughly 90,000 notes across his career and credited it as a thinking partner. Two of his practices survive in every good system since: each note held one idea, and notes were linked to each other so that retrieval followed connections rather than folders.

Evergreen notes. Later practitioners refined the slip box into a rule about how notes are written: a note should be atomic (one idea), densely linked, and written in a form that stays true as your understanding grows. A note you have to rewrite from scratch every time you learn something was not written well the first time.

Capture, organize, distill, express. Contemporary productivity methods added a workflow on top of the note-writing rules: capture what resonates, organize by when you will act on it, distill toward the essence, and express by producing something. The ordering principle in the best-known version is actionability: what you are working on now goes at the front, what you are responsible for goes next, what you might use someday goes further back, and what is finished goes into an archive.

What AI changes. None of the above assumed a reader other than you. The classic payoff of a knowledge system was that you could find things. The AI-era payoff is different: a well-kept system becomes the context that makes every AI interaction smarter. The same note that once saved you a search now shapes what an assistant writes, recommends, and remembers on your behalf.

This course takes one idea from each tradition: one subject per file from the slip box, write-to-last from evergreen notes, actionability from the modern workflow, and a new one that none of them needed: write for an AI reader.

Cognitive offloading, and why it is not cheating

Researchers who study memory describe a behavior called cognitive offloading: using the external world (a notebook, a calendar, a colleague, a device) to reduce the load on internal memory. Two findings from that research matter here.

First, offloading works. People who store information externally free attention for reasoning and judgment, which is where professionals earn their keep.

Second, offloading changes what you remember. When you know something is stored, you remember where it is rather than what it says. That is fine when the store is reliable and dangerous when it is not, because a stale note you trust is worse than no note at all.

The design implication runs through this whole course: the system must be trustworthy, which means it must be small enough to maintain and maintained often enough to trust. Every rule about capture, structure, and review below exists to protect that trust.

The context gap

Ask any AI assistant to "draft an email to my team about the project delay" and you get a competent, generic email. It reads like it was written for someone else, because it was. The AI knows nothing about your team, your project, the reason for the delay, or how you write.

Now imagine the same request from an assistant that already knows your role, the project's history, the decision that caused the delay, and the tone you use with your team. The output changes completely. Same model. Same prompt. Different context.

This is the context gap: the distance between what an AI model can do and what it knows about you. Model capability keeps improving on its own. Context is the part only you can supply.

The gap shows up in predictable ways:

Each row is a file in your system. That mapping is the whole design.

Why memory features are not enough

Most AI tools now offer some form of built-in memory. Useful, and this course encourages you to use it. It is limited in four specific ways:

• It is trapped in one tool. Switch assistants, or use two at once, and the memory does not follow you.
• You do not fully control it. The tool decides what to remember and how to phrase it. You can often view and delete entries, but you cannot easily rewrite them into the form you want an AI to read.
• It captures conversations, not knowledge. Your best thinking happens in meetings, documents, and decisions that never pass through a chat window.
• It does not version. When a fact changes, the tool may keep the old and new versions side by side, and you will not know which one it is applying.

A second brain solves all four problems by putting the knowledge in files you own. Any AI can read a text file. That single fact is what makes this system tool-agnostic and durable.

Think of it as a master and a cache. Your files are the master copy. Any tool's memory, custom instructions, or project space is a cache you load from the master and refresh when the master changes. Module 5 covers how to keep the two in sync.

The five principles of an effective system

Every design choice in this course follows from these principles. When you face a judgment call later, come back to them.

1. Capture what matters, ignore the rest. More is worse. A lean system you trust beats an archive you avoid. Every file you add is a file you must maintain, so the bar for entry is high. Counter-example: a folder of two hundred saved articles is not a knowledge system. It is a reading list you feel guilty about.

2. Write for retrieval. Every note is written so it can be found and used later, by you or by an AI. That means descriptive file names, front-loaded summaries, and full sentences with the nouns filled in. Counter-example: a note titled "Meeting" containing "discussed the thing with S., follow up next wk."

3. One file per subject. A fact lives in exactly one place. When it changes, there is exactly one place to update. This rule prevents the contradictions that make systems untrustworthy. Counter-example: a project's budget stated in the project file, the identity file, and two meeting notes, each with a different number.

4. Own the storage. Plain text files in a folder you control. No dependence on any one app or vendor. Counter-example: a system built entirely inside one tool's memory feature, which vanishes when you change tools or the vendor changes its policy.

5. Compound the value. Every interaction that teaches the system something makes the next interaction better. The mechanism is simple: when AI output is wrong because a file is wrong or missing, fix the file rather than the output. Counter-example: correcting the same voice problem in every draft for a year instead of once in the identity file.

The capture test

Principle one needs a working definition of "what matters." Before anything enters your system, it must pass at least one of these questions:

1. Will I act on this? It connects to a current project or decision.
2. Will I reuse this? It is something I explain, send, or look up repeatedly.
3. Does this change how AI should help me? It is a preference, a constraint, or a fact about my situation that would improve AI output if the AI knew it.

Question three is what makes this an AI-powered system rather than a filing cabinet. A note about your communication style fails the first two tests and passes the third. It belongs in your system.

Apply the test to a few common candidates:

The four knowledge types

Everything worth capturing falls into one of four types. Knowing the type tells you where it goes, how it is written, and how long it lives.

1. Identity knowledge (changes slowly) Who you are, what you do, how you work, how you communicate. Your role, your responsibilities, your writing voice, your recurring stakeholders, your standing constraints. This is the highest-leverage content in your entire system because it applies to nearly every AI interaction. Review monthly. Rewrite rarely.

2. Project knowledge (changes weekly) Active work with an end date. Status, goals, constraints, open questions, key people. Project knowledge is born, lives intensely, then gets archived when the project ends. The status line is the most volatile line in your whole system and the one most likely to go stale.

3. Reference knowledge (changes rarely) Facts, frameworks, and materials you return to. Definitions your industry uses, a pricing model, a process you follow, standards you must comply with, a template you reuse. Capture the version you actually use, not everything that exists on the topic. Reference notes are the ones most tempting to over-collect, and the capture test applies with full force.

4. Decision knowledge (accumulates forever) What you decided, when, and why. This is the most undervalued type. Six months from now, "why did we choose vendor A" is a question only your decision log can answer instantly. Decisions also teach AI your reasoning patterns, which sharpens its advice, and they let AI flag when a new choice contradicts an old one.

A fifth category sometimes appears in practice: people knowledge, meaning working relationships with specific individuals. This course treats it as a sub-type of identity knowledge that gets its own file when a relationship is important enough. Keep people files to working context (role, what you collaborate on, how you communicate, what they care about). They are relationship notes, not dossiers, and your organization's expectations about recording information on colleagues apply.

Common anti-patterns to avoid from day one

• The everything folder. Capturing without the test. Fix: apply the three questions before saving anything.
• The dead project file. Status last updated four months ago, still in the active folder. Fix: weekly review, archive on completion.
• The private shorthand. Notes only you can decode ("S. ok'd it, Q3 thing"). Fix: write for the AI reader, which forces full sentences.
• The duplicate fact. Same information in three files, two of them stale. Fix: one file per subject, and link rather than copy.
• The tool-first build. Setting up an elaborate app before there is content to put in it. Fix: plain text first, tooling last (Module 5).

Check your understanding

Before moving on, answer these for yourself:

1. What is the context gap, in your own words, and which file in your system would close it for the AI task you do most often?
2. Why is a file you own more durable than a memory feature inside one AI tool?
3. Which of the four knowledge types applies to nearly every AI interaction, and why?
4. Which of the five principles does a folder of saved articles violate?

How a Well-Designed System Improves AI Outputs and Workflows

The compounding effect

A knowledge system compounds the way savings do.

Week one, your AI drafts an email using your identity file and sounds roughly like you. Month two, it drafts the email, references the correct project status, and anticipates a stakeholder concern you logged three weeks ago. Month six, you ask "what did we decide about the vendor contract and why," and get an accurate answer in seconds instead of digging through email for twenty minutes.

None of that requires better AI. It requires that your context accumulated. The practical experience of people who work heavily with AI tools keeps landing on the same conclusion: output quality depends less on which model you use and more on what contextual information the model receives, and how well it is organized. The discipline of assembling that information deliberately now has a name in technical circles, context engineering, and your second brain is the personal version of it.

The core move behind everything

Every workflow in this course follows the same two-beat pattern:

Beat 1, load context: Give the AI the relevant files. Paste them, attach them, or point your tool at the folder if it supports that. Beat 2, give the task: Make your request, referencing the context.

Ten seconds of setup changes everything downstream. The order matters: context before task. Models weight what they read early, and a request that arrives before its context tends to get answered generically, with the context treated as an afterthought.

Three refinements to the basic move:

• Load only what the task needs. Identity and preferences for anything substantive. Project files only for project work. Loading everything every time dilutes attention and slows the tool.
• Tell the AI what the files are. A one-line frame ("The following is my identity file describing how I work and communicate") helps the model use the content correctly.
• Tell it what to do when the files are silent. "If you need a fact I have not provided, say so rather than inventing it." This single instruction prevents most fabricated specifics.

Where the improvement shows up

A working system changes four everyday workflows. You will practice all four in Module 4. Here is what each looks like once the system is feeding it, with a before-and-after sketch for each.

1. Drafting. AI output starts in your voice, with your context, so you edit instead of rewriting. The gap between first draft and final version shrinks every week, because every correction you feed back into the system applies to all future drafts.

Without the system: "Dear Team, I hope this message finds you well. I wanted to provide an update regarding the timeline for our project..."

With identity.md loaded (voice: "direct, ask first, context after, no filler openers"): "Go-live moves from March 31 to May 12. Cause: a data-mapping error affecting about 15 percent of records. One decision I need from you by Friday is below."

2. Meeting preparation. Instead of skimming old notes before a meeting, you ask your system what is unresolved, what was last decided, and what the other person is likely to raise. Prep drops from twenty minutes to five.

Without the system: You reread three email threads and still miss the open question from two weeks ago.

With the project file and a people file loaded: "Three things to raise: the unresolved vendor SLA question from the 9/2 review, the training dates decision, and the budget variance. Based on her file, she is likely to push on the training dates, which she flagged as a risk on 8/20."

3. Decision support. With your decision log loaded, AI advice reflects your actual constraints and your past reasoning instead of generic best practice. It can also flag when a current choice contradicts an earlier one.

Without the system: A balanced list of pros and cons that could apply to any organization.

With decisions.md loaded: "You chose Vendor A in August specifically because it met the compliance requirement under budget. Option B here fails the same requirement. Unless the requirement changed, this choice contradicts that decision."

4. Recall. Questions like "why did we choose this vendor" or "what is the status of every active project" get answered from your files in seconds, accurately, with the reasoning attached.

Without the system: Twenty minutes of searching, and an answer you are not sure of.

With the system: "Chosen 2026-08-09. Reason: only option meeting compliance requirements under budget; Vendor B quoted 40 percent higher. Revisit if Vendor B drops pricing or requirements change in the 2027 review."

What the system does not fix

Be clear about the limits, because knowing them keeps your trust calibrated.

• It does not make AI output correct. It makes output relevant. Verify anything factual before it leaves your hands, especially names, numbers, dates, and claims about what other people said or decided. AI inserts plausible specifics with complete confidence.
• It does not replace your judgment. The system supplies context. You supply judgment. That division of labor never changes, no matter how good the tools get.
• It does not read your mind. If a preference or constraint is not written down, the AI does not have it. The most common cause of a disappointing output is a missing line in a file, which is good news, because a missing line is a thirty-second fix.
• It does not maintain itself. A stale system produces confident, wrong output. Module 4 covers the routine.

A note on judgment and verification

Build a personal verification habit now, before the system makes AI output convincing enough to skip it:

1. Any number, date, or name in AI output gets checked against the source file or the real world before it goes anywhere.
2. Any claim about what another person said, decided, or agreed to gets confirmed before you repeat it.
3. Any recommendation gets the question "what would have to be true for this to be wrong?" before you act on it.

The system makes AI faster. The habit keeps it safe.

Build Your Second Brain with Your Own Notes, Documents, and Ideas

This is the core build module. By the end you will have the full skeleton of your second brain plus its most important files, populated with your real work, and a worked example to compare against.

Step 1: Inventory your raw material (8 minutes)

Open a blank note. Set a timer and list, fast and rough:

1. Identity: Your role, your top three responsibilities, the five people you interact with most, three phrases that describe how you like to communicate, and any constraint that shapes most of your decisions (a budget rule, a regulation, an approval chain).
2. Projects: Every active project or major commitment. One line each: name, goal, current status, next milestone.
3. Reference: Three to five things you look up or explain repeatedly.
4. Decisions: The last three significant decisions you made at work, each with a one-line reason and what would make you reconsider.
5. People: Two or three working relationships where re-explaining the context to an AI would be tedious.

Do not polish. This inventory becomes your actual files in Step 5.

Step 2: Know what to exclude

Keep these out of your system:

• Anything you can search for in seconds. General facts, public information, definitions the AI already knows. The exception is when your organization uses a term differently from the general definition; that difference is reference knowledge.
• Raw material without a purpose. Full meeting transcripts, entire articles, complete email threads. Capture the extract: the decision, the action, the insight. Link to the source if you must.
• Sensitive data that does not belong in AI conversations. Passwords, financial account details, other people's private information, health or personal details about colleagues, anything covered by confidentiality rules at your workplace. Your system will be pasted into AI tools regularly. Only put in it what you are comfortable sharing there, and know your employer's policy on what may be shared with AI tools at all.
• Stale duplicates. One current version of a fact, not five historical ones. History lives in the decision log, not in contradictory copies.
• Judgments about people. "Difficult to work with" in a people file helps no one and creates risk. "Prefers written proposals before meetings and pushes back on timelines" is useful working context.

Step 3: The extraction skill

The skill behind good capture is extraction. You do not capture the meeting. You capture the three sentences that matter from the meeting:

Decided to delay launch to March 15 due to compliance review. Sam Rivera owns the revised timeline. Open question: does the delay affect the Q2 pricing announcement?

That is a complete capture. It passes the capture test, it is written for retrieval, and it is small enough to maintain.

The extraction shape is always the same: decisions, actions with owners, open questions. Anything that does not fit one of those three is usually context you can leave behind.

AI can do the first pass for you. Paste raw notes into your assistant and use:

Extract from these notes, in three short bullet lists:
1. Decisions made (what was decided, by whom, and the
   stated reason if one was given)
2. Action items (what, who owns it, due when)
3. Open questions (what is unresolved and who needs to
   answer it)
Use full names and roles where the notes give them.
If a decision, owner, or date is not stated, write
"not stated" rather than guessing.

Store the extract. Discard or archive the transcript. Then check the extract against your own memory of the meeting, because the AI will occasionally promote a suggestion to a decision or invent an owner for an unowned action.

Step 4: The structure

Your system is one folder with four subfolders and a handful of files at the top level. That is the whole architecture.

Second Brain/
├── identity.md          ← who you are, how you work
├── preferences.md       ← how AI should behave for you
├── decisions.md         ← running log of decisions
├── projects/
│   ├── project-name.md  ← one file per active project
├── reference/
│   ├── topic-name.md    ← one file per recurring topic
├── people/
│   ├── person-name.md   ← one file per key working relationship
└── archive/
    └── (completed projects and retired notes move here)

Why this shape works:

• One file per subject, applying principle three from Module 1.
• Flat and shallow. No folders inside folders inside folders. If you cannot decide where something goes in five seconds, the structure is too complicated.
• Plain text, plain names. q3-vendor-selection.md beats Q3 Stuff (final) v2. Name files with the words you would use to search for them. Lowercase with hyphens is the most portable convention.
• Archive, do not delete. Finished projects move to the archive folder. They stop cluttering your active system but remain searchable when an old question resurfaces.

Optional additions once the core is working (Module 5 covers when): a wins.md log at the top level, and a templates/ folder inside reference/.

Writing for two readers

Every file in your system has two readers: future you, and an AI with no context beyond what the file says. Writing for both takes five habits:

1. Front-load the summary. The first three lines of any file should let a reader know what it covers and its current state.
2. Use descriptive headers. "Open questions" and "Key stakeholders" retrieve better than "Misc" and "Notes."
3. State facts fully. Write "Sam Rivera (VP Finance) approved the budget on June 3" rather than "Sam approved it." The AI does not know who Sam is or what "it" refers to. Neither will you in a year.
4. Date what changes. Status lines and decisions get dates. Undated status information becomes misinformation within weeks.
5. Mark what is uncertain. "Tentative," "unconfirmed," or "as of 9/10" tells both readers how much to trust a line. An AI that reads an unmarked guess as a fact will build on it confidently.

A useful test before you save any file: could a competent new hire, reading only this file, act on it correctly? If they would need to ask you a question, write the answer into the file.

The templates

File 1: identity.md

This file does more work than any other because it applies to every AI interaction you will ever have.

# Identity

## Who I am
[Name, role, organization type, one line on what the
organization does, how long you have been in the role]

## What I am responsible for
[3 to 5 bullets covering your core responsibilities.
Include anything you own that is outside your formal
title, because AI will otherwise assume your title
is the whole job.]

## Who I work with
[Key people: name, role, and one line on the working
relationship. Include how formally you communicate
with each. Link to a people file where one exists.]

## How I communicate
[Your voice, described concretely. Examples: "Direct
and brief. I open emails with the ask, then context."
"I avoid jargon with clients but use it freely with my
technical team." Include words or constructions you
never use, and a sentence or two of your actual writing
as a sample.]

## My current priorities
[3 to 5 bullets, revisited monthly. Date this section.]

## Constraints that shape my work
[Regulatory requirements, approval chains, budget
realities, tools you must or must not use, policies on
AI use and data sharing]

## My expertise and my gaps
[What you know deeply, so AI stops explaining it to
you. What you are learning, so AI explains it fully.]

The last section is the one most templates omit and one of the most valuable. An AI that knows you are an expert in your field skips the basics and spends its output on what you actually need.

File 2: preferences.md

Where identity.md describes you, preferences.md instructs the AI.

# AI Preferences

## Output style
[Length, tone, formatting. Example: "Default to short.
Use headers and bullets for anything over three
paragraphs. Never use hype language. No filler
openers."]

## Always
[Standing instructions. Example: "Always flag
assumptions you are making. Always give me the
reasoning, not just the recommendation. Always say
when you need a fact I have not provided."]

## Never
[Hard rules. Example: "Never invent statistics, names,
or quotes. Never draft anything for external audiences
without marking it as a draft. Never use these words:
[list]."]

## Defaults
[Recurring specifics: date format, currency, spelling
convention, time zone, units, templates to follow]

## How to disagree with me
[Example: "If you think my plan has a flaw, say so
before drafting, and say what you would do instead."]

One honest warning: keep the "Always" and "Never" sections pointed at style and format, not at judgment. An instruction like "never disagree with my plans" makes every AI tool less useful to you, because the disagreements are frequently the value. The "How to disagree with me" section exists to make the opposite explicit.

File 3: project files

One file per active project:

# [Project Name]

**Status:** [One line. Date it.]
**Goal:** [What done looks like, in observable terms]
**Next milestone:** [What and when]

## Key people
[Who is involved, their role in this project, and
what each one cares about most]

## Current state
[3 to 6 bullets on where things stand. Date each.]

## Decisions made
[Decision, date, one-line reason. Or link to your
main decision log.]

## Open questions
[What is unresolved, and who needs to resolve it]

## Constraints
[Deadlines, budget, dependencies, requirements]

## Risks
[What could derail this, and the earliest sign
you would see]

File 4: decisions.md

A single running file, newest entries on top. Each entry is three lines:

## 2026-08-09: Chose Vendor A for scheduling platform
**Why:** Only option meeting our compliance requirements
under budget. Vendor B quoted 40% higher.
**Revisit if:** Vendor B drops pricing or our compliance
requirements change in the 2027 review.

The "revisit if" line is the professional touch most people miss. It converts a static record into a standing alert you can hand to an AI: "Review my decision log against this news and flag anything I should revisit."

Log decisions you made, decisions you influenced, and decisions made over your objection (with your objection noted). The third category is the one you will most want six months later.

File 5: people files

One file per key working relationship. Keep it to working context.

# [Name]

**Role:** [Title, team, relationship to you]
**We work together on:** [Projects, recurring topics]

## Working style
[How they prefer to receive information, decide,
and communicate. Formality level between you.]

## What they care about
[Their priorities and pressures, as they have stated
them]

## History
[Dated notes on significant interactions: what was
raised, what was agreed, what was pushed back on]

## Open items between us
[What is pending, who owes what]

File 6: reference notes

One per recurring topic. No fixed template, but every reference note should open with what it is, when you use it, and when it was last verified.

# [Topic]

**What this is:** [One line]
**When I use it:** [The recurring situation]
**Last verified:** [Date]

[The content, in the form you actually use it:
a definition, a process, a checklist, a template,
a list of standards]

Worked example: a populated identity file

Here is an identity file for a fictional professional, so you can see what "rough and real" looks like at full length. Notice that it is specific enough to change AI output and short enough to read in a minute.

# Identity

## Who I am
Maya Chen, Director of Operations at Northgate Community
Health, a nonprofit network of six primary care clinics
serving about 40,000 patients. In the role three years.

## What I am responsible for
- Clinic operations: staffing, scheduling, and
  facilities across all six sites
- Vendor management for the scheduling and telehealth
  platforms
- Annual operating budget (about $12M) and the
  quarterly reforecast
- Compliance readiness for our state clinic licensure
  survey
- AI tool governance for non-clinical staff (informal
  ownership, not in my title)

## Who I work with
- Dr. Priya Nair, Chief Medical Officer. Peer. Formal in
  writing, informal in person. Cares about clinician
  time above all.
- Sam Rivera, VP Finance. Approves anything over $25K.
  Wants two quotes and a one-page rationale.
- Six clinic managers, weekly call. Direct reports.
  Casual tone, first names.
- Board Operations Committee, quarterly. Formal.
  Expects a one-page summary before the deck.

## How I communicate
Direct and brief. I open with the decision or the ask,
then give context. I use headers for anything over
three paragraphs. I never use "I hope this finds you
well," "circle back," "synergy," or exclamation points
in work email. Sample of my writing: "Telehealth vendor
decision is due Friday. Two options left. I recommend
Option A; details below."

## My current priorities (as of 2026-09-01)
- Close the telehealth vendor selection by 9/30
- Reduce no-show rate from 18% to 14% by year end
- Prepare all six sites for the licensure survey
  window (Nov to Jan)

## Constraints that shape my work
- Purchases over $25K need Sam's sign-off and two quotes
- Any patient-facing change needs Dr. Nair's review
- We cannot share patient data with AI tools; operational
  data is fine when de-identified
- Board sees only summarized numbers, never raw data

## My expertise and my gaps
Deep: clinic operations, staffing models, state
licensure requirements. Skip the basics on these.
Learning: vendor contract negotiation, AI governance.
Explain these fully.

Every section of that file would change an AI draft. The constraints section alone prevents three categories of unusable output.

Step 5: Exercise 3, build the system (40 minutes)

Using your Step 1 inventory and your Module 2 workflow map:

1. Create the folder structure shown above. (2 minutes)
2. Write identity.md. Use the template and the worked example as a model. Rough and real beats polished and vague. Include the expertise-and-gaps section. (12 minutes)
3. Write preferences.md. Even five bullets is a working start. Include one line under "How to disagree with me." (5 minutes)
4. Create one project file for the project most connected to your high-value workflows. Fill the status, goal, next milestone, key people, and open questions at minimum. (8 minutes)
5. Start decisions.md with the most recent significant decision from your inventory, including its "revisit if" line. Add a second entry if one comes easily. (4 minutes)
6. Create one people file for the relationship from your inventory where AI most needs context. (5 minutes)
7. Add one reference note for the thing you explain most often. (4 minutes)

Shortcut if you are staring at a blank page: paste the template plus your rough inventory into your AI assistant and ask it to draft the file, then correct what it gets wrong. The corrections are where the real context lives. Use this framing:

Here is a template for my [identity / project / people]
file and my rough notes. Draft the file using only what
the notes contain. Where the template asks for something
my notes do not cover, write [NEEDED: description]
rather than inventing content. Do not embellish.

Then read the draft aloud. Every place you stop and think "that is not quite right" is a line to rewrite by hand.

Practice Organizing, Querying, and Retrieving

Your system exists. This module is deliberate practice in the three operations that make it pay: loading the right context, querying it, and keeping it organized so retrieval stays sharp.

Which files to load

The core move from Module 2 was context first, then task. Which files to load follows from the task:

Loading identity.md and preferences.md at the start of any substantive session should become reflexive. If your tool supports standing context, Module 5 shows how to make that automatic.

A framing line that improves results across every task:

The files below are my personal context. Read them
before responding. Use them to match my voice, respect
my constraints, and reference my actual projects and
people. If you need a fact they do not contain, say so
rather than inventing one.

[paste files]

[Paste identity.md and preferences.md]

Draft an email to [person] about [topic]. Key points:
- [point]
- [point]
Match the communication style described in my identity
file. Put the ask in the first two lines.

Based only on my files:
1. What is the current status of [project] and what is
   the most urgent open question?
2. What did I decide about [topic], and what would
   trigger revisiting it?
3. What information in these files is missing, stale,
   internally contradictory, or vague enough that you
   had to guess?

Across my projects and decisions:
1. Which open questions are blocking more than one
   project?
2. Which decisions in my log affect more than one
   active project?
3. Where do my stated priorities and my active projects
   not line up?

[Paste project file + relevant people file]

I am meeting [person] about [project] tomorrow. Based on
the current state and open questions, what are the three
most important things to raise, what is [person] likely
to push back on given their file, and what is the one
decision I should try to leave the meeting with?

[Paste identity.md + project file + decisions.md]

I need to decide [decision]. Options are [A] and [B].
Given my constraints and how I have decided similar
things before, analyze both options. Check whether
either option contradicts a past decision in my log.
Argue against your own recommendation before
finalizing it.

[Paste identity.md + preferences.md + project file]

Draft a status update on [project] for [audience].
Use only facts from the project file. Structure:
status in one line, what changed since the last
update, what is at risk, what I need from the reader.
Mark anything you had to infer with [CHECK].

Keeping it organized: the maintenance routine

Retrieval quality decays exactly as fast as your files go stale. The routine that prevents it, measured in minutes:

In the moment (30 seconds): When AI output is wrong because a file is wrong, fix the file before moving on. This single habit outperforms any scheduled review.

After any meeting that matters (5 minutes): Extract, update the project file, date the people file.

Weekly (10 minutes): Run this review:

[Paste identity.md + all active project files + recent
decisions]

Review my system for this week:
1. Which status lines look stale or contradict each other?
2. Which open questions have sat unresolved longest?
3. Which decisions did I make this week that are not
   yet logged? (Check the project files for decisions
   mentioned in passing.)
4. Based on my stated priorities, what deserves my
   attention next week?

Update stale lines, log the week's decisions, and move anything finished to the archive. This turns maintenance from a chore into a briefing.

Monthly (15 minutes): Reread identity.md and preferences.md. Priorities drift, and these files must drift with them. Re-date the priorities section. Delete anything you no longer believe. Add any new constraint that appeared this month.

Quarterly (30 minutes): Prune. Archive dead projects. Merge redundant reference notes. Ask the AI: "Here is my full system. What looks outdated, duplicated, contradictory, or unclear? What would you need to know that is missing?"

Total steady-state cost: about 15 minutes a week.

Signs of health and signs of trouble

Healthy system:

• You reach for it without deciding to. Loading context becomes as automatic as opening your calendar.
• Files stay short. Growth shows up as better content and new files, not longer files.
• AI corrections get rarer, because corrections keep moving upstream into the files.
• Your decision log gets consulted, not just written.

Trouble, with the fix for each:

• You stop trusting it. Usually caused by stale status lines. Cure: one honest weekly review.
• Files bloat. A project file past two screens needs extraction, and old detail belongs in the archive.
• Capture stops. Usually means the capture bar is set too high. Lower it: rough one-line captures during the week, cleanup during the review.
• The same correction keeps recurring. The fix went into the output instead of the file. Find the file and write it in.
• You cannot find something. The file name does not match the words you searched for. Rename it with the words you actually used.

Scaling the System

The system works in plain text with copy and paste. This module covers how to make it faster to use, how to extend it beyond yourself, and how to keep it portable as tools change. The order matters: none of this is worth doing until the plain-text version has proven itself, which is why it comes after the practice module.

From files to standing context

Most AI tools offer a way to store context that applies automatically: custom instructions, a project space, a persistent memory, or a system-level preferences field. Use them, with one rule: the files are the master, the tool is a cache.

The practical workflow:

1. Paste the current contents of identity.md and preferences.md into the tool's standing context field.
2. Note the date you did so in a line at the top of preferences.md: "Loaded into [tool] on [date]."
3. When you edit either file, refresh the tool's copy. The monthly review is a natural time.
4. Project files stay out of standing context. Load them per task, because they change too often and apply too narrowly.

If your tool can read files directly from a folder, point it at your system folder and skip the paste. The master-and-cache rule still applies: edit the files, never the tool's internal copy.

Standing instructions worth saving

These lines belong in preferences.md and in your tool's custom instructions. Each one closes a specific failure mode.

- Read my identity and preferences files before any
  substantive task
- Never invent facts, figures, names, or quotes; write
  [NEEDED: description] where you lack a fact
- When my request conflicts with a constraint in my
  identity file, say so before proceeding
- When a new decision contradicts an entry in my
  decision log, flag it
- When you infer something about my situation that is
  not in my files, label it as an inference
- Default to shorter output; I will ask for more

Team and shared knowledge

A second brain is personal. Some of its contents are worth sharing, and the structure scales to a team with two adjustments.

What to share: reference notes (definitions, processes, standards) and project files for shared projects. These are the files where a single source of truth helps everyone.

What to keep personal: identity.md, preferences.md, people files, and your decision log. These describe you and your relationships, and sharing them creates both awkwardness and risk.

Two adjustments for shared files:

• Add an owner line at the top of each shared file. One person is responsible for keeping it current.
• Add a "last verified" date. A shared file without one becomes a shared rumor.

A team folder that holds only shared reference and project files, each with an owner and a date, gives every member's AI the same ground truth. That is the single most effective way to stop a team from getting five different AI-generated answers to the same question.

Portability and tool changes

The reason this course insists on plain text is that tools change. When you move from one AI assistant to another, or use several at once:

• Your files move with you unchanged.
• You re-paste identity.md and preferences.md into the new tool's standing context.
• Nothing is lost, because nothing lived only inside the old tool.

Test this now if you use more than one assistant: load the same files into a second tool and run the same request. The outputs will differ in style but should agree on your facts, your voice, and your constraints. Where they disagree on facts, the file is ambiguous and needs a rewrite.

When to add tooling, and in what order

Expand only when you feel a specific pain, in this order:

1. More people files, once you notice re-explaining working relationships to the AI.
2. A wins log (wins.md), a running file of accomplishments with dates and outcomes. Feeds performance reviews, resumes, and bios with zero extra effort at review time. Three-line entries: what, when, measurable result.
3. Templates, when you notice writing the same document type repeatedly. Store your best example in reference/templates/ and have the AI follow it.
4. Search tooling, when the folder passes about 40 files and finding things by name gets slow. Any plain-text search tool works.
5. Deeper tool integration, last. Once the system proves itself in plain text, connecting it to tools that read files automatically is easy, and everything transfers because you built on plain text.

The order matters. People add tooling first and content never catches up. Content is the system. Tools just read it.

Your 30-Day Plan

What you built today

Check each item you completed:

• System folder with the four-part structure
• identity.md describing who you are, how you work, and what you know
• preferences.md instructing AI on how to help you, including how to disagree
• At least one active project file, one people file, and one reference note
• decisions.md with your first logged decision and its "revisit if" line
• Baseline comparison proving the context difference
• At least two practiced workflows, one of them cross-file
• Recurring weekly review on your calendar
• identity.md and preferences.md loaded as standing context in your primary tool

If anything is unchecked, do it now. The whole list takes under 30 minutes and an incomplete system is the main predictor of an abandoned one.

The next 30 days

Days 1 to 7: Build the habit. Load identity.md and preferences.md at the start of every substantive AI session (or confirm the standing context is current). Fix files in the moment when output reveals gaps. Run your first weekly review. Target: five corrections moved upstream into files.

Days 8 to 14: Cover your active work. Create a file for every active project. Log every decision as it happens, including ones made over your objection. Capture meeting extracts within five minutes of each meeting that matters. Target: no active project without a file.

Days 15 to 21: Refine the voice and the constraints. Compare AI drafts to what you actually send. Each gap between draft and final version is a missing line in identity.md or preferences.md. Close three gaps this week. Add writing samples to the voice section if you have not.

Days 22 to 30: Evaluate and expand. Rerun the baseline test a third time and score it on the four questions from Practice 1. Run the quarterly-style prune early with AI help. Then expand only where you feel a specific pain, following the order in Module 5.

The one-month test

At day 30, ask yourself a single question: when I face a real task, do I reach for the system without thinking about it?

If yes, the system has crossed from project to practice, and from here it only compounds. If no, diagnose with the trouble signs in Module 4. The fix is almost always smaller than starting over.

A second, quieter test: open your decision log and read the oldest entry. If you had forgotten the reasoning and the log gave it back to you, the system is already doing the job that memory features cannot.

Final principle

Everything in this course reduces to one sentence: AI works from what it knows about you, and what it knows about you is now a set of files you own, control, and improve every week.

The model behind your AI assistant will change many times in the coming years. Your second brain will still be there, still in plain text, still yours, and more valuable than the day you built it.

Appendix A: Quick Reference

The five principles

Capture what matters. Write for retrieval. One file per subject. Own the storage. Compound the value.

The capture test

Capture only if: you will act on it, you will reuse it, or it changes how AI should help you.

The four knowledge types

Identity (slow-changing). Project (weekly). Reference (rare). Decision (accumulates).

The extraction shape

Decisions. Actions with owners. Open questions.

The core move

Load context first, then give the task. Default load: identity.md + preferences.md. Tell the AI what the files are and what to do when they are silent.

The five writing habits

Front-load the summary. Descriptive headers. State facts fully. Date what changes. Mark what is uncertain.

The maintenance schedule

Fix files in the moment. 5 minutes after meetings that matter. 10 minutes weekly. 15 minutes monthly. 30 minutes quarterly.

The master-and-cache rule

Files are the master. Any tool's memory or standing context is a cache. Edit the master, refresh the cache.

File templates

See Module 3 for identity.md, preferences.md, project files, decisions.md, people files, and reference notes.

Appendix B: Prompt Library

All prompts are tool-agnostic. Replace anything in [brackets]. Follow your organization's policy on what may be shared with AI tools.

The context frame (use before any task)

The files below are my personal context. Read them
before responding. Use them to match my voice, respect
my constraints, and reference my actual projects and
people. If you need a fact they do not contain, say so
rather than inventing one.

The extraction prompt

Extract from these notes, in three short bullet lists:
1. Decisions made (what, by whom, stated reason)
2. Action items (what, owner, due date)
3. Open questions (what is unresolved, who answers it)
Use full names and roles where given. Write "not stated"
rather than guessing.

The file drafter

Here is a template for my [file type] and my rough
notes. Draft the file using only what the notes contain.
Where the template asks for something my notes do not
cover, write [NEEDED: description]. Do not embellish.

The voice drafter

[identity.md + preferences.md]
Draft [message type] to [person] about [topic]. Key
points: [list]. Match the communication style in my
identity file. Put the ask in the first two lines.

The system query

Based only on my files:
1. What is the current status of [project] and the most
   urgent open question?
2. What did I decide about [topic] and what would trigger
   revisiting it?
3. What is missing, stale, contradictory, or vague enough
   that you had to guess?

The cross-file synthesis

Across my projects and decisions:
1. Which open questions block more than one project?
2. Which decisions affect more than one active project?
3. Where do my stated priorities and active projects not
   line up?

The meeting prep

[project file + people file]
I am meeting [person] about [project]. What are the three
most important things to raise, what will [person] likely
push back on, and what one decision should I leave with?

The decision support

[identity.md + project file + decisions.md]
I need to decide [decision]. Options: [A], [B]. Given my
constraints and past decisions, analyze both. Flag any
contradiction with my decision log. Argue against your
own recommendation before finalizing.

The weekly review

[identity.md + active project files + recent decisions]
1. Which status lines are stale or contradictory?
2. Which open questions have sat longest?
3. Which decisions this week are not yet logged?
4. Given my priorities, what deserves attention next week?

The quarterly prune

Here is my full system. What looks outdated, duplicated,
contradictory, or unclear? What would you need to know
about me or my work that is missing?

The decision-log alert

[decisions.md]
Here is some news / a proposed change: [paste]. Review my
decision log and flag any entry whose "revisit if"
condition this touches.