Luhmann's Card System Solved the AI Session Continuity Problem Before AI Existed
Niklas Luhmann spent over 40 years building a Zettelkasten of roughly 90,000 index cards. Over his career, he published around 50–60 books and hundreds of articles.
Not a typo. One scholar, one card system, 50–60 books and hundreds of articles.
Most people file this as a productivity curiosity. An obsessive academic with an elaborate system: nothing more than an interesting flex.
I’ve been thinking about this approach ever since I stumbled across it several years ago.
What made it work wasn’t the cards. It was the constraints. Each note is atomic — one idea, nothing more. Each note has a stable, permanent ID that never changes. Notes are linked to other notes by relationship, not organized into hierarchies. And notes are never edited. When an idea evolves, you write a new card. The old one remains static.
Those aren’t note-taking conventions. They’re system design principles.
The technical implementations of the same idea keep failing. The tools get built, adopted, and eventually collapse — because the tool tries to do the work the constraints were supposed to enforce. Remove the friction and you remove the thing that made the system work.
Luhmann’s cards worked because they were difficult and cumbersome to rearrange. That wasn’t a limitation. It was the feature. If you can reorganize everything, nothing has a stable location. If nothing has a stable location, links rot. If links rot, the system is a pile.
A couple of months ago I began designing a governance structure for AI-assisted development — a way to maintain coherent context across sessions with an AI that starts fresh every time. The system needed decisions to be permanent and findable, current state to be always current, and an entry point thin enough to load in full every session.
At some point I noticed the shape of what I was building:
- Decisions recorded as permanent records that never get edited, only superseded
- A stable identifier for every record that never changes
- A current-state document that maps content without containing it
- An entry point that stays thin by design
ADRs. project-state. CLAUDE.md.
It was a Zettelkasten. Not metaphorically — the isomorphism is clean. ADRs are the permanent notes. The supersedes field is Luhmann’s sequence link. project-state is the content map, not the content itself. CLAUDE.md is the overview note that stays thin because everything else has a home.
I hadn’t set out to build one. I’d set out to solve a context problem. The recognition came later.
What naming it unlocks isn’t a feeling of cleverness. It’s the failure modes.
A Zettelkasten breaks when notes aren’t atomic — two ideas in one card means you can’t link to just one of them. So watch for ADRs that bundle multiple decisions together.
It breaks when IDs change — links rot when cards move. So: never rename a slug.
It breaks when notes get edited rather than superseded — the record of what you decided at the time gets contaminated by what you know now. So: ADRs updated in place destroy the historical record. Write a new one. Leave the old one.
The constraints aren’t arbitrary. Each one prevents a specific mode of degradation. You don’t need to understand the full system to follow them — but knowing where they came from tells you which ones to treat as hard rules.
Luhmann was working with the best available substrate in 1952. Physical cards were slow, local, and couldn’t be queried. The principles were right. The implementation was limited by what existed.
The session continuity problem in AI-assisted development — how does an AI pick up where you left off without re-explaining everything? — turns out to have been solved, structurally, by an old man’s card system decades before the problem existed.
If you’re building AI governance systems, this isn’t trivial. The constraints that made Zettelkasten work — atomic records, stable identifiers, immutability enforced by design — are the same constraints that determine whether a governance system maintains coherent state or gradually collapses into a pile. Most teams treat them as implementation preferences. They’re not. Each one prevents a specific mode of degradation, whether you’re indexing 90,000 ideas or tracking 900 AI decisions.
Slow and steady isn’t a temperament. It’s occasionally just correct.