Open Knowledge Format plugin for portable LLM wikis

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:

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:

title: Some title                # recommended, optional
description: "Some description"  # declaring one only pins its shape
tags: [tag1, tag2]               # a LIST, not a comma-separated string
resource: https://...            # recommended, optional
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?

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

type: Attested Computation
runtime: bash
parameters:
  - { name: bundle_root, type: string, required: true }
executor:
  resource: references/skills/some_execution.md
  receipt: [command, exit_code, result]
attester:
  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.

# Example index

## An example section

* [An example link](./foo-bar.md) - Some example description
* [Another example link](./baz-qux.md) - Some example description

## Another example section

* [An example link](./foo-bar.md) - Some example description

The OKF plugin provides multiple levels of support for this. You can toggle the frontmatter schema requirements: no frontmatter on index files, and optionally okf_version in root.

You can additionally use the body linter, which looks for this specific shape.

Finally, you can have the OKF plugin manage your index files. When turned on, an index file is generated at every hierarchy where there is markdown. These index files contain all the documents at that folder's level, grouped by type and listed by title. The subfolders are listed in their own section, with links to their index files. These files are git-synced, and to avoid merge conflicts, a merge rule is added to a repository's .gitattributes file. When toggling this feature off, the .gitattributes change is removed, but the index files will remain.

Log files

The log.md file is also reserved at every hierarchy for reporting changes as they occur in the repository.

# Example log

## 2026-07-31

Example details from change

## 2026-07-30

Example details from change

## 2026-07-29

Example details from change

The OKF plugin ships with a body linter to ensure that dates are formed in the proper ISO format in headings. Log updates are expected to be written by the user and agent, and our included skill (see below) helps drive that.

Portability

OKF has a couple of recommendations that ensure portability.

• Only standard links are recognized
• OKF is Markdown-centered

We include two toggleable rules to help you be aware of these.

1. No wiki links: while OpenKnowledge supports wiki links, OKF does not.
2. No .mdx: while OpenKnowledge supports .mdx files, OKF does not explicitly say it does.

Ensuring your agent knows what to do

While the agent already receives feedback on its changes via the content rules system, the plugin includes a recommended skill called okf-knowledge-base. This skill helps inform your agent of both the OKF spec and how it can proactively ensure conformance and use the plugin. It contains:

• A distillation of the spec, along with links to the official documentation
• How to proactively use each of the schemas
• How to take advantage of the index.md and log.md files to navigate the bundle
• How to use the plugin

When used in combination with the rest of the plugin, the agent easily writes more than a conformant knowledge base. It writes an ideal OKF one.

Getting started

If you're new to OpenKnowledge, download the app to get started (available for Mac, Windows, and Linux).

For a new knowledge base, you can start with the OKF starter pack, which now ships with the plugin on.

For an existing knowledge base, you just flip on the plugin in the Plugins settings.

You can then enable index.md generation, install the skill, and tune the rules to your liking.

Once on, the linting rules will take effect and the problems panel will surface anywhere the knowledge base isn't conformant.

Use the Fix all with AI button to have an agent do the fixing and take care of the rest.