Live Load‑Bearing Dependency Graph from Execution Traces

The hidden cost of a static dependency graph

Teams often assume that a repository‑wide dependency graph tells them which code matters. The failure mode is clear: the graph includes every import, even those guarded by feature flags, dead‑code branches, or test‑only paths. When a refactor removes a leaf node that never runs in production, the static graph shows no impact, yet the build still fails because the node was declared a dependency. The audit trail is polluted with optional code that never bears load. The result is a software inventory that looks complete but cannot be trusted.

Execution tracing reveals the load‑bearing subset

Runtime tracing records the exact call stack for each request that hits production. By instrumenting the entry point of every module and writing a lightweight trace record, you collect a stream of “module‑A called module‑B” events. The trace is a concrete log, not a model‑generated guess. After a day of traffic, you can collapse the log into a directed graph where an edge exists only if the call occurred. The graph now represents load‑bearing code: every node has been exercised, every edge has carried real traffic.

Turning traces into a trustworthy inventory

Take the raw trace file and feed it to a simple reducer:

// Minimal reducer – TypeScript for clarity
type Edge = `${string}->${string}`;
const edges = new Set<Edge>();

for (const line of traceLines) {
  const [caller, callee] = line.split(' ');
  edges.add(`${caller}->${callee}`);
}

The resulting set of edges defines the runtime dependency graph. Nodes with no outgoing edges are leaf components that were actually used; nodes with no incoming edges are entry points that saw traffic. Compare this graph to the static one: the difference highlights optional paths, feature‑flag branches, and dead code. Because the graph is derived from execution, each row can be read, executed, and graded – it satisfies the definition of a real software inventory.

Applying the graph to audit and refactor

With the load‑bearing graph in hand, you can answer three practical questions on Monday:

1. Which modules are never hit in production? Remove them to shrink the codebase and reduce attack surface.
2. Which modules sit on a single inbound edge? They are candidates for extraction or dedicated testing.
3. Which paths are only taken under a flag that has not been toggled for weeks? Flag those as optional and document them separately.

Because the graph is built from production traffic, the audit is repeatable. Run the trace again after a deployment and diff the graphs; any new edges indicate newly load‑bearing code, any missing edges signal a regression in coverage.

How SHPBL makes this concrete

SHPBL supplies a model‑independent library that harvests load‑bearing graphs from existing repositories. The same method powers the HTTP API, the typed TypeScript client, and the offline file‑based edition, so you can integrate tracing into your CI pipeline or run it on live traffic without additional agents. The certification harness records a verdict for each harvested artifact – CERTIFIED if the graph matches the execution contract, PROVISIONAL if reproducibility is confirmed but correctness is pending, INCONCLUSIVE when the harness cannot exercise the contract, and FAILED otherwise. Start with a free repository evaluation to see the method in action, then upgrade to the Practitioner tier for the full gauntlet. Details are on the SHPBL home page and the complete master library.

For a deeper look at why a component count alone is insufficient, read the pillar post “A component count is not an inventory”.

---

Next step: instrument your main entry points with a one‑line trace logger, collect a day’s worth of production logs, and generate the load‑bearing graph using the reducer snippet above. Compare it to your static graph and flag any mismatches for review. This simple exercise gives you a trustworthy inventory you can rely on for audits and safe refactors.