Open Knowledge Format plugin for portable LLM wikis · OpenKnowledge<br>3.6K

The Open Knowledge Format (OKF) is an open specification released by Google to help make knowledge bases portable and interoperable.

Today, we are introducing the OKF plugin for the OpenKnowledge app, which applies default linting rules, skills, and automations to help you and your agents create, port, and maintain an OKF-conformant LLM wiki automatically.

To see the format in practice, explore the Odyssey OKF wiki, our example knowledge base that follows the format.

What is the Open Knowledge Format?

OKF was introduced in June 2026 by Google. It has three core goals:

Trust - Consumers want to know who made or validated a change to knowledge and when, with properly traceable sources and provenance.

Portability - The knowledge should be readable and editable with any editor or client, which is why the content is still just markdown and YAML.

Human & Agent Consumption - Agents need to know how to consume a knowledge base. They shouldn't need to learn all the quirks of each and every one.

OKF is not a linter, editor, execution engine, or a registry for document types.

Instead, it is a specification for how to format and organize your knowledge base.

Our new plugin helps you conform to that specification automatically.

Why use the OKF plugin?

We built the OKF plugin to translate the specification into a linter and auditor on the format's guidelines.

It leverages our content rules system to apply OKF-specific rules and report issues within the editor, CLI, and problems panel to surface any issues as you work.

This content rules system is also catered to your agents. When an agent is working on a file, our MCP tools give hints and warnings as agents write, so they can fix any issues immediately. Agents can also run the lint and audit MCP commands to identify and fix any issues with the entire project at any time.

The Rules

The OKF plugin currently supports the OKF v0.2 format, with rules regarding frontmatter, reserved files, and portability.

Note: Like all our content rules, everything it flags is a warning. It never blocks you or your agents from saving work.

Frontmatter

Frontmatter is best described as "properties for markdown documents" . These properties are shaped as a short YAML doc bounded by dividers at the top of any given markdown file. We support six different frontmatter rulesets from the format's spec: required, recommended, provenance, computation, and two for index files. Each of these rulesets generates a JSON schema in the .ok/okf subdirectory when toggled on.

For all files, there is only one requirement that needs to be satisfied for it to be considered conformant:

yaml<br>type: some-string # some non-empty string

All documents must carry a type. It can be as simple as document or spec, but it must exist.

The format does, however, recommend a set of optional fields for more details:

yaml<br>title: Some title # recommended, optional<br>description: "Some description" # declaring one only pins its shape<br>tags: [tag1, tag2] # a LIST, not a comma-separated string<br>resource: https://... # recommended, optional<br>anything_else: fine # unknown keys must not be rejected

Provenance, trust, and lifecycle frontmatter

The spec includes a recommended schema that aims to answer:

Where did this come from?

How much should you trust this?

Is this still current?

yaml<br>sources:<br>- resource: https://github.com/.../okf/SPEC.md<br>id: okf-spec<br>title: Open Knowledge Format specification, v0.2<br>last_modified: 2026-07-25<br>generated: { by: human:serafin, at: 2026-07-31T12:00:00Z }<br>verified:<br>- { by: human:serafin, at: 2026-07-31T12:00:00Z }<br>status: draft<br>stale_after: 2026-12-31

Attested Computation

One document type that is prescribed by OKF is the Attested Computation. These documents declare a deterministic computation that backs a claim: what runs it, what parameters it takes, and what evidence a run has to return. Both halves of that live in the bundle, conventionally under a references/ subdirectory: the instructions the runner follows, and the code the attester uses to check a run. What never lands in the bundle is the output. A run's receipt and the attester's verdict are runtime artifacts, which is what separates attestation from the verified field above, since that one is recorded.

yaml<br>type: Attested Computation<br>runtime: bash<br>parameters:<br>- { name: bundle_root, type: string, required: true }<br>executor:<br>resource: references/skills/some_execution.md<br>receipt: [command, exit_code, result]<br>attester:<br>resource: references/attesters/execute_thing.py

The final two schemas are for the index file, which deserves its own explanation.

Index files

The index.md file is reserved for navigation, at every hierarchy in the knowledge base. It carries no frontmatter, with the exception of the root index file containing the version (okf_version: "0.2"). It has the expected shape of a flat list of links, organized by groupings.

markdown<br># Example...