Discovery Result Safety

A Discovery result is a candidate with evidence. It is not automatic permission to call an endpoint, install a package, share data, or delegate work. This distinction matters even more when semantic Discovery returns highly relevant results. Relevance and safety are different questions.

Discovery is valuable because it narrows the search space and returns OAN-verifiable material. The relying party still decides whether to use the result.

This is especially important for autonomous agents. If an agent can select tools dynamically, a Discovery result may quickly become an action. The client or agent runtime should require verification and policy checks before the candidate enters an executable plan.

Semantic discovery pipeline

What a Result Can Tell You

A good Discovery result can tell you:

  • which resource matched;
  • what DID identifies the resource;
  • what resource type it is;
  • what tags, domains, and description were indexed;
  • what package or proof references support it;
  • what lifecycle status is known;
  • why it may match the query;
  • which endpoint, artifact, manifest, or schema is associated with it.

That is useful evidence. It is not a full risk assessment.

The result can reduce uncertainty about provenance, identity, and package facts. It cannot evaluate every future behavior of the resource. A verified API can still return bad data. A verified skill can still request permissions the user should deny. A verified agent service can still be inappropriate for sensitive data.

What a Result Cannot Guarantee

Discovery does not guarantee:

  • legal suitability;
  • business quality;
  • correctness of output;
  • safety of tool behavior;
  • compliance with your internal policy;
  • availability of the endpoint;
  • permission to access private data;
  • absence of prompt injection or malicious behavior;
  • native protocol authorization.

Those decisions belong to client policy, enterprise controls, runtime checks, and human review where appropriate.

This is not a failure of OAN. It is an honest boundary. OAN handles pre-use trust evidence. Runtime risk belongs to the protocol, application, user environment, and domain policy.

Semantic Scores Are Relevance Signals

Semantic score, reranking score, tag match, or explanation text should be treated as relevance information. A candidate may be relevant and still unsafe for a particular use. A candidate may have lower score but stronger policy fit. A high score should not bypass verification.

For user interfaces, this means trust details should not be hidden behind a single ranked list. The result card should expose resource type, lifecycle, domains, tags, and proof links so the user can inspect more than relevance.

A good result card can show relevance and trust separately. Relevance might be a score, matched tags, or explanation. Trust might show Root proof, active lifecycle, verified hashes, and domain coverage. Mixing them into one number hides important decisions.

Safe Client Behavior

A safe client should:

  1. query Discovery;
  2. verify Discovery response provenance;
  3. inspect candidate metadata;
  4. verify package proof and hashes;
  5. check lifecycle and domains;
  6. apply local policy;
  7. continue with native protocol security only after the OAN evidence passes.

If a user asks an autonomous agent to select tools, the agent should not skip these steps just because a candidate is highly ranked.

The same rule applies to batch or automated workflows. If a system periodically refreshes tool candidates, it should refresh verification too. A cached high score from an old query should not become permanent permission to call a resource.

Handling Untrusted or Partial Results

If a Discovery response lacks proof references, signature material, lifecycle, or package data, a client may still show it as informational depending on the product, but it should not label it as verified. A better UI distinguishes “candidate found” from “candidate verified.”

For enterprise settings, partial evidence may be enough to start review, but not enough for automatic invocation.

For public search experiences, partial results should be visually distinct. Users can still learn that a resource exists, but the UI should not imply that it has completed the OAN evidence chain.

Further Reading