Governance in Plain Language
Governance answers a practical question: who is allowed to operate OAN infrastructure, and under what scope? In a public agent-resource network, this cannot be left to self-description. A node saying “I am a Registrar” is not enough. A website saying “I am a Discovery service” is not enough. Authority needs identity, approval, scope, status, and enforcement.
The plain-language rule is: a node must be known, current, scoped, and checkable.
These four words are a practical test for every infrastructure claim. If a service endpoint cannot prove which node it is, it is not known. If its current status cannot be checked, it is not current. If its permitted domains are unclear, it is not scoped. If clients cannot verify responses and evidence, it is not checkable.
Known
A node should have a stable identity. In OAN, that means DID-based identity material and keys associated with the infrastructure subject. If a Registrar, Discovery node, or future issuer role cannot be identified consistently, it cannot be governed consistently.
Identity alone is not approval. It only tells the network who or what the subject claims to be. Governance decides whether that subject is allowed to perform an infrastructure role.
This distinction mirrors the resource side of OAN. A resource DID identifies a resource subject, but Root acceptance decides whether a package version enters the trusted publication path. A node DID identifies an infrastructure subject, but governance and Root authorization decide whether it can act.
Current
Authority changes over time. A node can be authorized, suspended, recovered, or revoked. A node that was approved last month may not be approved today. A current view is therefore essential.
This is why OAN treats current governance state as part of effective authorization. Old credentials, old configuration files, and old announcements should not override a current revocation or suspension.
For operators, this means monitoring is part of trust. A service can be technically online while its authority is stale, suspended, or unknown. Public status displays should not reduce all of that to one “healthy” indicator.
Scoped
Authority should have boundaries. A Registrar might be authorized for selected domains. A Discovery node might be authorized to expose a subset of resources. Wildcard scope can exist, but it should be explicit. Empty scope means no domain authorization.
Scoped authority makes open participation more realistic. OAN does not need every operator to be trusted for every domain. A specialized operator can serve a domain community, while official or full-scope services can serve broader public use.
Scoped authority also makes mistakes smaller. If a domain-specific node is misconfigured or later suspended, the impact should be limited to the scope it was allowed to serve. That is much better than treating every reachable node as all-domain infrastructure.
Checkable
Governance only helps if clients and services can check it. Root should consume governance-derived state. SDKs and clients should be able to verify node identity, response signatures, package proof, and lifecycle. Users should be able to distinguish official services, recognized third-party nodes, and experimental endpoints.
Checkability is what turns governance from a policy document into working infrastructure.
Checkability requires engineering discipline: signed envelopes, status endpoints, current read models, auditable events, clear lifecycle labels, and SDK verification helpers. Governance that cannot be checked by services and clients becomes ceremony rather than trust infrastructure.
A Simple Example
Suppose an organization applies to operate a Discovery node for a narrow domain. It publishes node identity, endpoint, and domain scope. Governance approves that role and scope. Root recognizes the state. The Discovery node can synchronize and expose resources in the covered domains. If the node is later revoked, clients and Root should stop treating it as an authorized Discovery node.
The node’s endpoint may still be online after revocation. That does not make it authorized. Current governance state wins.
The reverse is also true: a currently authorized node may be temporarily unreachable. That is an availability issue, not automatically a governance failure. OAN documentation and UI should keep authority and reachability separate.
Why This Is Different from a Directory
A simple directory can list endpoints and descriptions. OAN needs more because agents may use results automatically. The network must know whether infrastructure is authorized, whether resources were accepted, whether Discovery responses are signed, and whether the returned package can be verified.
Governance is therefore not a decorative committee layer. It is part of the technical trust path.
A mature OAN deployment can make this visible without exposing private operations. Public users can see official services, known third-party node applications, authorization status, and domain scope. Private operational tools can handle keys, voting, deployment, and recovery behind the scenes.