Zettelkasten Meeting Notes: Permanent Records

Introduction: The “Meeting Note Cemetery” Problem

Every knowledge worker recognizes the pattern: you attend six hours of intense meetings, take twenty pages of scattered notes in Google Docs, Notion, or a notebook, and file them into a folder named Meetings/2026. Within forty-eight hours, those notes become an inert graveyard of text.

When an architectural question resurfaces three months later—“Why did we decide to use SQLite FTS5 instead of RocksDB for client-side search?”—nobody can locate the specific paragraph buried across dozens of generic meeting documents.

The Knowledge Extraction Pipeline:
┌────────────────────────────────────────────────────────┐
│ Tier 1: Fleeting Meeting Note (Raw Discussion)         │
│ Captured automatically via Oyma on local disk    │
└───────────────────────────┬────────────────────────────┘
                            │ Distill Decisions & Tradeoffs
                            ▼
┌────────────────────────────────────────────────────────┐
│ Tier 2: Extraction Note (Literature / Synthesis)       │
│ YAML frontmatter, action items, attendee profiles      │
└───────────────────────────┬────────────────────────────┘
                            │ Deconstruct into Atomic Ideas
                            ▼
┌────────────────────────────────────────────────────────┐
│ Tier 3: Permanent Atomic Zettels (Knowledge Graph)     │
│ [[SQLite FTS5 Architecture]] ◄──► [[Local-First Sync]] │
└────────────────────────────────────────────────────────┘

The solution lies in adapting Niklas Luhmann’s celebrated Zettelkasten methodology. Developed in the mid-20th century to manage sociological scholarship, Zettelkasten is renowned for generating high-leverage intellectual connections through atomic, linked index cards.

In this architectural guide, we construct a modern digital Zettelkasten pipeline tailored specifically for software engineers, product architects, and executives who need to convert messy conversational deliberations into durable, lifelong knowledge assets.

---

1. The Three Tiers of Meeting Knowledge

A fatal error among personal knowledge management (PKM) practitioners is attempting to turn raw meeting transcripts directly into permanent notes. A 60-minute meeting is inherently messy, conversational, and multi-threaded.

To maintain vault hygiene, meeting knowledge must flow through three distinct architectural stages:

Tier 1: The Fleeting Meeting Record

• Format: Chronological Markdown document generated by Oyma or handwritten in real time.
• Location: 00-Inbox/Meetings/YYYY-MM-DD-title.md.
• Characteristics: Contains verbatim quotes, timestamped speaker dialogue, audio links, and raw follow-up tasks.
• Lifespan: Ephemeral. Serves as reference material.

Tier 2: The Extraction & Decision Synthesis

• Format: Structured synthesis document containing curated executive decisions, rejected alternatives, and assigned deliverables.
• Location: 10-Projects/ProjectName/Syncs/YYYY-MM-DD.md.
• Characteristics: Utilizes structured YAML frontmatter and standard Markdown callouts ([!DECISION], [!WARNING]).

Tier 3: The Permanent Atomic Zettel

• Format: Highly focused single-topic Markdown card (ADR-042-sqlite-fts5-search.md or Concept-Zero-Trust-Local-Storage.md).
• Location: 20-Concepts/ or 30-Permanent/.
• Characteristics: Autonomous, durable, self-contained, and deeply interlinked via bidirectional wikilinks.

---

2. Anatomy of a Meeting Extraction: From Dialogue to Structure

Let us examine a concrete engineering scenario: an architecture sync debating embedded full-text search indexes.

Raw Dialogue (Tier 1 Transcript Fragment):

Marcus Vance (14:22): “If we use SQLite with the FTS5 extension, we get Porter stemming and Okapi BM25 relevance scoring out of the box with zero external background daemons.”
Julian Thorne (14:24): “What about memory usage on entry-level 8GB M2 MacBooks? Will indexing 50,000 Markdown notes cause memory pressure?”
Marcus Vance (14:26): “FTS5 writes inverted index B-trees straight to disk in a separate database file. It operates with a page cache budget of only 16 MB. RocksDB would require a persistent memory table allocator.”
Decision (14:28): Adopt SQLite FTS5 for the search engine.

Synthesized Extraction (Tier 2 Document):

---
title: "Search Engine Architecture Review"
date: 2026-10-10
type: "meeting-extraction"
tags: ["architecture", "search", "sqlite"]
attendees: ["[[Marcus Vance]]", "[[Julian Thorne]]"]
project: "[[Project Desktop Shell]]"
---

## Key Architectural Decisions

> [!DECISION] Adopt SQLite FTS5 for Client-Side Search
> **Rationale:** Zero external daemons, built-in BM25 ranking, and strict 16 MB page cache budget.
> **Rejected Alternative:** RocksDB (excessive memory table overhead on 8GB workstations).
> **Origin:** Discussed during [[2026-10-10 Search Engine Architecture Review#14:22]].

## Action Items
- [ ] [[Marcus Vance]] Benchmark FTS5 indexing speed on 50,000 files by 2026-10-15
- [ ] [[Julian Thorne]] Implement incremental DB triggers for note edits

---

3. Constructing Permanent Atomic Cards (Tier 3)

The true magic of Zettelkasten occurs when you extract the core principles from Tier 2 and file them into your permanent knowledge graph.

Notice how the decision from the meeting gives birth to a durable concept card that outlives the specific project:

---
id: "ZET-20261010-01"
title: "SQLite FTS5 Memory Budget Architecture"
type: "permanent-concept"
created: 2026-10-10
tags: ["database", "embedded-systems", "memory-optimization"]
---

# SQLite FTS5 Memory Budget Architecture

In memory-constrained local-first desktop environments, search engines must operate within a deterministic RAM footprint.

SQLite FTS5 achieves memory stability by backing inverted index B-trees directly with POSIX disk storage rather than in-memory skip-lists or memory tables.

## Key Constraints
1. **Page Cache Bound:** Configured via `PRAGMA cache_size = -16000` (strictly bounds page cache to 16 MB).
2. **Crash Resilience:** Write-Ahead Logging (`PRAGMA journal_mode = WAL`) guarantees atomicity without risking index corruption during kernel reboots.

## Historical Origin & Lineage
- Adopted over RocksDB during [[2026-10-10 Search Engine Architecture Review]].
- Validated on Apple Silicon in [[ADR-042 Client-Side Lexical Search]].

## Related Concepts
- [[APFS Inode Traversal Latency]]
- [[Local-First Data Sovereignty]]
- [[BM25 Relevance Scoring Algorithmic Fundamentals]]

Now, when any team member researches memory optimization two years from now, the permanent card surfaces immediately in their graph view and search queries, with bidirectional links tracing directly back to the original meeting transcript.

---

4. The Power of Maps of Content (MOCs)

As your vault accumulates hundreds of meeting extractions and atomic cards, organizing them through flat folders becomes unwieldy. In modern Markdown vaults, we utilize Maps of Content (MOCs).

An MOC is a hub note that curates and structures links to related concepts:

---
title: "MOC: Client-Side Storage & Search Architecture"
type: "map-of-content"
---

# MOC: Client-Side Storage & Search Architecture

## 1. Storage Foundations
- [[APFS Filesystem Internals]] — Inodes, B-trees, and copy-on-write mechanics.
- [[POSIX Atomic Write Guarantees]] — Safe file persistence via temp swaps.

## 2. Search & Indexing
- [[SQLite FTS5 Memory Budget Architecture]] — Bounded memory lexical search.
- [[Okapi BM25 Scoring Parameters]] — Tuning term frequency saturation.

## 3. Deliberation History
- [[2026-10-10 Search Engine Architecture Review]]
- [[2026-09-28 Vault Performance Sync]]

MOCs provide high-level semantic orientation without imposing rigid hierarchical folder silos.

---

5. Integrating with Oyma

In the Oyma desktop ecosystem, the transition from Tier 1 to Tier 3 is frictionless:

1. Zero-Friction Recording: During calls, Oyma captures audio without bot interruptions and transcribes dialogue locally.
2. Structured Delivery: Notes drop straight into your designated Obsidian vault folder as standard CommonMark files with valid YAML metadata.
3. Local AI Assistance: Using local Ollama integration, you can prompt the on-device model:
   “Extract key architectural decisions into candidate Zettelkasten cards with rationale and rejected alternatives.”
4. Permanent Ownership: Every note remains a plain .md file on your local APFS drive, guaranteeing multi-decade accessibility with zero cloud vendor lock-in.

---

6. Luhmann’s Alphanumeric Branching Notation in Digital Vaults

In physical index card boxes, Niklas Luhmann utilized an alphanumeric numbering system (such as 1/1, 1/1a, 1/2) known as Folgezettel. This numbering allowed him to insert new cards between existing thoughts without reordering the entire collection, creating branching trains of thought.

While digital hyperlinking eliminates the physical constraint of card insertion, adopting structured UID notation provides immense organizational value in Markdown vaults:

Alphanumeric Knowledge Lineage:
ZET-042: Core Local Storage Principles
  ├── ZET-042a: APFS Copy-on-Write Inodes (Origin: [[2026-10-10 APFS Arch Review]])
  │     └── ZET-042a1: Atomic Swapping with RENAME_SWAP
  └── ZET-042b: SQLite FTS5 Inverted Index Design (Origin: [[2026-10-10 Search Review]])

By prefixing permanent notes with hierarchical identifiers:

• Notes maintain logical topical clusters even when sorted alphabetically in file trees.
• The conceptual genealogy of every architectural decision is visually apparent at a glance.
• Wikilinks can reference both the specific implementation card ([[ZET-042a1]]) and the high-level parent principle ([[ZET-042]]).

---

7. Automated Knowledge Synthesis via DataviewJS

In an active engineering organization, tracking the evolution of architectural decisions across dozens of meetings is simplified using DataviewJS automation inside Obsidian.

Below is an interactive dashboard script that aggregates all architectural decisions recorded in meeting notes over the last 30 days:

// DataviewJS: Real-time decision registry from meeting notes
const thirtyDaysAgo = new Date();
thirtyDaysAgo.setDate(thirtyDaysAgo.getDate() - 30);

const meetingNotes = dv.pages('"40-Meetings"')
  .where(p => p.type === "meeting-note" && new Date(p.date) >= thirtyDaysAgo)
  .sort(p => p.date, "desc");

const decisionRows = [];

for (const note of meetingNotes) {
  const content = await app.vault.read(app.vault.getAbstractFileByPath(note.file.path));
  // Extract custom [!DECISION] callout blocks using regex
  const decisionRegex = /> \[!DECISION\] (.*?)\n((?:> .*\n)*)/g;
  let match;
  while ((match = decisionRegex.exec(content)) !== null) {
    const title = match[1];
    const body = match[2].replace(/> /g, '').trim();
    decisionRows.push([note.date, note.file.link, title, body]);
  }
}

dv.table(["Date", "Meeting Note", "Decision Title", "Context & Rationale"], decisionRows);

By embedding this script into your engineering team’s primary dashboard, newly recorded decisions surface automatically across the organization the moment a meeting note is saved.

---

8. Managing Action Item Dependencies Across Concept MOCs

Meeting action items frequently cross team boundaries. When a decision requires engineering, design, and compliance follow-ups:

• Task Metadata: Action items are decorated with inline metadata keys:
  - [ ] Implement FTS5 table triggers [assignee:: [[Marcus Vance]]] [due:: 2026-10-15] [concept:: [[SQLite FTS5 Architecture]]]
• Global Rollup: A central Open Deliverables.md note queries all tasks grouped by concept or assignee.
• Bidirectional Completion: When an engineer checks off the task in their daily note or permanent concept card, the state synchronizes across all Dataview queries vault-wide.