A student asks, “Should I use Obsidian, Notion, or OneNote?” The question sounds specific, but it begins too late. Each application solves a different set of problems. Before comparing tools, define the system you need.
A personal system charter is a short Markdown document that records desired outcomes, constraints, non-goals, ownership, and evidence of success. It gives future decisions a stable reference point.
If .md files or Markdown markers are new to you, read the
five-minute Markdown quick start
before continuing. It explains the source notation used in the example and
download below. You can return here without completing the full 30-minute
exercise.
Start from needs, not products
First-principles reasoning begins with facts and requirements that remain true even if a favorite tool disappears.
Compare these statements:
- “I need Obsidian” names a proposed solution.
- “I need searchable notes that I can read offline and export” names outcomes and constraints.
The second statement allows several valid solutions. It also gives you a basis for rejecting a product that looks appealing but requires constant internet access or makes export difficult.
The charter does not need to predict every future need. Its job is to make the current needs explicit.
Begin with a four-part charter
The first pass needs only the work to protect, what must be rebuildable, hard
constraints, and one current priority. Use unknown, not applicable, or
return later rather than inventing an answer.
Work to protect means hard-to-replace content, such as drafts, notes, or data. What must be rebuildable means replaceable tools and setup, such as required applications, settings, course add-ons, or project packages. Do not repeat the same files in both sections.
Extend the charter during later decisions
1. Desired outcomes
Describe what the system should make possible. Avoid feature lists.
Weak:
Use a powerful note-taking app with plugins and dashboards.
Stronger:
I can find current course notes in under two minutes and read them without an internet connection.
An outcome describes a result from the student’s perspective.
2. Constraints
Constraints define the solution space. Common constraints include:
- the computer and operating system already available;
- software required by a course;
- budget and subscription limits;
- privacy or institutional rules;
- accessibility requirements;
- internet reliability; and
- time available for setup and maintenance.
A constraint should be concrete when possible:
I can spend at most one hour each week maintaining the system.
This statement is more useful than “maintenance should be easy.”
3. Non-goals
A non-goal records complexity you are deliberately excluding. It is not a claim that the excluded idea is bad. It means the idea does not solve a current priority at an acceptable cost.
Examples:
- I will not maintain two systems for the same notes.
- I will not run a home server this semester.
- I will not automate a process I have not performed manually.
- I will not customize the terminal beyond changes I can explain and reverse.
Non-goals protect time and attention. Add reconsideration conditions when they are clear: “I will reconsider automation after I repeat the task four times.”
4. Evidence
Evidence turns an aspiration into a test.
| Outcome | Evidence |
|---|---|
| Important work is protected | Restore a test file to a different folder |
| Projects are reproducible | Set up one project from written instructions |
| Files are organized | Find a named assignment in under two minutes |
| The student owns the system | Explain and perform a routine update |
Use observable checks. “My system feels organized” may be sincere, but it does not reveal what failed or improved.
5. Ownership
State what the student should manage independently. Independence does not mean working without documentation or asking no questions. It means the student can perform the task, explain the important parts, verify the result, and respond to common errors.
For example:
By the end of the semester, I will organize course files, install a documented dependency, use basic Git, and restore a deleted test file.
6. Review date
The charter is a hypothesis about what you need. Experience will reveal missing constraints and unrealistic goals. Add a specific review date, such as two weeks after classes begin, and review it again after a major course or device change.
Revise the current charter, but preserve important decisions in the working log. The log explains why the charter changed.
A complete example
# Personal System Charter
Created: 2026-08-10
Next review: 2026-09-07
## Desired outcomes
- I can find current assignments and notes in under two minutes.
- Drafts, code, feedback, and submissions do not exist only on my laptop.
- I can rebuild the tools required for CS 101 from written instructions.
## Constraints
- I use Windows 11.
- One course requires Microsoft Excel.
- I will not add another paid subscription.
- Course data may not be uploaded to unapproved AI services.
- Routine maintenance must fit within one hour a week.
## Non-goals
- I will not run a server or maintain a second note system.
- I will not add an automation until I understand the manual process.
## Evidence
- Restore a test file from backup.
- Find a current assignment in under two minutes.
- Rebuild the CS 101 practice project from the README.
## Ownership
I will manage course folders, routine application updates, basic Git, and
documented project setup. I will ask for help with account recovery and hardware
repair.
The example names no preferred note application. A later tool proposal must earn its place by satisfying these statements.
Charter, log, and documentation have different jobs
- The charter states direction and tests.
- The working log records events, evidence, and decisions.
- Documentation and scripts preserve confirmed processes for reuse.
Suppose a restore test fails. Record the failure and investigation in the log. If you change the backup process, update the recovery documentation. Change the charter only if the desired outcome or constraint has changed.
Common mistakes
- Naming tools as outcomes. Ask what the tool is expected to make possible.
- Writing vague constraints. Add a measurable boundary where one exists.
- Listing every ambition. Keep the first charter to about one page.
- Treating non-goals as permanent. Revisit them when needs change.
- Using evidence that cannot be tested. Name an action and expected result.
- Letting a parent or AI write it alone. The student should make and understand the final choices.
Do this now
Copy the personal system charter template. Complete the four required first-pass sections.
When a decision makes the extended fields relevant, complete them directly or use the optional guided chatbot workflow for completing a complicated template to collect one answer at a time and export the reviewed charter in Markdown.
Choose one immediate priority. Do not install anything yet.
Log what you learned
The charter is the learning log for this exercise. Save it with its next review
date. Link it from working-log.md only if you need a chronological record of
the decision.
Next, learn how to evaluate tool proposals without pursuing a perfect setup.