This chapter describes the federated architecture adopted by OpenAgenet (OAN): coordination by a root platform, access through multiple registrar service nodes, propagation through a content distribution platform, indexing by multiple discovery service nodes, and a governance read model provided by an off-chain trust indexer. The OAN network can simultaneously accept registrar service nodes and discovery service nodes operated by the official organization and third parties. Each node participates in the network with an independent DID, role, authorization domain, and runtime status. A resource controller can submit a resource to an appropriate registrar service node, and a caller can query different discovery service nodes. The root platform uniformly verifies node eligibility, resource versions, and publication facts. The content distribution platform propagates verified materials to authorized discovery service nodes, and each discovery service node uses those materials to maintain its own structured and semantic indexes.

Three types of flows are connected within the same resource lifecycle, but they do not replace one another. The data flow carries DID Documents, resource packages, metadata, digests, and proofs; the control flow carries node authorization, request authentication, publication acceptance, lifecycle, and governance status; and the semantic flow carries the capability tag tree, tag aliases, capability descriptions, use cases, and query explanations. An independent deployment may adjust its storage, messaging, and network implementation, but it must not allow the content distribution platform to acquire governance authority, allow a discovery service node to rewrite root-platform publication facts, or allow semantic relevance to replace identity and authorization verification.

3.1 Logical Architecture

The client is the primary operational boundary for resource controllers and callers. It stores local identities and private keys, generates or imports resource-control materials, and sends requests to any registrar service node or discovery service node that meets its authorization-domain and service requirements. Each registrar service node independently stores its local registration records, registration credentials, and submission status, and packages validated resource registration requests into requests submitted to the root platform. The root platform stores network-wide authorization status, acceptance records, resource versions, publication proofs, and pending tasks. The content distribution platform provides multiple authorized discovery service nodes with root-platform-verified resource packages, DID Documents, and metadata. Each discovery service node separately stores its synchronization cursor, verified resource packages, rejection records, structured index, and semantic index. The off-chain trust indexer stores a projection of on-chain governance events into node authorization status, providing a unified read model for third-party node onboarding, suspension, and authorization-domain changes.

The logical connections can be summarized as follows: the client-to-registrar-service-node connection is the resource access flow; the registrar-service-node-to-root-platform connection is a protected upstream submission flow; the root-platform-to-content-distribution-platform connection is a publication data flow; the content-distribution-platform-to-discovery-service-node connection is a synchronization flow; the discovery-service-node-to-client connection is a query response flow; and the on-chain governance system-to-off-chain-trust-indexer-to-executing-node connection is an authorization-state flow. The root platform also provides discovery service nodes with publication notifications or summaries, allowing them to obtain the current resource package by cursor instead of relying on registrar service nodes to write directly to discovery indexes.

The following logical configuration illustrates component boundaries in one deployment instance. Field names are provided only to explain role relationships. Domains, ports, databases, and messaging components in an actual environment are deployment configuration, not fixed protocol values.

network:
  root_platform:
    role: root
    publishes: [node-authorization, resource-publication, capability-vocabulary]
  registrar_nodes:
    - id: registrar-a
      role: registrar
      submits_to: root_platform
      operator: official
    - id: registrar-b
      role: registrar
      submits_to: root_platform
      operator: third-party
  discovery_nodes:
    - id: discovery-a
      role: discovery
      syncs_from: root_platform
      operator: official
      authorization_domain: domain-a
    - id: discovery-b
      role: discovery
      syncs_from: root_platform
      operator: third-party
      authorization_domain: domain-b
  trust_indexer:
    role: governance-read-model
    projects: governance-events

This topology organizes the network by node roles and authorization relationships rather than limiting its scale to a fixed set of service instances. After completing node identity, authorization-domain, interface, security, and conformance checks, a third-party operator can run a new registrar service node or discovery service node. The new node cooperates with existing nodes through common publication facts and governance status recognized by the root platform, while retaining independent deployment, storage, indexing, and service policies.

3.2 Root Platform as the Trust and Authorization Hub

The root platform’s trust and authorization hub responsibilities apply to infrastructure participants, not to the business quality of resources controlled by resource controllers. The root platform should maintain verifiable node identities, node roles, authorization domains, and governance status. When processing registration submissions, publication tasks, content distribution, and discovery notifications, it should check whether the relevant nodes remain effectively authorized. The off-chain trust indexer provides the root platform with a read-side projection of on-chain events, but the projection may have synchronization latency. For high-risk writes, the root platform should decide whether to accept, reject, or suspend processing according to explicit freshness, missing-data, and invalidation rules.

Node credentials prove that “the node has a certain type of network qualification”; resource-control proofs prove that “the requester can represent a resource DID”; and root-platform publication proofs prove that “a particular resource version has passed root-platform verification.” These three types of proof cover different facts, and none can replace another. At a minimum, an authorization check should bind the node DID, role, authorization domain, status, validity period or governance sequence, and record the verification result as an auditable accepted, rejected, or pending status.

The minimum input for a root-platform authorization decision can be abstracted as follows:

{
  "nodeDid": "did:oan:example-registrar",
  "role": "registrar",
  "authorizationDomain": "example-domain",
  "governanceStatus": "active",
  "requestedAction": "submit-resource-registration",
  "observedAt": "2026-09-09T00:00:00Z"
}

The output should at least distinguish allow, deny, and indeterminate. indeterminate means that the authorization status, governance projection, or a critical proof cannot currently be confirmed. It must not be silently converted into an allow decision. The specific status codes and error structures are described in the registration, governance, and API chapters.

3.3 Root Platform as the Data Distribution Hub

After a resource version passes verification, the root platform organizes the DID Document, resource metadata, resource package, DID Document digest, metadata digest, resource package digest, resource type, version, lifecycle status, authorization domain, and root-platform trusted publication proof into a publication artifact that can be carried by the content distribution platform. A publication artifact must have explicit version and digest boundaries. After obtaining the materials, a discovery service node must be able to independently recompute digests, verify the proof statement, and determine the current version without relying on an informal statement or interface status from the content distribution platform.

Consistency among different discovery service nodes does not require them to have identical local databases. It requires them to validate the same root-platform publication fact using the same resource version, digests, proof, and governance status. The root platform establishes a traceable order through the publication cursor, resource DID, and version. The content distribution platform may use caching, batching, or retries to improve transmission efficiency, but it must not present an old version as the current version or modify resource-package content without a new publication fact.

{
  "publicationArtifact": {
    "resourceDid": "did:oan:example-resource",
    "version": "1.2.0",
    "didDocumentDigest": "sha256:did-document",
    "metadataDigest": "sha256:metadata",
    "packageDigest": "sha256:package",
    "publicationSequence": 108,
    "status": "published"
  },
  "consumerCheck": ["digest", "version", "rootProof", "governanceStatus"]
}

This object represents the logical composition of a distributable publication artifact; it does not mean that every deployment must use exactly the same field names. The essential requirement is that the receiver can bind the resource DID, version, each type of digest, and the root-platform trusted publication proof, and then write the material into its read model only after local verification.

3.4 Root Platform as the Semantic Governance Hub

The root platform maintains the capability tag tree and its versions, hierarchical levels, tag identifiers, Chinese or English labels, aliases, and parent-child relationships, and provides this governed vocabulary to both registrar service nodes and discovery service nodes. During registration, a client can select tags for a resource based on its description or receive tag recommendations. During discovery, a discovery service node can convert the user’s natural-language task, tag conditions, and structured filters into local query conditions. The tag tree is used to unify semantic boundaries and support authorization-domain decisions; it does not mean that the root platform evaluates the business quality of a resource on behalf of its provider.

Semantic governance and semantic retrieval have clearly separated responsibilities: the root platform maintains shared vocabulary and governance facts, while discovery service nodes are responsible for local indexing, tokenization, vectors, or other ranking implementations. A discovery service node may retain local semantic aliases and ranking signals, but its returned results should still retain the resource source, version, authorization domain, and verification status. A result with high relevance but without a valid control proof, root-platform publication proof, or governance status must not enter the trusted discovery results.

Tag governance can be expressed as a versioned vocabulary entry:

{
  "vocabularyVersion": "2026-09",
  "tag": {
    "id": "code-repository-analysis",
    "preferredLabel": "Code Repository Analysis",
    "aliases": ["Code Search", "Project Structure Summary"],
    "parent": "software-development",
    "status": "active"
  }
}

A discovery node can generate candidate conditions based on aliases and natural-language queries, but returned results must still refer to the resource DID, publication version, and verification status. Changes to the vocabulary version affect query interpretation and ranking; they must not silently change the identity or digest of an already signed resource package.

3.5 Publication Path from a Registrar Node to the Root Platform

A normal publication consists of local preparation, access validation by a registrar service node, a signed submission from the registrar service node, root-platform authentication and verification, resource-version acceptance, content distribution, and discovery notification. A registrar service node may return a registration result or registration credential, but a resource is eligible to enter the propagation path only after the root platform has completed resource-version verification and generated a publication fact. Publication tasks are usually asynchronous. The registration response, root-platform acceptance, completion of content distribution, and completion of discovery indexing should be recorded and displayed separately.

Failure handling must preserve the stage at which the failure occurred. Client field errors, DID Document structure errors, and control-proof errors are access or verification failures. An unauthorized registrar service node, an expired upstream signature, or a request-body digest mismatch is a node-authentication failure. A resource type, version, digest, or governance condition that does not satisfy root-platform requirements is a publication rejection. Temporary unavailability of content distribution or discovery indexing is a propagation-stage failure. Only temporary failures that can be safely retried should be retried automatically, and retry requests must still satisfy freshness and idempotency constraints.

Client -> Registrar service node: Resource materials and control proof
Registrar service node -> Root platform: Node-signed upstream submission
Root platform -> Registrar service node: accepted / rejected / pending
Root platform -> Content distribution platform: Verified publication artifact
Content distribution platform -> Discovery service node: Publication materials and cursor

Each response in this path describes only the result of the current stage. For example, accepted may mean that the root platform accepted the resource version, but it does not mean that a discovery service node has completed indexing. pending means that the task is still progressing asynchronously. The caller and operator should continue to determine subsequent results from status interfaces or synchronization records.

3.5.1 Access Validation by a Registrar Node

A registrar service node first checks whether the request conforms to the resource registration model, including the resource DID, DID Document, resource type, subject type, resource name and description, capability tags, use cases, protocol bindings, service endpoints, authorization domain, version, and digest consistency. It should also verify the relationship between the resource DID and the DID Document subject, control keys, and control proof, and confirm that the submitted resource type is consistent with the semantic encoding of the DID. Recommended tags can assist with completion, but cannot replace required fields or proof of control.

3.5.2 Upstream Submission and Identity Authentication

The submission sent by a registrar service node to the root platform is not an unprotected form. It is a protected request containing the resource registration content, request identifier, protocol version, target path, timestamp, nonce, request-body digest, sender DID, and signature. The root platform uses this information to verify the registrar service node’s identity, authorization domain, and request freshness, and then verifies the resource registration credential, resource control proof, and resource-package statement contained in the request. The submitter’s private key is used only within the registrar service node’s own node environment; the resource controller continues to retain the resource-control private key.

3.5.3 Root-Platform Verification and Publication Confirmation

During verification, the root platform simultaneously checks node authorization, the resource DID Document, resource control proof, registration credential, resource-type binding, metadata digest, resource-package digest, version relationship, authorization domain, and lifecycle conditions. After successful verification, the root platform records the resource-version acceptance fact, generates a root-platform trusted publication proof containing the resource DID, version, digests, status, authorization domain, and relevant governance or publication references, and marks subsequent content-distribution and discovery-notification tasks as executable. This confirmation does not mean that a discovery service node has completed indexing.

3.5.4 Failure, Rejection, and Retry

The root platform should distinguish an idempotent retry of the same resource DID, version, and digest from an update request in which content or version changes under the same DID. The former can return the existing acceptance result or publication status. The latter must re-verify control, version relationship, and publication conditions. An invalid signature, replayed nonce, invalid node authorization, digest mismatch, or inconsistent resource type must not be bypassed through simple retries. Temporary errors such as network timeouts or temporary downstream unavailability can enter a backoff-based task retry, while retaining the association with the original request.

3.6 Distribution Path from the Root Platform to Discovery Nodes

The root platform provides publication content and synchronization positions to discovery service nodes through the content distribution platform or protected synchronization interfaces. A discovery service node requests incremental materials according to its locally stored cursor and can perform controlled backfill when the cursor is missing or recovery is required. For every candidate resource, the discovery service node must obtain the current resource package, verify the DID Document, metadata, digests, root-platform trusted publication proof, lifecycle status, and authorization domain, and then write the verified version into its local index. Materials that fail verification should enter a traceable rejection record rather than being silently discarded.

The ultimate goal of the synchronization path is for each discovery service node to form a read model that is “locally queryable, source-traceable, and status-verifiable.” A discovery index may use relational tables, a full-text index, a semantic index, or a cache, but each index record should retain the resource DID, version, package digest, publication time or cursor, source, and verification status. Ranking and summaries in a query response are derived information and cannot override root-platform publication facts.

3.6.1 Distribution Content and Publication Checkpoints

Distributable content includes at least the resource DID, resource type, resource version, DID Document, resource metadata, resource-package digest, metadata digest, DID Document digest, authorization domain, lifecycle status, root-platform trusted publication proof, and the necessary publication cursor or source reference. A publication checkpoint should answer whether the resource has been accepted by the root platform, whether the content has been written to the distribution layer, whether a discovery service node has obtained and verified it, and at which stage a failure remains.

{
  "resourceDid": "did:oan:example-resource",
  "version": "1.2.0",
  "checkpoints": {
    "rootAccepted": true,
    "publishedToDistribution": true,
    "discoveryFetched": false,
    "discoveryVerified": false,
    "discoveryIndexed": false
  },
  "lastError": null
}

This checkpoint object is used to explain propagation progress; it does not compress multiple states into a single available field. When a discovery service node has not yet obtained or verified the material, the resource may already have completed root-platform publication, but it should not be described as discoverable on that node.

3.6.2 Discovery-Node Synchronization and Indexing

After obtaining materials, a discovery service node first completes source, integrity, and governance verification, then writes the verified resource package to a table or equivalent storage, and subsequently updates the structured and semantic indexes. The structured index can support queries by DID, resource type, version, capability tags, and authorization domain. The semantic index can use capability descriptions, tag aliases, use cases, and protocol bindings for matching. Every index write should be associated with the verification result; the node must not display a result first and perform trust verification later.

3.6.3 Sequence Numbers, Freshness, and Convergence

A publication cursor expresses the propagation order of root-platform publication materials. A discovery service node’s synchronization cursor expresses the position that the node has processed. The two are not equivalent. A discovery service node should record the last successfully applied cursor, the time at which the material was received, the resource version, and the verification result, and should determine whether an old snapshot can still be used for limited display according to the permitted freshness. Advancement of the cursor means that the synchronization position has advanced; it does not mean that every resource is ready to be invoked.

{
  "nodeId": "did:oan:example-discovery",
  "rootPublicationCursor": 108,
  "localAppliedCursor": 105,
  "lastSuccessfulSyncAt": "2026-09-09T00:00:00Z",
  "freshness": "lagging",
  "pendingRanges": [[106, 108]]
}

When the local cursor falls behind, the node can report lag and continue processing verified old snapshots, but it must not disguise localAppliedCursor as the latest root-platform publication sequence. After a gap is recovered, the node should re-verify every publication material in the missing range before advancing the local cursor.

3.6.4 Distribution Failure and Recovery

Content-distribution failure, network interruption, temporary unavailability of a resource package, and discovery-service-node database failure should all support recovery. A recoverable task should retain the resource DID, target version, source cursor, and retry information. When a digest mismatch, proof mismatch, or invalid governance status is encountered, the task should enter a rejected or isolated state and wait for new publication materials or a governance change rather than retrying indefinitely. After recovery, processing should continue from a persisted cursor or controlled backfill point to avoid skipping publication records.

3.7 Multiple Registrar Nodes and Discovery Nodes

Multiple registrar service nodes can provide access for different organizations, resource types, or authorization domains, while multiple discovery service nodes can provide indexing for different network regions, user groups, or query policies. They share the root platform’s basis for judging identity, authorization, resource versions, and publication proofs, but do not need to share the same database or local ranking. When a resource is submitted repeatedly through multiple registrar service nodes, the root platform should identify an idempotent request or an update request based on the resource DID, version, digest, and control proof. When a discovery service node receives the same publication material repeatedly, its indexing should remain idempotent.

Federation does not mean that arbitrary nodes write to one another. A registrar service node may accept and submit only within its authorization domain. A discovery service node may synchronize and return only the published resources allowed within its authorization domain. Propagation between nodes should primarily pass through root-platform publication facts and the content distribution path. A failure of one discovery service node does not make root-platform facts disappear; another discovery service node that has completed synchronization can continue providing results, while the failed node’s local visibility and freshness should be reported accurately.

3.7.1 Access by Multiple Registrar Nodes

The root platform maintains an independent node identity, role, and authorization domain for each registrar service node. Different registrar service nodes can submit the same resource, but changing the registrar service node cannot grant new resource control; an update to the same resource still requires a valid control proof from the resource controller and must satisfy the version-update rules. A registrar service node’s local registration record is evidence on the intake side; the root platform’s acceptance record is the basis for determining network publication.

3.7.2 Synchronization by Multiple Discovery Nodes

Each discovery service node has an independent synchronization cursor and local index state, and can obtain the same root-platform publication facts from the content distribution platform according to its authorization domain. Nodes should not treat local search results as authoritative data for another node. When consistency needs to be compared, the comparison should use the resource DID, version, package digest, root-platform proof, and governance status. Different result counts or rankings over a short period may result from synchronization delay or local policy, but not from arbitrary rewriting of root-platform facts.

3.7.3 Data Consistency Between Nodes

Consistency between nodes should distinguish fact consistency from read-model consistency. Fact consistency requires the DID Document, metadata, resource-package digest, and root-platform proof of the same publication version to be consistent. Read-model consistency permits differences in indexing time, ranking, caching, and semantic interpretation, but each difference must be explainable by the cursor, freshness, or authorization domain. When a discovery service node detects a version conflict, it should prioritize the root-platform publication sequence and proof, rather than letting local arrival time override the trusted source.

When comparing two discovery service nodes, the following stable fields should be compared before result counts or rankings:

(resourceDid, version, packageDigest, rootProof, governanceStatus)

When these fields are consistent, the two nodes generally have the same core understanding of the publication fact. Differences in indexing time, semantic score, pagination position, and cache time are read-model differences. If the stable fields differ, the root-platform publication records and governance-event sequence should be consulted to locate the cause.

3.7.4 Node Failure and Isolation

When a node exhibits signature anomalies, expired authorization, persistent synchronization failure, publication-material tampering, or non-conforming interface behavior, it should be isolatable so that restricted writes are no longer accepted from it or new authorization scope is no longer provided to it. Isolation does not mean deleting historical facts. The root platform and other nodes should retain auditable records and decide whether to re-enable the node based on governance status and recovery checks. A failure of an ordinary query node can be handled by another node, but this must not expand the other node’s authorization domain.

3.8 Third-Party Node Onboarding Model

Third-party node onboarding starts with node identity materials and an operating role, rather than simply opening an HTTP port. The applicant should submit the node DID Document, public verification methods, service endpoint, proposed node role, authorization domain, and operating contact or operational materials. The governance authority or root platform then performs qualification review and authorization. After obtaining test status, the node must pass tests for identity, signatures, interfaces, resource-package verification, synchronization, error handling, and status updates. A production node then provides services within its formal authorization domain.

Test nodes and production nodes should be isolated in authorization status, visibility, data retention, and network impact. A test node can use test resources and test governance status to validate an implementation, but must not mix test publication facts into a production discovery index. A production node’s authorization revocation, suspension, or scope change must be recognizable at runtime and affect restricted operations.

3.8.1 Pre-Onboarding Authorization

Pre-onboarding authorization should at least confirm that the node DID can be resolved, verification methods are available, the node role is explicit, endpoint ownership is clear, request signatures can be verified, the authorization domain can be expressed, and the operator can explain key custody, data storage, and failure handling. Authorization materials should bind the node identity and role; a domain name, IP address, or human-readable name alone must not serve as proof of node eligibility.

3.8.2 Node Capabilities and Authorization Scope

The node capability description should distinguish between “interfaces the node can provide” and “actions the node is authorized to perform.” A discovery service node may support structured and semantic queries but be authorized to index only certain resource domains. A registrar service node may support access for all four resource types but be authorized to accept only some of them. The authorization scope should map to the node’s actual filtering, submission, and response logic. Requests outside the scope must be rejected or omitted from responses.

3.8.3 Protocol Conformance Checks

Conformance checks should cover health checks, DID Document parsing, signature and digest verification, node authorization status, resource registration, root-platform publication, content distribution, discovery synchronization, query responses, and error contracts. Test results should record the input, node version, configuration, expected result, actual result, and evidence location. Passing an interface-connectivity test does not mean that the node has passed trust-boundary tests.

The minimum onboarding record for a third-party node can be organized as follows; actual fields are determined by the onboarding process:

node:
  did: did:oan:example-third-party-node
  role: discovery
  endpoint: https://example.invalid/discovery
  authorizationDomain: example-domain
  testProfile: discovery-node-v1
  checks:
    - did-resolution
    - signature-verification
    - publication-sync
    - query-response
  status: test-passed

This record describes only the scope and result of the onboarding assessment; passing the test must not be directly interpreted as a guarantee of long-term operation. Authorization status, dependent services, and continuous synchronization status must still be checked during production operation.

3.8.4 Runtime Status Management

During production operation, a node should continuously check its own authorization, governance status, dependent endpoints, synchronization cursor, task queue, and database status. After authorization is suspended or revoked, the node should stop the corresponding restricted actions. When the content distribution platform or off-chain trust indexer is temporarily unavailable, the node may use existing state according to freshness rules, but must not fabricate new authorization, acceptance, or publication facts. Recovery should include an observable resynchronization and re-verification process.

3.9 Public, Private, and Consortium Network Deployments

A public network allows Internet users to access public registration, discovery, or resolution entry points, but public accessibility does not mean that every resource or every node status is visible to every user. A private network can restrict registrar service nodes, discovery service nodes, the content distribution platform, and resource endpoints to an organizational network or identity domain, while using the same resource identity, control proof, and publication-verification boundaries. A consortium network can be operated by multiple organizations that run nodes and exchange resource publication facts under an agreed root platform, governance authority, and authorization domain.

The three deployment forms can share protocol objects, but they should make the network scope, domains and endpoints, certificates, authorization materials, data retention, and cross-domain propagation conditions explicit. Deployment domains, node counts, and database choices are runtime configuration and should not be written into a resource DID or root-platform proof as immutable protocol conditions. What must be interoperable is identity, signatures, resource packages, digests, status, and node authorization.

The deployment form changes reachability and the scope of data propagation. It does not change how resource control is proved, nor does it turn the network entry point itself into a trust authority.

3.10 Availability, Isolation, and Failure Boundaries

OAN’s degradation strategy must distinguish read-side display from trust-sensitive actions. When the distribution service is temporarily unavailable, a discovery service node can display an old snapshot with a freshness marker, and an operations page can display delayed statistics or historical events. However, resource registration, root-platform publication, node-authorization changes, revocation-state application, and verification before high-risk invocation should be rejected, suspended, or placed in a pending state when critical evidence cannot be confirmed. No degradation may generate a new signed fact or change the resource lifecycle state.

Network interruption, database failure, and index lag should be recorded separately. During recovery, components should continue from persisted tasks, cursors, or event positions and re-verify cross-node materials, avoiding the direct treatment of an old cached version as the latest version. Isolation boundaries include node identity, authorization domain, resource version, and data-storage boundaries. A failure or incorrect data from one node must not automatically spread as a trust fact to other nodes.

3.11 Interaction of the Control, Data, and Semantic Planes

The control plane first decides whether a node and a resource version meet the conditions for entering the network, propagation, and validity. The data plane then transfers the DID Document, resource package, metadata, digests, and proofs permitted for publication by the control plane. The semantic plane builds capability-tag, description, and use-case indexes for resources that have already passed identity and publication checks. A query can use structured and semantic conditions at the same time, but the result must contain or be traceable to the resource DID, version, source, root-platform proof, and governance status.

Governance-status changes affect continued propagation through the data and semantic planes. After a node is revoked or a resource version becomes invalid, new synchronization should stop or filter the corresponding materials, and existing indexes should be updated after the status has propagated. A change to the tag tree can affect registration recommendations and query interpretation, but cannot retroactively change the identity or digest of a signed resource package. The dependency order among the three planes is that control facts constrain data propagation, data materials support semantic indexing, and semantic results cannot grant control authority in return.

The boundaries among the three planes also determine the order of failure handling. When control-plane status is unknown, the data plane can retain verified materials for limited reads, but must not expand propagation. When data-plane materials are missing or their digests are inconsistent, the semantic plane must not establish or update a trusted index. When the semantic index is unavailable, the system can still provide exact DID queries or other explicitly supported structured queries. After recovery, it should first restore control status and data integrity, and then rebuild or refresh the semantic index.

The three planes and their dependencies are shown below. In the implementation, the data exchanged between the planes is not undefined free-form JSON. It is a JSON/HTTP payload serialized from shared Rust types: resource registration uses ResourceRegistrationSubmission; forwarding from a registrar service node to the root platform wraps the request in ResourceVerifyAndPublishRequest; content distribution uses ResourceCdnPublishRequest or ResourceCdnBatchPublishRequest; and discovery queries use ResourceDiscoveryQuery and return ResourceDiscoveryResponse. These types define field names and nesting relationships, Axum routes define methods and paths, and signature envelopes and resource control proofs define different trust boundaries. Together, they form the node-cooperation contract.

A cross-plane query response should explain both “why it was found” and “why it can be used.” For example, a discovery service node can first use capability descriptions, capability tags, and structured resource types to filter resources, and then associate each result with the resource DID, version, resource-package digest, root-platform trusted publication proof, and current governance status:

{
  "resourceDid": "did:oan:SKDM:example-resource",
  "match": {
    "mode": "semantic_and_structured",
    "query": "Search a code repository and summarize the project structure",
    "matchedTags": ["code-repository", "project-structure-summary"]
  },
  "trust": {
    "governanceStatus": "active",
    "rootProof": "present",
    "packageDigest": "sha256:..."
  },
  "freshness": {
    "indexedAt": "2026-09-09T08:30:00Z",
    "sourceCursor": "publish-1842"
  }
}

The semantic match in this example can explain the relevance between the resource and the query. governanceStatus, rootProof, and packageDigest support status judgment, trusted-publication judgment, and content-integrity judgment respectively. If any trust field is missing, the discovery service node may return the resource, but it must lower the result status or require the caller to continue verification. It must not interpret semantic relevance directly as authorization or a security guarantee.

3.12 Sources of Facts and Derived Read Models

The sources of fact for the resource control relationship are the resource DID Document, control keys, and valid control proof. The source of fact for registration acceptance is the registrar service node’s registration record or registration credential. The sources of fact for root-platform acceptance and publication are the root platform’s persistent records and root-platform trusted publication proof. The source of fact for distribution is the publication artifact and its digests stored by the content distribution platform. The source of fact for discovery visibility is the synchronization, verification, and indexing record of the specific discovery service node. The source of fact for node authorization status is the governance events and their projection in the off-chain trust indexer. Website pages, cached interfaces, and statistics are observation layers and are not the sole authority for any of the facts above.

A derived read model must retain source references, a version or cursor, verification time, freshness, authorization domain, and error status. A read model may combine fields or build a full-text or semantic index for query efficiency, but it must not discard the DID, version, digest, and proof references needed to re-verify the resource. When the read model differs from the authoritative source, it should show a synchronization or verification anomaly rather than allowing the existence of a local database record to override the authoritative status.

A resource index in a discovery service node can use the following derived structure. It is not a new authoritative record, but a read model that organizes multiple sources for efficient querying. source is used to trace back to facts, and sync is used to determine whether local data has caught up with the publication position:

{
  "resourceDid": "did:oan:SKDM:example-resource",
  "version": "2026-09-09T08:20:00Z",
  "metadata": {
    "resourceType": "skill",
    "capabilityTags": ["code-repository", "summary"]
  },
  "source": {
    "registrarRecord": "registrar-record-901",
    "rootPublication": "publish-1842",
    "rootProof": "root-proof-1842",
    "packageDigest": "sha256:..."
  },
  "sync": {
    "localCursor": "publish-1842",
    "checkedAt": "2026-09-09T08:31:00Z",
    "freshness": "current",
    "error": null
  }
}

When localCursor is behind, source verification fails, or the governance projection has not yet been updated, the read model may still be retained for limited display, but freshness should be changed to stale or verification_required and the reason for the error should be retained. A row in an index database can only show that the local node once received the material; by itself, it cannot prove that the resource remains valid, propagatable, or invocable.

3.13 Network Topology and Sequence Consistency

The root-platform publication sequence is produced by the root platform and identifies the position of resource publication materials in the data-distribution path. The on-chain governance-event sequence is produced by the on-chain governance system and expresses the order of node-authorization and status changes. The discovery service node’s synchronization cursor is maintained by the discovery service node and expresses the distribution position that the node has processed. The three values may look numerically similar, but they are not interchangeable. The implementation must store and check them separately, avoiding the use of one global number to infer resource publication, governance finality, or local indexing status.

When a discovery service node encounters a cursor gap, disorder, or rollback, it should suspend application of the affected scope, retrieve missing materials from the root platform or content distribution platform, and continue only after re-verification. Duplicate materials can be processed idempotently by resource DID, version, and package digest. Duplicate governance events should be deduplicated by event identifier or sequence. A rollback in the publication sequence must not overwrite a newer version that has already been confirmed. During cross-node delay, an old snapshot may be retained for limited read-side display, but freshness must be marked, and sensitive actions must stop when revocation, suspension, or authorization status cannot be confirmed.

The three sequences should be stored separately in implementation and operations records. The configuration-style example below expresses their sources and processing boundaries only; it does not mean that they share one numbering format:

resource_publication:
  producer: root-platform
  latest: publish-1842
  applies_to: did-document-and-resource-package
  gap_action: pause-affected-publication

governance_events:
  producer: governance-ledger
  latest: event-771
  applies_to: node-authorization-and-resource-status
  gap_action: fail-closed-for-sensitive-actions

discovery_sync:
  producer: discovery-service-node
  local_cursor: publish-1839
  applies_to: local-validation-and-indexing
  gap_action: fetch-missing-publications-and-revalidate

For example, a discovery service node’s synchronization cursor falling behind the root-platform publication sequence only means that the local index may be incomplete. It does not mean that governance events are behind by the same amount. If a gap appears in governance events, an application that depends on governance status should be suspended even when resource publication materials are complete. A node may mark a resource as a current discoverable result only after the corresponding sequences are continuous, the materials pass verification, and the status projection is complete.

References