The graph
Every [[link]] written by the compiler is parsed and stored as an edge -- creating a dense, queryable graph that powers retrieval, backlinks, and structural health checks. The compiler assembles the graph as it writes pages, so every accepted source, answer, and correction can add nodes, edges, aliases, and provenance that compound over time.
A real knowledge base becomes this dense in hours. The hub pages (topics, people) surface as high-degree nodes; red links drive health-agent work queues.
How the graph is built
The graph is not a separate system -- it is updated on every page write. No background jobs, no eventual consistency. Link parsing and edge writes happen synchronously in the same transaction as the page write, so newly saved links are available to search and agents immediately. Nightly jobs still compute health signals and propose structural cleanup, but they are not required for a new link to appear in the graph.
Graph growth is cumulative. A page can start as a thin node created from a source file, then gain aliases, backlinks, temporal events, citations, source agreement, and revision context as connectors sync newer evidence and agents add accepted updates. Beakr does not let that growth become unbounded: clustering, condensation, reorganization, and density checks merge duplicate structure, tighten sparse neighborhoods, and keep the graph information-dense and useful.
Page links
Every parsed [[link]] is stored as an edge. Records the source page, target page (or null for red links), and the link text as written.
Title aliases
Preserves old titles after renames so existing links keep resolving. Aliases are checked during link resolution when exact title match fails.
Parent hierarchy
Pages can declare a parent page, creating a tree structure for navigation and scoped search.
Backlinks
Computed from page links -- all pages that reference a given page. Powers "what links here" queries and hub detection.
How a [[link]] resolves
Every time a page is written, the compiler parses all [[links]] in the content and resolves each one against the existing knowledge base. Resolution happens synchronously in the same database transaction as the page write.
Resolution happens on every write. An edge always exists, even when the target doesn't.
Renames don't break links
When a page is renamed, the old title is stored as a title alias. Any existing [[old title]] links continue to resolve because the resolution pipeline checks aliases after failing an exact title match. No global find-and-replace is needed.
Auth Service. Three other pages link to [[Auth Service]]. All resolve normally.Authentication Service. The old title Auth Service is saved as a title alias automatically.[[Auth Service]] links still resolve to the same page via alias lookup. New links can use either [[Auth Service]] or [[Authentication Service]].Fuzzy dates and semantic context
The graph stores dates with explicit precision, such as day, month, quarter, or year, instead of pretending every source provides exact timestamps. Embeddings help retrieve fuzzy references like "early Q2" or "after the advisory meeting", while temporal metadata remains the source of truth for ordering and filtering.
Graph health signals
The nightly health scan computes structural metrics from the graph. These signals drive maintenance agent work queues and surface in the dashboard.
| Signal | What it measures | Why it matters |
|---|---|---|
| Backlink count | Number of inbound links to a page | High-backlink pages are knowledge hubs. Zero-backlink pages may be orphaned or poorly integrated. |
| Orphan count | Pages with no inbound or outbound links | Orphans are invisible to graph traversal. The maintenance agent attempts to connect them or flags them for review. |
| Red-link density | Ratio of unresolved to total links | A high ratio means the knowledge base has many references to concepts it has not yet compiled. Drives compiler prioritization. |
| Thin content | Pages below a word-count threshold | Thin pages are often stubs created by red-link resolution. They need enrichment from additional sources. |
| Staleness | Time since last revision relative to source update frequency | A page whose sources have been updated but which has not been recompiled may contain outdated information. |
| Source agreement | Agreement, contradiction, and coverage across citations, sources, and revisions | Pages with thin or conflicting evidence are candidates for review, enrichment, or contradiction resolution before agents rely on them for high-stakes answers. |