Roadmaps: a new visual surface for long-arc paths to expertise
openA separate Roadmaps surface where each long-arc path to expertise (AI Engineer, Lawyer, Quantum Physicist, Quantum Computing Hardware Engineer, more) lives as its own richly visual sub-page. Authored in a custom roadmap-making mini-language inside Obsidian; rendered as a proper diagram with milestones, dates, progress bars, and linked tasks.
proposed 2026-05-18roadmapssurfacevisualexpertiseauthoringdsl
The Life Plan covers the constitution. The Master Plan covers the operating document. Neither is the right home for a specific long-arc path to expertise in a single field. Roadmaps is for those.
What it is
A new top-level surface at /roadmaps. Each roadmap is a sub-page at /roadmaps/<slug>. Examples I want to ship:
- Becoming a serious AI Engineer
- Becoming a Lawyer (UK / UAE jurisdiction path)
- Becoming a Quantum Physicist (foundations to research-grade)
- Becoming a Quantum Computing Hardware Engineer
- A few more (will expand the list as I draft them)
Each roadmap is a long arc. Years, not weeks. Different in shape from a Master Plan Part: a Part is a syllabus; a roadmap is a journey with a destination, milestones along the way, and explicit fork points.
What makes it different from existing surfaces
| Roadmaps vs. | Distinction |
|---|---|
| Life Plan | Life Plan is constitutional, has no dates. Roadmaps have dates, deadlines, progress bars. |
| Master Plan | Master Plan is the single operating doc for everything. Roadmaps are domain-specific, parallel, can be started or paused independently. |
| Tasks | Tasks are atomic. A roadmap milestone might contain many tasks. The roadmap is the structure; tasks live underneath. |
| Notebook / Library | Reading material, not a path. Reading happens in service of a roadmap. |
Visual design
This should be the most visual surface on the site so far. Editorial register stays (no chartjunk, no random colours, no animated bling), but the rendered output is a real diagram, not just headings.
References to consider for tone:
- The clean horizontal-timeline style of well-designed academic syllabi
- Edward Tufte's small multiples
- The "every two weeks" rhythm of Andy Matuschak's working notes
- Roadmap.sh's tree diagrams (without the bloat)
Elements the rendered roadmap should support:
- Phases along a horizontal or vertical timeline
- Milestones as marked nodes with title + optional date
- Branches and merges (a roadmap can fork on a decision point and rejoin)
- Resource pins (books, courses, papers, repos) hanging off any node
- Progress fill on each node (0 → 100%) driven by the linked tasks
- Status states per node: not started, in-progress, completed, dropped, blocked
- Optional "stretch" track running parallel to the main track for advanced material
The roadmap-making mini-language
Authoring needs to happen in Obsidian, in plain markdown, in a format that is fast to write and survives copy-paste from existing notes. Not Mermaid. Not raw JSON. A small DSL that reads naturally as text and renders as a diagram.
Sketch (subject to revision):
# Becoming a Serious AI Engineer
## Phase 1: Mathematical fluency
:: target 2026-08
:: depends-on nothing
:: progress auto
- milestone: Linear algebra reproduced from scratch
:: by 2026-07
:: tasks task-la-notebook task-la-problem-set
:: resources Strang Introduction to Linear Algebra MIT 18.06
- milestone: Probability and statistics rebuilt
:: by 2026-08
:: tasks task-prob-notebook
## Phase 2: Classical ML
:: target 2026-12
:: depends-on Phase 1
- milestone: Bishop PRML worked through, chapters 1-8
:: by 2026-11
:: tasks task-bishop-1 task-bishop-2
:: resources Pattern Recognition and Machine Learning
- stretch: Implement HMM from scratch
:: by 2026-12
:: tasks task-hmm-impl
## Decision point: applied vs. research
:: at 2026-12
:: branches
- branch: Applied (production AI engineering)
:: leads-to Phase 3a
- branch: Research (paper reproduction + original contributions)
:: leads-to Phase 3b
The parser converts this into structured JSON, then renders it as a real visual roadmap.
Editing experience
The whole point of the DSL is that editing the roadmap means editing a plain markdown file in Obsidian. Add a milestone by typing six lines. Move a date by changing a string. Mark a node done by changing one word in a frontmatter-like attribute. No drag-and-drop GUI required, no tool-specific binary file, no proprietary export.
Schema
Per-roadmap markdown file in vault/roadmaps/<slug>.md. Frontmatter carries:
title: "Becoming a Serious AI Engineer"
slug: ai-engineer
summary: "Two-to-three sentence pitch"
status: active | paused | shipped | archived
started: 2026-05-01
target: 2029-12-31
cover: optional cover image
Body is the DSL (Phase / milestone / branch / decision-point blocks). Tasks linked via wikilink to the existing tasks surface so the roadmap and the live task list stay coherent.
Tasks integration
A roadmap's tasks ARE tasks in the existing tasks table. The roadmap adds:
- A
roadmapfield on each task pointing back to the roadmap slug - A
milestonefield grouping tasks under a milestone slug - An aggregate progress: a milestone is N% complete when its linked tasks are.
So tasks remain the source of truth for status. Roadmaps are the higher-level structure.
Rendering
Probably an SVG renderer for the main diagram (clean, scalable, screenshot-friendly), with each node clickable to a detail card. Mobile collapses the diagram to a vertical timeline.
The Master Plan's editorial register applies: no stock icons, no chartjunk, no rainbow colour palette. Orange for "active" / "in-progress", neutral for "not started", muted for "completed" (the work is in the past). Borders carry the structure, not fills.
Why this matters
Roadmaps are the artefact between "I want to learn X" and "I am doing the work of learning X." Without one, a long arc collapses into either anxious planning or undisciplined drifting. With one, the next concrete step is always visible, the destination doesn't move, and the reader (me, six months from now) can see where on the path I actually am.
Also: published roadmaps are a service. Anyone reading the site can copy mine, fork it, disagree with it publicly.
Next steps if this becomes Building
- Pick the DSL grammar (probably 1-2 iterations to settle)
- Write the parser (markdown body → JSON tree)
- Schema + migration for
roadmapsandroadmap_milestonestables - Vault parser entry (already routes by folder)
/roadmapsindex +/roadmaps/[slug]detail pages- SVG renderer (the visual heavy lift)
- Tasks integration (foreign key from tasks to milestones)
- Mobile responsive treatment
- Author the first three roadmaps in the new format
Out of scope here
- Automated suggestions ("based on your roadmap, here are the next tasks"). That's a separate idea.
- Public-facing collaboration ("fork this roadmap"). Same.
- Mermaid or other off-the-shelf diagram engines. The custom DSL is the point.