This chapter explains how OpenAgenet (OAN) converts on-chain governance facts into authorization states that infrastructure nodes can use. Governance contracts record node authorization, authorization domains, capability scopes, and status changes; the off-chain trust indexer reads and stores these events and produces queryable subject states; the Root platform, Registrar nodes, and Discovery nodes use these states to decide whether to accept requests, propagate resources, or use governance materials produced by a node. On-chain authorization, node authorization credentials, resource registration, and resource publication prove different facts and cannot substitute for one another.

In this chapter, “current state” means the judgment made by a component based on its synchronized read model. The read model may temporarily lag behind on-chain events. Therefore, when handling new authorization, suspension, resumption, revocation, or high-risk actions, the event sequence, synchronization position, state validity period, and evidence source should all be considered.

13.1 Governance Objectives and the On-Chain/Off-Chain Boundary

The on-chain governance layer and the off-chain business layer are connected through “read, verify, project, and execute”; they do not share one state table. On-chain governance contracts produce reviewable raw events, the indexer stores events and subject states, and the Root platform or node services read this projection and make runtime decisions together with the node DID, authorization credentials, and request content. Resource control proofs, resource packages, and publication status belong to the resource business path. Their existence does not allow a service to skip node governance-state checks.

13.1.1 On-Chain Governance Facts

On-chain governance facts include node authorization, suspension, resumption, and revocation, together with their times, sequences, and sources. On-chain facts are the authoritative source of governance state, but an off-chain service may retain an old read model before synchronization is complete. Responses should distinguish the on-chain position, indexing time, and state currently adopted by the service.

In the current governance contract, governance events are expressed by GovernanceExecutionEvent. The event contains fields such as the action type, event sequence, target node DID, node type, status, authorization domain, effective time, expiration time, policy hash, metadata hash, and the previous-event and current-event digests. The raw payload, transaction, event sequence, and on-chain position such as the checkpoint should be stored together. In this way, the read side can obtain both a node’s current state and the governance execution that produced that state.

The relationship between on-chain events and off-chain services can be summarized as follows: the chain records that “a governance action has occurred, together with its order and parameters”; the indexer constructs a queryable state from these events; and the Root platform and other nodes use that state according to their own policies. The indexer cannot modify on-chain events, reissue governance permissions, or fill in missing events on its own. When the raw event and the read model disagree, the original position and event digest should be the starting point for verification.

13.1.2 Root Platform Runtime State

Root platform runtime state indicates whether the service has read and applied the current governance result, including whether it accepts node submissions, permits publication, and permits downstream distribution. It is a runtime projection of on-chain governance facts and must not replace those facts.

At runtime, the Root platform must distinguish at least between “the governance state is known” and “this request has been authorized.” The former depends on the state, sequence, and freshness provided by the off-chain trust indexer or another governance read side. The latter also requires matching the requesting node DID, requested action, authorization domain, and capability scope. Even if a node is in active status, this only indicates that it may have the corresponding infrastructure responsibility. Resource control, resource content, version, and publication materials still require separate verification.

13.1.3 Registration and Publication Status

Registration acceptance, Root platform publication, content distribution, and Discovery visibility are different states. Valid node authorization is a qualification for executing infrastructure actions; it does not mean that a resource has passed control, content, and version verification.

These states are produced by different components: the Registrar node records the resource registration request and its validation result; the Root platform decides whether to form a Root-verified publication fact; the content distribution platform propagates approved materials; and the Discovery node adds visible resources to its local index. On-chain node authorization only determines whether an infrastructure node is qualified to perform a certain type of action. It cannot replace the resource provider’s signature, resource package integrity checks, publication process, or Discovery index update.

Node authorized -> may submit a request
Request validated -> may enter the publication process
Root platform publication -> may enter the distribution process
Discovery node indexing -> resource may become visible to queries

13.1.4 Discovery Node Read Model

The Discovery node uses the off-chain trust indexer or governance synchronization result to filter resources. The read model must record its source and synchronization progress. When a governance event has not yet been synchronized, the node should use a conservative state and must not interpret an old cache directly as a current authorization conclusion.

The Discovery node consumes a governance read model in normal operation, rather than scanning the entire on-chain history for every query. The read model must at least associate the node DID, node type, current status, authorization domain, last governance sequence, event digest, and update time. The source status in a query result should also remain separate from the resource’s own lifecycle and publication proof. If the indexer is behind, a Discovery node may retain a read-only snapshot to improve access continuity, but it must not label that snapshot as the current governance fact.

13.2 Infrastructure Node Authorization Model

Infrastructure nodes use the node DID as the governance subject and distinguish Registrar nodes, Discovery nodes, and VC issuers by node type. The current indexer’s SubjectState stores the node type, node DID, status, authorization domain, policy hash, metadata hash, effective time, expiration time, state version, last update time, last governance sequence, and last event digest. A node authorization credential can be used as off-chain evidence, but it and the on-chain state are two evidence chains that must be checked together: the credential states the issuer’s claim about the node’s qualification, while the on-chain read model states the current governance status and authorization scope.

A minimal state judgment can be represented as follows:

{
  "subjectType": "discovery",
  "subjectDid": "did:oan:INDS:example",
  "status": "active",
  "authorizedDomains": ["technology.software_engineering"],
  "effectiveFromMs": 0,
  "expiresAtMs": 0,
  "lastSequence": 12
}

The DID, sequence, and authorization domain in the example are illustrative values. At runtime, the state can be used as an input for “governance-level authorization” only when the node type matches, the status is valid, the effective time has been reached, and the expiration time has not been exceeded. The requested action must then still be checked against the authorization domain and capability scope.

13.3 Authorization Domains and Capability Scopes

The authorization domain answers “which business or resource scopes may the node process,” while the capability scope answers “which infrastructure actions may the node perform.” For example, a Discovery node may be authorized to serve a particular capability domain, but this does not mean that it may represent the resource controller to modify a resource DID Document, nor that it can issue a registration credential. Authorization domains should use normalized and comparable values. The current contract also constrains empty domains, quantity, length, canonical order, duplicate entries, and the mixed use of wildcards.

Multiple authorization domains normally represent the union of the node’s service scopes. Whether a specific resource may be processed still requires a combined judgment over node status, the resource authorization domain, and governance state. A change to the authorization domain should produce a new governance event and state version. After the scope is reduced, the node must not continue accepting new requests under the old scope. Historical publication facts that have already been formed should retain their source and time and must not simply be deleted.

13.4 Governance Event Model

The governance contract handles proposal creation, voting, and final execution separately; the indexer focuses on the emitted initialization events and governance execution events. After parsing, the indexer stores both raw event records and structured governance events. Raw records retain the transaction digest, event sequence, checkpoint, package identifier, event type, time, and original JSON. Structured records support queries by node DID, governance sequence, status, and authorization domain. Event names and descriptions shown on a page are projection fields and cannot replace the raw event payload.

The key fields of a governance execution event can be understood as follows:

The official Network page exposes the event list in the current read model through the public endpoint /api/public/network/governance-events. At the time of this review, the endpoint’s generatedAt was 2026-09-12T02:01:05.463553057+00:00. The following table records the time, node, and page description in the order currently returned by the endpoint. It gives readers a direct view of publicly observed governance actions, but does not replace the raw event payload, transaction, or checkpoint in the governance contract. The list changes as on-chain governance and indexer synchronization change:

13.4.1 Node Authorization Events

An authorization event places a node in the candidate set of usable nodes. The recipient must still check finality, authorization expiration, capability scope, and the binding of the node DID. It must not allow a request solely because of the event name.

In the current action encoding, authorization of a Registrar node is 21, authorization of a Discovery node is 31, and authorization of a VC issuer is 41. These codes come from the action mapping in the governance contract and indexer. The actual effect of an authorization event is still determined jointly by status, the time window, the authorization domain, and whether the read model has been synchronized. If the target DID and target address in the authorization event do not match the node DID Document and runtime connection identity, automatic acceptance should stop and the case should enter verification.

13.4.2 Node Suspension and Resumption Events

Suspension events take precedence over ordinary business requests. A resumption event becomes effective only after governance conditions are met and the indexer observes it in the correct order. The service should retain the raw suspension and resumption events rather than only replacing a current Boolean state.

Suspension and resumption do not delete or overwrite historical events. The indexer should store them as a continuous governance sequence and project the current state from the last valid sequence. After resumption, the system only allows subsequent actions that meet the conditions again. Whether a request rejected during suspension should be resubmitted is decided by the caller based on the request identifier and business result; state recovery must not resubmit it automatically.

13.4.3 Node Revocation Events

A revocation event indicates that a node should no longer perform new operations within its authorization scope. Completed resource publications and historical queries should not be rewritten unconditionally, but downstream services must stop adopting new governance conclusions produced by the revoked node.

Revocation affects the node’s subsequent governance qualification; it does not erase all data previously produced by that node from history. After processing a revocation event, downstream services should stop accepting new registrations, publications, distributions, or governance-state updates from that node, and should recheck materials from the node that have not completed verification. Historical resource records independently confirmed by other facts may be retained, but must preserve their source node, event position, and state at that time.

13.4.4 Event Time, Sequence, and Source

Event ordering should prioritize the on-chain checkpoint, transaction sequence, event sequence, or an explicitly defined composite key. The event occurrence time, indexing time, and page display time must be recorded separately.

After paginated reads, the current event source orders events by checkpoint, transaction digest, and event sequence, and saves the read cursor together with the last processed position in the indexer state. emittedAtMs represents the on-chain time in the event payload. The indexer write time represents read-side observation and persistence, while the page generation time represents only the display moment. These values cannot replace one another. If an event has no usable time, ordering and diagnosis should rely on the on-chain position and indexing time.

13.5 Node Authorization, Suspension, Resumption, and Revocation

Node status is the current projection of a governance sequence onto a subject state. Authorization, suspension, resumption, and revocation all change subject availability through governance events, but their concrete effect is also constrained by the authorization domain, node capability, effective time, expiration time, event order, and index freshness. Before executing an action, a service node should combine the status judgment with the request source, request type, and resource facts. A successful historical request must not be treated as proof that current authorization remains valid.

13.5.1 Authorization

After authorization, a node obtains an explicit authorization domain and capability scope. When receiving a node request, the Root platform should validate the current status and scope. It must not interpret an authorization event as proof that resource content has already passed verification.

13.5.2 Suspension

While suspended, a service may retain read-only status queries and audit capabilities, but must not continue accepting new submissions or propagation actions that require the node’s authorization, unless governance policy explicitly permits them.

13.5.3 Resumption

Resumption should re-confirm the node identity, authorization scope, and governance event order. Resumption does not automatically resubmit requests rejected during suspension. The client must re-confirm them according to the request ID and current status.

13.5.4 Revocation

After revocation, new actions within the authorization scope must stop. The revocation reason, time, operator, and on-chain position should be retained. The Discovery node and distribution service need to refresh their governance read models and converge progressively.

13.5.5 Effects of Status on Registration, Distribution, and Discovery

State-transition decisions should not rely on a single Boolean field. When projecting state, the indexer must also check whether the event sequence is continuous, whether the previous-event digest matches, whether events are duplicated, and whether effective and expiration times are valid. Runtime authorization checks must compare the current time with effectiveFromMs and expiresAtMs: an action cannot be allowed before the effective time, and a nonzero expiration time makes the state invalid once reached. When the state is unknown, the sequence has a gap, or the digest chain is inconsistent, high-risk new actions should be blocked rather than guessing the next state.

13.6 Governance Notifications and Authorization State

Governance notifications are suitable for communicating that a state has changed and providing an entry point for verification to service nodes and operations interfaces, but a notification itself is not a new authorization credential. A notification or snapshot should contain at least the node DID, node type, current status, authorization domain, last governance sequence, event digest, on-chain position, and indexer observation time. After receiving a notification, the recipient should read the status interface or original on-chain evidence according to its security requirements and verify it. It must not execute a high-risk action solely from the notification text.

When notification delivery fails, the read model lags, or a state snapshot disagrees with the raw event, a service may temporarily retain the known state for low-risk read-only display. It should stop advancing new high-risk authorization actions and record the synchronization position that needs recovery. After notification delivery resumes, the service should recheck according to the governance sequence rather than processing only the last notification.

13.7 The Off-Chain Trust Indexer as a Governance Read-Side Projection

The off-chain trust indexer is a component for reading and projecting governance information. It reads target governance events from the configured chain endpoint, stores raw events, structured events, and current subject states in local storage, and provides query endpoints for the Root platform and node services over HTTP. Through chain adapters and a unified state projection, the indexer decouples the blockchain implementation from OAN nodes and business logic, allowing the same node-authorization, governance-reading, and state-judgment mechanisms to support consortium chains such as Xinghuo Chain Network and well-known public chains such as Ethereum. The event model, finality, query interface, and deployment adaptation of each chain still require separate implementation and verification; the current reference implementation mainly covers Sui. The value of the indexer is to convert on-chain events into an operational read model. Its boundary is that it does not hold governance keys, submit governance transactions, or create or revoke node authorization based on its own judgment.

13.7.1 Reading On-Chain Events

Event reading should support initial synchronization, cursor-based incremental reading, and resume from a checkpoint. When reading fails, the last confirmed position must be retained. An empty result must not overwrite an existing valid read model.

The indexer’s event source supports paginated queries by event type and combines the GraphQL cursor, transaction digest, and event sequence associated with the event type into a resumable cursor. The configured event-type package, accepted emitting packages, and synchronization mode must remain consistent with the actual on-chain upgrade history. Otherwise, the service may appear healthy while being unable to read target events. Initial synchronization establishes the complete history, incremental synchronization continues from the saved cursor, and checkpoint recovery must reread from a safe position and use idempotent writes to eliminate duplicates.

13.7.2 State Projection

State projection updates node status, authorization domains, and capability scopes according to event order and retains the necessary event history. Duplicate events should be handled idempotently, and an old event must not overwrite a confirmed newer state.

The current storage layer uses the governance sequence as the primary key for governance events and uses “node type + node DID” as the primary key for subject state. A repeated event with the same sequence and event digest can be treated as an idempotent replay. If the same sequence arrives with a different digest, the service should report a governance-event conflict and stop silent overwriting. Only an event with a sequence greater than the subject state’s last sequence may update the current projection.

13.7.3 Synchronization Cursor and Lag

The cursor is used for recovery and observation; it is not equivalent to on-chain finality. The interface should distinguish the currently read position, confirmed position, and position adopted by the service, and should make synchronization lag computable.

/v1/status may provide the package identifier, governance-object identifier, last processed checkpoint, event cursor, event source, latest governance sequence, latest event digest, sequence-gap flag, digest-gap flag, and last synchronization time. latestSequence only indicates the highest governance sequence written by the indexer. It does not by itself prove that the indexer has caught up with the latest on-chain checkpoint. Lag judgment must also consider the latest position returned by the event source and the synchronization result.

13.7.4 Query Interfaces

Query interfaces should return the state source, on-chain position, indexing time, and reason for the state. Callers may use these values for filtering, but high-risk authorization must still be verified against original facts or verifiable proofs.

The public subject query, authorization-state query, and governance-event query provided by the indexer serve different purposes: subject queries are suitable for listing node states, authorization-state queries are suitable for runtime decisions, and event queries are suitable for auditing and fault tracing. Query responses come from the indexer read model. Callers should judge freshness by combining the last governance sequence, event digest, and synchronization status. An authorized result must not be interpreted as meaning that the indexer has verified all node keys, endpoints, or resource behavior on behalf of the caller.

The current off-chain trust indexer provides read interfaces including GET /v1/status, GET /v1/summary, GET /v1/subjects, GET /v1/registrars, GET /v1/discoveries, GET /v1/vc-issuers, and GET /v1/events. Subject interfaces usually return a subjects array, governance-event interfaces return an events array, and the status interface returns an index-status structure. These responses use dynamic JSON because index state and on-chain event fields are serialized from the indexer read model. POST /v1/admin/sync-once is a synchronization management operation and should not be mixed with public query interfaces.

The indexer’s chain-access implementation uses official Sui gRPC/protobuf types, such as checkpoint and service-information requests. These types belong to the external Sui RPC protocol and are not OAN’s own node-coordination .proto. OAN nodes therefore continue to use JSON/HTTP protocols serialized from shared Rust types as business interfaces, while chain endpoints and protobuf remain at the boundary where governance facts are read.

13.7.5 Synchronization Failure and Recovery

When synchronization fails, the service should record the error, retry count, and last successful cursor. After recovery, it should replay from a safe position and perform consistency checks. A temporary indexer outage must not cause all nodes to be marked as revoked.

Recovery should at least include identifying the reason for the read failure, retaining the last successful cursor, rereading affected pages, checking the event sequence and digest chain, confirming that a subject state has not been overwritten by an old event, and recording the new cursor and processed count after recovery. When the indexer is unavailable, dependents should mark the state as unknown or temporarily unavailable rather than writing revoked in bulk. Revocation must come from an actual governance event or a verifiable governance state.

13.8 Enforcing Governance State at Root Platform Runtime

When processing a request, the Root platform should perform the following steps in order:

1. Identify the requesting node DID and verify the communication signature.
2. Query the current governance state and its synchronization freshness.
3. Check whether the requested action belongs to the authorization domain and capability scope.
4. Then verify resource control, version, hash, and content.
5. Write the acceptance, rejection, or delay reason to traceable logs.

Valid authorization is only a prerequisite for entering the resource-verification process; it is not a resource-publication conclusion.

The first step confirms which node sent the communication request. The second confirms that node’s state and freshness on the governance read side. The third confirms that the action, node type, authorization domain, and capability scope match. Only the fourth step enters verification of the resource DID Document, control signature, resource package, version, and content. Insufficient evidence at any step cannot be compensated for merely by success in a later step. For example, a valid resource-package signature may show that the resource control proof is potentially valid, but it does not prove that the Registrar node submitting it still has current authorization.

13.9 Governance Filtering on the Discovery Side

Discovery filtering must distinguish at least the source node status, resource lifecycle, Root platform publication status, and index freshness. Semantic relevance or tag matches may participate in ranking only after these hard conditions pass.

The Discovery node may use node authorization status to filter sources, but it should not write that authorization status directly into the resource lifecycle field. When a source node is suspended, revoked, or unknown, newly synchronized materials should be rejected, isolated, or marked as restricted. Existing resource records confirmed by other evidence may retain their historical presence, but they must not continue to be treated as normal new candidates without current governance confirmation. When the authorization domain does not match, the resource is not visible to that Discovery node; this does not mean that the resource DID does not exist across the entire network.

13.10 Governance Event History and Public Observability

Public event queries should use stable pagination and explicit ordering, and should display the on-chain position and indexing time together:

Public display may use eventLabel as a readable action name, but should retain the raw eventType, governance sequence, and source position. “Recent” in an event list should be interpreted by governance sequence or on-chain position, not by the response time of the web interface. Pagination boundaries should also be tied to stable ordering so that a client does not display the same event twice or miss an event when new events arrive.

13.11 Chain Endpoints, Packages, Objects, and Deployment Configuration

Indexer configuration must record the network, current operation package, event-type definition package, allowed emitting packages, governance bulletin object, event-source mode, and synchronization parameters together. OAN currently uses Sui Mainnet. The governance bulletin object is 0xb900fb0dc1ebd58fbc4d0c697d644c861578ed948e26638836e338de0d1a3b46; the initial package 0x1b602d575ddf1ced075f9d2986bfe53cd7d4e59967ec26a0d949009c7b2c9d6c defines the governance event types; and the current operation package is 0x232f984a25ceb8358290a8bae594078deca2d670a80c8d57d291d64a491d7fd5. During upgrades, 0x2fd18248c0cd42f371409eb1003176dc0d5744cccfdf2e49e5224b4249a5ffb4 also emitted governance events. Therefore, the indexer must accept events produced by all three packages to reconstruct the governance sequence continuously across the upgrade.

[chain]
network = "sui-mainnet"
grpc_endpoint = "https://fullnode.mainnet.sui.io"
event_query_endpoint = "https://graphql.mainnet.sui.io/graphql"
package_id = "0x232f984a25ceb8358290a8bae594078deca2d670a80c8d57d291d64a491d7fd5"
event_type_package_id = "0x1b602d575ddf1ced075f9d2986bfe53cd7d4e59967ec26a0d949009c7b2c9d6c"
emitting_package_ids = [
  "0x1b602d575ddf1ced075f9d2986bfe53cd7d4e59967ec26a0d949009c7b2c9d6c",
  "0x2fd18248c0cd42f371409eb1003176dc0d5744cccfdf2e49e5224b4249a5ffb4",
  "0x232f984a25ceb8358290a8bae594078deca2d670a80c8d57d291d64a491d7fd5",
]
bulletin_object_id = "0xb900fb0dc1ebd58fbc4d0c697d644c861578ed948e26638836e338de0d1a3b46"

[sync]
event_source = "event_query"
poll_enabled = true
sync_on_start = true
poll_interval_ms = 10000
event_page_size = 50
max_pages_per_sync = 2

The values above correspond to the current Mainnet event-synchronization configuration. package_id points to the package that executes current governance operations. event_type_package_id remains directed to the package that originally defined the event structure. emitting_package_ids covers the packages that actually emitted governance events during the upgrade history. bulletin_object_id points to the governance bulletin object that evolves continuously. These four values have different roles: updating only package_id to the latest package while omitting the old event-type package or an intermediate emitting package creates gaps in event queries; configuring only the bulletin object without checking the event source may produce a service that starts normally while its governance sequence has stopped growing.

13.12 Governance Upgrade and Migration Rules

Before an upgrade, the compatibility relationship among the contract package, event structures, indexer, and node services should be declared, followed by migration and replay. Old events must remain parseable or have an explicit conversion rule. If conversion fails, the raw data must be retained and an uncertain state must be prevented from overwriting a valid state.

An upgrade should also distinguish a “package-address change” from an “event-type-definition change.” An upgradeable Sui package’s current operation package may differ from its event-type definition package. Therefore, event-query configuration, checkpoint-audit configuration, and the set of emitting packages accepted by the indexer cannot be inferred from a package name. After migration, a set of known governance events should be used to verify the raw event count, structured event count, latest sequence, digest chain, and subject states, confirming that the upgrade introduced neither duplicate projections nor skipped events.

13.13 Governance Event Ordering and Finality

Event processing can be understood through the following states:

observed -> ordered -> confirmed -> projected -> exposed

An event that arrives later but has an earlier on-chain position should be inserted into the history, and affected projections should be recalculated. A confirmed higher-version state must not be directly overwritten by an old event.

observed means that the event has been read from the event source. ordered means that the indexer has established an order by on-chain position or governance sequence. confirmed means that the event has passed the implementation-defined integrity and position checks. projected means that it has been written to subject state. exposed means that the query interface can read the projection. The fact that an event has entered the public read model does not mean that its on-chain occurrence time equals the interface observation time. When a sequence gap or digest gap exists, public state should carry uncertainty so that incomplete history is not treated as a continuous governance chain.

13.14 Consistency Among On-Chain Facts, Off-Chain Publication State, and Read Models

Consistency does not require on-chain events, the indexer, the Root platform, and the Discovery node to update at exactly the same moment. It requires every layer to explain the fact position and delay it is using. On-chain events are the source of governance facts; the indexer provides a read model with cursors and times; the Root platform uses it to make publication decisions; and the Discovery node uses it to filter sources and resource visibility. When any layer lags or conflicts, confirmed facts should be retained, differences and their sources should be marked, and restrictive handling should be applied to high-risk actions.

13.14.1 Final On-Chain Facts

Final on-chain facts are based on a verifiable event position and contract state and should retain at least the object, action, operator, time, and reference to the original event. An indexer interface can provide an access path for reading, but cannot change the original fact.

SubjectState in the governance contract stores the node’s current status, authorization domain, policy and metadata hashes, effective and expiration times, state version, and update time. GovernanceExecutionEvent stores the event context that caused the state change. Together, they can answer “what is the current state” and “which governance execution formed it,” but the result should still be verified against the original on-chain position of the transaction, event, and governance object.

13.14.2 Root Platform Publication State

Root platform publication state represents the result of the off-chain verification and publication process. It may lag behind on-chain authorization, or may not be produced because resource verification failed. Therefore, resource publication cannot be inferred from node authorization.

The Root platform may read node governance state before accepting a submission from a Registrar node, but resource publication must still pass checks for the resource DID Document, control signature, resource package integrity, version relationship, content policy, and publication process. Publication state should retain the resource DID, resource version, publication-proof reference, processing time, and source node. It is stored separately from on-chain node authorization state so that downstream propagation eligibility can be reconsidered when the node’s governance state changes.

13.14.3 Discovery Node Index State

Discovery index state indicates whether a Discovery node has received and indexed a propagatable resource. It should associate the resource DID, version, publication-proof reference, indexing time, and governance filtering result.

Discovery index state is a local read-model state, not an on-chain resource state. An index record should identify the publication or distribution source, the resource version used, the time written to the local index, the node governance state adopted at that time, and whether the resource was filtered by authorization domain or lifecycle. Semantic-index hits, capability-tag hits, and governance-authorization hits should be explained separately. A retrieval score must not conceal that the source node has been revoked or that its governance state is unknown.

13.14.4 State Inconsistency and Convergence

When states are inconsistent, the system should act conservatively: pause high-risk actions, retain confirmed facts, mark the source of the difference and synchronization lag, and update the external state after the governance read model, Root platform, and Discovery index converge.

Common inconsistencies include an on-chain governance sequence that the indexer has not read, an event read by the indexer that the node service has not refreshed, a Root platform publication that the Discovery node has not indexed, and an old local resource record whose source-node status has changed. Each inconsistency should record the compared sequences, times, sources, and handling action. During recovery, the system should recompute from the fact source rather than overwriting the difference with the web access time or the last successful request.

13.15 Governance Authority Key Management and Emergency Procedures

Governance-key operations must be strictly separated from the local control private keys of resource providers. Emergency procedures should at least include pausing high-risk governance operations, rotating or isolating suspected leaked keys, confirming on-chain events, resynchronizing the indexer, notifying nodes, and verifying state convergence. An operations marker that has not been confirmed through on-chain or authorization procedures must not be used directly as the final governance fact.

Governance keys are used to initiate or approve governance actions. Resource control private keys prove the control relationship for a specific resource DID or resource version. The indexer and ordinary operations processes should not hold governance keys. After emergency handling, the system should separately verify the permissions of the governance account or object, the on-chain event sequence, the indexer state, node runtime decisions, and downstream Discovery results. If any one of these remains unknown or lagging, the external state should retain a restrictive marker; service-process recovery alone is not enough to declare governance recovery complete.

References