Graph Load Audit

Surveys the graph at integration-depth scale. The audit answers a different question from Graph Audit: where Graph Audit asks "is the graph correct" (drift, ghosts, vocabulary, orphans, un-annotated edges), this audit asks "which nodes are pulling weight." A node may be structurally valid (passes its Form Contract, has annotated edges, no ghosts) and still be load-bearing or dormant; integration depth is what the audit measures.

The skill produces a tier-based report. True orphans (zero inbound across both wikilink and prose) sit at the top because they are the clearest signal of misintegration. Wikilink-orphans whose concept is saturated in prose (meta-category candidates) sit next, because their fix is a small wikilinking pass rather than a structural decision. Recently-seeded nodes get their own tier because their latency is by-design rather than misintegration. Low-usage Predicates and structurally-thin-by-design nodes (Aspirations, narrow Decisions) are reported but not flagged as findings.

The audit's purpose is to inform the project's discipline against premature commitment ([[Adopt Minimum-Viable-Architecture Stance]]) and the convergence-evidence test ([[Convergent Motivation as Load-Bearing Signal]]). A node with five inbound references has accumulated independent motivation; a node with zero has not yet earned its place. The audit makes that question answerable.

Steps

Step 1: Determine scope

Ask the user whether the audit covers the full graph or a scoped subset. Common scopes:

A full-graph audit is appropriate at curation pass cadence; scoped audits are appropriate when checking specific suspicions.

Step 2: Count inbound wikilink references per node

For each node in scope, count how many other nodes mention it via a wikilink. The pattern matches three reference shapes:

The node's own file is excluded from its own count. The result is a per-node integer: the number of OTHER nodes that wikilink to it.

A regex shape that matches all three forms for a given concept name C:

\[\[<C>(\]\]|\s*--\s|\|)

Where <C> is the regex-escaped concept (the part of the filename stem before any -- separator).

Step 3: Count predicate edge-usage for Predicate nodes

For Predicate nodes specifically, the inbound-wikilink count undercounts their actual load-bearing. Predicates are used as edge predicates (predicate::[[Target]]) far more often than as wikilink targets, and the edge-usage form is what makes them load-bearing.

For each Predicate node, additionally count occurrences of <predicate>:: across all nodes (excluding the Predicate's own file). A regex shape:

\b<predicate>::

The result is a per-Predicate integer: how many edges across the graph use this Predicate as their named relation. A Predicate with two edge-uses is genuinely under-pulling; a Predicate with two hundred is heavily load-bearing regardless of its wikilink-inbound count.

Step 4: Identify orphans and verify

A node with zero inbound wikilink references is an apparent orphan. Before reporting it as a true orphan, verify by also searching for prose mentions of the concept across the graph:

The distinction matters because the recommendations differ. A true orphan needs structural attention (cascade, deprecate, or accept-as-latent). A wikilink-orphan-prose-saturated needs a wikilinking sweep. A wikilink-orphan-prose-rare may be premature.

Step 5: Decompose prose mentions for meta-category candidates

When a node's wikilink-inbound count is low but its concept appears frequently in prose, decompose the prose mentions:

Only the third category is a candidate for wikilinking to the meta-category node. A meta-category node may have hundreds of total prose mentions and only a handful of legitimate-target prose mentions; the decomposition surfaces the true gap.

Step 6: Categorize by structural baseline

Some forms have a structurally-low inbound baseline. Reporting a low count for these as a "finding" is noise. Categorize accordingly:

For these categories, report the count but classify as "structurally appropriate" rather than as "under-pulling."

Step 7: Identify low-usage Predicates

For Predicate nodes, the load-bearing measure is edge-usage from Step 3, not wikilink-inbound from Step 2. A Predicate with edge-usage below ~10 is a candidate for either-find-it-work or merge-with-adjacent. Specifically:

Recently-seeded Predicates (e.g., scion_of shortly after the Scion Publication Model was adopted) are expected to grow and should be classified per Step 6.

Step 8: Produce the tier-based report

Group findings by tier:

For each Tier 1 and Tier 4 finding, name the specific recommended action and what would change it (e.g., "cascade reciprocal informed_by:: edges from Vocabulary Diversity Is a Feature and Translation Over Convergence to Synpraxis Spectrum -- both Convictions are claimed downstream by the Gloss but neither documents the back-edge").

Step 9: Stop

Do not edit nodes. Do not stage or commit. The audit produces findings; acting on them is a separate authoring pass (typically using Node Create for new nodes, direct Edit for cascades, or Predicate Propose for vocabulary changes).

If the user wants a follow-up action committed in the same session, surface the specific edits the audit recommends and let the user authorize them per finding. The audit's role is to surface the gaps; the user decides which are worth closing now.

Relations