Publication Lifecycle

Publication in OAN is a lifecycle, not a single flag. A resource can be submitted, accepted by Root, published to the distribution path, indexed by Discovery, superseded by a newer version, suspended, or revoked. These states let users understand where trust evidence exists and where propagation is still pending.

The lifecycle is especially important for public services. A user registering a resource needs to know whether the submission failed, is waiting for Root, has been accepted, or is simply not visible in Discovery yet. Operators need the same distinctions when diagnosing queues, index lag, or domain-scope mismatches.

Lifecycle language also prevents a common mistake in distributed systems: treating yesterday’s evidence as today’s permission. A package may have been accepted, a node may have been authorized, and a Discovery result may have been visible at an earlier time. The consumer still needs to know the current state before acting.

Main Lifecycle Stages

Not every UI has to show every internal state, but public tools should avoid collapsing them into one vague success message.

Different audiences need different levels of detail. A first-time publisher may only need “submitted,” “accepted,” “visible,” and “rejected.” An operator needs queue positions, publication cursors, indexer health, and proof verification status. SDKs need machine-readable states so applications can decide whether to retry, wait, warn, or reject.

Root Acceptance

Root acceptance is the trust-defining moment for a resource version. Root verifies the Registrar, DID material, hashes, domain coverage, package consistency, freshness, and proof requirements. If accepted, Root can generate package proof and record accepted claims.

Root acceptance is not the same thing as being searchable. It means the package has passed Root-level checks and can move into distribution. Downstream systems still need to receive and process it.

For versioned resources, Root acceptance applies to a specific version and its accepted facts. The DID can continue to identify the resource across versions, but the proof, hashes, lifecycle state, and publication records are version-sensitive. This lets a skill or service evolve without losing identity continuity.

Publication and Distribution

After acceptance, Root publishes package material and references through the distribution path. In the current architecture, CDN-style distribution helps separate accepted package bytes from Discovery query load. Discovery nodes can fetch package material, verify proof and hashes, and build indexes without Root serving every query or every artifact read directly.

This separation is good engineering. Root remains the authority for acceptance. CDN serves package material. Discovery serves search. Clients verify.

It also makes scale more realistic. Root should not have to answer every keyword query or serve every package byte. Discovery can be optimized for read traffic and semantic ranking. Distribution can be optimized for artifact availability. Verification ties those pieces back together so the split does not become a trust gap.

Discovery Indexing

Discovery indexing happens after package material is available and verified. A Discovery node should apply its own authorized-domain scope before indexing or serving results. If a Discovery node is not authorized for a resource’s domain, the resource should not be visible there even if another Discovery node can expose it.

Indexing can lag behind publication. Semantic indexing can add additional processing time. Query caches may update on a different cadence. These are operational realities, not trust failures, as long as status is observable and evidence remains verifiable.

A Discovery node should be able to explain its own view. If a resource is absent because the node is not authorized for the domain, that is different from being absent because indexing is delayed. If semantic ranking did not retrieve a resource, that is different from the package being invalid. Public APIs and tools should preserve these distinctions where practical.

Version Updates

OAN should support resource evolution. The resource DID can remain stable while a new package version is accepted. Discovery can then expose the current version and, where useful, historical version information. This matters for fast-moving resources such as skills, MCP servers, or APIs that release updates frequently.

Version updates should preserve the same evidence principles: new package facts, new hashes, Root acceptance for the new version, and clear lifecycle state for old versions. Consumers should not have to guess whether a result is current.

A practical update policy can support both stability and safety. Consumers that want the latest active version can follow the current-version pointer. Consumers that need reproducibility can pin a version and verify its historical proof. Operators can keep old records for audit while ensuring revoked or suspended versions are not presented as normal active candidates.

Failure Diagnosis

Lifecycle states make failures easier to diagnose:

• Submitted but not Root accepted: check Registrar authorization, DID material, hashes, or domain scope.
• Root accepted but not published: check publication queue, package store, or CDN path.
• Published but not indexed: check Discovery synchronization, proof verification, domain filtering, or indexing jobs.
• Indexed but not returned: check query terms, filters, capability tags, semantic ranking, or resource type.
• Returned but rejected by client: check proof, hashes, lifecycle, endpoint binding, or local policy.

This diagnostic model should guide website messages, SDK errors, and operational dashboards.

It also guides low-downtime operations. During a server move, software upgrade, or index rebuild, the system should make temporary catch-up states visible instead of making users guess. That is especially important for Root and Trust Indexer components, where stale governance state can affect which infrastructure nodes are accepted as currently authorized.

Further Reading

• OAN yellow paper
• OAN architecture overview
• IETF draft: OAN resource identity and discovery