Semantic Discovery
Semantic Discovery helps OAN find better matches for natural-language needs. It improves relevance, recall, ranking, and explanation. It does not change the trust model. A resource still has to be Root-accepted, package-verified, lifecycle-valid, and within the Discovery node’s authorized-domain scope before it should appear as a trusted OAN candidate.
This distinction is central to OAN’s design. Semantic search is powerful, but it is not authority. Similarity does not grant permission. A high score does not repair a missing Root proof. An embedding match does not override a revoked package or a domain boundary.
For readers comparing OAN with ordinary AI search, this is the most important difference. OAN can use modern retrieval techniques, but it surrounds them with admissibility checks. The search engine is allowed to be clever about language; it is not allowed to be careless about trust.
Why Semantic Discovery Matters
Agent resources are not always found by exact keywords. A user may ask for “a tool that checks API security risks,” while a resource describes itself as “OpenAPI risk analysis and endpoint policy review.” A developer may need an MCP server for “retrieving internal knowledge base documents,” while the resource metadata uses “enterprise retrieval” and “document search.” Exact tag matching alone can miss good candidates.
Semantic Discovery lets the system use descriptions, examples, tags, protocol fields, resource type, and metadata together. It can map user intent to resource capabilities even when the words differ. This is especially valuable for agent ecosystems because users often describe tasks, not package names.
The same problem appears across resource types. A Skill may describe the workflow it automates. An MCP Server may describe the tools it exposes. A Tool/API may describe an operation surface. An Agent Service may describe a role or service capability. Semantic Discovery gives OAN a way to compare those descriptions without forcing every resource into one rigid keyword vocabulary.
Trust-First Retrieval
The semantic pipeline should operate over verified resource material. A Discovery implementation can use embeddings, lexical indexes, hybrid retrieval, reranking, and explanation models, but the candidate pool must remain bounded by trust rules.
| Pipeline stage | What happens | Trust constraint |
|---|---|---|
| Package synchronization | Discovery receives Root-accepted package material. | Verify Root proof and package hashes. |
| Index construction | Metadata, tags, examples, and descriptions become searchable. | Use verified package fields as source of truth. |
| Candidate recall | Search retrieves possible matches. | Exclude revoked, invalid, or out-of-scope resources. |
| Ranking | Hybrid scoring orders candidates. | Ranking cannot bypass authorization. |
| Response | Discovery returns signed result material. | Include evidence for client verification. |
In other words, trust narrows the search space before relevance decides order.
This order should be visible in implementation and testing. Negative tests should prove that an out-of-scope resource is not returned even if it is a perfect semantic match. Index rebuild tests should prove that revoked or superseded resources disappear from active results. Benchmarking should measure retrieval quality without weakening those invariants.
Relationship to GRAIL
The OAN slides and research materials connect semantic Discovery to GRAIL, a deep-granularity hybrid resonance framework for real-time agent discovery. The key idea is that agent-resource search should combine structured metadata with semantic matching rather than rely on a single flat keyword index.
GRAIL-style retrieval is a natural fit for OAN because OAN already makes resource metadata structured and verifiable. DID Documents and ResourcePackages provide resource type, capability tags, descriptions, examples, protocol information, and package references. Semantic search can use those fields while still treating Root proof and lifecycle as non-negotiable constraints.
The result is a stronger combination: governance-aware trust evidence plus serious retrieval quality.
GRAIL is useful here because agent discovery is not only about finding a document similar to a query. It is about matching task intent to machine-usable capabilities under latency and scale constraints. OAN supplies the governed resource set; semantic Discovery improves how that set is searched.
What Semantic Indexes Are
Semantic indexes are derived state. They may contain vectors, token indexes, sparse retrieval structures, reranking features, or explanation caches. They are useful, but they are not the source of truth. If package metadata changes, lifecycle state changes, authorization scope changes, or Discovery configuration changes, indexes may need to be updated or rebuilt.
This is why operational tooling matters. A Discovery node should be able to rebuild semantic indexes from verified packages. It should not require manual reconstruction from ad hoc notes. If the index says one thing and package proof says another, package proof wins.
Derived indexes also create a design responsibility. Operators should know which package revision, embedding model, tokenizer, or ranking profile an index was built from when those details affect behavior. A public user does not need all of that internal data, but the system should be debuggable when results look wrong.
Query and Explanation
A semantic Discovery response can be more helpful when it explains why a candidate matched. It may show matched capability tags, relevant description fragments, resource type, protocol, or domain. It may also expose a score or structured reason. Explanation should be useful without pretending to be proof.
For example, a result might say that a skill matched because its description covers “API security review” and its tags include code-analysis and security-review. That helps the user understand relevance. The proof section should separately show Root proof, package hash, lifecycle, and DID identity. Mixing the two weakens the model.
A clear UI can therefore show two different kinds of confidence. Relevance confidence explains why the resource may satisfy the user’s need. Trust confidence shows whether the publication path and evidence are valid. Users need both, especially when an agent is selecting resources automatically.
What Semantic Discovery Must Not Do
Semantic Discovery must not:
- index unverified material as trusted OAN resources;
- return out-of-scope resources because they are semantically similar;
- treat capability tags as domain authorization;
- hide revoked or superseded lifecycle state behind a high relevance score;
- make clients skip package and proof verification;
- become a separate, unaudited source of resource truth.
These restrictions make semantic search more valuable, not less. Users can benefit from better matching without losing the ability to verify the result.
They also leave room for future innovation. OAN can improve ranking models, add domain-specific retrieval plugins, support multilingual queries, or expose richer explanation fields without redefining what makes a resource trusted. That separation keeps the protocol stable while retrieval technology evolves.