Hvad OKF er, og hvorfor det rammer et ømt punkt nu
Google Cloud har løftet sløret for Open Knowledge Format v0.1 – OKF – et åbent, leverandørneutralt format, der beskriver virksomheders viden som en mappe med Markdown-filer og YAML-frontmatter. Ifølge MarkTechPost, der først rapporterede lanceringen, formaliserer OKF LLM-wiki-tilgangen, så agenter og mennesker læser samme kuraterede kontekst uden endnu et katalog eller SDK. Timingen giver mening: foundation-modeller er stærke, men falder stadig, når intern kontekst mangler eller er spredt.
MarkTechPost skriver direkte: “There is no compression scheme, no new runtime, and no required SDK… It renders on GitHub, ships as a tarball, and mounts on any filesystem.” Det er kernen. Bare filer, der kan bo i git og bruges af både mennesker og agenter.
Struktur i v0.1 og designvalget
OKF v0.1 modellerer viden som en mappestruktur med konceptfiler for tabeller, datasæt, metrikker, playbooks, runbooks og API’er. Ét koncept per Markdown-fil. Filstien er identiteten. Øverst ligger en kort YAML-frontmatter med felter som type, title, description, resource, tags og timestamp. Relationer laves med almindelige Markdown-links, så der opstår en simpel graf på tværs af mapper.
Pointen er bevidst enkelhed. OKF er et format, ikke en platform. Ingen serverkomponent, ingen tvungen klient. Den enkelhed flytter arbejdet over til teams: implementering, validering og styring skal man selv lave.
Det fragmenterede kontekstproblem
I mange organisationer er modelkontekst spredt i siloer: metadata-kataloger med egne API’er, wikis, delte drev og kodekommentarer. Det gør viden ikke-portabel og tvinger hvert agentteam til at genskabe samme opsamling af skemaer, metrikdefinitioner, runbooks og join-stier. MarkTechPost rammer den frustration præcist og kobler den til Karpathys LLM-wiki-idé: lad filer og krydsreferencer være strukturen, som modeller kan læse og vedligeholde.
Det hænger også sammen med bredere modelnyheder. Google DeepMinds Gemma 4-familie er udgivet på Amazon Bedrock. Modeller flytter frit mellem skyer; virksomhedsviden gør sjældent. Derfor vokser behovet for et bærbart kontekstlag.
Hvad OKF løser – og hvad der er uden for scope
OKF giver et fælles, tekstbaseret lag for nøglekontekst: skemaer, metrikker, runbooks og henvisninger. Det reducerer dobbeltarbejde, hvor alle ellers opfinder egen “AGENTS.md”. Den lave friktion øger sandsynligheden for import/eksport på tværs af værktøjer.
Men realtid lever et andet sted. En mappe kan opdateres ofte, men er ikke et feed for transaktioner eller alarmer. Sikkerhed og autorisation er heller ikke en del af formatet. Governance opstår gennem processer som git-branching, reviews og versionstags – hvis de bliver brugt.
Operationelle konsekvenser man ikke slipper for
At vælge OKF er at bygge processer omkring filer. Hvem godkender en metrik, før den merges? Hvilken version må forsyne produktionsagenter? Hvem ejer “orders.md”, når to domæner gør krav? De beslutninger venter ikke. Git hjælper, men er ikke governance i sig selv.
Indeksering og søgning bliver lokale valg. En RAG-pipeline kan crawle mapper og lave embeddings per fil eller afsnit. Uden referenceimplementering er performance og relevans et teamansvar. Det kan bide, især når repoet vokser.
Et konkret fejlscenarie – og hvordan OKF strammer skruerne
Forestil dig en RAG-agent, der svarer på “hvad er WAU for produkt X i Norden”. Den henter en gammel metrikbeskrivelse fra en wiki, hvor WAU måles på en session-nøgle. I datalagret er definitionen opdateret til unikke brugere med et 28-dages vindue. Svaret bliver forkert, dashboards og beslutninger følger efter.
Med OKF ligger “weekly_active_users.md” ved siden af de relevante tabeller og dashboards. Frontmatter indeholder title, type og resource, og brødteksten forklarer ændringen samt linker til PR’en, der indførte vinduet. Agenten indlæser samme fil, som mennesker læser, og kan henvise til netop den version. Færre tvivlssvar. Mindre rod i definitioner.
Interoperabilitet, lock-in og kildeklarhed
Den store gevinst kræver broer: “eksporter til OKF” og “importer fra OKF” i kataloger, agent-frameworks og dokumentationsværktøjer. MarkTechPost nævner ikke konkrete partnere eller udrulninger. Kilderne linker heller ikke til en officiel specifikation eller et GitHub-repo, så licens og fremtidig steward er uklare. Det er et åbent punkt.
Konsekvensen er enkel: prøv formatet i periferien først. Byg en tynd bro ind og ud af jeres eksisterende værktøjer, mål effekten, og vent på officiel dokumentation før en bred konvertering.
Sikkerhed, compliance og den kedelige virkelighed
Filer er praktiske – og lette at lække. Krypter lagre. Sæt filsystemrettigheder. Kontroller distributionsveje. Hold styr på hvem der må hente tarballs og mounte dem i agentmiljøer. Brug scanning for hemmeligheder i CI.
I praksis vil regulatoriske krav og interne godkendelsesprocesser begrænse autonome agenters adgang til følsomme kilder. Læg derfor eksplicitte godkendelseslag ind i workflows: review af ændringer, signering af versioner og segmentering af repos efter følsomhed. Et tekstligt, versioneret format hjælper sporbarhed, men erstatter ikke kontroller.
Validering og performance i praksis
Der findes enkle værn der virker: schema-validering af YAML-frontmatter i CI, pre-commit hooks der nægter brudte links og manglende felter, samt konventioner for fil- og mappenavne. Det lyder småt, men det er her orden opstår.
For ydeevne: chunk per overskrift eller afsnit, cache embeddings per filhash, og prioriter centrale koncepter i indekset. Log kildehenvisninger systematisk, så drift kan genskabe svar med præcis kontekst.
Tradeoffs der er værd at kende
Enkelhed vs. semantik. Portabilitet vs. stringent validering. Lokal fleksibilitet vs. fælles tooling. OKF vælger enkelhed og portabilitet. Starten er let, men uden interne standarder for navngivning, tags og linking bliver grafen mudret.
Skalerbarhed er ubesvaret i kilderne. Hvad sker der, når tusindvis af filer krydslinker? Hvilke opskrifter anbefales for chunking, prioritering og caching? Det bør følges op hos Google Cloud.
Relationen til eksisterende idéer
Karpathys LLM-wiki-gist fremhæver, at modeller trives med bogholderi-arbejdet: krydsreferencer, ensartethed, mange filer i én omgang. MarkTechPost kobler den historik til OKF som et forsøg på at gøre mønsteret delbart og forudsigeligt.
Har man brugt Obsidian, AGENTS.md-konventioner eller “metadata as code”, vil formen føles genkendelig. Forskellen er ambitionen om et fælles sæt felter og en stabil mappestruktur. Om det rækker, afhænger af værktøjsadoption.
Praktiske næste skridt for tekniske teams
En kort prioriteringsliste virker bedst:
- Start småt: formalisér 5–10 metrikker, 3–5 kritiske tabeller og 2 runbooks i OKF-struktur. Læg dem i git med reviews.
- Byg en enkel RAG-crawler, der indlæser OKF-mappen, chunker per overskrift eller paragraf og logger kildehenvisninger i svar.
- Definér ejerskab per mappe. Én ansvarlig pr. domæne.
- Kør hemmelighedsscanning i CI, så nøgler og credentials ikke ender i Markdown.
- Aftal en frigivelsespolitik: kun taggede versioner må bruges af produktionens agenter.
Det er nok til at teste, om agentsvar bliver bedre, og om sporbarhed hjælper drift.
Adoption, licens og åbne spørgsmål
MarkTechPost tilskriver initiativet Google Cloud, men peger ikke på en officiel specifikation, et repo eller en governance-model. Det efterlader licens og steward-rolle uklare – en hæmsko for bred adoption, indtil noget officielt dukker op.
Dertil kommer praktiske huller: hvem bygger import/eksport i populære værktøjer, og hvordan håndteres udvidelser af felter og konventioner uden at bryde kompatibilitet?
Konklusion
OKF går efter et reelt problem med et jordnært greb: færre platforme, flere filer. For AI-agenter kan det blive en stabil, læsbar og delbar kilde til virksomhedens nøglekontekst.
Men arbejdet ligger hos jer: versionering, ejerskab, sikkerhed, validering og værktøjskæder. Start småt med metrikker, tabeller og runbooks, mål effekten i jeres RAG-pipeline, og byg først derefter bredere – når den officielle dokumentation også er på plads.
