Prioritising Repairs by Load‑Bearing Impact

Audits that end in a spreadsheet

Teams run static‑analysis or dependency audits, collect hundreds of warnings, and hand a report to the next sprint. The report sits on a drive, the items are discussed, and most never become code changes. The failure is not the audit itself – it is the lack of a decision framework that tells engineers which findings actually affect the product’s ability to run.

When the audit output is treated as a to‑do list, technical debt balloons. Engineers spend time on low‑impact refactors while the real load‑bearing components remain fragile. The result is a perpetual audit‑repair loop that never delivers measurable improvement.

Load‑bearing impact as a ranking signal

Load‑bearing impact measures how many runtime paths, critical features, or external contracts depend on a piece of code. It is a concrete, computable property: count the distinct entry points that eventually invoke the function, and weight each by the feature’s usage frequency. The analysis is model‑independent; it works from the repository’s own call graph and usage telemetry.

A function that serves a payment gateway, for example, will appear in the call graph of every checkout flow, in health‑check endpoints, and in the audit log exporter. A utility that formats dates for log messages will appear only in a handful of internal scripts. The former is load‑bearing; the latter is not.

Prioritisation workflow

1. Run the load‑bearing analysis – generate a table of symbols with a “bearing score”. The score is the sum of weighted call‑graph edges.
2. Merge the table with the audit findings – each audit warning now carries a bearing score.
3. Apply a cut‑off – decide that only findings with a bearing score above a threshold will be turned into repair pull requests.
4. Create a repair PR per high‑score item – the PR description includes the audit rule, the bearing score, and a short test plan.

Because the bearing score is derived from the repository itself, the ranking is repeatable and auditable. Engineers can see exactly why a particular warning was promoted to a repair. Low‑score items can be deferred to a future technical‑debt backlog without losing visibility.

From ranking to merged repair

The ranked list feeds directly into the repair pipeline described in the pillar post /blog/closing-the-loop-from-repository-audit-to-merged-repair. The only addition is the bearing filter. When a repair PR lands, the certification harness runs the artifact and records a verdict. If the harness returns CERTIFIED, the change is safe to merge; if it returns PROVISIONAL, the team knows the change is reproducible but still needs correctness validation.

This approach eliminates the “audit‑repair” disconnect. Instead of a report that never moves, the audit becomes a source of prioritized, test‑backed pull requests. The effort spent on each PR is proportional to the risk it mitigates, which aligns engineering capacity with product resilience.

What is hard, and how to cope

Computing bearing scores for very large monoliths can be expensive. Incremental analysis – running the graph builder only on changed modules – reduces cost but may miss cross‑module dependencies that only appear after a full build. Accept the trade‑off: run a full analysis quarterly, and use incremental runs for weekly audit cycles. The INCONCLUSIVE verdict from the harness is a useful signal that the current test suite does not cover the input contract; treat it as a prompt to add tests rather than a failure of the repair.

Monday’s concrete step

1. Clone the repository you plan to audit.
2. Run the load‑bearing analysis tool (the command is documented in the project’s /volumes page).
3. Export the bearing scores to a CSV file.
4. Open the latest audit report, join it with the CSV on symbol name, and filter for scores > 50 (or another threshold that matches your risk appetite).
5. Create a single repair pull request for the highest‑scoring finding and attach the audit rule and bearing score to the PR description.

Starting with one high‑impact repair on Monday turns the audit from a static document into a measurable improvement. The same pattern scales: each subsequent audit cycle repeats the steps, and the backlog of low‑impact warnings stays visible without stealing focus from the code that truly keeps the product alive.