The Zettelkasten Philosophy in ThreatRecall¶
ThreatRecall's internal codename — ZettelForge — reveals its intellectual lineage. The system applies Niklas Luhmann's Zettelkasten ("slip box") method to AI agent memory, translating principles designed for a 20th-century sociologist's index cards into a 21st-century CTI knowledge architecture.
Five Principles, Translated¶
1. Atomic Notes¶
Luhmann's rule: each card captures one idea, expressed in your own words.
ThreatRecall's translation: each MemoryNote captures one piece of intelligence. The two-phase extraction pipeline (FactExtractor) enforces this — when an analyst feeds in a 3,000-word threat report, the LLM distills it into 3-5 discrete facts, each stored as a separate note. "APT28 shifted to edge device exploitation" is one note. "DROPBEAR is no longer in active use" is another.
This atomicity is what makes retrieval precise. A vector search for "edge device exploitation" returns the specific note about APT28's shift, not the entire 3,000-word report.
2. Meaningful Links¶
Luhmann didn't file cards by topic — he connected them by relationship. Card 21/3a linked to 15/7b not because they shared a subject tag, but because one idea led to another.
ThreatRecall implements this through TypeDB's typed relationships. A uses relation between APT28 and Cobalt Strike is not a generic "related-to" tag — it's a specific, directional, confidence-scored relationship with temporal validity. The STIX 2.1 schema provides 8 relationship types, each with defined semantics:
| Relationship | Meaning |
|---|---|
| uses | Actor employs tool/malware |
| targets | Actor/campaign targets entity |
| attributed-to | Activity attributed to actor |
| indicates | Indicator signals threat |
| mitigates | Control reduces risk |
| mentioned-in | Entity appears in note |
| supersedes | Newer intel replaces older |
| alias-of | Two names for same entity |
These aren't tags — they're first-class objects with their own attributes (confidence, valid-from, valid-until).
3. Emergent Structure¶
Luhmann famously said his Zettelkasten surprised him. He didn't impose a hierarchy — structure emerged from the connections between notes.
ThreatRecall achieves this through TypeDB's inference functions. When a campaign is attributed to APT28 and that campaign uses a new malware strain, TypeDB's campaign-tool-attribution function automatically infers that APT28 uses that malware — without anyone explicitly creating that relationship. The knowledge graph grows smarter as it grows larger.
The BlendedRetriever surfaces these emergent connections during recall(). A query about APT28's capabilities returns not just directly stored facts, but inferred relationships discovered through multi-hop graph traversal.
4. Unique Identifiers¶
Every Luhmann card had a unique address (21/3a, 15/7b). This was the backbone — without stable addresses, links break.
ThreatRecall uses two ID schemes:
- STIX deterministic IDs for entities: threat-actor--{uuid5(namespace, "apt28")}. The same entity always gets the same ID, regardless of when or how it's ingested.
- Timestamped IDs for notes: note_20260409_102040_1742. Each note gets a unique address in the LanceDB store.
The mentioned-in bridge connects the two: TypeDB's deterministic STIX IDs reference LanceDB's timestamped note IDs.
5. Evolution Over Deletion¶
Luhmann rarely discarded cards. He'd add new cards that refined, corrected, or superseded old ones — creating a visible intellectual history.
ThreatRecall's supersedes relation follows this exactly. When the MemoryUpdater decides a new fact contradicts an existing note (the DELETE operation), it doesn't delete the old note. It creates a correction note and marks the old one as superseded_by the new one. The old note remains in storage, searchable for historical context, but recall() filters it out by default (exclude_superseded=True).
This means an analyst can always ask "what did we used to think about this?" — the evolution history is preserved.
Where the Analogy Breaks¶
Two important differences between Luhmann's system and ThreatRecall:
Scale. Luhmann's Zettelkasten had ~90,000 cards over 30 years. ThreatRecall can ingest thousands of notes per hour. At this scale, manual linking is impossible — entity extraction and heuristic relationship inference replace the human act of connecting ideas.
Retrieval. Luhmann browsed his cards by following links from a starting point. ThreatRecall adds vector similarity search — you can find relevant notes even when you don't know the right entity name to start from. The BlendedRetriever combines both approaches: graph traversal (Luhmann's method) and semantic search (the modern addition).
LLM Quick Reference¶
ThreatRecall (codename ZettelForge) applies five Zettelkasten principles to AI agent memory. (1) Atomic notes: the two-phase extraction pipeline (FactExtractor) distills reports into discrete facts stored as individual MemoryNote objects, each with its own vector embedding. (2) Meaningful links: TypeDB typed relationships (uses, targets, attributed-to, indicates, mitigates, mentioned-in, supersedes, alias-of) replace generic tags with directional, confidence-scored, temporally-valid STIX 2.1 relationships. (3) Emergent structure: TypeDB inference functions (get_aliases, get_tools_used, campaign-tool-attribution) discover indirect relationships automatically — if a campaign uses malware and is attributed to an actor, the actor-malware relationship is inferred. (4) Unique identifiers: STIX deterministic IDs (uuid5-based) for entities ensure the same entity always gets the same ID; timestamped IDs for notes (note_YYYYMMDD_HHMMSS_xxxx) provide stable LanceDB addresses. The mentioned-in bridge connects STIX entity IDs to note IDs across databases. (5) Evolution over deletion: the supersedes relation preserves intellectual history — old notes are marked superseded_by newer corrections rather than deleted, and recall() filters them by default. The system diverges from classical Zettelkasten in scale (thousands of notes per hour vs manual linking) and retrieval (BlendedRetriever adds vector similarity search alongside Luhmann's link-following approach).