AI as a Compiler for My Notes

Over the last couple of years I have tried my share of note-taking tools and systems: Tana, Obsidian, Notion, Apple Notes, PARA, Zettelkasten, GTD. All well-designed, all with thoughtful philosophies. Yet none of them landed as a complete system for me. I think that might have changed recently, thanks to AI. This is Part 1 of a series: here I explain the system, and in Part 2 I walk through the tools that make it work.

# The Core Tension

# The Value of Structure

Every system for managing knowledge eventually confronts the same tension: structure enables understanding, but structure also creates friction. The more precisely we define how information should be captured, the more effort we spend on compliance rather than cognition. Yet without structure, information degrades into noise; useful to no one, least of all our future selves.

Structure matters because meaning is relational. When we note that a book influenced a project, that a conversation shaped a decision, that an insight connects to a question we’ve been carrying for months, we are not decorating information. We are preserving the relationships that give it meaning. Structured notes are easier to retrieve, because retrieval depends on understanding what we’re looking for. They are easier to connect, because explicit types and relationships create affordances for linking. Without structure, entropy wins. The brilliant insight captured in haste becomes indistinguishable from the mundane note captured alongside it. Both sink into the sediment of an ever-growing archive, equally inaccessible, equally useless.

# The Cost of Structure

Structure is not free. Its first cost is immediate: friction. Every decision forced at the moment of capture (which template to use, which category to assign, which metadata to include) competes directly with thinking. Attention spent on compliance is attention not spent on the idea itself. Some structure genuinely aids cognition. Much of it does not. Enforcing a date format or requiring particular fields rarely makes a thought clearer; it merely makes it compliant. A system that demands three decisions before you can record a thought will eventually stop receiving thoughts worth recording, at least for me.

Sometimes structure even blinds us from possible synergy with other notes and thoughts we might have had. A ‘Book’ template with fixed fields might prevent us from recognizing that the same book influenced a project, and sparked an unrelated insight. Structure applied too early doesn’t organize thought, it quietly filters it.

# I Want Both

Some systems respond to this tension by minimizing structure altogether. Zettelkasten-style approaches emphasize atomic notes and dense linking, encouraging organic emergence over predetermined categories. For many minds, this works extremely well.

For me, it does not. I need some orientation before I can think quickly. Without knowing what kind of information I’m dealing with, I don’t feel liberated; I feel lost. Types and categories aren’t overhead for me; they’re cognitive scaffolding. When I see that something is a task, I know how to relate to it. When I see that something is a knowledge note, I know what to do with it. Context is not friction. Context is a prerequisite.

The question, then, is not whether to choose structure or freedom. It is whether I can have both. Full structure in the system. Zero structure at the moment of capture.

# Resolving the Tension

When I did some quick research (or, more precisely, asked Claude to help me think through this), I learned that I wasn’t the first to have this insight. Almost every note-taking methodology in the world acknowledges this tension. GTD has its inbox. PARA has its inbox. Building a Second Brain calls it “capture.” Zettelkasten has its fleeting notes. The obvious solution is usually the right one: separate the moment of capture from the process of organizing.

At the moment of capture, speed matters more than correctness. Anything goes: fragments, voice notes, half-formed ideas, raw observations. As long as they land somewhere inside the system. An inbox exists precisely to receive this chaos without judgment.

But delaying structure is not the same as abandoning it. If everything remains raw forever, the system collapses into the noise it was meant to prevent. Structure must still be applied, just not by you, in the moment, under pressure. It should be applied by a process that has the patience and context to do it well.

Every system I’ve used acknowledges this. And yet, in practice, the “processing” step has always been where my systems broke down. You schedule a weekly review. You commit to processing your inbox every evening. It works for a few weeks, maybe a month. But life gets busy, the inbox grows, and suddenly you’re staring at 47 unprocessed captures that all need manual sorting, tagging, and routing. The review session stops being a quick maintenance task and starts feeling like homework.

The separation between capture and processing is the right idea. But it only works if processing is sustainable. And for me, manual processing at scale has never been sustainable.

# AI as a Compiler

Since this is a blog about note-taking and PKM systems, let me throw in a fun metaphor from a seemingly unrelated topic: JavaScript.

JavaScript is permissive. You can write quickly, loosely, without committing to precise types. This lowers friction at the moment of authorship, but pushes complexity downstream. Safety, clarity, and maintainability suffer as systems grow. Sounds familiar.

So how do maintainers of large JavaScript codebases deal with this? They don’t demand that everyone writes perfectly structured code from the start. Instead, they configure a layer of tooling that sits between the moment code is written and the moment code is run. Linters, compilers, bundlers, type checkers: these tools analyze, transform, and optimize loose input into something far more structured than the developer produced.

The human interface is permissive. The system underneath is rigorous.

Frictionless input does not require a structureless system. It requires a structured processor.

Now, JavaScript, even at its loosest, is still far more structured than the language we speak day to day. It has syntax, keywords, scoping rules. But as we’re now in 2026, we’ve reached a point where even plain English can be transformed into strictly typed code. AI is, in a very real sense, the ultimate compiler. It transforms commands in plain language into working, structured output. It adds types. It infers intent. It fills in the boilerplate you didn’t want to write.

By now you’ve probably guessed where I’m going with this. To keep capture frictionless while still having structured notes, I use AI as the compiler that processes my captures.

The workflow looks like this:

A raw capture goes in: a voice memo, a quick text, a photo of a whiteboard. The AI compiler processes it: it determines what type of note this is, extracts structured metadata, applies the right template, and proposes where the note should live in the system. The human reviews and accepts. The machine handles the structural work that I never wanted to do manually.

This changes the economics of note-taking in a fundamental way. Structure is no longer something I pay for at the moment of capture (or with time-consuming organizing sessions). It’s something the system adds for me, after the fact, at near-zero cognitive cost. I get the full benefits of a typed, structured, well-organized knowledge system, without the friction that usually comes with it.

# Translating This into a System

With this insight, AI as a compiler between raw capture and structured knowledge, I could finally design a note-taking system that doesn’t compromise. One where capture is truly frictionless, structure is truly thorough, and the gap between them is bridged by automation rather than discipline.

I have called it S4²2Why S4: the system has 4 domains: Capture, Tasks, Areas, and Library. Each optimized for a different purpose. Information flows between them through well-defined pipelines. The AI compiler sits at the transition point, turning raw captures into typed objects that earn their place in the right domain., and it’s built on a simple observation: different types of information need different workflows. A fleeting idea doesn’t need the same treatment as a task with a deadline. A long-term knowledge note doesn’t belong in the same pipeline as a project document. Trying to force all of these into one unified workflow is what makes most systems feel either too rigid or too loose.

# The Core Idea

The core principle of my system is that different aspects of note-taking require different tools and workflows. I work with 4 different note-taking domains: Capture, Tasks, Areas, and Library. Tasks need a Kanban board with calendar integration. The knowledge library needs a flat graph with dense links. Projects need folders with clear boundaries. And capture needs nothing. Just an inbox.

# Guidelines

The system is guided by six principles:³3Most of these are borrowed from other popular frameworks.

1. Memory is for creativity, not storage. Mental energy spent remembering cannot fuel creation. Capturing must be instant, seamless, and possible in every context.
2. Purpose defines process; process defines structure. Different types of information demand different workflows, and different workflows demand different organizations. One size fits nothing.
3. Simplicity sustains systems. Complexity kills habit. If the system is too complex, it will be abandoned.
4. Mimic the mind. The brain creates meaning through connection. The system should encourage linking notes, tasks, and ideas into a living web of context.
5. Optimized for myself. This is a tool for thought, not a performance. Optimize for personal utility, not presentation.
6. Capture raw, compile structured. Getting information into the system must be effortless: no formatting, no categorization, no schema awareness. Turning that raw input into well-typed objects that earn their place in the system is a separate concern, and the right place for automation to help.

# Terminology

Before diving into the system, it helps to be precise about a few overloaded words. I’ve found that being deliberate about naming helps me conceptualize things correctly:

One rule I try to follow: use Domain names (Capture, Tasks, Areas, Library) when explaining purpose and mental models. Use zone names (like 20-areas/) when explaining where something belongs. Use Process names as verbs for step-by-step behavior (Capture, Refine, Route, Plan, Review, Archive). This keeps things unambiguous.

# The Four Domains

Let’s walk through each one.

# Capture

All information enters the system through a single linear pipeline.

The capture pipeline from raw input to structured destination

Three steps. Capture: record immediately. No evaluation, no formatting, no categorization. One input field, automated timestamp. Optimize for speed alone. Refine: add the minimum structure required for the destination, a title, relevant frontmatter, splitting compound captures into individual items. Route: put each refined item into its appropriate Zone using the routing decision tree.

Refine and Route can be performed manually or delegated to automation (e.g. AI-driven compilation against templates in 99-templates/). When automated, I am the gate for the output: nothing leaves the inbox without explicit acceptance.

The capture schema is minimal by design:

type: capture
created: YYYY.MM.DD.hh.mm
medium: text | audio | image

That’s all a capture needs. Type, timestamp, medium. Everything else gets added during refinement and routing.

If a capture contains multiple actionable items, it gets split into individual tasks, and the original compound capture is archived. If a non-actionable capture contains multiple ideas, it gets atomized into separate Library notes. The AI compiler handles this splitting automatically; one raw capture can produce multiple typed, well-placed notes.⁴4Think of a meeting transcript: one capture that produces three tasks, two knowledge notes, and an area update.

# Tasks

Tasks exist to allocate time, not to describe work in the abstract. A task without a calendar slot is an intention, not a commitment. My calendar is the source of truth for how I commit my time. These two facts lead to a new insight: task management is not tracking progress or executing tasks, it’s a planning loop.

Tasks live in a Kanban-style lane system:

Task lifecycle through Kanban lanes

A few constraints keep this honest:

Each task must be a coherent unit of work completable within about four hours. If it’s bigger, break it down. Each blocker becomes its own task. If the blocker is your own work, create a regular task. If you depend on someone else, schedule a “check progress” task on your calendar. After a planned timeslot passes, the task returns to the inbox for review. Most reviews result in completion and archival. If not, re-commit a new calendar slot.

The task schema:

type: task
created: YYYY.MM.DD.hh.mm
status: to-plan | planned | blocked | to-review | done
planned: [{ start, end }] # committed calendar slots (optional)
blockers: [ref<Task>] # what must resolve first (optional)

The status field drives which lane the task lives in. The planned field holds committed calendar intervals. The blockers field references other tasks that need to resolve first. Everything is explicit, everything is typed.

# Library

The Library is the long-term memory of the system. It follows three rules:

1. Flat. No subdirectories. All organization emerges from links.
2. Atomic. Each note covers exactly one idea, concept, or insight.
3. Connected. Notes earn their value through references to other notes. An isolated note is an incomplete note.

Library notes are timeless; they evolve but rarely retire. They form a graph where notes are nodes and references are edges. The denser the graph, the more useful the system becomes.

My Library is basically a Zettelkasten system, but unlike pure Zettelkasten, S4’s Library supports typed frontmatter schemas (via templates) to add structured metadata without sacrificing the flat, linked architecture. As explained earlier, these structures are helpful to me.

At some point I might decide that “Library Index Notes” (non-atomic, navigation-only) would help organization, so they are allowed, but actual content has to demand it first. I’m letting the graph grow and seeing if navigation becomes a problem before adding structure I don’t yet need.

# Areas

Areas serve projects and collections that benefit from hierarchy. Unlike the Library’s flat graph, Areas use folder structures because project management requires clear scope boundaries.

Each Area has an index.md that serves as its homepage. Every cross-reference to the Area from elsewhere in the system must appear here. Areas are often time-bound. When an Area is completed or retired, the entire folder moves to 90-archive/.

# System Architecture

Under the hood, the four domains map to numbered top-level folders I call zones:

00-inbox/       Frictionless capture. Everything enters here.
10-tasks/       Task board (Kanban lanes in subfolders; completed tasks move to 90-archive/).
  11-inbox/     Unplanned actionable items.
  12-planned/   Tasks with committed calendar slots.
  13-blocked/   Tasks awaiting dependencies.
20-areas/       Active Areas (projects and collections), folder-structured.
30-library/     Flat Zettelkasten. Atomic, interlinked, timeless notes.
90-archive/     Completed and retired items.
99-templates/   Object schemas (capture, task, area-index).
media/          Attachments (audio/, images/).

Lower numbers represent raw, unprocessed information. Higher numbers represent structured, finalized content. Information flows forward through the system. The numbering is intentional: it creates a natural sort order in any file browser that mirrors the information flow.

# The Data Model

The system is built bottom-up from a minimal set of primitives.

Objects never nest inside each other. They reference each other via ref<T> and list<ref<T>>, keeping every unit modular, reusable, and independently addressable. A task can reference a Library note. A Library note can reference an Area. An Area’s index can list all related tasks. The system is primarily a web, not a tree.

# Object File Format

Every Object is a single .md file with two parts:

YAML frontmatter at the top: structured properties that vary by Object type. This is where types, timestamps, statuses, and references live.

Freeform markdown body below: context, notes, checklists, links. Whatever you need.

Minimal shape:

---
type: <object-type>
created: 2026.02.01.09.30
# ... typed properties here (vary by Object type) ...
---

Freeform markdown starts here.

This makes the entire system plain-text, portable, and tool-agnostic. Every item in every domain follows this same format. The object type determines which properties are expected; the freeform body is always open.

# Conventions

A few rules keep everything consistent:

Timestamps use YYYY.MM.DD.hh.mm format. Always. No exceptions.

File names use kebab-case.md. Predictable, URL-friendly, no spaces to worry about.

Storage is plain markdown + YAML frontmatter. No proprietary formats, no databases, no lock-in.

The daily rule: both inboxes, 00-inbox/ (Capture) and 10-tasks/11-inbox/ (Tasks), must be empty by end of day. This is the habit that keeps the system alive. If inboxes grow without limit, the system degrades into the noise it was designed to prevent.

# From Theory to Practice

If you look at the schemas and workflows above and think, “This looks like a lot of administrative work,” you are absolutely right. If I had to manually type YAML frontmatter, manage file names, and strictly enforce these routing rules every time I had an idea, I would have abandoned S4 within a week. The friction would outweigh the value.

But as I mentioned in the beginning, I don’t do the heavy lifting, the “compiler” does. The strictness of the system is only possible because I am not the one enforcing it.

In Part 2, I will show you the tools I use to manage the system. I’ll walk through the custom iOS application I built for capture, the specific AI configuration, and the compiling and routing flows of raw captures to structured notes.

- Jan Willem