A Component Count Is Not an Inventory

You search the internal package index for an HMAC-SHA256 request signer. The portal says one exists: auth-tools@2.4.1.

You pull it into a clean service. It immediately fails to build. It requires three peer dependencies that are not declared in its package manifest. It references an internal configuration server that was decommissioned eighteen months ago. When you finally stub those out, the function panics if the headers map is empty.

Diagnosing the failure takes forty minutes. Writing a clean, fifteen-line wrapper around the language runtime’s standard crypto package takes six minutes.

You write the wrapper. You commit it directly into your service repository. The corporate portal still reports that the company owns an authentication module, bringing the total in the catalog to 412.

Every engineering organisation above fifty developers tracks a component count. Very few maintain a real software inventory. The difference is not semantic. A count is a list of things someone once committed. An inventory is a ledger of things you can execute right now with known inputs and verified outputs.

The difference between an index and an inventory

A component registry usually begins as an infrastructure initiative and ends as an archaeological site.

The decay happens because static analysis makes promises that runtime environments refuse to keep. An indexer scans a source tree, identifies an exported class or public interface, parses the docstring, and creates a database record. The dashboard shows healthy growth: fifty new components this quarter, three hundred the next.

This creates a dangerous illusion of asset accumulation. In physical manufacturing, an inventory item sitting on a shelf has physical mass. It either fits the assembly line or it does not. In software, source text costs almost nothing to store, which allows non-functional code to pose as reusable capability indefinitely.

An AST export is not a component. It is simply text that compiled under a specific set of ambient assumptions on a specific day. Until you isolate that code from its originating repository, supply it with input data, and assert the validity of its output, you do not have a reusable asset. You have a historical artifact.

When an internal library indexes unverified code, it shifts the cost of verification from the catalog maintainer to the consuming engineer. That shift is catastrophic for adoption.

The calculus of the rewrite

Developers do not rewrite existing code because they suffer from "Not Invented Here" syndrome. They rewrite code because they understand the economics of verification friction.

When an engineer needs a utility to parse multipart form streams, calculate date offsets, or retry failed HTTP requests, they run a quick mental calculation:

1. Time to locate the internal component: two minutes.
2. Time to read documentation and evaluate dependencies: five minutes.
3. Time spent discovering hidden environment assumptions: twenty minutes.
4. Probability that the component actually works as advertised: forty percent.

If the expected time to verify an existing component exceeds the time required to write a minimal implementation from scratch, writing new code is the rational choice.

Cost(Reuse) = Search + Isolation + Verification + (Failure Rate × Rewrite Cost)

As an unverified component registry grows, the failure rate rises. Once that failure rate crosses roughly twenty percent, developers stop searching the registry altogether. They simply write the logic inline.

At that point, the organisation pays a double penalty. It pays to maintain the registry infrastructure that nobody trusts, and it pays for every team to independently rebuild, re-test, and re-debug the exact same business logic across twenty different repositories.

What execution requires

To turn a list of code fragments into a dependable software inventory, an organization must replace static indexing with an automated, reproducible verification pipeline. This requires three distinct technical properties.

1. Hermetic extraction

Reusable software cannot rely on implicit ambient context. If a date-formatting utility requires the root repository’s global logging singleton, it is not reusable. It is tethered.

A true code reuse audit must test components in total isolation. The extraction harness must pull the module into an empty execution context with zero network access, zero global configuration, and only its explicitly declared dependencies. If it cannot initialize in isolation, its inventory state is zero.

2. Contract exercise, not type inspection

Static type signatures describe what data structures look like; they do not describe what code does. A signature like parse(input: string): Result tells you nothing about how the function handles a 10MB payload, invalid UTF-8 sequences, or null byte injections.

An inventory grade must be based on contract execution. The harness must feed valid, boundary, and malformed inputs to the artifact and compare the actual outputs against deterministic assertions. If an artifact has no executable test vectors, it is not an inventory item—it is an unproven hypothesis.

3. Clear, non-binary grading

Binary pass/fail systems hide critical operational detail. When a verification run fails, why did it fail?

A reliable inventory requires distinct execution verdicts:

• Fully Certified: The artifact runs in isolation, exercises its complete contract, and passes all assertions.
• Provisional: The artifact compiles and runs reproducibly, but its correctness assertions are incomplete.
• Inconclusive: The harness itself could not supply the necessary environmental inputs or mock contracts. This is a harness limitation, not an artifact defect, and must be tracked separately.
• Failed: The artifact threw unhandled exceptions, failed contract assertions, or broke isolation boundaries.

Tracking inconclusive results separately is vital. If you mark an inconclusive run as a failure, you discard potentially valuable code. If you mark it as a pass, you poison the inventory with unverified logic.

The SHPBL approach

SHPBL treats reusable code as a verified engineering discipline rather than a searchable index. We do not aggregate counts into a single vanity metric. We report our counts apart: the engineered catalog, the discovery-engine vault (unpromoted rows derived from a 40-primitive matrix), and our standalone Crown Jewels.

Every artifact in the catalog runs through our certification harness, which executes the code in isolated environments and publishes the explicit verdict: CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED.

We use no AI models inside our runtime software; behavior is fully deterministic, owned, and free of hallucination surfaces. Byte-for-byte reproducibility across all release archives is guaranteed and sealed by published checksums.

You can run your own repositories through our free repository evaluation to see your actual verified yield, or inspect our full gauntlet via the Practitioner tier and Complete Master Library.

A verification audit for Monday morning

If you want to know the true state of your internal component registry, do not audit the database rows. Audit their execution.

Take these four steps on Monday:

1. Pull a random sample. Select twenty components from your internal package manager or shared utility libraries. Choose items from different teams and different years.
2. Spin up a bare execution container. Create an empty runtime environment with standard toolchains installed, but with no local configuration files, no access to internal staging networks, and no ambient environment variables.
3. Attempt cold instantiation. Try to install and import each of the twenty components into a blank project file. Do not fix their missing peer dependencies or patch their build scripts. Record how many build cleanly on the first attempt.
4. Run three test vectors. For the components that do build, feed them three inputs: a standard valid payload, an empty input, and an intentionally malformed input.

Count how many of the twenty survive all four steps without manual developer intervention.

If four out of twenty pass, your component count is not whatever your registry dashboard says. Your component count is twenty percent of that number. The rest is technical debt dressed up as reusable capability.

Once you know that number, stop adding unverified code to the pile. Grade what you have, throw away what fails isolation, and never mark an artifact as reusable until a harness has executed it and recorded the verdict.