Der Second-Brain-Bibliothekar aus Beitrag 4 darf laut Rollenmodell keine Quellnotizen verändern – nur lesen. Das wirft sofort eine praktische Frage auf: Wie kommen seine Erkenntnisse dann überhaupt irgendwo an? Und wie bleibt nachvollziehbar, wenn derselbe Themencluster über mehrere Läufe hinweg immer wieder auftaucht? Bis zur Antwort brauchte es mehrere Entwurfsrunden – und am Ende einen ersten echten Testlauf über 100 Notizen.
Das Problem: Erkenntnisse ohne Schreibrecht
Ohne Schreibrecht auf die Quellen bleibt dem Bibliothekar nur ein Weg: ein eigenes, separates Ergebnisdokument. Aber ein einzelnes Dokument pro Lauf reicht nicht, wenn Cluster nicht sauber voneinander abgegrenzt sind oder derselbe thematische Zusammenhang bei jedem neuen Lauf wie ein völlig neuer Fund erscheint, obwohl er eigentlich zu einem bereits bekannten Thema gehört.
Ein Schema, das mehrere Runden brauchte
Das Übergabe-Artefakt-Schema ist deshalb nicht am Reißbrett entstanden, sondern iterativ auf einem Canvas gewachsen, in mehreren geprüften und verfeinerten Runden. Zentrale Bausteine am Ende: eine kategorie ("Neues Potenzial" vs. "Ergänzung/Synergie"), ein Reifegrad (Inbox → Seed → Growing → Evergreen) sowie eine Cluster-ID. Die Cluster-ID war dabei die wichtigste Designentscheidung: Sie ist bewusst persistent, wächst über mehrere Läufe hinweg statt bei jedem Lauf neu zu beginnen. Der Gedanke dahinter: Es geht nicht nur darum, Muster vorzugeben, sondern ihnen auch zu erlauben, sich über Zeit weiterzuentwickeln. Aus dem Canvas-Entwurf wurde anschließend eine echte Vorlage plus eigene Datenbank im Vault.
Technische Grenzen unterwegs
Nicht alles ließ sich wie geplant umsetzen. Die Cluster-ID hat keine live nachschlagbare Referenz – aus einer Datenbank-Formel heraus lässt sich in Obsidian derzeit keine Property einer verlinkten Notiz auslesen, bestätigt gegen die offizielle Dokumentation. Auch die Routing-Regel, die festlegt, welche Kategorie an mich direkt geht und welche an den Agenten Cowork, ist bislang nur vorläufig – "erstmal so, und dann sehen, wie das im Alltag funktioniert", mit einem noch terminlosen Review nach etwas praktischer Erprobung. Und wer über die Basis-Einstufung hinaus einen höheren Reifegrad vergeben darf – ich selbst beim Sichten, oder der Second-Brain-Bibliothekar heuristisch beim Verarbeiten –, war mangels ausreichender Praxisdaten schlicht noch nicht zu entscheiden.
Drei echte Testläufe
Trotz dieser offenen Punkte bin ich nicht beim Entwerfen stehen geblieben, sondern habe das Schema dreimal an echten Daten getestet: einmal als Audit der bestehenden Themenfelder-Liste, einmal als Abgleich eines einzelnen Inputs gegen bereits vorhandene eigene Ausarbeitungen, und schließlich als eigentlicher Belastungstest – ein Batch-Lauf über 100 Input-Notizen. Ergebnis dieses dritten Laufs: sieben Übergabe-Artefakte, von einem 32 Quellen starken Cluster zu Obsidian-Tooling bis zu einem einzelnen, aber wertvollen Duplikat-Hinweis. Parallel dazu habe ich die Reifegrad-Baseline "Inbox" rückwirkend auf den gesamten Bestand angewendet – 1.662 von 1.665 Input-Notizen, bewusst ohne Sonderbehandlung der Notizen, die durch den Testlauf bereits mit einem Cluster verknüpft waren.
Ergebnis
Das Rollenmodell aus Beitrag 4 hat sich damit erstmals nicht nur auf dem Papier, sondern an echten Daten bewährt. Ganz abgeschlossen ist das Thema damit aber nicht: Offen bleiben unter anderem eine echte Liste noch unausgereifter Cluster über mehrere Läufe hinweg, die Überprüfung der Routing-Regel nach etwas mehr Praxis, die eigentliche Hochstufungslogik über die Baseline hinaus, ein vollständiger Duplikat-Scan über den gesamten Bestand sowie ein Log, das echte Übergaben zwischen den Rollen nachvollziehbar macht.
Ausblick
Der Testlauf hat vor allem eines gezeigt: Wie gut der Bibliothekar clustern kann, hängt direkt davon ab, was überhaupt an Input hereinkommt – und wie es dort ankommt. Genau darum geht es im nächsten Teil dieser Serie: die verschiedenen Wege, auf denen neues Wissen mein Second Brain überhaupt erreicht.