Building an Open Knowledge Format with Draft_: the practical guide
An OKF bundle is just a directory of tidy Markdown files: exactly what Draft_ produces, with nothing to configure. Why write your knowledge base in a Markdown word processor, then hand it as-is to an AI agent. Three cases where it changes everything.
Google’s Open Knowledge Format (OKF) requires no proprietary tool. A bundle is a directory of Markdown files, a little YAML frontmatter, links between concepts, and that’s it. In other words, the format is already your text editor.
That said, “possible” and “pleasant” aren’t synonyms. Writing a knowledge base is a writing job: you want a calm place to do it, not a terminal. That’s where Draft_ fits, not thanks to a dedicated “OKF” feature, but because its native format is already OKF’s. Let’s see why, then three concrete cases where it counts.
Why a Markdown word processor for OKF?
OKF separates two roles: the one who produces the knowledge and the one who consumes it. The consumer is an AI agent. The producer is a human who writes, and who deserves better than an input box to do it.
This reversal is Draft_’s line: you feed the AI, the AI doesn’t create in your place. OKF may address machines, but everything it contains is born of human thought, written, structured, owned. And who holds the keyboard is not a neutral choice: handing writing over to an assistant carries a now-measured cognitive cost, from mental overload to AI dependence, while the neuroscientific hierarchy hand > keyboard > AI shows that it is the writer’s engagement that gives value to what is produced. A knowledge base is only worth what you put into it. Better to write it yourself, in a tool built for that.
Now, OKF’s building blocks are, one by one, Draft_’s:
| OKF convention | Draft_, as it stands |
|---|---|
| Directory of Markdown files | Native storage format |
| YAML frontmatter | Metadata zone at the top of a document |
| Cross-links between concepts | Relative internal links ([text](../folder/doc.md)) |
| Tree of concepts | Spaces and folders |
| Versioned bundle | Built-in GitHub sync |
| Human-readable | Distraction-free Markdown editor |
Nothing to install, nothing to wire up. The match is no accident: OKF simply formalized what good Markdown editors have done for a long time.
The concrete workflow
You create a space: that’s the root of your bundle. You arrange folders inside (characters/, tables/, places/…) that become the families of concepts. Each document opens with a metadata zone where you type the frontmatter in plain text (type: Character, title, tags), without even the --- delimiters, which Draft_ adds on export. The document name becomes the filename (orders → orders.md), so you control the path of each concept; your internal links become the edges of the graph the agent will follow; and GitHub sync turns the whole thing into a versioned repository. A valid OKF bundle, produced in an editor where you mostly wrote.
Three concrete cases
Case 1: the bible of a fiction universe
You’re writing a novel, a series, a game. You keep a bible/ space:
characters/
└── elena.md (type: Character)
places/
└── valdris.md (type: Place)
factions/
└── iron-pact.md (type: Faction)Elena’s sheet cites Valdris and the Iron Pact through simple links. Later, you hand the repository to an LLM: “Here’s my bible. Write a scene where Elena returns to Valdris, faithful to her history and to the atmosphere of the place.” The agent pulls up the relevant sheets by following the links and writes within your universe, without you having to re-explain it every session. Your consistency becomes an asset, not a mental burden.
Case 2: living technical documentation
You document an API or a product, by type: endpoints/, concepts/, runbooks/, each with its type. The repository lives alongside the code, in the same GitHub, versioned by the same commits. The docs stop being a parallel wiki that goes stale: they’re readable by a CI agent, by the assistant that answers the team’s questions, or by the developer who starts on Monday. One source, and everyone, humans and machines alike, drinks from it.
Case 3: queryable research notes
You accumulate notes on a topic: competitors, readings, ideas. Each note is a concept, linked to the others. The synced bundle becomes an external memory you query: “What tensions run through these two approaches in my notes?” The LLM traverses the graph of your thinking to answer: not Wikipedia, your own reasoning, structured and cited.
The scope, in one line
Draft_ covers the human link of the OKF chain: writing, naming, linking, versioning. Consumption then happens with any LLM, and that’s the whole point of a portable format. You type the frontmatter and you keep control of consistency, exactly the level of control you’d expect from careful writing work.
In short
- An OKF bundle is a directory of Markdown + YAML frontmatter; Draft_ produces it natively.
- Space = root, folders = concepts, metadata zone = frontmatter, document name = filename, internal links = graph, GitHub sync = versioned bundle.
- You write in a real word processor, then hand the knowledge as-is to an agent.
- Three playing fields: fiction bible, living technical docs, queryable research notes.
To start building your OKF knowledge base, you already have everything you need in Draft_: you write, you name, you sync. The rest is Markdown, and it’s already in your hands.