Detecting Orphaned Code via Executable Registry Audits

Stub entries break inventory trust

A registry that lists a component but never runs it is a stub. The count looks healthy, but the row cannot be trusted. When a build or a deployment fails, the stub is blamed. The failure mode is simple: the inventory claims existence, the code does not exist in practice.

The result is a misleading component count. Stakeholders treat the number as a health metric. Developers waste time chasing phantom failures. The inventory is no longer an inventory; it is a wish list.

Executable audit turns rows into evidence

An executable audit runs every registry entry inside an isolated sandbox. The sandbox provides the same runtime constraints a production environment would. If the entry produces a result that matches its contract, the harness records CERTIFIED. If it runs without error but the contract cannot be verified, the harness records PROVISIONAL. If the sandbox cannot exercise the contract, the result is INCONCLUSIVE. If the entry crashes or produces the wrong output, the result is FAILED.

These verdicts replace the vague “present” flag with a concrete grade. Rows that return FAILED or INCONCLUSIVE are orphaned code. Rows that return CERTIFIED are trusted inventory items.

The process is model‑independent. No AI model decides the outcome; the harness executes the artifact and records the verdict. Byte‑for‑byte reproducibility of the release archive guarantees that the same entry will always receive the same verdict, provided the same sandbox configuration.

Worked example

A monorepo contains a registry entry utils/slugify. The entry declares a function slugify(text:string):string that should replace spaces with hyphens and lower‑case the result.

The audit harness launches a sandbox with Node 18, installs the package, and runs a test script:

import { slugify } from 'utils/slugify';
console.log(slugify('Hello World'));

The sandbox captures stdout. The expected contract output is hello-world. The harness compares the actual output to the expectation.

• The script exits with code 0 and prints hello-world.
• Verdict: CERTIFIED.

A second entry utils/oldParser claims to parse CSV strings. The same harness runs a test script, but the module throws ReferenceError: process is not defined.

• The script exits with code 1.
• Verdict: FAILED.

The failed verdict flags utils/oldParser as orphaned code. It can be removed, rewritten, or moved to a separate legacy catalog.

Running this audit across the whole registry turns a static list into a living inventory.

Integrating the audit into your workflow

Start by selecting a small, representative slice of the registry. Run the executable audit on that slice using the same sandbox configuration you will use for the full run. Inspect the verdicts.

• If most entries are CERTIFIED, the slice is healthy.
• If many entries are FAILED or INCONCLUSIVE, investigate the root causes.

Common causes are missing peer dependencies, outdated runtime targets, or stale build scripts.

Once the slice is clean, scale the audit to the entire registry. Store the verdicts alongside the registry metadata. Treat the verdict column as the source of truth for inventory trust.

When a new component is added, the build intent gate registers the proposal, resolves licensing, and returns a terminal state. The audit harness then runs the component automatically. Only components that achieve CERTIFIED or PROVISIONAL are merged into the catalog.

This disciplined flow prevents stub entries from ever reaching the published count. It also gives you a quantitative health score without resorting to vague metrics. For a deeper dive into how the harness works, see the related post on Executable Registry Audits Eliminate Stub Entries.

Monday’s concrete step

1. Clone the repository that holds your component registry.
2. Identify a folder that contains at least five registry entries.
3. Run the harness locally (the same command used by the SHPBL live run) against that folder.
4. Record the verdicts and flag any FAILED or INCONCLUSIVE rows.

By the end of the day you will have a concrete list of orphaned code and a proof that the remaining entries are executable. The next sprint can focus on fixing or retiring the flagged rows, turning your component count into a trustworthy inventory.