A wiki page is text. With frontmatter, it's also structured data. With consistent frontmatter conventions, the wiki becomes a queryable knowledge graph.
This page covers how frontmatter feeds knowledge graphs and the patterns for designing useful schema.
In Wikantik (2026-10-13): page frontmatter does not populate the Knowledge Graph. The Knowledge Graph (
kg_*tables) holds LLM-extracted entities built from page text; the projector that once turned frontmatter into graph nodes and edges was retired in April 2026 (see GraphProjector and PageGraphVsKnowledgeGraph). Frontmatter instead drives the structural index (clusters, tags, canonical ids), the RDF ontology's page and concept graphs, the agent projection at/api/pages/for-agent/{id}, and one Knowledge Graph control,kg_include. The generic sections below describe the general model; read "edges" there as links between pages, not Knowledge Graph edges.
YAML (or similar) at the top of a markdown file:
---
title: Page Title
tags:
- tag1
- tag2
related:
- OtherPage
status: published
---
The metadata is structured; the body is unstructured. Tools can use the metadata without reading the body.
"Show all pages tagged 'security'" is a query against frontmatter. No body parsing needed.
related: field links pages. Across the wiki, this builds a graph.
status: deprecated lets tools surface old pages.
Title, tags, and other frontmatter fields can be weighted in search. See WikiSearchOptimization.
With consistent schemas, the wiki answers questions:
Some fields every page needs:
title: ...
date: ...
type: article | hub | runbook | ...
Validation enforces presence. (In Wikantik the frontmatter schema has no required fields: canonical_id is assigned automatically on first save, and field-value checks are advisory.)
Fields that may or may not apply:
tags: ... # for topic indexing
related: ... # cross-references
status: ... # lifecycle
canonical_id: ... # stable identifier
A page with type: runbook might have a structured runbook: block:
type: runbook
runbook:
when_to_use: [...]
steps: [...]
references: [...]
A page with type: article doesn't need that.
The Wikantik agent-cookbook uses this pattern.
Each page is a node.
Frontmatter related:, links_to:, embedded references — these are edges.
Frontmatter fields are properties of the node.
Tools query the graph:
Find all pages where:
type = "runbook"
AND tags contain "security"
AND status = "published"
This is a structured query; doesn't require text search.
Wikantik's structural spine + agent-grade content design uses frontmatter heavily:
canonical_id: stable identifier (ULID), assigned on first save and kept across renamescluster: thematic grouping; a scalar, or a list on non-hub pages. The one page with type: hub and a cluster: value declares that cluster (see ClusterDeclarationDesign)tags: topic tagsrelated: cross-referencestype: page type (article, hub, reference, runbook, design)status: lifecycle state (draft, active, archived)verified_at, verified_by, confidence: verification metadataaudience: humans / agents / bothkg_include: per-page override of Knowledge Graph inclusion (see KgInclusionPolicy)These feed:
/api/pages/for-agent/{id})cluster and kg_include), but not Knowledge Graph contentDecide what fields exist; what they mean; what values are valid. Then write pages following the schema.
Without schema, frontmatter is inconsistent; queries don't work.
Tools validate frontmatter at save time. Pages with invalid schema reject (or warn).
Wikantik uses save-time enforcement via StructuralSpinePageFilter (it assigns a missing canonical_id and rejects an invalid kg_include) and RunbookValidationPageFilter. The schema-driven field checks (non-canonical type or status, odd dates, non-kebab clusters) are advisory warnings, and malformed YAML is rejected.
A field's name and meaning don't change. Consistent across all pages.
Renaming related → links_to is a major migration. Avoid unless necessary.
New fields can be added; existing pages without them still work.
For required fields with defaults, this is straightforward. For required fields without defaults, migration is needed.
Tags should be from a controlled vocabulary. Otherwise users invent variants ("security", "Security", "infosec", "SecurityRelated").
Either:
related: entries point to other pages. Validate the targets exist.
Tools surface broken cross-references.
In Wikantik, a hub page has type: hub and a scalar cluster: value that declares the cluster; member pages join it by carrying the same cluster: value. The earlier hubs: membership field is retired (see ClusterDeclarationDesign), so there is one authoritative mechanism rather than two lists to keep in step.
Pages can have:
verified_at: 2026-04-26
verified_by: alice
confidence: authoritative | provisional | stale
Tools surface stale or unverified pages.
Frontmatter cluster: name groups pages. Hub pages organize the cluster.
For 5+ pages on a topic, a cluster + hub provides structure.
Validate schema on save. Reject invalid pages.
Read all pages' frontmatter; build searchable index. Periodic rebuild.
Find broken related: links; missing hub members.
Graph visualization of the knowledge graph. Useful for understanding wiki structure.
Different fields used; same fields with different values. Queries unreliable.
Bad frontmatter slips in. Subtle issues compound.
Tags multiply; no curation; eventual mess.
Pages created without thinking about metadata. Later, can't be queried.
Manual updates to related: lists. Drift; missing cross-references.
For wikis using frontmatter for knowledge graphs:
cluster:)The Wikantik approach (structural spine + agent-grade content) shows mature implementation.
Cluster Hub: Wikantik Platform Development Hub: Architecture, MCP Protocols, and Agent Briefings (wikantik-development)