OpenWiki 0.2 brings OKF to codebase documentation

Vince The thing I like here is they're not claiming magic. They're basically saying your repo wiki got too big and your agent keeps rummaging through drawers.

Ava Yeah.

Vince And honestly, that is such an Exploring Next problem to spend a Wednesday on. But it's a real one.

Ava It is. The actual argument isn't 'documentation matters,' which, fine, everybody says that. It's that once the wiki is hundreds of files, free-form markdown stops being enough for discovery and updates, especially if an agent is the thing reading it.

Vince Right, right.

Ava So OpenWiki zero point two adds OKF support, and the bet is pretty modest. Put structured metadata in every doc, add directory indexes, add a running log, and you cut down search time and token spend for simple retrieval.

Vince Which is a product claim I actually buy. If your coding agent has to do open-ended scavenger hunts through a giant repo wiki, that is cost, latency, and weirdness all at once.

Ava Exactly.

Vince And you can hear your ep seven hundred brain kicking in here. It's the same thing we keep landing on. Better surfaces beat raw capability when the loop is messy.

Ava Yeah, no, that's basically it. The mechanics are simple too. Each markdown file gets YAML front matter with fields like type, title, description, tags, categories, resource, timestamp. Then OKF uses conventions like index dot M D for summarizing a directory, and logs dot M D for what changed over time.

Vince Mm-hm.

Ava The nice part is the index can be generated deterministically from those description fields. So instead of an agent reading twenty sibling files to figure out what's in a folder, it can start from the index. And the log means after an update run, it can inspect the delta instead of rereading the whole wiki.

Vince That log part is sneaky useful. You know what it reminds me of? Your whole failure-label bottleneck rant, except for docs. Don't give me a vibe check for the whole wiki. Tell me what changed and where to inspect first.

Ava Oh interesting.

Ava Yes, and thank you for stealing my point correctly. The sample they give is dead simple too. Added new BigQuery table reference here. Created a Dataplex playbook there. That's enough to route attention without pretending the log is the documentation itself.

Vince Ha! okay. I'm writing down 'stealing my point correctly' for the fake merch store we absolutely should not open.

Ava Oh, come on.

Vince No, because it'd be one shirt and somehow still need a metadata schema.

Ava Stop it. Also, my week's been weirdly pleasant, so I'm less ready than usual for your nonsense.

Vince Good. Stay off the ledge for one episode, Ava.

Ava I wasn't on a ledge. I was on a well-labeled balcony with front matter.

Vince Oh no. Okay, but technically, does their case hold up for you?

Ava Mostly, yes. I think the strongest part is where they stop short of saying structured metadata replaces agentic search. They explicitly frame it as a cleaner path for simple lookups. Filter docs by a BigQuery tables category, or by a billing tag, rather than making the model infer everything from prose.

Vince Sure.

Ava That's real. Deterministic retrieval for obvious cases is cheaper and usually better behaved. Where I'd be careful is the overhang. Metadata only helps if the descriptions are good, the tags are maintained, and the taxonomy doesn't turn into junk drawer syndrome after a month.

Vince Yeah, that's the part where my optimism has paperwork attached. Because if this ships into a team that already can't keep docs fresh, adding YAML doesn't save them. It just gives them a more structured stale mess.

Ava Right.

Vince But if they're already using OpenWiki to generate and maintain docs, then this is exactly the kind of upgrade that can matter without fanfare. Fewer tokens burned on dumb lookup. Easier review. Better handoff into AGENTS dot M D or CLAUDE dot M D. That's not glamorous. It ships.

Ava And the open-format angle is probably the second real claim. Because OKF is drafty, to be clear, version zero point one draft, so I would not act like the standard is settled. But if multiple tools can read the same wiki shape, then you get viewers, linters, visualizers, all that, without one vendor owning the container.

Vince Which is the part I like more than the branding, honestly. I don't care that it's called OKF. I care that a repo wiki stops being a weird private export format nobody else can touch.

Ava Yeah. Google apparently has an open-source OKF visualizer, and the post points to ecosystem tools and an OpenSWE example. That's enough for me to say there is at least the beginning of an ecosystem, not just a lonely spec document.

Vince So who actually cares? I think pretty narrow, but in a good way. Big codebase, agent-heavy workflow, docs already painful, and enough discipline that generated structure won't rot instantly. That's the buyer.

Ava I agree. If your repo is small, this is probably overkill. If your agent mostly works from local code search and tests, same story. But once the wiki becomes a retrieval layer, structure stops being ceremony and starts being systems work.

Vince And if somebody wants to try it, the concrete bit is at least real. The repo is langchain A I slash openwiki, and the local install is N P M install dash G openwiki at latest, then openwiki dash dash init.

Ava I could be wrong, but this feels like one of those boring upgrades that ages well. Not because the format wins some standards war. Just because agents hate rummaging.

Vince That's clean. All right, go enjoy your well-labeled balcony. I'll go admire the one shirt in our cursed merch catalog.