Lifecycle States
Lifecycle states make OAN understandable over time. A resource or infrastructure node is not simply “known” or “unknown.” It may be pending, accepted, active, superseded, suspended, revoked, or temporarily unavailable. A current state can matter more than a historical credential.
This is especially important in an ecosystem where resources update frequently. Skills may release new versions. MCP servers may add or remove tools. APIs may change schemas. Registrars and Discovery nodes may receive new authorization scope or be suspended. OAN needs state names that users, SDKs, nodes, and operators can interpret consistently.
The lifecycle model is therefore part of interoperability. If one tool treats “accepted” as “safe to invoke” while another treats it as “awaiting publication,” users will see confusing behavior. Shared state names help the website, SDKs, skills, Root, Registrar, Discovery, and operators tell the same story.
Resource Lifecycle
A resource lifecycle can be understood as a path from preparation to current use:
| State | Meaning | Consumer behavior |
|---|---|---|
| Prepared | The publisher has local material but has not submitted it. | Nothing to verify in OAN yet. |
| Submitted | Registrar has received or accepted the submission workflow. | Wait for Root acceptance before treating it as trusted. |
| Rejected | Registrar or Root rejected the material. | Fix the cause and resubmit if appropriate. |
| Root accepted | Root accepted a specific package version. | Trust evidence exists for that version. |
| Published | Package material is available in the distribution path. | Fetch and verify hashes before use. |
| Indexed | At least one Discovery node has indexed it. | It can appear in Discovery results for that node. |
| Active | The current version is valid for normal use. | Verify evidence and continue with native protocol checks. |
| Superseded | A newer version has replaced it. | Prefer the newer active version. |
| Suspended | Temporarily not valid for normal use. | Do not invoke unless a special policy says otherwise. |
| Revoked | No longer valid under the trust model. | Reject for normal use. |
Actual services may use a smaller set of exposed labels, but the conceptual differences should remain.
Two resources can share a DID across time only if their versions are handled carefully. The stable identity tells consumers which resource lineage they are looking at. The lifecycle state tells them which version in that lineage should be used now.
Node Lifecycle
Infrastructure nodes also have lifecycle state. A Registrar can be authorized, suspended, recovered, or revoked. A Discovery node can have domain scope updated. A future issuer role may have its own governance status. Root’s operational view should reflect current governance-derived state rather than relying on a static configuration file forever.
For node authorization, the state and domain scope matter together. A Discovery node may be authorized but only for specific domains. A Registrar may be active but unable to onboard a resource outside its scope. A revoked node’s old credentials should not keep granting current authority.
This is why Root-side authorization should be derived from current governance state rather than only from a static genesis file. Genesis can bootstrap a trial or official network, but ongoing operation needs lifecycle updates, domain updates, suspension, and revocation to be visible to Root and its indexer.
Why Historical Evidence Is Not Enough
Many systems treat a credential as the end of the story. OAN cannot. A credential or proof may show that something was accepted at a past time, but a client still needs to ask whether that version is still current and usable. A resource may have been superseded. A node may have been revoked. A domain scope may have changed. A package may have been replaced by a newer accepted version.
This does not make historical evidence useless. It remains important for audit and reproducibility. It simply means current use requires current status.
Historical evidence answers “what happened?” Current lifecycle answers “what may I rely on now?” OAN needs both. Researchers, auditors, and operators may need old package records; users and agents need clear current-use guidance.
Lifecycle and Discovery
Discovery should be lifecycle-aware. It should not return revoked resources as ordinary active candidates. It should handle superseded versions consistently. It should expose enough status information for clients to make good decisions. If a resource is accepted but not indexed, the issue should be described as propagation or indexing, not as a trust failure.
Semantic Discovery also depends on lifecycle state. Derived indexes must not keep returning stale active candidates after a resource changes state. Rebuilds, updates, and cache invalidation are operationally important because search indexes are derived from the verified package set.
A semantic index should therefore behave like a cache over trusted resource facts, not like an independent database of truth. When lifecycle state changes, the trusted facts change first, and search visibility follows.
Lifecycle and User Experience
Clear lifecycle labels improve user experience. When a publisher registers a resource, they need to know whether it is waiting for Root, waiting for publication, waiting for Discovery, or rejected. When a user discovers a resource, they need to know whether the result is active and current. When an operator diagnoses a problem, they need to know which queue or state transition is delayed.
Good UX should use plain terms without hiding evidence. “Submitted” should not look like “published.” “Accepted by Root” should not imply immediate Discovery visibility. “Visible in Discovery” should not imply that native invocation is automatically safe.
This kind of precise wording is not cosmetic. It reduces support burden and prevents dangerous user assumptions. A publisher can understand whether they should edit their submission or simply wait for indexing. A consumer can understand whether a candidate is current enough to evaluate.
Lifecycle and Low-Downtime Operations
Lifecycle thinking also helps with future migration and upgrades. If a node moves servers, rebuilds indexes, restores a database, or upgrades software, the system should preserve current state and make any temporary gap visible. Operators should be able to distinguish “node is catching up” from “node is unauthorized” and “resource is superseded” from “resource is revoked.”
This is one reason OAN’s detailed design includes attention to Trust Indexer state, Root authorization cache, package archives, Discovery indexes, and migration planning. Lifecycle is not only a UI label; it is a way to keep distributed trust understandable during change.
For future low-downtime migration, lifecycle state should remain portable with the data that defines it. Moving a node should not silently erase accepted packages, authorization history, current resource states, or Discovery rebuild inputs. Upgrades may change software, but they should preserve the evidence needed to explain current trust.