Do not force every note into one template or promise to keep every note forever. Choose the note type by its job.
Use capture notes for temporary intake, course notes for one class context, concept notes for reusable understanding, project notes for active state and decisions, and reflection notes for evidence-based review. When a project note contains a verified instruction other people or future you must follow, promote it into maintained project documentation.
A note type defines a job and lifecycle
Two notes can contain similar sentences while serving different purposes.
“The program expects input in data/raw” might be:
- an unverified observation in a capture note;
- an instructor statement in a course note;
- an explanation of relative paths in a concept note;
- a current constraint in a project note; or
- a lesson about a failed setup in a reflection note.
The type tells you what context, evidence, review, and future action the note needs. It does not require five applications or five complicated folder trees. A heading or property can be enough.
Capture notes: collect now, decide soon
A capture note records information before you know its final value:
- a question during lecture;
- a task mentioned in conversation;
- a source to evaluate;
- an error to investigate; or
- an idea that should not interrupt current work.
Keep capture fast. Record enough context to make the item understandable:
- Check whether the lab requires CSV or XLSX.
Source: instructor comment in class, 2026-08-28
Next action: confirm in the assignment instructions
A capture inbox is temporary. Review it on a defined schedule. Convert the item into a task, another note type, or delete it. An inbox that only accumulates becomes another place to search.
Course notes: preserve the class context
Course notes support one course, lecture, reading, or assignment. Include:
- date and topic;
- source or instructor context;
- definitions and examples;
- questions to resolve;
- links to assignments or readings; and
- corrections after review.
Do not rewrite every lecture into permanent prose. Course notes can remain contextual and incomplete as long as they support learning and attribution.
Separate your interpretation from a source:
Instructor claim: Submit the workbook, not a CSV export.
My interpretation: Formulas and the second sheet are part of the assessed work.
Verification: Assignment instructions, "Submission format."
This prevents a remembered inference from becoming an unattributed rule.
Concept notes: explain reusable understanding
A concept note answers a question likely to matter beyond one class session:
- What is standard output?
- How does a relative path depend on the current directory?
- Why is a CSV export different from a workbook?
Write it in your own words after checking the source. Include:
- a clear concept or question;
- a concise explanation;
- one example;
- important limits or exceptions;
- source attribution; and
- links back to course or project contexts.
Do not create a permanent concept note for every vocabulary word. Promote a course idea when it recurs, connects to existing understanding, or supports future work.
Project notes: maintain active state and decisions
Project notes answer operational questions:
- What are we trying to build?
- What is the current state?
- Which decisions and constraints apply?
- What remains unresolved?
- What should happen next?
Useful project notes include a working log, decision record, issue note, design sketch, or meeting summary.
Project notes can contain uncertainty:
Hypothesis: The test fails because the fixture uses the old filename.
Next check: Compare the fixture path with the current data directory.
Do not copy the hypothesis into setup instructions. First verify it.
Reflection notes: review evidence and adjust
A reflection note examines what happened and what should change:
- Which study method produced usable recall?
- Where did a project process fail?
- Which tool added more maintenance than value?
- What should be repeated, stopped, or tested next?
Ground reflection in evidence:
Observation: I spent 35 minutes recreating the environment because the README
omitted the required data directory.
Decision: Add the directory creation step after reproducing it on a clean copy.
Next review: At the next project setup.
Reflection is not a requirement to write a motivational diary. A short record of evidence, interpretation, and next experiment is enough.
Promote verified knowledge into documentation
Notes support thinking. Documentation supports reliable action.
Promote a project discovery when it is:
- verified;
- likely to recur;
- needed by another person or future session;
- stable enough to maintain; and
- assigned to a canonical project location.
Examples:
| Note discovery | Durable destination |
|---|---|
| Confirmed setup sequence | Project README |
| Required contribution rule | Contributor guide |
| Repeated command | Script or task definition |
| Expected behavior | Automated test |
| Recovery procedure | Recovery documentation |
Do not erase the original project note. Link it to the new documentation so the decision history remains available. Update the maintained documentation when the process changes.
Use the note-type guide
Do I need to record this before deciding what it is?
└─ Capture note
Does it depend on a particular course, lecture, or assignment?
└─ Course note
Am I explaining reusable understanding in my own words?
└─ Concept note
Does it track active project state, decisions, or next actions?
└─ Project note
Am I evaluating evidence to change future behavior?
└─ Reflection note
One note can change type. A capture item can become a course question. A verified course explanation can become a concept note. A confirmed project note can become documentation.
Prefer moving or linking over uncontrolled copying. If several copies claim to be authoritative, they will eventually disagree.
Classify five notes
Choose five existing notes. For each, record:
Current note:
Type:
Job:
Source or evidence:
Next action:
Review or disposal date:
Canonical destination:
Possible actions:
- delete a capture item that no longer matters;
- attach a course note to its source;
- revise a concept note with an example;
- give a project note a next action; or
- turn a reflection into one testable change.
Then find one verified project instruction. Promote it into the relevant README or documentation and link back to the note.
Common mistakes
- Using one permanent template for everything. Match structure to purpose.
- Keeping every capture. Review, route, or delete it.
- Removing course context. Preserve source and assignment boundaries.
- Calling copied text a concept note. Explain and attribute it.
- Putting unverified hypotheses in documentation. Test first.
- Reflecting without evidence. Name the observation behind the decision.
- Duplicating an authoritative instruction. Maintain one canonical version.
- Storing private material in an unapproved service. Follow course and institutional rules.
Do this now
Classify five notes and complete one lifecycle action for each. Promote one verified project instruction to documentation. Do not reorganize the entire note system.
Log what you learned
Record only:
- Result: What did the action produce?
- Evidence: What observation, test, or source supports that result?
- Next action or unresolved question: What should happen next?
Next, use these requirements to decide whether Obsidian or Notion fits the work.