LLM Wiki: Theory part02 | How Does an LLM Wiki Work? From Markdown and Google OKF to Obsidian and Knowledge Graphs

About the “LLM Wiki: Theory” series

I am currently building a Knowledge Engine, which I plan to release as an open-source project once it is ready.

The system organises knowledge according to Google’s Open Knowledge Format (OKF) v0.1 Draft and combines an LLM Wiki, RAG and an agent Harness. People can read the knowledge pages in Obsidian and explore the relationship graph through Sigma.js.

The first article looked at why the LLM Wiki idea emerged and how it differs from RAG. This one opens the system up and examines what each layer is responsible for.

Open an Obsidian vault, switch to Graph View, and a few hundred Markdown notes turn into a cloud of dots and lines.

It is easy to come away with the impression that:

An LLM Wiki is simply an Obsidian vault that an AI can use.

Obsidian can certainly display and edit knowledge pages. Sigma.js can turn the links between them into an interactive network.

A system that answers questions reliably, however, also has to manage sources, knowledge pages, metadata, citations, search indexes, graph relationships, agent behaviour, versioning and release controls.

An LLM Wiki is better understood as a layered knowledge architecture.

Raw sources
PDFs, websites, documents, databases
        ↓
Knowledge compilation
Parse, reconcile concepts, summarise, add citations and relationships
        ↓
Knowledge representation
Markdown + Metadata + Links
        ↓
Search and indexing
Full-text search + BM25 + Vector index + Graph
        ↓
Agent Harness
Rules for searching, checking, citing and answering
        ↓
Interfaces
Obsidian, Sigma.js, API, Chat

The tools in each layer can be replaced. The useful distinction is the job each layer performs.

Start with a Markdown knowledge page

The main unit in an LLM Wiki is often not a database row or a chunk cut from a PDF. It is a knowledge page that can be read on its own.

For example:

---
type: Metric
title: Weekly Active Users
description: Unique users who complete at least one qualifying action within seven days.
tags:
  - product
  - engagement
status: approved
---

# Definition

Weekly active users, or WAU, is the number of unique users who complete at least one
[qualifying action](../definitions/qualifying-action.md) within a seven-day period.

# Notes

Different products may define a qualifying action differently. WAU figures should not
be compared unless they use the same definition.

# Citations

1. Product analytics specification

To a person, this is an ordinary document.

To software, it provides four kinds of information at once:

the knowledge in the body;
structured metadata in the YAML front matter;
links to related pages;
citations pointing towards the underlying evidence.

The same file can be versioned in Git, displayed in Obsidian, indexed for search, embedded for vector retrieval and parsed into a graph node.

That is why Markdown is such a practical fit. It does not require a proprietary reader, yet it remains structured enough for software to work with.

What does Google OKF provide?

Google Cloud introduced the Open Knowledge Format as an open format for representing the kind of knowledge structure used by an LLM Wiki.

OKF v0.1 remains a draft. Its design is deliberately modest:

a body of knowledge is stored as a folder, called a Knowledge Bundle;
a concept is usually represented by one Markdown file;
YAML front matter stores structured metadata;
standard Markdown links connect concepts.

A bundle might look like this:

knowledge-bundle/
├── index.md
├── metrics/
│   ├── weekly-active-users.md
│   └── monthly-active-users.md
├── definitions/
│   └── qualifying-action.md
└── sources/
    └── product-analytics-spec.md

OKF does not require a particular model, vector database, search engine, agent framework, cloud platform or graph interface.

Its job is to define how knowledge is stored and exchanged. It does not define the entire retrieval and answering system.

Two products may both read OKF while searching it in completely different ways. Nor does conformance to the format mean that the content has been checked.

Metadata makes the document machine-readable

The Markdown body is written for reading. YAML front matter tells software what sort of page it is.

---
type: Metric
title: Weekly Active Users
tags:
  - engagement
status: approved
owner: product-analytics
valid_from: 2026-07-01
---

Software can use these fields for filtering, ranking, permissions, lifecycle management and search weighting.

An agent might, for example, search only for pages that are:

marked status: approved;
typed as Metric;
valid after July 2026.

OKF defines only a small common core. An actual system still has to decide:

which types are allowed;
which status values exist;
which fields are mandatory;
how versions and expiry are represented;
how precisely citations must point into the source.

Format compatibility means that a file can be read. Reliability depends on the governance and validation built around it.

Links naturally form a graph

Whenever one Markdown file links to another, the two pages can be treated as nodes and the link as an edge.

Weekly Active Users
        │
        ├──→ Qualifying Action
        ├──→ Product Event Stream
        └──→ Monthly Active Users

Parsing the links across the bundle produces a directed graph.

A normal link, however, often says only:

A is related to B in some way.

It may not tell the system whether the relationship means definition, dependency, support, contradiction, replacement or causation.

A → B

contains less information than:

A --DEFINED_BY--> B
A --SUPERSEDED_BY--> B
A --CONTRADICTS--> B

Standard Markdown links are useful for reading and navigation. Typed relationships are more useful for precise queries and validation.

An LLM Wiki can preserve both:

ordinary Markdown links, which remain easy for people and general-purpose tools to read;
typed relationships, which agents can query, filter and traverse.

What is each component responsible for?

Component	What it does	What it does not do
Markdown / OKF	Stores knowledge, metadata, links and citations	Does not search or validate the content
Obsidian	Lets people read, edit and inspect backlinks and graphs	Does not guarantee that the content is correct
Graphology	Stores and analyses graph data	Does not provide a complete user interface
Sigma.js	Renders an interactive graph in the browser	Does not judge whether a relationship is true
BM25 / full-text search	Finds exact terms, names and version strings	Does not understand the full meaning of a document
Vector search	Finds semantically similar pages	Does not guarantee reliable sources
Graph traversal	Follows existing relationships to gather related knowledge	Does not create correct relationships automatically
Harness	Governs how the agent searches, checks and answers	Does not replace the knowledge or its sources

This also clears up several common misunderstandings:

Obsidian is not the whole LLM Wiki.
Sigma.js is not a search engine.
Graph View does not validate knowledge.
OKF is not an agent framework.
A vector database is not a complete Knowledge Engine.

How do Obsidian, Graphology and Sigma.js work together?

Obsidian stores notes as Markdown files inside a vault. It can display YAML properties, internal links, backlinks and a graph view.

That makes it a useful interface for people who need to read, edit and inspect the knowledge base.

Obsidian supports both [[Wikilinks]] and standard Markdown links. Standard links are usually the safer choice when portability matters, because other tools can parse them without understanding Obsidian-specific syntax.

When the graph needs to appear on the web, or when the built-in Obsidian view is not flexible enough, Graphology and Sigma.js can take over.

Graphology stores and analyses graph data: nodes, edges, attributes and traversal.

Sigma.js renders that graph in the browser and provides interactions such as zooming, clicking, searching and filtering.

Markdown files
      ↓
Parse pages and links
      ↓
Graphology graph
      ↓
Sigma.js
      ↓
Interactive relationship map

Sigma.js renders the graph it receives.

If an upstream process has mistakenly merged two people into one node, Sigma.js will display the mistake perfectly well.

The graph is an interface for observing the knowledge system. It is not the source of trust.

How does an agent find the knowledge it needs?

A practical system will usually combine several search methods.

Search method	Best suited to
Index pages and links	Small knowledge bases, clear topic structure, multi-step reading
BM25 / full-text search	Names, companies, API paths, error codes and version strings
Vector search	Different wording, vague descriptions and concept similarity
Graph traversal	Definitions, supersession, evidence, dependencies and multi-hop questions

A query might follow this path:

User question
      ↓
BM25 finds exact terms
      +
Vector search finds semantic candidates
      ↓
Open the main knowledge page
      ↓
Follow graph relationships for missing context
      ↓
Check important claims against the source
      ↓
Assemble the answer

No single search method covers every case.

The Harness governs how the agent uses these capabilities

OKF defines how the knowledge is stored.

Obsidian and Sigma.js provide interfaces for people.

Search and graph operations help the agent find material.

The system still needs a control layer that decides what the agent is allowed and required to do. That is the Harness.

It broadly covers four areas:

Search and context rules
Where to search first, how much material to read, and when to follow another relationship.
Source and citation requirements
Which claims must be checked against the source and what evidence the answer must include.
Write and review boundaries
Whether the agent may modify the Wiki, which changes need human review, and what can enter a published release.
Evaluation and release controls
Retrieval quality, source coverage, failure cases and the identity of the published version.

Suppose an agent finds a Wiki page that says:

Product retention increased by 20% after the new release.

The Harness may require it to check:

whether 20% means relative growth or a 20-percentage-point increase;
which periods are being compared;
whether seasonality was accounted for;
which source contains the number;
whether the Wiki page is still valid;
whether a newer version exists.

Without those controls, an agent can easily turn a plausible sentence into an unjustifiably confident answer.

A complete example: the definition of WAU changes

Suppose the Knowledge Engine receives three documents:

A. Product metrics specification
B. Weekly operations report
C. Tracking migration note

Document A says:

A user counts as active after signing in.

Document B says:

WAU increased by 18% this week.

Document C says:

From 1 July, a user counts as active only after completing a core action.

The system may create:

metrics/weekly-active-users.md
definitions/active-user-v1.md
definitions/active-user-v2.md
events/tracking-migration-2026-07.md
reports/weekly-operations.md

and preserve relationships such as:

Weekly Operations Report
        │
        └── REPORTS_METRIC ──→ Weekly Active Users

Weekly Active Users
        │
        ├── DEFINED_BY ──────→ Active User v2
        ├── PREVIOUSLY_DEFINED_BY → Active User v1
        └── CHANGED_BY ──────→ Tracking Migration

Active User v1
        │
        └── SUPERSEDED_BY ───→ Active User v2

Now consider the question:

Does an 18% increase in WAU mean that users became more active?

The agent should not retrieve only the sentence containing “18%”.

It also needs to follow the relationships to the definition change and check whether the comparison crosses 1 July.

A more defensible answer would be:

Not necessarily. The definition of WAU changed during the comparison period. The old version counted sign-ins, while the new version requires a core action. The 18% movement may therefore reflect both user behaviour and the measurement change. The metric should be recalculated on a consistent basis before drawing a conclusion.

The graph has not answered the question.

It has provided a route through the evidence and made it harder to miss the definition, version and source.

One body of knowledge, two interfaces

People and agents can share the same knowledge layer without using the same interface.

People may work through Obsidian, web documentation, Sigma.js, Git history or a review dashboard.

Agents may use search indexes, metadata filters, graph relationships and source retrieval.

Whichever route is used, important claims should remain traceable to the underlying material. A production system may also preserve:

the source document version;
a source ID;
a content digest;
a page or passage locator;
claim-to-source mappings;
validity periods;
supersession status;
review and release versions.

These details may live in Markdown front matter, a manifest, a ledger or a separate metadata store.

The exact location is less important than the guarantee: a Wiki page must not become a dead end that cannot be checked against the evidence.

Conclusion

An LLM Wiki can begin with Markdown, but Markdown alone is not the whole system.

Google OKF provides a lightweight, readable and portable knowledge format.

Obsidian gives people a way to read and edit the pages.

Graphology stores and analyses graph data.

Sigma.js displays the graph in a browser.

BM25, vector search and graph traversal help find the relevant knowledge.

The Harness governs how the agent uses those capabilities and when it must return to the source.

Sources
   ↓
Knowledge Compilation
   ↓
OKF Concepts
   ↓
Metadata + Links + Citations
   ↓
Search Indexes + Graph
   ↓
Harnessed Agent
   ↓
Grounded Answer

People see pages and relationship maps.

The AI uses content, metadata, indexes, relationships, sources and rules.

Once both are working from the same knowledge layer, the Wiki becomes more than a database for a model to search. It becomes a system that can be read, checked, corrected and maintained over time.