How OAN Works

OAN works as a trust-preserving publication pipeline. A resource provider prepares identity and metadata, a Registrar performs onboarding checks, Root verifies and accepts a version, CDN distributes package material, Discovery indexes verified resources, and a client verifies evidence before invocation.

The important point is that these stages are separate on purpose. A submission can be accepted by a Registrar but not yet accepted by Root. A package can be accepted by Root but not yet visible in Discovery. A Discovery result can be relevant but still require client-side verification. OAN treats these distinctions as part of the product experience rather than hiding them behind one vague “published” status.

This staged model is what lets OAN be useful across different kinds of resources. A Skill package, an MCP Server, a Tool/API endpoint, and an Agent Service do not share the same runtime protocol, but they can share a common path for identity, registration evidence, Root acceptance, package proof, authorized-domain scope, Discovery visibility, and verification before use. OAN standardizes the trust path before native invocation begins.

One Flow, Several Trust Checks

The high-level flow is easy to state:

Each stage reduces ambiguity. Instead of asking users to trust a search engine, OAN lets them inspect where a candidate came from and what evidence supports it.

The table also shows why OAN is not just a metadata registry. Metadata is present, but each important transition has a responsible actor and a verifiable output. Registrar checks improve onboarding quality. Root acceptance creates the publication proof. Discovery signs candidate responses. Clients verify before they cross into installation, connection, or invocation.

Why the Pipeline Is Not a Single API Call

It is tempting to imagine registration as one request that immediately makes a resource visible everywhere. That would be simpler to explain, but weaker in practice. OAN needs to support governed infrastructure nodes, asynchronous publication, multiple Discovery nodes, semantic indexing, resource version updates, and client verification. A single instant operation would blur too many responsibilities.

The current flow also makes operations more honest. If a user submits a skill and cannot find it immediately, the system can explain whether the issue is validation, Root acceptance, CDN publication, Discovery synchronization, or query matching. That diagnostic clarity matters for public services and for future third-party operators.

The same clarity helps ecosystems evolve without centralizing all work in one website. A community-facing registration skill can guide users through resource publication. An official service can operate full-scope Registrar and Discovery nodes. A domain-specific operator can run a specialized Discovery node. These different entry points can still converge on the same Root-verifiable lifecycle.

Registration to Root Acceptance

Registration begins with a resource package proposal. The provider supplies enough material for the Registrar to understand what is being published. The Registrar checks the request and submits Root-bound material through an authorized path. Root does not blindly trust the Registrar’s business judgment; Root verifies the parts that affect the OAN trust model.

The result of Root acceptance is not just “stored metadata.” It is an accepted package version with hashes and proof. That proof becomes the anchor for downstream distribution and Discovery visibility.

Root acceptance is intentionally conservative. It is the place where the system confirms that the upstream Registrar is authorized, the resource identity and package are internally consistent, and the declared domains are admissible. Root does not need to understand every business promise in a resource description. It needs to preserve the trust semantics that downstream components rely on.

Root Publication to Discovery Visibility

After Root acceptance, publication may proceed through queues and workers. Root archives package facts, publishes package artifacts, and notifies eligible Discovery nodes. Discovery nodes fetch or receive package references, verify Root proof and hashes, enforce their own authorized-domain scope, and index resource metadata.

This asynchronous path is especially important once the ecosystem contains many Registrars and Discovery nodes. It lets Root preserve a clear acceptance role while Discovery nodes scale read traffic and search workloads.

Asynchronous publication is also a resilience feature. Package archives, Discovery indexes, semantic indexes, and caches can be rebuilt from Root-accepted package facts. If a Discovery node falls behind or a semantic index is rebuilt, the system can recover without changing what counts as accepted truth.

Discovery to Invocation

Discovery answers a query with candidates, not with permission to execute arbitrary code. A candidate may contain DID material, package references, metadata, tags, domains, scores, and proof information. The client still verifies before use. If the resource is a Skill, the next step may be package retrieval and installation. If it is an MCP Server, the next step may be an MCP connection. If it is an Agent Service or Tool/API endpoint, the next step is native invocation under the user’s policy.

OAN’s value is that this native invocation begins from a verified resource path instead of from an untrusted URL.

That distinction is important for agent systems. Autonomous or semi-autonomous software often selects tools dynamically. OAN gives such software a verifiable way to ask: who published this resource, through which Registrar, under which authorized domains, in which version, and with which proof? The answer still does not guarantee product quality, but it gives the consumer a much stronger starting point than a loose search result.

What Readers Should Remember

The workflow has a simple rhythm: register, accept, publish, discover, verify, use. The details matter because OAN is designed for real ecosystem growth, not only a demo. Separate stages make the system auditable. Package proof makes results verifiable. Domain scope makes delegated authority meaningful. Semantic search improves relevance without changing the evidence chain.

For the technical architecture behind this flow, see the OAN yellow paper. For public integration guidance, see the resource registration and discovery guide.