269 Nodes, 1513
Edges: What the Graph Ledger Measures
Introduction: Numbers
That Mean Something
That Mean Something
Every knowledge base accumulates. Files multiply, pages grow, links
accumulate until the structure itself becomes opaque. Without
measurement, you cannot tell the difference between a system that is
getting smarter and one that is getting cluttered. A graph ledger
answers that question with numbers — not opinions, not vibes, but a
structural census of what the system actually knows and how that
knowledge connects.
The Council Vault’s graph ledger is a quantitative snapshot of the
knowledge graph’s shape: how many nodes exist, how many edges link them,
what those edges connect, and where the graph is breaking. As of this
writing, the ledger reads 269 nodes and 1513 edges. Those two numbers
are not just metrics — they are a diagnosis. This article explains what
the graph ledger measures, how those numbers map to structural health,
and why a self-improving knowledge base cannot improve what it cannot
count.
What Is a Graph Ledger?
A graph ledger is a periodic audit of a knowledge graph’s topology.
It counts nodes (the atomic units — pages, entities, concepts, sources,
articles) and edges (the links between them — wiki references,
backlinks, provenance connections). Think of it as a balance sheet for
knowledge: what you have, how it connects, and what is missing.
In the Council Vault, the ledger scans three layers:
Layer 1: The Wiki — 188 notes across three schema
types. 93 concept pages (ideas, patterns, frameworks), 74 entity pages
(tools, services, agents), and 20 source pages (evidence, references,
logs). Each page has mandatory fields: definition, related concepts,
related entities, and sources. Every [[wiki-link]] is an
edge — a claim that two nodes have a structural relationship.
Layer 2: The Pipeline — Articles in various stages
of drafting, review, and publication. Each article is a node that
connects back to the wiki through its frontmatter grounding and forward
to WordPress through its post ID. The pipeline is the bridge between
internal knowledge and published authority.
Layer 3: The Bridge — The MASTER-INDEX-BRIDGE
connects 274 published WordPress posts back to wiki concepts and skills.
Each connection is an edge: “this published article is grounded in that
wiki concept.” The bridge is what makes the graph queryable, not just
browseable.
The ledger counts all three layers and reports the totals. 269 nodes
is the combined count: wiki pages plus pipeline articles plus bridge
entries. 1513 edges is the link count: every [[wiki-link]]
in every page, every grounding reference in every article frontmatter,
and every post-to-concept connection in the bridge.
How Edges Break: The
Three Failure Modes
Three Failure Modes
A graph with 1513 edges is only useful if those edges actually work.
The graph ledger’s real value is not the count — it is the failure
report. Three types of broken edges degrade a knowledge graph from a
navigable structure into a pile of markdown.
Dead links are edges that point to nodes that do not
exist. In the Council Vault, dead links appear when a page is renamed,
deleted, or referenced by a wrong slug. Every dead link is a broken
promise — a page that says “see also [[this concept]]” but the target is
gone. The lint report tracks these: when the wiki grew from 13 to 188
pages, dead links grew from 5 to 157. The ratio matters more than the
raw count.
Orphan nodes are pages with no inbound links. They
exist but nothing points to them — they are reachable only by direct
search, never by navigation. Orphans are the knowledge graph equivalent
of dead code: present, consuming resources, but invisible to the system.
The ledger flags any node with zero inbound edges as a structural
risk.
Ungrounded edges are links that exist on paper but
have no semantic backing. A concept page that lists “related concepts”
without explaining why those relationships exist is an ungrounded edge.
It creates the appearance of structure without the substance. The ledger
counts these by checking whether linked pages reciprocate the
relationship — a one-way link without context is a warning signal.
Why the
Count Matters: From Measurement to Improvement
Count Matters: From Measurement to Improvement
The self-improving knowledge base promises that every article makes
the next cheaper to write. That promise is testable through the ledger.
If the graph is truly improving:
- Edge density should increase — more links per node
means each new page connects to more existing knowledge, making
discovery faster. - Dead link ratio should decrease — as the lint
process catches and repairs broken links, the graph becomes more
navigable. - Orphan count should stabilize — new pages should
link to existing pages, not float alone.
At 269 nodes and 1513 edges, the edge-to-node ratio is approximately
5.6:1. That means each node connects to roughly five others on average.
For a knowledge graph at this scale, that ratio indicates a healthy
density — dense enough for cross-reference, sparse enough for each
connection to carry meaning.
But the raw ratio hides the real story. The graph is not uniform.
Concept pages (93) carry most of the structural weight — they link to
entities, sources, and each other. Entity pages (74) are referenced
heavily but link outward less. Source pages (20) are leaf nodes: they
provide evidence but rarely connect to other sources. The ledger reveals
this asymmetry, which is structural, not pathological.
The Ledger as a Governance
Tool
Tool
The graph ledger is not a vanity metric. It is a governance
instrument that answers three operational questions:
-
Is the knowledge base growing in structure, not just
volume? If node count grows but edge count does not, pages are
accumulating without connecting. The graph is becoming a filing cabinet
instead of a network. -
Are published articles feeding back into the
vault? The bridge layer should show new edges after every
publish cycle. If posts publish but the bridge does not grow, the loop
is broken — content goes out but knowledge does not compound. -
Is the lint process working? A healthy graph
should show dead links and orphans declining over time, not growing with
the node count. If the lint report shows rising failure counts alongside
rising node counts, maintenance is not keeping pace with
growth.
These are the questions the self-improving knowledge base must answer
honestly. The graph ledger provides the raw data. The lint report
provides the diagnosis. The publish loop provides the corrective action.
Together, they form a feedback loop that is measurable, auditable, and
improvable.
What 269 Nodes Actually
Represents
Represents
The 269 nodes are not abstract. They are 93 concept pages that define
the system’s vocabulary, 74 entity pages that document its components,
20 source pages that ground claims in evidence, and roughly 82 pipeline
and bridge entries that connect internal knowledge to published
authority. Each node is a piece of the system’s memory — some held by
the agent (via Hermes memory layers), some held by the vault (via
Obsidian and ChromaDB), and some held by the public site (via
WordPress).
The 1513 edges are the connective tissue that turns those nodes into
a graph. Without edges, 269 pages are 269 separate files. With edges,
they are a navigable, queryable, self-reinforcing structure where every
new page makes every existing page more discoverable.
That is what the graph ledger measures: not how much the system
knows, but how well it knows what it knows.
Conclusion: The Graph
Knows What It Is
Knows What It Is
A knowledge base that cannot measure itself cannot improve itself.
The graph ledger turns the abstract notion of “knowledge growth” into
concrete, auditable numbers. At 269 nodes and 1513 edges, the Council
Vault’s graph is dense enough to be useful, structured enough to be
navigable, and measured enough to be improvable. The next lint cycle
will change those numbers. The next publish cycle will change them
again. That is the point — not to reach a target number, but to build a
system where every change is visible, every connection is traceable, and
every improvement is measurable.
