Zbudowałem drugi mózg. Trafiłem w standard Google (OKF)

Zbudowałem drugi mózg. Okazało się, że w 100% trafiłem w standard Google (OKF)

Jakiś czas temu opisałem, jak LLM Wiki Karpathy'ego pomogła mi uporządkować moją bazę wiedzy - ponad 300 notatek, którymi zarządza agent, trzy indeksy nawigacyjne, workflow do ingestu i kompilacji. System działa. Codziennie. To mój drugi mózg.

Ale ostatnio złapałem się na niewygodnym pytaniu. Cała ta wiedza żyje w moich narzędziach - w Obsidian, w Quartz, w moim CLAUDE.md. A co, jeśli zechcę ją komuś przekazać? Zmienić tool? Albo potraktować jako aktyw firmowy, który ma przeżyć dowolny program i dowolny model? Notatki zamknięte w czyimś prywatnym formacie to vendor-lock-in - tyle że zrobiony własnoręcznie.

Wniosek, do którego doszedłem, jest prosty: trwałość wiedzy to nie narzędzie - to format. I wtedy trafiłem na OKF (Open Knowledge Format) od Google. Zrobiłem audyt swojego brain pod kątem tego standardu, spodziewając się sporego rozjazdu. Wynik mnie zaskoczył: zgodność w okolicach 100% - mimo że nigdy nie projektowałem brain pod OKF. W tym artykule pokażę, dlaczego tak się stało, co dokładnie sprawdziłem i co wtedy, gdy czysty markdown to za mało. Bez teorii - konkretny audyt i konkretne liczby.

Czym jest OKF (Open Knowledge Format)

OKF to otwarty format zapisu wiedzy, zaprojektowany pod erę agentów. Technicznie nie ma w nim magii: to markdown + frontmatter YAML. Cała filozofia mieści się w jednym haśle wzorca - „authored by people, generated by agents" (tworzą ludzie, generują i utrzymują agenci). Dokładnie ten podział, który u siebie wypracowałem organicznie.

Podstawową jednostką jest Knowledge Bundle - katalog plików .md. Może być repozytorium git, tarballem albo podkatalogiem. I to jest sedno przenośności: git clone i masz całość. Wewnątrz Concept to jedna myśl - jeden plik .md = jeden koncept (frontmatter plus treść markdown). Format rezerwuje dwie nazwy plików: index.md (listing katalogu pod progressive disclosure) oraz log.md (chronologia zmian, najnowsze u góry).

Najciekawsza jest minimalna bariera wejścia. Jedyne twardo wymagane pole frontmattera to type. Cała reszta - title, description, resource, tags, timestamp - jest zalecana, ale opcjonalna. Producent może dodawać własne klucze, a konsument musi tolerować nieznane pola i broken links. Najprostszy zgodny koncept wygląda tak:

---
type: note
---
Treść notatki w czystym markdownie.

Warto rozumieć różnicę między OKF a LLM Wiki. OKF to specyfikacja interoperacyjności - mówi „jak zapisać wiedzę, żeby była wymienialna". LLM Wiki to metodologia pracy - mówi „jak agent ma tę wiedzę budować i utrzymywać". To dwie komplementarne warstwy, a nie konkurencja.

Jedna uczciwa uwaga. Repozytorium OKF ma wprost notkę: „This repository and its contents are not an official Google product". OKF to otwarta specyfikacja interoperacyjności, a nie produktowe zobowiązanie Google.

Mój brain trafił w standard - choć go pod niego nie projektowałem

To jest serce tej historii. Zrobiłem realny audyt zgodności brain z OKF v0.1. Werdykt jednym zdaniem: brain przechodzi 100% twardych warunków conformance OKF v0.1; rozbieżności są wyłącznie w warstwie rekomendowanej, czyli kosmetyce.

Spec definiuje trzy twarde warunki zgodności. Brain spełnia wszystkie trzy:

Liczby na głos: twarda zgodność = 100% (3/3). Warstwa rekomendowana (te wszystkie opcjonalne pola i konwencje) to ~85-90%. I tu robi się ciekawie, bo wszystkie cztery rozbieżności są nazewniczo-składniowe - dotyczą tego, jak coś nazwałem, a nie tego, jak modeluję wiedzę:

Spójrz na kolumnę „Charakter". Nigdzie nie ma „brakuje mi tej koncepcji" - wszędzie jest „nazwałem to inaczej" albo „narzędzie kompiluje to za mnie". Wikilinks Obsidian są pełnoprawnymi linkami OKF po buildzie Quartz. _indexes/ pełni dokładnie rolę index.md. Pola mapują się jeden do jednego.

„Zgodność nie jest przypadkiem - brain i OKF wyrastają z tej samej koncepcji LLM Wiki Karpathy'ego. OKF to spec interoperacyjności, brain to działająca implementacja. Różnice to wybory narzędzia, nie różnice modelu wiedzy."

To jest konwergentna ewolucja. Dwa systemy budowane niezależnie - specyfikacja w Google i mój vault w Obsidian - zbiegły się do tego samego kształtu, bo wyrosły z tej samej idei. I właśnie dlatego standard jest wiarygodny: nie wymyślono go zza biurka, tylko spisano to, do czego praktyka i tak dąży.

Dlaczego format ma znaczenie

Można zapytać: skoro mój system działa, po co mi w ogóle standard? Odpowiedź to pięć konkretnych rzeczy, które daje format - a których nie da żadne pojedyncze narzędzie:

• Przenośność. „If you can git clone it, you can ship it." Bundle to repozytorium - kopiujesz całość i działa u kogokolwiek, bez instalacji, bez konfiguracji, bez zależności od mojego setupu.
• Interoperacyjność. Bundle wiedzy można wymieniać niezależnie od narzędzia. Eksport z mojego brainu, import do cudzego. To realny przyszły kierunek produktowy - ekstrakt bazy jako gotowy bundle OKF.
• Trwałość i future-proofing. Narzędzia umierają, format zostaje. Markdown plus frontmatter przeżyje Obsidian, przeżyje Quartz, przeżyje konkretny model LLM. Za pięć lat wciąż otworzysz te pliki.
• Czytelność podwójna. Ten sam plik czyta agent i człowiek. Bez żadnego toola wystarczy go otworzyć w edytorze - to nie baza w zamkniętym formacie binarnym.
• Aktyw, nie silos. Wiedza zapisana w standardzie staje się zasobem, który da się audytować, przekazać i wycenić. I to jest most do kolejnego pytania - co, gdy ten aktyw rośnie do skali firmy.

Gdy czysty markdown to za mało - Google Knowledge Catalog

Tu zmieniam ton na ostrożny. Tego fragmentu nie testowałem - sygnalizuję kierunek, nie wystawiam rekomendacji.

Karpathy sam zakreśla skalę, na której to podejście działa: „moderate scale (~100 sources, ~hundreds of pages)" - zanim potrzebny staje się embedding-based search. Mój brain to dziś rzędu 300 notatek, czyli wciąż ten przedział: czysty markdown z indeksami ogarnia go bez embeddings i bez infrastruktury RAG. W poprzednim artykule pokazywałem ten mechanizm w liczbach: progressive disclosure daje tam około 30× mniej kontekstu na zapytanie niż wrzucanie całego vaulta. To nie twardy limit - raczej rząd wielkości, do którego index-first pozostaje wygodny. Na osobisty drugi mózg w zupełności wystarcza. Ale powyżej - przy milionach dokumentów, danych ustrukturyzowanych i nieustrukturyzowanych jednocześnie, wielu agentach pracujących równolegle - to inna liga.

Tu wchodzi Google Knowledge Catalog (managed, wg strony produktu „formerly Dataplex"). Google opisuje go jako „universal context engine for your enterprise" - „always-on context and governance for your agents". Zamiast Twoich notatek kataloguje cały data estate: automatycznie zbiera metadane z BigQuery, AlloyDB, Spannera czy Lookera, a źródła nieustrukturyzowane - PDF-y, kontrakty, wiki - zamienia w „structured knowledge graph", który agent może odpytać. To samo repozytorium (GoogleCloudPlatform/knowledge-catalog), które zawiera katalog okf/, trzyma też samples/ i toolbox/.

Widać tu ciągłość, nie przeskok. Ta sama idea - wiedza ustandaryzowana, semantyczna, czytelna dla agentów - tyle że na poziomie przedsiębiorstwa. OKF i LLM Wiki to skala osobista; Knowledge Catalog to skala firmowa. Jeden łańcuch, dwa końce.

Gdzie dokładnie jest granica? To nie jest „local vs cloud" - mój brain też stoi w chmurze. Różnica jest jakościowa, na czterech osiach:

• Co katalogujesz. Brain = Twoje autorskie notatki. Catalog = warstwa semantyczna nad całym, żywym data estate firmy: tabele, hurtownie, pliki, modele BI.
• Silnik retrieval. Brain = index-first plus progressive disclosure, bez embeddings. Catalog = semantic search z sub-sekundową latencją nad knowledge graphem milionów encji.
• Governance. Brain = git i konwencje. Catalog = polityki dostępu (IAM), data quality, lineage, audyt - retrieval respektuje uprawnienia, więc agent widzi tylko to, do czego ma prawo.
• Świeżość i współbieżność. Brain = snapshot, który sam utrzymujesz. Catalog = always-on, aktualizuje się wraz z danymi i obsługuje wielu agentów naraz przez Context API i MCP tools.

Liczba plików to tylko objaw. Prawdziwa granica to typ danych plus silnik retrieval plus governance plus dynamika. Dla osobistej wiedzy w prozie czysty markdown wygrywa prostotą; dla firmowego, heterogenicznego data estate potrzebujesz warstwy pokroju Knowledge Catalog.

I jeszcze raz, bo to ważne: repozytorium OKF nosi notkę „not an official Google product", a Knowledge Catalog opisuję tu wyłącznie jako kierunek, którego sam nie wdrażałem. Bez obietnic co do funkcji produktu.

Co z tego wynika

1. Format wygrywa z narzędziem. Jeśli budujesz bazę wiedzy, projektuj ją pod standard od pierwszego dnia. Migracja później kosztuje - zgodność od startu jest darmowa.
2. Zgodność bywa konwergentna. Jeśli twój system wyrasta z dobrej idei (LLM Wiki), masz szansę trafić w standard bez celowania w niego. To dobra wiadomość: nie musisz przepisywać brainu, prawdopodobnie wystarczy go wyeksportować.
3. Wiedza w standardzie to aktyw. Przenośny, audytowalny, wymienialny - i skalujący się od osobistego brain po Knowledge Catalog.

Jeśli chcesz zacząć z gotowym fundamentem, udostępniam szablon second-brain-template - „Use this template", /onboard, pierwszy ingest i masz własny system zgodny ze standardem w kilka minut. Pracuję też nad szerszymi materiałami o budowaniu drugiego mózgu - jeśli temat cię interesuje, warto trzymać rękę na pulsie.

Przydatne zasoby

• Jak LLM Wiki Karpathy'ego pomogła mi uporządkować bazę wiedzy - bazowy artykuł o LLM Wiki, progressive disclosure i architekturze brainu
• Second brain w Obsidian i Claude Code - jak zacząć od zera
• brain.lipowczan.pl - żywa instancja mojego drugiego mózgu
• second-brain-template - gotowy szablon do startu
• OKF / knowledge-catalog (repo) - specyfikacja OKF w katalogu okf/ (uwaga: „not an official Google product")
• Google Knowledge Catalog - managed platforma katalogu danych (skala enterprise)

FAQ

Czym jest Open Knowledge Format (OKF) i kto za nim stoi?

OKF (Open Knowledge Format) to otwarta specyfikacja zapisu wiedzy oparta na markdown plus frontmatter YAML, zaprojektowana pod pracę z agentami AI. Specyfikacja żyje w repozytorium GoogleCloudPlatform/knowledge-catalog w katalogu okf/. Ważna uwaga: repozytorium nosi notkę „This repository and its contents are not an official Google product" - to otwarty standard interoperacyjności, nie produktowe zobowiązanie Google.

Czym OKF różni się od LLM Wiki Karpathy'ego?

OKF to specyfikacja interoperacyjności - definiuje, jak zapisać wiedzę, żeby była przenośna i wymienialna między narzędziami. LLM Wiki to metodologia pracy - opisuje, jak agent ma budować i utrzymywać bazę wiedzy. Są komplementarne: OKF mówi o formacie, LLM Wiki o procesie. Działająca baza wiedzy korzysta z obu warstw naraz.

Jedyne wymagane pole w OKF to type - co to oznacza w praktyce?

Oznacza minimalną barierę wejścia: zgodny plik OKF musi mieć tylko niepuste pole type we frontmatterze, a cała reszta (title, description, tags, timestamp) jest opcjonalna. Producent może dodawać dowolne własne klucze, bo konsument formatu musi tolerować nieznane pola i broken links. Dzięki temu standard jest liberalny przy zapisie, a rygorystyczny tylko tam, gdzie to konieczne.

Czy moja istniejąca baza w Obsidian jest zgodna z OKF?

Najprawdopodobniej w dużej części tak, zwłaszcza jeśli używasz plików .md z frontmatterem. W moim audycie brain przeszedł 100% twardych warunków conformance OKF v0.1 (3/3), a rozbieżności były wyłącznie kosmetyczne. Wikilinks [[...]] Obsidian kompilują się przez Quartz do linków [label](path), a pola jak summary czy date mapują się jeden do jednego na description i timestamp przy eksporcie.

Kiedy czysty markdown przestaje wystarczać i wchodzi Google Knowledge Catalog?

Podejście index-first na czystym markdownie działa świetnie w skali osobistej - rzędu setek notatek (mój brain to dziś nieco ponad 300), bez embeddings i bez infrastruktury RAG. To nie twardy limit, tylko rząd wielkości. Powyżej - przy milionach dokumentów, danych ustrukturyzowanych i nieustrukturyzowanych oraz wielu agentach naraz - wchodzi skala enterprise, którą adresuje Google Knowledge Catalog (managed, „formerly Dataplex"). Zaznaczam jednak, że tego progu osobiście nie testowałem - sygnalizuję kierunek, nie rekomendację produktową.