Der blinde Fleck in meiner Obsidian-Vault

 26.07.2026 -  Sebastian Pech -  ~6 Minuten

Mein Second Brain in Obsidian ist über Jahre auf rund 400 Notizen gewachsen. Der größte zusammenhängende Textbestand darin war für die Vault selbst unsichtbar: ein Ordner mit chronologischen Arbeitsnotizen, den weder Suche noch Übersichten noch Verlinkung je erfasst haben. An einem Samstag habe ich das mit Claude Opus 5 aufgeräumt. Herausgekommen ist weniger eine Textarbeit als eine Reihe von Regeln, die ich beim nächsten Mal von Anfang an anwenden würde.

Ausgangslage

Die Struktur meiner Vault läuft schon länger nicht mehr über Ordnertiefe, sondern über Properties und Obsidian Bases. Notizen sind typisiert (projekt, buch, hobby, entscheidung, konzept), und sieben Bases erzeugen daraus Übersichten: alle offenen Projekte, alle Entscheidungen mit Status, alle Notizen zu einem Kontext. Das funktioniert gut, weil ich beim Anlegen einer Notiz nur zwei Felder ausfüllen muss und die Einordnung danach von selbst passiert.

Ein Ordner war davon vollständig ausgenommen: das Logbuch. 183 Tageseinträge aus acht Jahren, in denen Projektstände, Messwerte, Fehlschläge und Entscheidungen festgehalten sind. Keine Properties, keine Links, keine Base. In meiner Projektanweisung stand sogar explizit, dass dieser Ordner nicht gelesen werden soll.

Der Effekt: Alles, was dort dokumentiert war, existierte für den Rest der Vault nicht. Ich hatte acht Jahre Primärquelle und daneben ein Wissenssystem, das davon nichts wusste.

Warum das passiert

Protokollieren und Strukturieren sind zwei verschiedene Tätigkeiten. Ein Logbuch ist chronologisch, unsortiert und schreibt sich nebenbei. Ein Wissenssystem ist thematisch, verknüpft und will gepflegt werden. Obsidian behandelt beides gleich, es sind Markdown-Dateien im selben Verzeichnis, und genau deshalb fällt so lange nicht auf, dass der eine Teil nie im anderen ankommt.

Der Ansatz war deshalb nicht, 183 Einträge zu verlinken. Sondern eine Verdichtungsebene dazwischen einzuziehen: pro Jahr eine Notiz, die verlinkt ist und auf die Einzeleinträge zeigt.

Die sechs Regeln

1. Zusammenfassen heißt nicht kürzen, sondern erschließbar machen. Aus 183 Tageseinträgen wurden acht Jahresnotizen, alle mit identischer Struktur: Verteilung der Einträge, das Jahr in einem Satz, Themenblöcke, wiederkehrende Muster, verwandte Notizen. Die Gleichförmigkeit ist der eigentliche Punkt. Erst dadurch wird ein Jahr mit einem anderen vergleichbar, und erst dann kann eine Base darauf arbeiten.

2. Die Zahl der Einträge ist selbst ein Datum. 43, 27, 7, 15, 8, 52, 22, 9. Diese Verteilung erzählt eine eigene Geschichte, unabhängig vom Inhalt: wann intensiv dokumentiert wurde, wann gar nicht, und was in den Lücken lag. Ein Jahr mit sieben Einträgen ist ein Befund und kein Mangel an Material.

3. Offene Fragen markieren statt raten. Immer wenn zwei Quellen sich widersprachen oder etwas nicht belegbar war, kam ein Abschnitt “Offen” in die Notiz statt einer plausibel klingenden Vermutung. Diese Abschnitte habe ich danach einen nach dem anderen abgearbeitet, teils aus späteren Jahren, teils aus dem Gedächtnis. Der Nutzen bleibt auch danach: Man sieht der Notiz an, was Beleg ist und was Interpretation.

4. Eine Datenquelle ist führend, der Rest verweist. Eine über 13 Jahre laufende Messreihe liegt in einer externen App und wird dort täglich gepflegt. Statt die Zahlen über die Vault zu verteilen, gibt es genau eine Notiz mit der Langzeit-Einordnung und dem Link zur Quelle. Alle anderen Stellen verlinken nur dorthin. Nebeneffekt des Abgleichs: In zwei alten Einträgen standen falsche Werte.

5. Korrekturen sichtbar machen, nicht überschreiben. Tageseinträge sind Zeitdokumente. Wo ein Wert nachweislich falsch war, habe ich ihn korrigiert, aber mit einer Klammer darunter: was im Original stand und wann korrigiert wurde. Stilles Überschreiben würde rückwirkend behaupten, ich hätte es damals schon richtig gewusst.

6. Namen sind das größte Konsistenzproblem. Drei Varianten davon in einer einzigen Vault:

• Dasselbe Ding unter zwei Bezeichnungen, im Logbuch die Kurzform aus dem Alltag, in den Übersichtsnotizen der offizielle Produktname.
• Zwei verschiedene Dinge unter derselben Kurzform, jahrelang unbemerkt nebeneinander.
• Eine Bezeichnung, im Logbuch durchgehend falsch geschrieben, und das in zwei verschiedenen Varianten.

Die Lösung besteht aus eindeutigen Dateinamen, gegenseitigen Warnhinweisen in beiden Notizen, Alias-Links der Form [[Vollständiger Name|Kurzform]] und einer Faustregel im Text, an welchem Kontext man erkennt, was gemeint ist. Ohne diesen Schritt zeigt der Graph zwei Inseln, wo eine Sache steht.

Was erst durch die Verlinkung sichtbar wurde

Der interessanteste Teil sind Erkenntnisse, die in keinem einzelnen Eintrag stehen.

Eine technische Umstellung war undatiert. Ein Eintrag beschrieb sie ohne Datum, ein zweiter bestätigte zwei Wochen später den Zustand danach, und ein dritter enthielt beiläufig die Angabe “seit anderthalb Jahren”, aus der sich zurückrechnen ließ. Erst zusammen ergaben die drei Stellen den Monat.

Ein wiederkehrendes Ereignis war zweimal der Auslöser für eine größere Weichenstellung. In den Einzeljahren wirkte das jeweils wie Zufall. Sichtbar wurde das Muster erst, als die acht Jahresnotizen nebeneinander lagen.

Die Messreihe aus Regel 4 hatte über 13 Jahre drei klar getrennte Phasen statt eines gleichmäßigen Verlaufs. Das erklärt rückwirkend, warum das zugehörige Thema in bestimmten Jahren als Dauerthema im Logbuch auftaucht und in anderen gar nicht.

Ein Präzedenzfall stellte sich als teurer heraus als gedacht. Eine frühere Regelung galt in zwei Notizen als Beleg für Entgegenkommen. Aus einer dritten Quelle ergab sich, dass sie an eine Gegenleistung geknüpft war. Das verändert eine Entscheidung, die aktuell offen ist.

Vorher und nachher

Der Unterschied ist unspektakulärer, als ich erwartet hatte, und trotzdem eindeutig: Der Kern ist dichter vernetzt, mehrere Sterne am Rand hängen jetzt an einem Hub statt frei im Raum, und die neuen Verdichtungsnotizen sind als große Knoten erkennbar. Die Zahlen dazu:

Dazu drei neue Hub-Notizen, rund 1270 geprüfte Wikilinks und ein aktualisiertes Schema-Dokument.

Fallstricke

Massenersetzung ist gefährlich. Ein sed-Durchlauf zur Vereinheitlichung einer Bezeichnung hat eine Aufzählung zerschossen und eine Kurzform der falschen Notiz zugeordnet. Danach habe ich nur noch gezielt einzeln geändert. Bei 400 Dateien ist die Versuchung groß, aber Markdown ist eben kein strukturiertes Format.

Automatische Prüfungen produzieren Fehlalarme. Ein Skript für tote Links meldete zwei Dutzend Treffer, alle davon Bild-Embeds, die das Skript nicht mitgelesen hatte. Prüfergebnisse muss man selbst gegenlesen, sonst repariert man Dinge, die nie kaputt waren.

Neue Property-Werte schleichen sich ein. Aus zwei kontext-Werten wurden vier, aus zwei kategorie-Werten drei. Jede einzelne Erweiterung war begründet, aber sie passiert schnell und ungeplant. Wichtig ist, das Schema-Dokument im selben Durchgang nachzuziehen. Sonst ist es nach drei Sitzungen veraltet, und die Bases filtern auf Werte, die es nicht mehr gibt.

Nicht jede Lücke ist ein Fehler. Mehrere Notizen ohne Status-Property waren Absicht. Statt sie zu füllen, habe ich die Absicht dokumentiert (“kein Versäumnis, nicht nachbessern”), damit der nächste Aufräumdurchgang sie nicht wieder anfasst.

Nächste Schritte

Zwei Punkte sind offen. Erstens der laufende Betrieb: Eine Jahresnotiz einmal zu schreiben ist Fleißarbeit, sie aktuell zu halten ist eine Gewohnheit. Ich versuche es zunächst mit einem festen Termin pro Quartal statt eines jährlichen Kraftakts. Zweitens die Anbindung der externen Datenquelle aus Regel 4 per MCP, damit die Zahlen nicht bei jeder Aktualisierung von Hand in die Notiz wandern. Das ist geplant, aber noch nicht umgesetzt.

Fazit

Der eigentliche Aufwand war nicht das Schreiben. Acht Zusammenfassungen sind schnell erzeugt, das ist genau die Art Aufgabe, für die sich ein Modell wie Opus 5 anbietet. Der Aufwand steckte im Entscheiden: Was ist Beleg, was ist Interpretation, was bleibt offen, und welche von zwei widersprüchlichen Angaben stimmt. Diesen Teil kann mir niemand abnehmen, weil nur ich die Quellen daneben halten kann.

Was ich mitnehme: Ein Ordner, der von der eigenen Struktur ausgenommen ist, wird nicht harmlos mit der Zeit, sondern teuer. Acht Jahre lang habe ich Dinge dokumentiert und trotzdem nicht gewusst, dass sie dokumentiert sind.

Bildquelle: Eigene Erstellung, Graph View aus Obsidian