Creating a Zettelaste in Notion

Purpose

A Zettelkasten is not a database of notes. It is a working system for thinking over time: capturing fragments, refining them into durable claims, and forcing those claims into contact through links until new structure appears.

This essay documents a Zettelkasten implemented in Notion, a general-purpose digital workspace that combines databases, documents, and lightweight automation in a single environment. Notion functions less like a traditional note-taking app and more like a configurable framework for building custom information systems. In this case, it is used to host a single database that holds every zettel, enforces a staged workflow, and makes linking density visible—so the system itself can signal when a note is ready to be assembled into an essay or other finished artifact.

The goal is not organization. The goal is legibility of thought over time.

Design Intent

This build optimizes for five constraints.

1. Fast capture without losing future usefulness

The system must accept rough, incomplete notes quickly, without requiring structure up front—while still making it easy to revisit and process those notes later without friction.

2. A clear state machine for thinking

Each note moves through defined stages. At a glance, you should be able to trust what a note means in the system, not just what it contains.

3. Links as first-class objects

Connections between notes are not optional metadata. They are the center of gravity. A note that never links is unfinished by definition.

4. Separation of meaning from output

Notes are allowed to exist without being “for” an essay. When a note becomes relevant to an output, the system records that explicitly rather than assuming intent retroactively.

5. Quality signals without rewriting the note

Short summaries and writing pointers support draft assembly without flattening the original note into a derivative outline.

The Core Structure

(One database, one record per zettel)

The system is implemented as a single Notion database called 🧩 Zettelkasten. Each row represents one zettel. The schema encodes workflow, linking pressure, and readiness for use.

Key Properties—and Why They Exist

Identity

• Title - A human readable name for the idea.

• Zettel ID - An optional human assigned identifier, useful for migrations or stable external references.

• ZID (computed) A standardized identifier that normalizes naming even when human IDs drift.

Workflow / State

• StageCapture → Processed → Linked → Used → Published

  Stage is a contract. It represents work completed, not intent or confidence.

Type Discipline

• Note TypePermanent, Literature, Observation, Quote, Workbench (extendable later).

  Type clarifies what kind of thinking the note represents, not its importance.

Linking

• ConnectionsA self-relation to other zettels.

• Connections CountA visible signal of integration density. This is not a quality metric—but it is a readiness cue.

• 
  

Input → Output Orientation

• Output PipelineEssay, Race Review, SGO Report, Deep Time, None.

  Output intent is explicit and separable from the note’s meaning.

Compression Fields

(Retrieval aids, not replacements)

• Summary (3 sentences)A short retrieval description, written by the author.

• Brief (AI)Intentionally constrained to 1–2 descriptive sentences only. No interpretation.

• Use in WritingAssembly guidance: pull-quotes, section placement, or structural hints for drafts.

Evidence / Provenance

• SourceRelation to a separate Sources database, especially important for Literature and Quote notes.

Lifecycle Bookkeeping

• Last EditedA recency signal, not a productivity metric.

• Used / Published LinkWhere the note ultimately appeared, once shipped.

• Era Window (optional)Temporal framing for historically or geologically bounded ideas.

What Makes This a Zettelkasten

(Not just “notes in a database”)

Three design choices matter more than the tool itself:

• Forced integrationThe Connections relation is required during intake (via a form). Notes must link at creation, preventing silent accumulation.

• Stage as promise“Capture” permits mess. “Linked” implies neighbors. “Used” means the note paid rent in a draft.

• Operational views, not decorative onesAudit views expose missing fields, weak linkage, and readiness for assembly. They function like maintenance routines, not filing cabinets.

Views as Operating Modes

(How the database stays usable)

The schema is the skeleton. Views are the behavior.

Common operating views include:

• All ZettelsThe canonical table.

• New Zettel FormStructured intake for fast, repeatable creation.

• Missing Fields / Missing Summary / Missing Note TypeHygiene dashboards that surface debt.

• Literature OnlyIsolates source-bound notes for review.

• Standards AuditGrouped by Note Type or Stage to make drift visible.

• Promote to LinkedHighlights notes that have been processed but not integrated.

• Ready for AssemblySurfaces notes with sufficient linkage and writing guidance to support draft construction.

  
  

Principle: You do not organize a Zettelkasten. You maintain it.

Minimal Instructions to Recreate the System

This is the smallest viable build. Add complexity only after friction appears.

1. Create the Database

Create a database called Zettelkasten with these properties:

• Note Type (Select): Permanent, Literature, Observation, Quote, Workbench

• Stage (Select): Capture, Processed, Linked, Used, Published

• Connections (Relation → this same database)

• Summary (3 sentences) (Text)

• Use in Writing (Text)

• Output Pipeline (Select): Essay, None

• Source (Relation → Sources database, optional but recommended)

Optional but useful:

• Connections Count (Formula)

• Ready Flag (Formula)

2. Create the Intake Form (Optional, High Leverage)

Create a Form view called New Zettel. Include:

• Title

• Note Type

• Stage

• Output Pipeline

• Source

• Summary (3 sentences)

• Full Note (if body text is stored as a property)

• Connections (make required if you want enforced integration)

3. Create Maintenance Views

Start with three:

1. Missing Summary

   • Filter: Summary is empty

2. Promote to Linked

   • Filter: Stage is Processed AND Connections is empty

3. Ready for Assembly

   1. Filter:

      • Stage is Linked

      • Output Pipeline is Essay

      • Use in Writing is not empty

      • Connections is not empty

   2. Optional: constrain Connections Count (e.g., 2–5)

      
      

4. Daily Operating Loop

• Capture ideas into Stage = Capture

• Process: clarify title, assign type, write summary → Processed

• Link: add 2–5 connections → Linked

• Assemble drafts from Ready for Assembly

• After use: mark Used and add the published link

Practical Conventions

• Summary and Brief fields are retrieval aids, not the note itself.

• Stage is not a mood. Stage is a promise about completed work.

• Links are the system. Deferred linking turns thinking into storage.

• Keep Output Pipeline separate from Note Type.

• Keep Topics small, stable, and boring.

  
  

What This Construction Buys You

A Notion-based Zettelkasten like this becomes an idea engine because it converts three vague activities into concrete, inspectable actions:

• Capture becomes Stage = Capture

• Thinking becomes Processed → Linked

• Writing becomes Ready for Assembly → Used

Notion is incidental. The point is that the system makes thinking legible over time—and makes the next action obvious.