H.2 Discovery

A search result is useful only if you can tell whether it is the contract you may depend on. A similarly named implementation, an old design document, and a widely copied example can all rank above the supported API. Discovery therefore combines finding evidence with interpreting its authority and freshness.

Find The Surface And Its Context

Imagine you know one symbol from an error. H.2.1 Code Search asks the global index for definitions, references, history, representative consumers, and ownership without assuming those files exist in your sparse checkout. A missing result can mean absent code, missing index support, stale data, or an access boundary; those diagnoses lead to different repairs.¹

Next, H.2.2 API Discovery compares the declared API, examples, consumers, and implementation. The exercise is to find the supported surface and identify which observed behavior is merely private implementation. Popularity alone does not convert an accidental dependency into a compatibility promise.

Detect Stale Knowledge

Now add a design record that describes an older API and an example that still compiles through a compatibility shim. H.2.3 Knowledge Lifecycle makes support state, supersession, deprecation, ownership, and retirement visible so search does not present all three artifacts as equally current.

If you cannot locate anything, start with Code Search. If you found several plausible answers, use API Discovery. If the problem is that yesterday's answer still looks authoritative, go to Knowledge Lifecycle.

Footnotes

1. Why Google Stores Billions of Lines of Code in a Single Repository — global code discovery and cross-reference infrastructure ↩