Live Execution of Registry Entries to Detect Stale Code

Stale entries hide behind a tidy count

A component count looks impressive on a dashboard, but the number tells nothing about whether the listed rows actually run. In many organisations the registry contains placeholder stubs, dead‑ends, or code that no longer compiles. Those rows inflate the count while the underlying inventory is effectively empty. The failure mode is clear: a static list is treated as an inventory, and stale code goes undetected until a runtime error surfaces in production.

Execute each entry as an isolated process

The only way to prove that a registry entry is alive is to run it. An executable registry treats every row as a tiny program that the certification harness launches in a sandbox. The harness supplies the declared input contract, captures the exit code and any output, and records a verdict – CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED. Because the harness never relies on a model, the result is computed rather than generated and repeatable across runs.

Consider a simple utility function stored in the registry:

// registry entry: src/util/slugify.ts
export function slugify(text: string): string {
  return text.trim().toLowerCase().replace(/\s+/g, '-')
}

The harness creates a temporary runner that imports the module, calls slugify('Hello World'), and checks that the return value matches the expected pattern. If the module fails to import because of a missing dependency, the harness marks the entry FAILED. If the function throws an exception for a corner case, the verdict becomes PROVISIONAL – the code runs but its correctness is not yet asserted.

Running every entry this way turns the registry from a spreadsheet of names into a live inventory. Each row is either verified as executable or flagged for attention. The process is cheap: the harness reuses the same container image, and preview runs cost nothing because the Build Intent gate only records intent, not entitlement.

What the results mean for your inventory

A verdict of CERTIFIED confirms that the component can be loaded, executed, and satisfies its contract. Those rows form the reliable core of the inventory. PROVISIONAL entries are still usable, but they need additional tests or contract clarification before they can be trusted in critical paths. INCONCLUSIVE rows indicate that the harness could not exercise the contract – perhaps the entry requires external services that are not available in the sandbox. Those are not defects in the code, but they do signal a gap in the testing environment. FAILED entries are the stale code that should be removed or repaired.

When you aggregate the verdicts, you obtain a live inventory count that is meaningful. Unlike the raw component count, this number reflects actual executability. It also provides a clear remediation path: focus first on FAILED entries, then on INCONCLUSIVE ones, and finally tighten contracts for PROVISIONAL rows.

The approach aligns with the argument in the pillar post /blog/a-component-count-is-not-an-inventory. There the author stresses that a claim of “X components” is not an inventory unless each component can be read, executed and graded. Live execution supplies the missing grading step.

A Monday‑ready step

Pick a small, representative slice of your registry – for example all utilities under src/util. Run the certification harness against that slice using the offline edition of the library. Record the verdicts and prune any FAILED rows. By the end of the day you will have reduced the stale‑code surface and turned a static count into a live inventory for that subset. Replicate the process next week for the next slice, and you will gradually convert the entire registry into trustworthy, executable entries.