---
title: Zettelkasten as Object Model
synced_from_vault: true
vault_source: 03-living-docs/patterns/Zettelkasten-as-Object-Model.md
public: true
type: pattern
tags:
  - pattern
  - philosophy
  - design
  - zettelkasten
  - smalltalk
created: 2026-02-22T00:00:00.000Z
---

## 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:

1. **The unit of meaning should be small and self-contained** (an atomic note / an object)
2. **The unit communicates through connections** (wiki-links / message passing)
3. **The power is in the composition, not the individual unit** (the knowledge graph / the running system)
4. **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](/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](/patterns/protocol-over-tool) — wiki-links are a protocol (any note can send one, any note can receive one) not a tool
- [Integration-vs-Composition](/patterns/integration-vs-composition) — atomic notes compose; monolithic documents integrate. The zettelkasten chooses composition.
- [Galls-Law](/patterns/galls-law) — complex knowledge graphs evolve from simple note-taking that worked; don't pre-design the ontology

---

## Cross-References