Making In-Tree Prior Art Searchable to Stop Rebuilding It

A developer needs a token bucket rate limiter with a sliding window. They search the monorepo for RateLimiter. They find three results: a deprecated wrapper around Redis, an unmaintained interface from 2021, and a mock class in a test directory.

Assuming the organisation has no reusable implementation, they write a fourth one. It takes three days to write, test, and tune against edge cases.

Two weeks later, someone points out that the checkout service has had a rock-solid, in-memory sliding window rate limiter running in production for three years. It was never exported as an internal library. It lived in services/checkout/internal/limiter/bucket.go under the name ThroughputController.

Text search did not fail because the engine was poor. It failed because text search indexes lexical choices, not behavioural contracts.

The Vocabulary Gap in Internal Codebases

When engineers look for existing capabilities, they query names and domain nouns. But implementations are named after the immediate context of the ticket that created them: TenantBudget, SyncThrottle, PayloadGuard.

Even when teams establish a central component registry, it decays unless maintained through mechanical enforcement. Engineers rarely volunteer to extract, package, and document a 60-line utility when shipping a product feature. The utility remains buried in the service tree.

A standard code reuse audit using string matching or abstract syntax tree (AST) pattern matching runs into two distinct walls:

1. False negatives from nomenclature: Two functions with identical logic (for example, exponential backoff with full jitter) share zero tokens in their function names or parameter identifiers.
2. False positives from dead code: A search hits a file that looks like a match, but the module was abandoned eighteen months ago, lacks tests, and fails silently under concurrent load.

Finding code is worthless if you cannot immediately determine whether it works. As we explored in A Component Count Is Not an Inventory, knowing an artifact exists in a directory does not tell you if it can run.

Query: "Sliding window rate limiter"
├── Lexical Search: Looks for exact symbol matches ("RateLimiter")
│   └── Result: 3 matches (all mocks or stubs)
│
└── Contract Index: Looks for input/output invariants & verified behaviour
    └── Result: services/checkout/internal/limiter/bucket.go:ThroughputController
        └── State: Executable, passes concurrency harness, zero external dependencies

Indexing by Executable Contract

To make in-tree prior art discoverable, capabilities must be indexed by what they accept, what they guarantee, and whether they execute cleanly in isolation.

An executable contract index does not care what a function is called. It classifies code by three properties:

1. Pure Input/Output Signatures: What types cross the boundary, and what external side effects are required? A rate limiter requires an identifier, a timestamp, and a limit configuration; it returns an allow/deny verdict and a remaining balance.
2. Dependency Footprint: Does the code import five framework packages, an ORM, and a global database handle, or is it decoupled? Code tied to domain entities cannot be reused; code operating on primitives or standard interfaces can.
3. Execution Verdict: Can a test harness execute the component outside its parent repository and pass its invariant checks?

When you extract and isolate these components, the search problem changes. Instead of asking "Where is the string RateLimiter?", an engineer or a build system asks: "Is there an isolated unit that enforces a rate-limiting contract against a deterministic clock?"

This cuts through the proliferation of duplicate logic. Instead of finding eleven different retry loops scattered across different microservices, the repository surface is collapsed into verified primitives.

The Hard Part: Isolating the Seams

Indexing by contract sounds straightforward until you encounter legacy codebases. The failure mode here is underestimating coupling.

Most in-tree prior art is not neatly isolated. A developer writes an excellent sorting algorithm or state machine, but embeds a logger instance, a metric collector call, or a hard-coded configuration struct directly inside the loop.

To make that prior art searchable and reusable, the extraction pipeline must recognise where the core invariant ends and where the host environment begins. If extracting a component requires pulling in half the vendor directory, it is not reusable prior art; it is integrated application code.

A true inventory separates what is genuinely self-contained from what is entangled. It labels components that run cleanly as verified, and marks tightly coupled logic as provisional or unpromoted until the seams are cut clean.

What to Do on Monday

Stop asking your team to manually curate wiki pages or central utility packages that nobody updates.

1. Audit one utility domain: Pick a single, non-domain capability that every service needs: token parsing, retry policies, or payload chunking.
2. Scan across service boundaries: Search by structural shapes (functions taking a context, an interface, and returning a concrete status) rather than keyword names.
3. Run them in isolation: Strip the framework wrappers and run the raw functions through a local test harness. If a function cannot run without a live database or a config server, discard it from the reusable inventory.
4. Publish the contract, not just the path: Document the inputs, the failure modes, and the verified test status in a readable catalog.

When developers can query verified behaviour rather than guessing filenames, the habit of rebuilding existing code ends on its own.