本章说明 OpenAgenet (OAN) 采用“根平台协调、多注册服务节点接入、内容分发平台传播、多发现服务节点索引、链下信任索引器提供治理读模型”的联邦式架构。OAN 网络可以同时接入官方和第三方运行的注册服务节点、发现服务节点，各节点以独立 DID、角色、授权域和运行状态参与网络。资源控制方可以选择合适的注册服务节点提交资源，调用方也可以选择不同发现服务节点查询；根平台统一验证节点资格、资源版本和发布事实，内容分发平台把已验证材料传播给获得授权的发现服务节点，各发现服务节点据此维护自己的结构化与语义索引。

三类流在同一条资源生命周期中相互衔接但不相互替代。数据流承载 DID文档、资源包、元数据、哈希和证明；控制流承载节点授权、请求认证、发布接受、生命周期和治理状态；语义流承载能力标签树、标签别名、能力描述、用例以及查询解释。任何独立部署都可以调整存储、消息和网络实现，但不得让内容分发平台取得治理权威、让发现服务节点改写根平台发布事实，或让语义相关性替代身份和授权验证。

3.1 逻辑架构

客户端是资源控制方和调用方的主要操作边界，保存本地身份和私钥，生成或导入资源控制材料，并向任一符合其授权域和服务要求的注册服务节点或发现服务节点发起请求。每个注册服务节点独立保存本节点的登记记录、注册凭证和提交状态，将经过校验的资源登记请求封装为提交给根平台的请求；根平台保存全网授权状态、接受记录、资源版本、发布证明和待处理任务。内容分发平台向多个获得授权的发现服务节点提供根平台已验证的资源包、DID文档和元数据；每个发现服务节点分别保存自己的同步游标、已验证资源包、拒绝记录、结构化索引和语义索引。链下信任索引器保存链上治理事件到节点授权状态的投影，为第三方节点接入、停权和授权域变更提供统一读模型。

逻辑连接可概括为：客户端到注册服务节点是资源接入流，注册服务节点到根平台是受保护的上游提交流，根平台到内容分发平台是发布数据流，内容分发平台到发现服务节点是同步流，发现服务节点到客户端是查询响应流，链上治理系统到链下信任索引器再到执行节点是授权状态流。根平台同时向发现服务节点提供发布通知或摘要，使发现服务节点能够按游标取得当前资源包，而不是依赖注册服务节点直接把资源写入发现索引。

一个部署实例可以用以下逻辑配置理解组件边界。字段名称仅用于说明角色关系，实际环境中的域名、端口、数据库和消息组件属于部署配置，不是协议固定值。

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

该拓扑以节点角色和授权关系组织网络，而不是以某一组固定服务实例限定网络规模。第三方运营者完成节点身份、授权域、接口、安全和符合性检查后，可以运行新的注册服务节点或发现服务节点；新节点通过根平台认可的共同发布事实和治理状态与现有节点协作，同时保留独立部署、存储、索引和服务策略。

3.2 根平台作为信任授权枢纽

根平台的信任授权枢纽职责针对基础设施参与者，而不是针对资源控制方的业务质量。根平台应维护能够验证的节点身份、节点角色、授权域和治理状态，并在处理注册提交、发布任务、内容分发和发现通知时检查相关节点是否仍处于有效授权状态。链下信任索引器为根平台提供链上事件的读侧投影，但投影存在同步延迟；涉及高风险写入时，根平台应依据明确的新鲜度、缺失和失效规则决定接受、拒绝或暂停处理。

节点凭证证明“该节点具有某类网络资格”，资源控制证明证明“请求方能够代表某个资源 DID”，根平台发布证明证明“某个资源版本已经通过根平台验证”。三者覆盖的事实不同，不能由其中任何一项替代另外两项。授权检查至少应绑定节点 DID、角色、授权域、状态、有效期或治理序列，并将验证结果写入可审计的接受、拒绝或待处理状态。

根平台授权判断的最小输入可以抽象为：

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

输出应至少能区分 allow、deny 和 indeterminate。indeterminate 表示授权状态、治理投影或关键证明暂时无法确认，不应被静默转换为允许；具体接口状态码和错误结构由注册、治理与 API 章节说明。

3.3 根平台作为数据分发枢纽

根平台在资源版本通过验证后，组织 DID文档、资源元数据、资源包、DID文档哈希、元数据哈希、资源包哈希、资源类型、版本、生命周期状态、授权域和根平台可信发布证明，形成可被内容分发平台承载的发布产物。发布产物必须具有明确的版本和哈希边界，发现服务节点取得材料后能够独立重算哈希、校验证明声明并判断当前版本，而不依赖内容分发平台的口头或接口状态。

不同发现服务节点的一致性不是要求它们拥有相同的本地数据库，而是要求它们对同一根平台发布事实使用相同的资源版本、哈希、证明和治理状态作校验。根平台通过发布游标、资源 DID 和版本建立可追踪顺序；内容分发平台可采用缓存、批量或重试机制提高传输效率，但不得把旧版本冒充当前版本，也不得在未取得新发布事实时修改资源包内容。

{
  "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"]
}

该对象表示可分发发布产物的逻辑组成，不代表所有部署必须采用完全相同的字段名。关键是接收方能够把资源 DID、版本、各类摘要和根平台可信发布证明绑定起来，并在本地校验后再写入读模型。

3.4 根平台作为语义治理枢纽

根平台维护能力标签树及其版本、层级、标签标识、中文或英文标签名、别名和父子关系，并将这套受治理词汇同时提供给注册服务节点和发现服务节点。注册时，客户端可以根据资源描述选择或获得标签推荐；发现时，发现服务节点可以把用户的自然语言任务、标签条件和结构化过滤转换为本地查询条件。标签树用于统一语义边界和授权域判断，不代表根平台替资源提供方评价业务质量。

语义治理与语义检索分工明确：根平台维护共享词汇和治理事实，发现服务节点负责本地索引、分词、向量或其它排序实现。发现服务节点可以保留本地语义别名和排序信号，但对外返回结果时仍应保留资源来源、版本、授权域和验证状态；相关性高的结果如果缺少有效控制证明、根平台发布证明或治理状态，也不能进入可信发现结果。

标签治理可以用版本化的词汇条目表达：

{
  "vocabularyVersion": "2026-09",
  "tag": {
    "id": "code-repository-analysis",
    "preferredLabel": "代码仓库分析",
    "aliases": ["代码检索", "项目结构总结"],
    "parent": "software-development",
    "status": "active"
  }
}

发现节点可以根据别名和自然语言查询生成候选条件，但返回结果仍需引用资源 DID、发布版本和验证状态。标签词汇的版本变化影响查询解释和排序，不应悄悄改变已经签署资源包中的原始身份和摘要。

3.5 注册节点到根平台的发布路径

一次正常发布由本地准备、注册服务节点接入校验、注册服务节点签名提交、根平台认证与验证、资源版本接受、内容分发和发现通知组成。注册服务节点可以返回登记结果或注册凭证，但只有根平台完成资源版本验证并产生发布事实后，资源才具备进入传播链路的条件。发布任务通常是异步的，登记响应、根平台接受、内容分发完成和发现服务节点索引完成应分别记录和展示。

失败处理必须保留失败所在阶段。客户端字段错误、DID文档结构错误、控制证明错误属于接入或验证失败；注册服务节点未获授权、上游签名过期或请求体哈希不一致属于节点认证失败；根平台资源类型、版本、哈希或治理条件不满足属于发布拒绝；内容分发或发现索引暂时不可用属于传播阶段失败。只有可安全重试的暂时性失败才能自动重试，重试请求仍应具备新鲜度和幂等约束。

客户端 -> 注册服务节点: 资源材料与控制证明
注册服务节点 -> 根平台: 节点签名的上游提交
根平台 -> 注册服务节点: accepted / rejected / pending
根平台 -> 内容分发平台: 已验证发布产物
内容分发平台 -> 发现服务节点: 发布材料与游标

这条链路中的每个响应只说明当前阶段的结果。例如 accepted 可以表示根平台接受了资源版本，但不表示发现服务节点已经完成索引；pending 表示任务仍在异步推进，调用方和运营者应继续依据状态接口或同步记录判断后续结果。

3.5.1 注册节点接入校验

注册服务节点首先检查请求是否符合资源注册模型，包括资源 DID、DID文档、资源类型、主体类型、资源名称和描述、能力标签、用例、协议绑定、服务端点、授权域、版本和哈希等字段的一致性。它还应验证资源 DID 与 DID文档主体、控制密钥及控制证明的对应关系，并确认提交的资源类型与 DID 语义编码一致。推荐标签可以辅助填写，但不能替代必填字段和控制权证明。

3.5.2 上游提交与身份认证

注册服务节点向根平台提交的不是未经保护的表单，而是包含资源登记内容、请求标识、协议版本、目标路径、时间戳、随机数、请求体哈希、发送方 DID 和签名的受保护请求。根平台据此验证注册服务节点的节点身份、授权域和请求新鲜度，再验证其中的资源登记凭证、资源控制证明和资源包声明。提交方私钥只在注册服务节点自身的节点环境中使用，资源控制私钥仍由资源控制方保管。

3.5.3 根平台验证与发布确认

根平台在验证阶段同时检查节点授权、资源 DID文档、资源控制证明、注册凭证、资源类型绑定、元数据哈希、资源包哈希、版本关系、授权域和生命周期条件。通过后，根平台记录资源版本接受事实，生成包含资源 DID、版本、哈希、状态、授权域及相关治理或发布引用的根平台可信发布证明，并将后续内容分发和发现通知任务置为可执行。该确认不等于发现服务节点已经完成索引。

3.5.4 失败、拒绝与重试

根平台应对重复请求区分相同资源 DID、相同版本和相同哈希的幂等重试，以及相同 DID 下内容或版本发生变化的更新请求。前者可以返回既有接受结果或既有发布状态，后者必须重新验证控制权、版本关系和发布条件。签名失效、随机数重放、节点授权失效、哈希不匹配和资源类型不一致不得通过简单重试绕过；网络超时、下游暂时不可用等暂时性错误可以进入带退避的任务重试，并保留原请求关联关系。

3.6 根平台到发现节点的分发路径

根平台通过内容分发平台或受保护的同步接口向发现服务节点提供发布内容和同步位置。发现服务节点依据自身保存的游标请求增量材料，也可以在游标缺失或需要恢复时执行受控回填。对每个候选资源，发现服务节点必须取得当前资源包，验证 DID文档、元数据、哈希、根平台可信发布证明、生命周期状态和授权域，再将通过验证的版本写入本地索引；验证失败的材料应进入可追踪的拒绝记录而不是静默丢弃。

同步链路的最终目标是让发现服务节点形成“本地可查询、来源可追溯、状态可验证”的读模型。发现索引可以使用关系表、全文索引、语义索引或缓存，但索引记录应保留资源 DID、版本、包哈希、发布时间或游标、来源和验证状态。查询响应中的排序和摘要是派生信息，不能覆盖根平台发布事实。

3.6.1 分发内容与发布检查点

可分发内容至少包括资源 DID、资源类型、资源版本、DID文档、资源元数据、资源包哈希、元数据哈希、DID文档哈希、授权域、生命周期状态、根平台可信发布证明及必要的发布游标或来源引用。发布检查点应能够回答资源是否已被根平台接受、内容是否已写入分发层、发现服务节点是否已经取得并校验，以及失败停留在哪一个阶段。

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

该检查点对象用于解释传播进度，不是把多个状态压缩成一个 available 字段。发现服务节点尚未取得或校验时，资源可以已经完成根平台发布，但不应被描述为已在该节点可发现。

3.6.2 发现节点同步与索引

发现服务节点取得材料后，先完成来源、完整性和治理校验，再写入已验证资源包表或等价存储，随后更新结构化索引和语义索引。结构化索引可以支持按 DID、资源类型、版本、能力标签和授权域查询；语义索引可以使用能力描述、标签别名、用例和协议绑定进行匹配。任何索引写入都应与验证结果关联，不能先展示、后补做信任校验。

3.6.3 序列号、新鲜度与收敛

发布游标用于表达根平台发布材料的传播顺序，发现服务节点同步游标用于表达该节点已经处理到的位置，二者不等价。发现服务节点应记录最后成功应用的游标、收到材料的时间、资源版本和校验结果，并根据允许的新鲜度判断旧快照是否还能用于有限展示。游标前进表示同步位置前进，不表示每一个资源都已经可以调用。

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

当本地游标落后时，节点可以报告滞后并继续处理已验证旧快照，但不能把 localAppliedCursor 伪装成根平台最新发布序列。缺口恢复完成后，应重新校验缺失范围内的每个发布材料，再推进本地游标。

3.6.4 分发失败与恢复

内容分发失败、网络中断、资源包暂时不可获取和发现服务节点数据库故障都应支持恢复。可恢复任务应保留资源 DID、目标版本、来源游标和重试信息；遇到哈希不匹配、证明不匹配或治理状态无效等确定性失败时，应转入拒绝或隔离状态，等待新的发布材料或治理变化，而不是无限重试。恢复后应从持久化游标或受控回填点继续，避免跳过发布记录。

3.7 多个注册节点与发现节点

多个注册服务节点可以面向不同组织、资源类型或授权域提供接入，多个发现服务节点可以面向不同网络区域、用户群或查询策略提供索引。它们共享根平台对身份、授权、资源版本和发布证明的判断基础，但不必共享同一套数据库或本地排序。资源在多个注册服务节点重复提交时，根平台应依据资源 DID、版本、哈希和控制证明识别幂等请求或更新请求；发现服务节点重复收到同一发布材料时，应保持索引幂等。

联邦化不意味着任意节点之间互相写入。注册服务节点只能在其授权域内受理和提交，发现服务节点只能同步和返回其授权域内允许的已发布资源；节点之间的传播优先经过根平台发布事实和内容分发路径。一个发现服务节点故障不会使根平台事实消失，另一个已完成同步的发现服务节点可以继续提供结果，但故障节点的本地可见性和新鲜度应如实标识。

3.7.1 多注册节点接入

根平台为不同注册服务节点维护独立的节点身份、角色和授权域。不同注册服务节点可以提交同一资源，但不能通过更换注册服务节点获得新的资源控制权；同一资源的更新仍必须由资源控制方提供有效控制证明，并满足版本更新规则。注册服务节点的本地登记记录属于受理侧证据，根平台接受记录才是网络发布判断的依据。

3.7.2 多发现节点同步

每个发现服务节点拥有独立同步游标和本地索引状态，可以按自身授权域从内容分发平台取得同一根平台发布事实。节点之间不应直接把本地搜索结果当作对方的权威数据；需要比较一致性时，应比较资源 DID、版本、包哈希、根平台证明和治理状态。不同节点短时间内结果数量或排序不同，可能来自同步延迟或本地策略，但不得来自对根平台事实的任意改写。

3.7.3 节点间数据一致性

节点间一致性应区分事实一致性和读模型一致性。事实一致性要求同一发布版本的 DID文档、元数据、资源包哈希和根平台证明一致；读模型一致性允许不同节点在索引时刻、排序、缓存和语义解释上存在差异，但差异必须可由游标、新鲜度或授权域解释。发现服务节点发现版本冲突时，应优先依据根平台发布序列和证明进行判断，不能以本地到达时间覆盖可信来源。

比较两个发现服务节点时，可以优先比较以下稳定字段，而不是直接比较结果数量或排序：

(resourceDid, version, packageDigest, rootProof, governanceStatus)

这些字段一致时，通常说明两节点对同一发布事实的核心理解一致；索引时间、语义分数、分页位置和缓存时间不同，属于读模型差异。若稳定字段不一致，应回到根平台发布记录和治理事件序列定位原因。

3.7.4 节点故障与隔离

节点出现签名异常、授权过期、持续同步失败、发布材料篡改或接口行为不符合要求时，应能够被隔离，不再接受其受限写入或不再向其提供新的授权范围。隔离不等于删除历史事实；根平台和其它节点仍应保留可审计记录，并根据治理状态和恢复检查决定是否重新启用。普通查询节点故障可以由其它节点承接，但不能因此扩大其它节点的授权域。

3.8 第三方节点接入模型

第三方节点接入应从节点身份材料和运行角色开始，而不是从开放一个 HTTP 端口开始。申请方应提交节点 DID文档、公开验证方法、服务端点、拟承担的节点角色、授权域和运行联系人或运维材料；治理方或根平台据此完成资格审核和授权。获得测试资格后，节点需要通过身份、签名、接口、资源包验证、同步、错误处理和状态更新测试，正式节点再按照正式授权域提供服务。

测试节点和正式节点应在授权状态、可见范围、数据保留和网络影响上隔离。测试节点可以使用测试资源和测试治理状态验证实现，不得把测试发布事实混入正式发现索引；正式节点的授权撤销、暂停或范围变化应能够在运行期被节点识别并影响受限操作。

3.8.1 接入前授权

接入前授权至少应确认节点 DID 可解析、验证方法可用、节点角色明确、端点归属清楚、请求签名可验证、授权域可表达，并且节点运营者能够说明密钥保管、数据存储和故障处理方式。授权材料应绑定节点身份和角色，不应仅凭域名、IP 地址或人工名称作为节点资格证明。

3.8.2 节点能力与授权范围

节点能力描述应区分“能够提供的接口”和“被授权执行的动作”。一个发现服务节点可能支持结构化查询和语义查询，但只被授权索引某些资源域；一个注册服务节点可能支持四类资源接入，但只获准受理其中部分类型。授权范围应能够映射到节点实际过滤、提交和响应逻辑，超出范围的请求必须拒绝或不返回。

3.8.3 协议符合性检查

符合性检查应覆盖健康检查、DID文档解析、签名和哈希验证、节点授权状态、资源注册、根平台发布、内容分发、发现同步、查询响应和错误契约。测试结果应记录输入、节点版本、配置、预期结果、实际结果和证据位置；通过接口连通性测试不等于通过信任边界测试。

第三方节点的最小接入记录可以按以下结构组织，实际字段由接入流程确定：

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

该记录只能说明接入评估的范围和结果，不能把测试通过直接扩大为长期运行保证；正式运行仍需检查授权状态、依赖服务和持续同步状态。

3.8.4 运行期状态管理

正式节点运行期间应持续检查自身授权、治理状态、依赖端点、同步游标、任务队列和数据库状态。授权暂停或撤销后，节点应停止相应受限动作；内容分发或链下信任索引器暂时不可用时，节点可以按新鲜度规则使用既有状态，但不得伪造新的授权、接受或发布事实。状态恢复应具有可观察的重新同步和重新校验过程。

3.9 公开网络、私有网络与联盟网络部署

公开网络允许互联网用户访问公开注册、发现或解析入口，但公开可访问不等于所有资源或所有节点状态都对任何用户可见。私有网络可以把注册服务节点、发现服务节点、内容分发平台和资源端点限制在组织网络或身份域内，仍然使用相同的资源身份、控制证明和发布验证边界。联盟网络可以由多个组织共同运营节点，在约定的根平台、治理权威和授权域下交换资源发布事实。

三种部署形态可以共用协议对象，但应明确网络范围、域名和端点、证书、授权材料、数据留存和跨域传播条件。部署环境的域名、节点数量和数据库选型属于运行配置，不应写入资源 DID 或根平台证明作为不可变协议条件；真正需要互操作的是身份、签名、资源包、哈希、状态和节点授权。

部署形态改变的是可达性和数据传播范围，不改变资源控制权的证明方式，也不把网络入口本身变成信任权威。

3.10 可用性、隔离性与故障边界

OAN 的降级策略必须区分读侧展示和信任敏感动作。发现服务节点可以在分发服务暂时不可用时展示带新鲜度标记的旧快照，运营页面可以展示延迟的统计或历史事件；但资源注册、根平台发布、节点授权变更、撤销状态应用和高风险调用前验证在无法确认关键证据时应拒绝、暂停或进入待处理状态。任何降级都不得生成新的签名事实或改变资源的生命周期状态。

网络中断、数据库故障和索引滞后应分别记录。恢复时，组件应从持久化任务、游标或事件位置继续，重新校验跨节点材料，避免把缓存中的旧版本直接当作最新版本。隔离边界包括节点身份、授权域、资源版本和数据存储边界；一个节点的故障或错误数据不应自动扩散为其它节点的信任事实。

3.11 控制面、数据面与语义面的交互

控制面先决定节点和资源版本是否具备进入网络、传播和被视为有效的条件；数据面再传输控制面允许发布的 DID文档、资源包、元数据、哈希和证明；语义面对已经通过身份和发布检查的资源建立能力标签、描述和用例索引。查询可以同时使用结构化条件和语义条件，但结果必须携带或可追溯到资源 DID、版本、来源、根平台证明和治理状态。

治理状态变化会影响数据面和语义面的继续传播：节点撤销或资源版本失效后，新的同步应停止或过滤相应材料，既有索引应在状态传播后更新；标签树变更可以影响注册推荐和查询解释，但不能追溯性地改变已签署资源包的身份和哈希。三平面之间的依赖顺序是控制事实约束数据传播，数据材料支撑语义索引，语义结果反过来不能授予控制权限。

三类平面的边界也决定了故障处理顺序：控制面状态未知时，数据面可以保留已验证材料用于有限读取，但不得继续扩大传播；数据面材料缺失或哈希不一致时，语义面不得建立或更新可信索引；语义索引不可用时，仍可提供 DID 精确查询或其它已明确支持的结构化查询。恢复后应先恢复控制状态和数据完整性，再重建或刷新语义索引。

三类平面及其依赖关系如下。实现上，三类平面之间传递的不是未定义的自由 JSON，而是由共享 Rust 类型序列化形成的 JSON/HTTP 载荷：资源注册使用 ResourceRegistrationSubmission，注册服务节点向根平台转发时包入 ResourceVerifyAndPublishRequest，内容分发使用 ResourceCdnPublishRequest 或 ResourceCdnBatchPublishRequest，发现查询使用 ResourceDiscoveryQuery 并返回 ResourceDiscoveryResponse。这些类型规定字段名称和嵌套关系，Axum 路由规定方法与路径，签名包络和资源控制证明规定不同信任边界；三者共同构成节点协作契约。

flowchart TB
    subgraph C[控制面]
        G[治理事件]
        T[链下信任索引器]
        A[节点授权与资源状态]
        G --> T --> A
    end
    subgraph D[数据面]
        R1[注册服务节点]
        ROOT[根平台]
        CDN[内容分发平台]
        D1[发现服务节点]
        R1 --> ROOT --> CDN --> D1
    end
    subgraph S[语义面]
        TREE[语义标签树与治理]
        SEARCH[结构化/语义检索]
        TREE --> SEARCH
    end
    A --> ROOT
    A --> D1
    ROOT --> TREE
    D1 --> SEARCH

一次跨平面查询的返回值应同时说明“为什么找到”和“为什么可以被使用”。例如，发现服务节点可以先用能力描述、能力标签和结构化资源类型筛选资源，再关联资源 DID、版本、资源包哈希、根平台可信发布证明和当前治理状态：

{
  "resourceDid": "did:oan:SKDM:example-resource",
  "match": {
    "mode": "semantic_and_structured",
    "query": "检索代码仓库并总结项目结构",
    "matchedTags": ["code-repository", "project-structure-summary"]
  },
  "trust": {
    "governanceStatus": "active",
    "rootProof": "present",
    "packageDigest": "sha256:..."
  },
  "freshness": {
    "indexedAt": "2026-09-09T08:30:00Z",
    "sourceCursor": "publish-1842"
  }
}

上例中的语义匹配只能解释资源与查询的相关性，governanceStatus、rootProof 和 packageDigest 才分别支撑状态判断、可信发布判断和内容完整性判断。任一信任字段缺失时，发现服务节点可以返回资源，但必须降低结果状态或要求调用方继续验证，不能把语义相关性直接解释成授权或安全保证。

3.12 事实来源与派生读模型

资源控制关系的事实来源是资源 DID文档、控制密钥和有效控制证明；注册受理事实来源是注册服务节点的登记记录或注册凭证；根平台接受与发布事实来源是根平台持久化记录和根平台可信发布证明；分发事实来源是内容分发平台保存的发布产物及其哈希；发现可见性来源是具体发现服务节点的同步、校验和索引记录；节点授权状态来源是治理事件及其链下信任索引器投影。官网页面、缓存接口和统计数据只能作为观察层，不是上述事实的唯一权威。

派生读模型必须保留来源引用、版本或游标、校验时间、新鲜度、授权域和错误状态。读模型可以为了查询效率合并字段、建立全文或语义索引，但不能丢失足以重新验证资源的 DID、版本、哈希和证明引用。读模型与权威来源不一致时，应显示同步或校验异常，不能用本地数据库的存在覆盖权威状态。

发现服务节点中的资源索引可以采用如下派生结构。它不是新的权威记录，而是把多个来源组织成便于查询的读模型；其中 source 用于回溯事实来源，sync 用于判断本地数据是否已经追上发布位置：

{
  "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
  }
}

当 localCursor 落后、来源校验失败或治理投影尚未更新时，读模型仍可保留用于有限展示，但应将 freshness 改为 stale 或 verification_required 并保留错误原因。索引数据库中的一行记录只能说明本地曾经接收过材料，不能单独证明资源仍处于有效、可传播或可调用状态。

3.13 网络拓扑与序列一致性

根平台发布序列由根平台产生，用于标识资源发布材料在数据分发链路中的位置；链上治理事件序列由链上治理系统产生，用于表达节点授权和状态变化的顺序；发现服务节点同步游标由发现服务节点维护，用于表达该节点已处理到的分发位置。三者可能数值相似，但没有可互换关系。实现必须分别保存和检查它们，避免用一个全局编号推断资源发布、治理最终性和本地索引状态。

发现服务节点遇到游标缺口、乱序或回退时，应暂停受影响范围的应用，向根平台或内容分发平台补取缺失材料，并在重新验证后继续。重复材料可以按资源 DID、版本和包哈希幂等处理；治理事件重复应依据事件标识或序列去重；发布序列回退不得覆盖已经确认的较新版本。跨节点延迟期间，可以保留旧快照用于有限读侧展示，但必须标记新鲜度，并在无法确认撤销、暂停或授权状态时停止敏感动作。

三类序列应在实现和运维记录中分开保存。下面的配置式示例只表达它们的来源和处理边界，不表示三者共享同一种编号格式：

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

例如，发现服务节点的同步游标落后于根平台发布序列，只能说明本地索引可能不完整，不能据此推断治理事件也落后同样数量；治理事件出现缺口时，即使资源发布材料完整，也应暂停依赖治理状态的应用。只有在对应序列各自连续、材料校验通过且状态投影完成后，节点才可以把资源标记为当前可发现结果。

参考来源