302 nodes. 365 edges. 4 edge kinds. One BFS. The galaxy is the input graph, and compilation is traversal.
The Galaxy
Every governance system needs a map. Most organizations draw theirs by hand: org charts in PowerPoint, architecture diagrams in Lucidchart, dependency graphs scribbled on whiteboards during planning meetings. The map is always out of date because updating it requires remembering to update it, and nobody remembers.
CANONIC compiles its map from the governance artifacts themselves. The galaxy is a directed graph with 302 nodes and 365 edges, built automatically by phase 07 of the build pipeline (scopes-galaxy). Every governed scope in the system is a node. Every relationship between scopes is an edge. The graph is not a visualization; it is the input to the compiler, and compilation is traversal.
When the build runs, it does not iterate over a hardcoded list of files. It loads the galaxy graph and runs breadth-first search from a starting node, discovering every scope that is reachable. If a scope exists in the governance tree but is not reachable from the starting node, it does not compile. The graph is the source of truth, and anything not in the graph does not exist.
BFS From Any Node
The distinctive property of the galaxy is that any node can be the starting point. CLAUDE is the first composed instance: the CLAUDE.md at the repository root is compiled by running BFS from the CLAUDE node in the galaxy, discovering contextual INTEL and cross-scope LEARNING by graph distance. But MammoChat can be a starting node too, and so can CaribChat, OncoChat, or any other scope.
This means every scope can compile its own contextual surface. MammoChat’s compiled context includes breast health INTEL at distance 0, oncology INTEL at distance 1, and general clinical INTEL at distance 2. CaribChat’s compiled context includes Caribbean epidemiology at distance 0, breast health at distance 1, and the fleet-wide evidence base at distance 2. The same graph, the same algorithm, different starting points, different compiled surfaces.
The compiler does not need to know what the scopes are. It discovers them. Add a new scope to the governance tree, and the next build discovers it automatically, places it in the galaxy, and includes it in every BFS traversal that reaches it.
Budget by Distance
Not every node contributes equally. A scope at graph distance 0 (the starting node itself) contributes its full INTEL and LEARNING. A scope at distance 1 contributes a summary and its top five learning patterns. A scope at distance 2 contributes a summary and three meta-patterns. A scope at distance 3 contributes axioms only.
| Distance | Budget | Content |
|---|---|---|
| d=0 | All | Full INTEL, all LEARNING, complete context |
| d=1 | Summary + 5 | Scope summary, top 5 learning patterns |
| d=2 | Summary + 3 | Scope summary, 3 meta-patterns |
| d=3 | Axioms | Axiom statement only |
This budget function is what makes the system scalable. The galaxy has 302 nodes, and some scopes have thousands of learning patterns. Compiling all of them into every surface would produce documents that are too large to be useful. The budget function ensures that closer scopes contribute more context and distant scopes contribute only their essential truths, producing compiled output that is both comprehensive and readable.
Cross-Axiomatic Discovery
The galaxy has four edge kinds: PARENT edges (bidirectional, forming the tree spine), INHERITS edges (forward only, enabling cross-axiomatic discovery), and two additional edge types for specialized relationships. The INHERITS edge is the most powerful because it crosses repository boundaries.
When hadleylab-canonic declares that a scope inherits from canonic-canonic (the governance framework repository), the INHERITS edge allows BFS to discover INTEL from the framework itself. This means a clinical service like MammoChat can inherit governance constraints from the CANONIC framework without duplicating them. The constraint lives in one place, the governance repository, and every scope that inherits it discovers it through the graph.
Cross-axiomatic discovery is what makes CANONIC a framework rather than a collection of services. The services do not hardcode their governance rules; they inherit them, and the inheritance is discovered at compile time through graph traversal.
Idempotent Builds
A governance compiler that produces different output on consecutive runs is not a compiler; it is a random number generator. Idempotency was one of the hardest properties to achieve and one of the most important.
The fix required three changes. First, emit_json_stable() ensures that JSON output is serialized with sorted keys and deterministic formatting, so the same data always produces the same bytes. Second, BFS neighbor iteration is sorted, so the traversal order is deterministic regardless of how the graph was constructed. Third, timestamps only update when content actually changes, so a build that runs twice with no input changes produces byte-identical output.
Consecutive builds now produce identical output. This property is validated in the build pipeline, and a diff between consecutive outputs that shows any change is a build failure. Idempotency is not a nice-to-have; it is the foundation of trust, because a governance system that changes its compiled output without input changes is a system that cannot be audited.
Figures
| Context | Type | Data |
|---|---|---|
| post | gauge | value: 302, max: 302, label: GALAXY NODES |
Sources
| Source | Reference |
|---|---|
| Galaxy | ~/.canonic/canonic-canonic.github.io/MAGIC/galaxy.json |
| Build phase | 07-scopes-galaxy → 09-compile-claude |
| CANONIC | canonic.org |
| Hadley Lab | hadleylab.org |
| *BLOG | GALAXY | ONE GRAPH. EVERY NODE DISCOVERED. | 2026-03-10* |