Nach dem Datenimport aus Notion stand die nächste Frage im Raum: Nach welcher Logik sollen die zusammengeführten Daten künftig geordnet werden? Naheliegend war PARA (Projects/Areas/Resources/Archive) / fortelabs.com – das bekannteste Ordnungssystem in diesem Umfeld. Es fühlte sich aber von Anfang an nicht richtig an, ohne dass ich genau hätte benennen können, warum - (siehe Beitrag 1 dieser Serie).
PARA prüfen, PARA verwerfen
Ein strukturierter Abgleich anhand mehrerer Leitfragen brachte die eigentliche Ursache ans Licht: Ich denke prozessorientiert ("was ist als Nächstes zu tun"), nicht ablageorientiert ("wo liegt das ab"). Die vier festen PARA-Kategorien wirkten für meine tatsächlichen Themen zu starr. Vor allem aber ist PARA eine reine Ablage-Taxonomie – Dashboard, wiederkehrende Reviews und Claude als aktiver Mitwirkender kommen darin schlicht nicht vor, obwohl genau das für mein System zentral sein sollte.
Referenzmodelle im Vergleich
Bevor ich PARA verworfen habe, habe ich mehrere Modelle nicht gegeneinander, sondern übereinander gelegt – als unabhängige Achsen auf denselben Inhalt, nicht als konkurrierende Alternativen:
- Workflow-Achse (C.O.D.E.): Capture → Organize → Distill → Express – beantwortet, was gerade mit einem Inhalt passiert.
- Ablage-Achse (lose PARA-Begriffe): beantwortet, wo ein Inhalt aktuell einsortiert ist.
- Reifegrad-Achse: Inbox → Seed → Growing → Evergreen – beantwortet, wie weit ein Inhalt inhaltlich verdichtet ist.
Die wichtigste Erkenntnis dabei: Ablageort und Reifegrad sind unabhängig voneinander. Eine Notiz kann bei den Resources liegen und trotzdem noch im Reifegrad Seed sein – der Ordner sagt nichts über die inhaltliche Qualität aus. Parallel dazu habe ich einen ersten System-Prompt entworfen, der Claude als Co-Piloten für dieses Second Brain positioniert – ein erster Versuch, das Konzept in eine Form zu bringen, mit der sich tatsächlich arbeiten lässt.
Klärungsbedarf unterwegs
Ein paar Punkte mussten sich im Verlauf noch präzisieren. Der wichtigste: "Archiv" sollte kein physischer Ordner sein, in den Inhalte verschwinden, sondern ein Property-Filter – der Inhalt bleibt an seinem Ort, nur sein Status ändert sich. Zwei weitere Fragen blieben zunächst offen: welches Werkzeug sich fürs Erfassen neuer Inhalte unterwegs eignet, und wie sicher automatisierte Abläufe (Cronjobs, die im Hintergrund Reviews anstoßen) laufen dürfen, ohne dass etwas unbeaufsichtigt passiert.
Die Entscheidung: ein eigenes Prozessmodell
Am Ende stand eine bewusste Richtungsentscheidung: PARA verworfen zugunsten eines eigenen Prozessmodells – Input → Review-Vorschlag → Task/Project → Extrakt → Dashboard, mit einem Cronjob und Claude als aktiven Akteuren im Review-Schritt. Entscheidend dabei: Dieser Review-Schritt erzeugt ausdrücklich nur Vorschläge, keine automatisch übernommenen Aufgaben. Erst wenn ich mich aktiv einem Vorschlag zuwende, wird daraus etwas Verbindliches. Auch die Automatisierung selbst bleibt vorerst zurückhaltend: Der Cronjob startet nur auf Anweisung, volle Automatisierung folgt frühestens, "wenn sich der Prozess bewährt hat" – eine bewusste Sicherheitsgrenze, keine technische Verlegenheitslösung.
Ergebnis
Aus diesem Abgleich ist ein konsolidiertes Zielverständnis-Dokument entstanden, das seit heute als gemeinsame Referenz für alle weiteren Arbeiten am Second Brain dient – für mich selbst ebenso wie als Grundlage, gegen die sich Claude in künftigen Sessions abgleichen lässt.
Ausblick
Mit einem Prozessmodell statt einer Ablage-Taxonomie stand fest, wie ich künftig über mein Second Brain denken will. Wie sich das auf der Werkzeugebene tatsächlich umsetzen lässt, erwies sich schnell als eigene Baustelle – etwa bei der Suche nach einem Projekt-Board, das zu diesem Prozessdenken passt, statt es zu untergraben. Davon handelt der nächste Teil dieser Serie - Wenn das Kanban-Board bricht: Grenzen des Task-Board-Plugins und der Weg zu Bases.