Sealed, evaluated, and searchable

A platform team ships forty cognitive units across three product lines. An agent builder asks which judgment handles weekday practicality for meal planning. Someone opens Slack, searches Notion, reads three prompt threads, and still cannot say which package is measured, owned, or safe to call on a busy week. That is a library design problem rather than a search-engine problem, because no ranking algorithm can recover information the packages never published.

What the builder needed was the ability to choose correctly before spending anything. Selection had to happen without invoking the judgment, without reading the template, and without asking the author. Everything else on this page follows from that one requirement, because sealing, evidence, and searchable metadata are the three conditions that make selection-without-execution possible, and a library missing any one of them collapses back into archaeology.

Helpful context: Libraries of cognition defines what gets packaged. Packages, not prompts states what a package contains. Evaluation as engineering explains the evidence lane. This page covers discovery.

Selection without execution is the requirement

Everything a caller needs to decide has to be answerable at browse time. That sounds like a search feature, but it is a claim about what a package must publish, because a catalog can only answer questions the entries were required to declare.

The requirement splits cleanly by what can be known when. Whether a package handles this judgment, covers this terrain, needs this authority, and has performed acceptably are all properties of the package, knowable before any call. Whether this particular week is practical is a property of the case, knowable only by running the judgment. A library works when the first set lives in metadata and only the second set costs tokens. Libraries fail when the two sets blur, since callers then execute in order to find out whether they should have executed.

That division is why the three properties below are preconditions rather than features. Each one protects the browse-time answer from a different kind of corruption.

Why sealing comes first

Sealing is the precondition that has to hold first, because it determines what the other two can be built on. If discovery requires opening the prompt, the library is a folder of secrets, and callers behave accordingly: agents re-read prose, humans diff templates, and substitution becomes guesswork.

The failure is self-reinforcing, which is why it deserves more weight than it usually gets. Once template bodies are visible at browse time, callers start depending on them, because prompt text is more specific than any contract summary and therefore more tempting. Dependencies form on wording that the maintainer believed was internal. The contract stops being the interface while still being described as one, and the next implementation change breaks callers who were never supposed to be able to see what changed.

So chain-of-thought, few-shot examples, and internal routing stay inside the sealed package rather than appearing in catalog results. Operator transparency belongs in inspect endpoints behind explicit grants, where reading internals is a deliberate act with an audit trail. Cognitive capability should be encapsulated makes this argument for the invoke path, and sealing extends the same protection to the discovery path.

Why evidence has to travel with the version

Sealing alone produces a catalog of opaque, unrankable boxes. A caller can see that AssessMealPracticality exists and cannot tell whether to trust it, which means selection degrades to whatever name appears first. Searchable without evaluated is the more dangerous arrangement, because a row that lists a package without suite scores, regression status, or calibration age invites callers to read availability as endorsement. Published is not qualified.

Evidence therefore has to be bound to the version rather than to the package name. That binding is what lets an agent prefer JudgeWeekdayPracticality v1.4 with green regression over v1.3 with stale calibration without reading either template. Suite identity, scores on declared distributions rather than demo anecdotes, regression status for the current release train, known failure modes, and an operational profile covering cost, latency, and purity all belong to the version that was measured.

Freshness is part of the same argument, since evidence decays while the version number holds still. A sealed package with year-old calibration is genuinely sealed and still unsuitable for autonomous invocation, so suite age and last promotion date have to be visible, and stale suites should rank down even when the semantic version has not moved. Otherwise the catalog reports confidence it can no longer justify.

What the metadata has to answer

Given those two constraints, the metadata schema is the load-bearing design decision, because it is the only channel left through which a caller can learn anything. The schema is fixed by the questions callers actually ask before invoking.

Selection question	Metadata that answers it
What judgment does this perform?	Decision sentence, input and output schema
What terrain is it for?	Domain, applicability summary
What authority does it need?	Grants, side-effect flags
How has it performed?	Suite scores, regression status, cost and latency
Can I substitute v2 for v1?	Contract hash, substitution guarantees
Who owns it?	Maintainer, release policy

Substitution deserves attention as a metadata field rather than a separate topic, because the alternative is a human diffing prompts. An agent selecting v2 needs the catalog to state that v2 is substitutable for v1 on this interface, which means contract hash compatibility, semantic version bands, and rollback paths are browse-time facts. Substitution rules defines the gates those fields encode, and search is where callers discover which packages pass them.

The right mental model is a dependency registry rather than a wiki. Wikis optimise for human reading, registries for selection under constraint, and the difference shows in what each makes easy: a wiki makes it easy to read everything, a registry makes it easy to choose without reading anything.

What this looks like in practice

An agent needs weekday practicality assessment for the Meal Companion. It queries the judge library filtering for schedule-fit judgment type, meal-planning domain, and read-plan authority. The catalog returns JudgeWeekdayPracticality v1.4 with its contract summary, a busy-week grader floor of 0.82, latency p95, owner team, and substitution compatibility with v1.3. The agent reads the manifest through inspect, confirms applicability for this week's interpreted calendar, and invokes, having never seen last sprint's paragraph-level prompt edits.

Change the need to a production assessor and the query has to change with it. Filtering for single-evening-fit judgment type, meal-planning domain, and domain-library placement returns AssessMealPracticality v2.1 with an evening-fit suite, a busy-evening calibration note, and a flag that it is not substitutable with judge-library entries. Those two packages share vocabulary and serve different shelves, so a caller that matched on words alone would invoke an evaluation judge for a production decision. That is the case that shows why metadata schema matters more than embedding quality.

Human architects and autonomous agents run the same discipline at different depths. Architects browse to assign placement and audit drift, while agents query mid-loop when terrain shifts, because a busy week and a dinner party week are not the same catalog row. Human views may carry richer summaries than agent APIs need, and both descend from the same metadata schema rather than from a prompt preview pane. Structured filters stay the default with semantic assist layered over metadata fields, since semantic search over sealed innards is a sealing failure wearing a search-quality costume.

Where this breaks

Each common failure is a violation of one of the three preconditions, which is the useful way to recognise them early.

Indexing template bodies breaks sealing, and it is the most frequent error because it looks like progress. Embedding over prompts feels like discovery while hiding contract drift and ranking forks by wording similarity rather than fitness for terrain. Exposing innards for transparency is the same violation with better intentions, and belongs behind debug grants instead of default browse. Publishing without eval fields breaks the evidence condition and invites trust by label alone. Sealing without metadata breaks searchability, and its symptom is distinctive: contracts exist, nobody can find them, and autonomy collapses into longer system prompts listing package names from memory. Conflating judge and assessor shelves in results breaks selection itself, letting agents invoke evaluation judges for production decisions or the reverse.

What to do next

The whole apparatus rests on one decision, which is what the manifest is required to carry. Fields chosen well let a caller answer whether this is the right judgment and whether it is safe to trust without opening the package, which is the only reason sealing and search can coexist. Fields chosen badly push callers back to reading templates, and once that happens the contract stops being the interface no matter what the catalog claims.

So the practical work is to make manifest completeness a publish gate rather than a documentation aspiration. Decision, domain, authority, suite pointer, owner, and limitations are required for a row to be selectable at all, which turns catalog quality into a pipeline property instead of a review habit. Inspect endpoints that return contract and evaluation summary without running judgment then give agents somewhere to look, and teaching them structured queries before embedding fallback keeps that path the cheapest one available.

See substitution rules for safe swaps, inspect before you call for pre-invocation manifest reads, and do not rediscover known work for why search must beat prompt rewrite.

Read next: Substitution rules.