The wiki is a set of regular Seed documents under a /_wiki/ path prefix in each space. No new document types, no new storage layer. Every wiki page is created via the existing CreateDocumentChange gRPC endpoint and flows through normal blob indexing -- FTS, embeddings, resource_links, everything.

The tree looks like this:

/_wiki/                         # Index page: auto-generated table of contents, recent changes
/_wiki/entities/                # Directory listing all entity pages
/_wiki/entities/person-name     # An entity page
/_wiki/entities/project-alpha   # Another entity page
/_wiki/topics/                  # Directory listing all topic pages
/_wiki/topics/architecture      # A topic page
/_wiki/topics/auth-migration    # Another topic page
/_wiki/contradictions           # Contradiction log
/_wiki/_config                  # Wiki instruction document

Each wiki document carries metadata attributes (set via SetAttribute change operations on the document root):

One page per notable person, project, concept, or thing that appears across multiple source documents. "Notable" means
it shows up in more than one source with enough context that a standalone page is useful. An entity mentioned once in
passing doesn't get its own page -- it gets a line in a topic page.

Content of an entity page: what the entity is, key facts extracted from sources, a timeline of mentions (chronologically ordered by source document dates), and inline hm:// links back to every source document that discusses it. The entity
page is the single place you go to understand everything the space knows about that entity.

The LLM decides what qualifies as a notable entity. This is governed by the wiki instruction document (/_wiki/_config), which can define rules like minimum mention count, types of entities to track (people, projects,
tools, decisions), and entities to explicitly include or exclude.

One page per recurring theme, decision area, or subject that spans multiple sources. Where entity pages are about nouns,
topic pages are about ideas. "How we handle authentication" is a topic. "The migration from REST to gRPC" is a topic.

Content: a synthesized overview of the theme, the key arguments or positions from different sources (attributed with
links), open questions that haven't been resolved, and links to relevant entity pages. Topic pages are where the LLM's
synthesis work is most visible -- it's not just listing facts, it's connecting them into a narrative.

A single document at /_wiki/contradictions. Each entry is a section with:

When the LLM processes a new source and finds that it says something different from what's already in the wiki, it does
two things: updates the relevant wiki page to reflect the tension (e.g., "Source A says X, but Source B says Y"), and
adds an entry to the contradiction log.

The contradiction log is a Seed document like any other. It shows up in search, it syncs via P2P, and its :activity/citations view links back to the wiki pages and source documents involved. Humans can review contradictions
and resolve them -- by editing source documents, by editing wiki pages, or by adding a new source that clarifies the
conflict. When a contradiction is resolved, the LLM removes the entry on the next processing run (it re-evaluates the
sources and sees that the tension no longer exists).

Wiki pages link to each other and to source documents using inline hm:// links -- standard Seed annotations with type=Link. This is the existing annotation system, nothing new.

Because Seed already indexes all links in the resource_links table and computes backlinks via the ListEntityMentions gRPC (which powers the :activity/citations view), the cross-reference graph builds itself automatically. When the LLM creates a wiki page about "Project Alpha" and links to three source documents and two other wiki pages, those links are indexed during normal blob processing. Open any of those source documents, check :activity/citations, and you'll see
the "Project Alpha" wiki page listed as a citation.

This is bidirectional by default. Source documents cite wiki pages (because the wiki links to them). Wiki pages cite each other (because topics reference entities and vice versa). The existing citation-based authority ranking in search (applyAuthorityRanking in entities.go) means wiki pages with many inbound links rank higher in search results --
which is exactly right, because a well-connected wiki page is more useful than an isolated one.

No new cross-reference infrastructure is needed. The existing resource_links table, ListEntityMentions RPC, and
citation graph do all the work.

The /_wiki/_config document is the brain of the wiki pipeline. It's not a system prompt string stuffed into an API
call. It's a comprehensive reference manual -- like the skill documents we use for agent workflows in this repo -- that
teaches the LLM everything it needs to know to build and maintain the wiki.

The pipeline reads /_wiki/_config and passes its full content as context to the LLM on every processing run. This
document encodes all the decisions that shape wiki behavior:

include/exclude lists)

and formal)

source does)

The Seed team ships a default version of this document. When the pipeline first runs on a space and /_wiki/_config
doesn't exist, it creates it with the default content. Users can then edit it -- it's a regular Seed document, so it's
versioned, synced, and editable by anyone with write capabilities on the space.

Different spaces can have radically different wiki behaviors just by editing their config. The Seed team can evolve the
default by updating the hardcoded fallback. Users who haven't customized their config get improvements automatically.
Users who have customized it keep their version.

The pipeline runs in the Electron main process as a background loop, same environment as the existing chat assistant. It uses the same Vercel AI SDK infrastructure -- the same createProviderModel() factory, the same provider configuration,
the same API keys or ChatGPT login session. No Go daemon code for LLM calls. The daemon is involved only as a data
layer: gRPC calls to read documents, write changes, and query the index.

Where the chat uses streamText (because it needs to show tokens appearing in real time), the wiki pipeline would use generateObject from the AI SDK -- it sends the LLM a prompt and gets back a typed, structured response describing
exactly what pages to create or update. No streaming to a UI needed.

The loop runs on a configurable interval (default maybe 5 minutes). Each cycle:

exist yet).

pages themselves -- each wiki page's wiki:source-versions metadata records which version of each source was last
processed. A new document (not referenced in any wiki page's metadata) or an updated document (version mismatch) gets
queued for processing.

and the current wiki pages that might need updating. The LLM sees the full picture -- what the source says and what
the wiki currently says about it.

new block content), which new pages to create (with path, type, and content), which contradiction entries to add.

flows through normal indexing -- FTS gets updated, embeddings get queued, resource_links are recomputed. The wiki
integrates with everything else automatically.

The processing state lives in the wiki pages themselves rather than a separate tracking table. This is intentional --
the wiki pages are the source of truth for what's been processed. If a wiki page says it was built from version X of a
source, and the source is now at version Y, that page needs reprocessing. No separate state to get out of sync.

Wiki pages are owned by the space owner -- they're created with the space owner's signing key (or an AGENT capability
delegated to the wiki bot). The permission model is the same as any other Seed document:

to the space can read the wiki but not modify it (standard Seed behavior -- you need a write capability to push
changes).

the same permission boundaries as any other document under the space's path hierarchy.

The /_wiki/ path prefix is a convention, not a permission boundary. But you could issue path-scoped capabilities restricted to /_wiki/ if you wanted to give someone wiki-editing rights without access to the rest of the space. The existing capability model supports this -- no_recursive and is_exact flags control path scoping.

Three mechanisms keep the wiki accurate over time:

Version tracking. Each wiki page records which version of each source document it was built from (in wiki:source-versions metadata). When a source document gets updated -- a new Ref blob with different heads -- the
version changes. The next pipeline run detects the mismatch: the wiki page says it processed version A, but the source
is now at version B. The pipeline re-reads the source and sends it to the LLM along with the current wiki page, asking
it to update the page to reflect the new version. Only the changed content needs re-evaluation, not the entire wiki.

Deletion handling. When a source document is tombstoned (via CreateRef with a tombstone target, which is how Seed handles deletion), the pipeline detects this on its next run. It finds all wiki pages that list the deleted source in their wiki:sources metadata. For each affected page, it sends the current page content to the LLM with instructions to
remove or flag content that relied solely on the deleted source. If all sources for a page are deleted, the page itself
gets tombstoned.

Periodic regeneration. Incremental patching accumulates drift. The LLM keeps adding sentences, restructuring paragraphs, and after twenty incremental updates a page can become incoherent -- repetitive, poorly organized, internally contradictory. To prevent this, every N processing cycles (configurable via /_wiki/_config, maybe every 20
cycles), the pipeline fully regenerates a wiki page from all its current sources rather than patching incrementally. The
LLM reads all sources fresh and writes the page from scratch. This is more expensive (more tokens, more API calls) but
prevents quality decay. The regeneration schedule could be staggered -- regenerate a few pages per cycle rather than all
at once.

When should wiki content be removed?

wiki page itself gets tombstoned. An entity with no sources is an entity that doesn't exist.

deleted path gets added to an implicit exclusion list -- the pipeline won't recreate a page at a path that was
explicitly tombstoned by a human. The human's intent takes priority over the LLM's.

document, or it was only ever mentioned once and that mention was minor), the LLM can fold its content into a broader topic page and tombstone the standalone entity page. This keeps the wiki from bloating with stale, low-value pages. The rules for this are defined in /_wiki/_config.

Wiki pages are regular Seed documents. Anyone with write capabilities can edit them. The question is what happens when
the LLM next processes that page.

The rule: when a human edits a wiki page, the wiki:human-curated metadata attribute gets set to true. The pipeline
detects this by comparing the latest Change blob's author against the wiki bot's signing key -- if the author is someone
else, a human edited it. When this flag is set, the LLM switches to append-only mode for that page. It can add new
information below the human-edited content (clearly demarcated), but it won't overwrite, restructure, or remove anything
the human wrote.

If you want the LLM to take full control of a page again -- maybe you made a quick fix that the LLM should integrate properly -- clear the wiki:human-curated flag (set it to false or remove it). The next processing run will treat the
page as fully LLM-managed and may restructure it.

This gives humans a clean override mechanism. Edit a wiki page and it becomes yours. The LLM will still add to it, but
it won't mess with your work.

Once generated, the wiki doesn't need any new access infrastructure. It plugs into everything that already exists
because wiki pages are just documents.

Browsing. Navigate to /_wiki/ in the desktop app. It's a document tree. The index page has a table of contents. Follow links to entity pages, topic pages, the contradiction log. Check :activity/citations on any page to see what else references it. Check :directory to list child pages.

Full-text search. Wiki pages are indexed in the FTS5 virtual table like any other document. Search for
"authentication" and you'll get both raw source documents and the wiki's topic page on authentication. The wiki pages
might actually rank better because they're more structured and keyword-dense -- the synthesis concentrates relevant
terms.

Semantic search. If the embedding indexer is enabled, wiki pages get embedded alongside regular documents. The
synthesized, cross-referenced wiki content produces denser embeddings that may match queries better than raw source
fragments.

Chat assistant. The existing assistant can search and read wiki pages through its search and read tools -- no
changes needed. When a user asks the assistant a question, it can find and reference wiki pages as context. This is
where the wiki's value compounds: instead of the assistant piecing together five raw documents, it finds the wiki page
that already synthesized those five documents. Better answers with fewer tool calls.

Citations. Open any source document and check :activity/citations. You'll see which wiki pages reference it. This creates bidirectional navigation: sources lead to wiki pages, wiki pages lead to sources. The existing ListEntityMentions RPC and resource_links table power this with zero new code.

The wiki is LLM-written, human-read. You add source documents to your space -- notes, imports, meeting records, whatever content you work with. The LLM maintains the wiki. You browse, search, and read it. You can edit wiki pages if you want -- the LLM will respect your changes. You can customize how the wiki behaves by editing /_wiki/_config.

The wiki is not a replacement for source documents. Sources are ground truth. The wiki is the map. It tells you what's
in the territory, how things connect, and where the conflicts are. When the territory changes (sources are added,
updated, or deleted), the map updates itself.

The wiki is only useful if there are enough source documents to synthesize. Today, getting content into Seed is manual
-- you write documents in the editor or use the WordPress XML importer. For the wiki to deliver real value, users need
to import content from various sources: web pages, PDFs, notes from other apps, bookmarks, articles.

What the wiki needs from this: a reliable way to ingest external content as Seed documents with proper metadata. At
minimum, each imported document should carry its source URL (or origin identifier) and import date so the wiki can
attribute information back to its source. The import pipeline doesn't need to be perfect -- the wiki LLM can work with
rough text extraction and messy formatting -- but it needs to exist. Without it, most users won't have the document
volume that makes a wiki meaningful. A wiki over three documents isn't a wiki, it's a summary.

The wiki pipeline needs to programmatically create and edit Seed documents from LLM output. Today, the backend handles document creation via the CreateDocumentChange gRPC, but the path from "LLM generates structured content" to "that
content becomes a Seed document" doesn't exist as a reusable layer.

What the wiki needs from this: a service in the frontend (TypeScript, same environment as the chat assistant) that takes structured LLM output -- something like "create a document at path /_wiki/entities/project-alpha with these blocks, these inline links, and these metadata attributes" -- and translates it into CreateDocumentChange requests with proper block IDs, MoveBlock + ReplaceBlock + SetAttribute operations, and signing. This is the bridge between
LLM-generated content and Seed's document model.

The AGENT capability role already exists in the proto definitions (proto/documents/v3alpha/access_control.proto) but
isn't fully wired into a content-creation workflow. The wiki bot would be the first real consumer of AGENT capabilities
-- a signing key that's authorized to write documents on behalf of the space owner, used by the pipeline to create and
update wiki pages without requiring the owner's key for every change.