Source
A repo file, Product Intent artifact, workflow, ADR, or public copy file that can be inspected.
Fireweed Deep Dive
Building Documentation as a Knowledge Graph
Fireweed is turning documentation into an inspectable knowledge graph: source files, claims, evidence spans, pages, and public worksets that can be reviewed together.
This is not a content calendar. It is a way to make architecture, UX, operations, product thinking, and public knowledge transfer traceable to the work that made each statement true.
Documentation starts from the repo because the repo is where code, decisions, workflows, and verification already meet.
The graph does not replace authored writing. It gives the writing a memory and a maintenance loop.The acid test.
A useful documentation system must answer a simple question: why should the reader believe this sentence?
If a claim matters, it needs evidence. If a public page teaches something, it should connect back
to the graph that made the lesson real.
The substrate.
The first version is Git-first and read-only. Fireweed renders the graph in the authenticated Docs tab, while selected public deep dives are exported through the static public site.
That boundary matters. Internal docs stay protected. Public work carries only the claims and sources that have been deliberately marked public.
Five graph objects.
The graph is intentionally small enough to review by hand and structured enough for tools to query.
Claim
An atomic statement a human or agent may rely on, with evidence refs and a freshness posture.
Module
A reusable group of claims that can appear in internal docs or public pages.
Page - authenticated or public projection
Workset
The ordered publication boundary. Public export starts here, not from an ad hoc copy operation.
The maintenance harness.
The point is not to make more files. The point is to make documentation reviewable when the platform changes.
Drift governance
The docs relevance map ties authored docs to the source paths that should trigger review.
Graph validation
Rust tooling checks ids, references, visibility, and public-workset safety.
Unified graph
The docs graph feeds the same broader knowledge graph as ADRs, System of Work artifacts, work packets, services, and contracts.
Where each projection goes.
| Projection | Boundary |
|---|---|
| Internal docs | Authenticated Fireweed #/docs tab, read-only in v1. |
| User docs | Repo-authored pages that can be projected into the Docs tab. |
| Public deep dives | Static public site routes selected from graph-validated public worksets. |
| Agent context | Queryable graph nodes and edges, not hidden chat memory. |
The public route is intentionally static-first. Fireweed does not open anonymous documentation routes inside the protected app.
The stack.
repo-authored sources
-> docs graph schema
-> Rust compiler and validator
-> Fireweed Docs tab
-> static public deep dives
-> unified knowledge graphWhat this proves.
Documentation can be product infrastructure.
The docs surface is not a sidecar; it is part of how Fireweed understands itself.
Public writing can keep its source lineage.
A deep dive can teach without becoming a marketing fork.
Agents need graph-shaped context.
A future maintainer should be able to ask which claims depend on a file and receive a real answer.
The first rule.
If a documentation claim matters, it should have evidence. If a public page teaches something, it should be connected to the internal graph that made the lesson real.