Zettelkasten as Object Model
Core Concept
The zettelkasten’s atomicity principle and Smalltalk’s “everything is an object” are the same design principle applied to different substrates. Both say:
- The unit of meaning should be small and self-contained (an atomic note / an object)
- The unit communicates through connections (wiki-links / message passing)
- The power is in the composition, not the individual unit (the knowledge graph / the running system)
- If you find yourself wanting to reference something independently, it should be its own unit (the atomicity heuristic / “make it an object”)
A zettelkasten note that can be linked from five different contexts IS an object that responds to messages from five different senders. The linking protocol IS the message-passing protocol. The entity index IS the object runtime.
Why This Connection Matters
This isn’t a metaphor — it’s a structural identity. Recognizing it means:
- Zettelkasten conventions are already an object protocol. Atomic notes with frontmatter properties, typed by convention, communicating through wiki-links — that’s objects with properties, typed by class, communicating through messages.
- The entity index is a Smalltalk runtime. It resolves entities (objects), traverses relationships (messages), and derives structure from conventions (the metaclass layer).
- The linking discipline is garbage collection. Orphan detection, broken link repair, bidirectional link enforcement — these are memory management for a knowledge graph.
- The atomicity heuristic IS Smalltalk’s “everything is an object” rule. “If you find yourself wanting to reference it independently, make it an object” = “if you want to send it a message, it needs to be an object.”
Where I’ve Seen It
- This OS: The entire vault is built on this principle — atomic notes, frontmatter properties, wiki-link message passing, entity index as runtime
- Palantir’s ontology: Typed objects with properties and relationships, actions as mutations — the same model at enterprise scale
- Product Schema: Features as objects, JTBD as the organizing class hierarchy, test suites as the behavioral protocol
- WCP: Work items as typed objects with properties (frontmatter), activity logs (message history), and artifact links (composed references)
The Atomicity Heuristic (Restated as Object Heuristic)
“If a section could be referenced independently from multiple other notes, it should probably be its own note.”
Restated in Smalltalk terms:
“If something receives messages from multiple senders, it should be its own object.”
Both heuristics answer the same question: when does something deserve to be a first-class citizen in the system? The answer: when multiple other things need to point at it independently.
Related Patterns
- Augmentation-Over-Automation — the knowledge graph built by atomic notes IS the augmentation infrastructure; each note is a piece of context that makes the human-AI system smarter
- Protocol-Over-Tool — wiki-links are a protocol (any note can send one, any note can receive one) not a tool
- Integration-vs-Composition — atomic notes compose; monolithic documents integrate. The zettelkasten chooses composition.
- Galls-Law — complex knowledge graphs evolve from simple note-taking that worked; don’t pre-design the ontology