This appendix describes implementation through the chain “specification clause -> data structure/interface -> implementation file -> test evidence -> deployment configuration -> maintenance responsibility”, rather than treating the repository name itself as proof of functionality. The current core runtime implementation consists of the shared protocol library, Root platform, Registrar node, Discovery node, content distribution platform, and off-chain trust indexer; the SDK, community skill package, and official website are client and public entry points; the third-party node admission test kit provides independent evaluation support and is not a production runtime node. oan-onboard-tests and the root-level genesis are not independently verifiable directories in the current workspace. Therefore, historical references involving them can only be treated as source-material conventions and cannot serve as evidence of the current implementation.

Mapping statuses have the following meanings:

Each implementation fact should record both the source version and the verification time. For inputs, explain how they are converted into validation conditions, authorization-domain filters, or query conditions; for outputs, explain whether they are raw facts, verification results, cached projections, search rankings, or display summaries; for Root proof, VCs, signatures, and governance status, the issuer, verifier, bound content, and status source must be retained. Capability labels, semantic relevance, A2A Agent Card, or MCP metadata only describe or assist capability discovery and cannot replace control and governance verification. Mapping records must distinguish at least three types of evidence: source-code evidence explains where the logic and fields are defined, test evidence explains what result the logic produces for fixed inputs, and runtime evidence explains what the service, configuration, and dependencies can actually complete in the specified environment. They answer “what was written”, “what was tested”, and “what was run”, respectively, and cannot replace one another with a README, a single successful compilation, or one health endpoint. For dynamic data, also record the commit, configuration summary, database/index state, and request correlation identifier at the time the evidence was generated.

F.1 oan-protocol-common

This repository provides shared Rust workspace-level foundations and primarily maps to Chapters 4 through 8, Chapter 15, and Appendices A through C. crates/oan-core carries DID Document, resource types, and core domain objects; oan-crypto handles cryptographic suites, keys, and hash-related logic; oan-credentials handles credential construction or verification; oan-package handles ResourcePackage and its bindings; oan-protocol handles cross-node requests, responses, and protocol constants; oan-publication-events handles publication events; oan-storage provides JSON, SQLite, or PostgreSQL storage abstractions; oan-service-security provides shared logic for request envelopes, nonce, request ID, and signatures; oan-semantic-recommender and its data directory provide capability-label trees, authorization-domain classification, and recommendation/normalization assistance.

The shared library’s maintenance responsibility is to keep data structures, serialization, error codes, and cryptographic bindings consistent across nodes. Any field change should trigger synchronized checks of the Root platform, Registrar node, Discovery node, SDK, community skill package, and fixed fixtures. The shared library does not have authority to decide node authorization, resource publication, or business calls on behalf of upper-layer services.

When tracing downward from an HTTP interface, the contract can be located through the implementation chain: services/registrar-node/src/main.rs in the Registrar node binds /resources/register and /resources/submit to register_resource; services/root-node/src/main.rs in the Root platform binds /root/resources/verify-and-publish to verify_resource_and_publish; the Discovery node’s service directory of the same name binds /discovery/resources/query to resource_query; services/cdn-node/src/main.rs in the content distribution platform handles /cdn/resources, batch publication, and resource reads; and src/api.rs in the off-chain trust indexer handles read interfaces such as /v1/status and /v1/events. A handler signature is direct evidence for confirming input and output types, while a route table is direct evidence for confirming HTTP methods and paths.

When maintaining interfaces, record “shared DTO changes” separately from “dynamic response-field changes”: the former requires checking oan-protocol, oan-package, all deserialization callers, and cross-language SDKs; the latter requires checking the handler that generates the JSON, error-code tests, public proxies, and the endpoint table in Appendix B. Successful Rust compilation only proves that the type layer compiles; it does not prove that JSON fields, HTTP paths, authentication boundaries, and asynchronous state semantics still match the external documentation. When locating a shared field, maintainers should verify it in the order “domain structure -> serialization implementation -> callers -> fixture”. For example, first confirm the ResourcePackage structure and validation methods in oan-package, then check the request/response types in oan-protocol and the deserialization paths in the Registrar node and Discovery node, and finally use resource fixtures to verify behavior for missing, tampered, and version-conflicting inputs. The fact that a single node compiles after modification does not show that the cross-repository protocol remains compatible; at minimum, the corresponding SDK exports and the community skill package’s inputs and outputs must also be checked. When a field in the shared library changes, maintainers should first determine whether the change is a serialization-compatibility change, a validation-semantics change, or a purely internal implementation change. Serialized fields, enum values, error codes, and hash calculation methods belong to the cross-repository impact surface; even if the Rust workspace compiles, node HTTP payloads, TypeScript types, community skill package scripts, and admission-test fixtures must still be checked. If only an internal helper function changes and external payloads and error behavior remain unchanged, the relevant unit tests should be retained as boundary evidence, without expanding the protocol-version scope.

F.2 oan-root-services

This repository corresponds to Chapter 3, Chapters 9 through 10, Chapters 13 through 15, and the related lifecycle, distribution, and operations chapters. The main Root platform service is located at services/root-node/src/main.rs. Its routes include the root DID Document, status, Registrar node and Discovery node directories, resource details and versions, capability-label trees, announcements/events, authorization, revocation, and internal interfaces for the content distribution platform and Discovery node. services/cdn-publisher consumes publication tasks, prepares ResourcePackage from the Root platform, publishes them to the CDN in batches, and writes back publication results; services/cdn-node provides the data-plane service for the content distribution platform. Configuration examples are located in each service directory’s config.example.toml.

The Root platform implementation boundary can be checked as follows:

Root platform maintainers must also monitor operational boundaries involving idempotency, version conflicts, publication retries, queue backlogs, database backups, and loss of governance-status connectivity. The Root platform issues Root proof, which proves only facts within its verification and publication scope; it does not prove the business quality of resource endpoints and does not hold resource control private keys. Root platform code review should record public query routes separately from internal write routes. /root/resources/{did}, version queries, and capability-label queries are read paths; Registrar node submissions, node authorization, revocation, content distribution queues, and Discovery node notifications are protected write or coordination paths. When modifying services/root-node/src/main.rs, maintainers should also check publication-task consumption in services/cdn-publisher/src/main.rs, ResourcePackage reads in services/cdn-node/src/main.rs, and the queues, database, and upstream endpoints in Root platform configuration; a Root platform HTTP response alone cannot establish that content distribution has completed. The key verification point for Root platform changes is when the publication fact is created. Maintainers should record the Registrar node submission time, Root platform verification result, resource version and hash, Root proof, content distribution task status, and Discovery node notification status separately. Only after Root platform verification has produced a publication fact do the subsequent distribution and discovery paths have a citable root source. Root platform query interfaces, content distribution platform caches, and Discovery node index entries should be retained as separate evidence.

F.3 oan-registrar-node

This repository primarily corresponds to Chapters 5 through 8, Chapter 15, and the resource lifecycle section. Its implementation entry point is services/registrar-node/src/main.rs. Current routes include /health, /registrar/did, /resources/register, the compatible /resources/submit, resource lists and details, status, statistics, Root platform authorization, capability-label trees, label suggestions, label normalization, registration-domain directories, and registration recommendations. The configuration example is located at services/registrar-node/config.example.toml; data directories, key directories, and optional SQLite/PostgreSQL databases are determined after configuration parsing.

The Registrar node processing chain is:

Resource controller submits public materials and control proof
  -> validate shape, DID, resource type, metadata, and authorization domain
  -> construct a signed request for the Root platform
  -> receive the Root platform verification/publication response
  -> generate and store the registration VC and registration record
  -> return the registration result and Root platform response to the caller

The registration VC here is issued by the Registrar node for the registration fact and cannot replace Root proof. When the Root platform rejects a request, the Registrar must not treat local acceptance as network-wide publication. The Registrar node can see public resource materials, public keys, signatures, and credentials, but the normal flow must not obtain the resource control private key. oan-third-party-node-admission-test-kit/fixtures/v1-alpha/resources provides fixed verification examples for DID, resource type, authorization domain, VC subject, hash, control challenge, proof integrity, and lifecycle; SDK and official website tests cover client-call shapes but do not replace server-side validation by the Registrar.

Maintenance priorities are to keep the fields of /resources/register consistent with the protocol types, make error codes and HTTP statuses explicit, ensure that upstream failures do not create false success, prevent duplicate submissions from producing conflicting records, and update configuration examples, public error documentation, the SDK, and the community skill package together. Registration issue diagnosis should follow request correlation: first confirm whether the request was rejected locally at the input-validation and error-conversion points of register_resource; then check whether ResourceVerifyAndPublishRequest for the Root platform was constructed correctly; finally compare the registration record, VC, and Root platform response to determine whether the result was only local acceptance. A reusable diagnostic record should retain at least the resource DID, request identifier, version, error code, upstream status, and database-write result; “the page displayed success” must not replace the actual result between nodes. The Registrar node’s implementation mapping should also state which layer each result belongs to: local request validation, registration-record write, submission to the Root platform, registration VC return, and Root platform publication result must not be collapsed into one “registration succeeded” outcome. For retries after network timeouts or incomplete responses, use the original request’s correlation information to check whether the server has already produced a registration fact; only after confirming idempotency conditions and final state can the client decide whether to submit again.

F.4 oan-discovery-node

This repository corresponds to Chapter 3, Chapter 6, Chapters 10 through 12, Chapters 14 through 15, and freshness and lifecycle requirements. services/discovery-node/src/main.rs provides interfaces for node DID, status, authorization domain, synchronization history, index statistics, query statistics, resource index, resource query, query suggestions, query explanations, rejection packages, and capability-label trees; semantic_aliases.v1.json contains Discovery-side semantic alias materials. services/embedding-service provides an optional text-vector service. Its configuration, tests, and real-model smoke files are located in that service directory; enabling a semantic model must not be written as a mandatory dependency for every deployment.

The Discovery node data path should be distinguished into four layers:

1. The synchronization layer receives materials from the Root platform or content distribution platform and records the source, cursor, and synchronization result.
2. The verification layer checks Root proof, ResourcePackage hashes, DID Document, version, authorization domain, and lifecycle.
3. The indexing layer writes verified materials into a structured index and builds retrieval indexes by capability labels, text fields, or optional vectors.
4. The query layer converts DID, structured conditions, and natural-language input into conditions and returns candidates with source, version, status, and explanation information.

Current fixed fixtures cover in-domain visibility, out-of-domain invisibility, empty results, arbitrary-label matching, and invalid queries. Real synchronization, vector-model quality, concurrent indexing, and cross-node convergence still require confirmation through service integration or deployment tests. Discovery node maintainers are responsible for index consistency, query error contracts, source retention, governance-status filtering, and semantic-configuration versioning. Maintenance diagnosis for discovery queries can trace backward from the entry point: /discovery/resources/query handles request parsing and query dispatch; index tables provide the read model for verified resources; semantic aliases and capability-label materials provide normalization and candidate assistance; services/embedding-service/src/server.ts and src/embedding.ts participate in text-vector generation only when vector mode is enabled. When investigating “duplicate results”, separately check same-DID version deduplication, index-copy deduplication, pagination cursors, and frontend display mapping; do not only adjust ranking or the frontend array. The Discovery node’s code mapping must also retain the conversion relationship “raw materials -> verification results -> index records -> query candidates”. An original ResourcePackage or Root platform publication notification must not be treated directly as a queryable result; it may enter the index only after source, hash, version, authorization-domain, and lifecycle checks are complete. Relevance scores, label hits, and text snippets in query responses are ranking or explanation evidence; the resource DID, version, source, and governance status are the factual entry points for callers to continue verification.

F.5 oan-trust-indexer

This repository corresponds to Chapter 13, Chapters 19 through 20, and authorization-status and recovery requirements. src/event_source.rs handles event sources, src/sync.rs handles cursor advancement and synchronization, src/store.rs handles projection storage, src/domain.rs handles domain state, src/api.rs and src/grpc.rs provide query interfaces, and src/config.rs handles runtime configuration. configs/mainnet.example.toml, mainnet.current-events.toml, and the single-checkpoint smoke configuration distinguish continuous synchronization, current-event observation, and diagnostic runtime modes.

The indexer’s trust path is “read on-chain events -> process them in order or by cursor -> validate event structure and state transitions -> write the off-chain read model -> provide state queries externally”. The read model must retain the event source, cursor, last successful processing time, projection time, errors, and necessary version information. The off-chain projection is a queryable cache of governance facts and does not create on-chain authorization; when using it, the Root platform, Registrar node, and Discovery node should account for delay, staleness, and fail-closed boundaries. The latest sequence returned by trust/v1/status or an equivalent interface can only serve as an observation of index progress and cannot alone prove that a particular on-chain transaction has reached finality.

Existing admission fixtures can verify consistency for active, suspended, and revoked states and governance snapshots, but they are not equivalent to proof of a real chain RPC, GraphQL endpoint, finality, checkpoint recovery, or continuously growing data. Maintenance responsibilities include event-source compatibility, non-regressing cursors, idempotent duplicate-event handling, exception retries, database backups, and state-freshness monitoring; when changing the chain endpoint, do not only change the address while overlooking the linked checks for package, objects, event types, and parsing logic. The interface response of the off-chain trust indexer can only describe the state of its read model. Maintainers should place the event source, last processed cursor, projection time, errors, and chain-endpoint configuration in the same runtime record, and record “on-chain event read”, “off-chain state projected”, and “Root platform adopted this state” separately; a successful health endpoint must not merge the three into one conclusion. An off-chain trust indexer version upgrade should perform at least one small-scope replay or checkpoint-recovery verification: use a known event sequence to check parsing results, cursors, duplicate-event handling, and state projections, then compare the subject, node, credential issuer, and event sequence returned by the API. If the package, object, or event type changes, determine separately whether the old read model can continue to be used; a restarted process with a successful /health response does not establish that historical governance state has been correctly recovered.

F.6 oan-sdk-ts

This repository corresponds to Chapters 4 through 8, Chapter 11, Chapters 15 through 16, and Appendices A through C. packages/sdk-ts/src/index.ts centrally provides resource DID Document drafts, ResourcePackage shape validation, lifecycle checks, registration, discovery, query explanations, capability-label assistance, and governance read interfaces; identity.ts handles Local Identity and resource identity records, key-pair generation, identity-package import/export, and generation of registration materials from an identity; did-oan.ts handles did:oan parsing, normalization, mapping from subject codes to resource types, and semantic conflict checks. packages/protocol-types/src/index.ts provides cross-package protocol types. Tests are located in tests/sdk-core-tests.ts, identity-store-node-tests.ts, and client-workflow-tests.ts.

The SDK is a caller tool, not the authoritative implementation of the Registrar, Root, or Discovery. It can generate keys locally, construct DID Documents and registration materials, call public interfaces, and structurally validate ResourcePackage, but it cannot confirm on-chain finality for the caller and must not treat recommendation results as authorization conclusions. Endpoint stubs, fixed DIDs, and placeholder hashes in tests are used to verify interface behavior; publication examples must replace them with real endpoints, package hashes, authorization domains, and resource descriptions. Private keys and Local Identity packages are stored by the caller and are not sent to OpenAgenet (OAN) nodes.

SDK release maintenance must also check build output, export entry points, Node/browser runtime boundaries, and protocol-version compatibility, to avoid inconsistencies among the README, npm package contents, and source API. The SDK’s public entry points are governed by package.json exports: the root entry, ./client, ./governance, ./protocol-types, and ./identity-store-node correspond to modules in the build output. After changing packages/*/src, check whether npm run build generates the corresponding JavaScript and declaration files, then run tests/sdk-core-tests.ts, tests/client-workflow-tests.ts, and tests/identity-store-node-tests.ts; even if only internal implementation changes but export paths, request fields, or error types change, it should still be treated as a client-compatibility change. SDK mapping should record the boundary between “local generation” and “remote confirmation”: identity, DID Document drafts, ResourcePackage shape, and signature materials can be generated or verified locally by the caller, whereas registration VC, Root proof, Discovery index status, and governance status come from nodes or subsequent caller queries. The existence of an SDK method name does not mean that remote business processing has completed; examples and tests should make clear which responses are supplied by stubs and which require a real Registrar node or Discovery node.

F.7 oan-community-skill

This repository corresponds to Chapter 16 and the community-caller operation paths in Chapters 4 through 8, 11, 15, and 18. Its SKILL.md makes clear that the skill package is used for organizing resource descriptions, managing Local Identity, generating registration materials, submitting to the Registrar node, performing Discovery queries, explaining semantic queries, observing lifecycle, and assisting with read-only governance; it does not start or maintain the Root platform, Registrar node, Discovery node, content distribution platform, NATS, PostgreSQL, or off-chain trust indexer, and it does not perform on-chain governance writes. The implementation description requires continued checking of src/index.ts, validation.ts, registration.ts, resource-description.ts, discovery.ts, lifecycle.ts, capability-assist.ts, and tests/oan-community-skill-tests.ts.

Typical inputs to the community skill package are a resource README, skill-package description, or product description supplied by the user. It first generates candidate registration materials, then reports missing fields and quality issues, requires the user to supplement facts such as name, description, public access address, authorization domain, capability labels, use cases, inputs and outputs, license, and maintainer, and finally calls the SDK’s normal registration path. It must not invent endpoints, maintainers, licenses, or authorization domains, and must not treat capability labels as an authorization scope. For batch resources, report success, skipped items, failures, missing inputs, and next steps item by item; do not silently discard other results because one item failed.

The skill’s maintenance responsibility is to keep user-operation semantics, SDK calls, public endpoint defaults, error classification, and privacy boundaries consistent; a published package must include the scripts, documentation, and resources required for runtime, rather than only TypeScript compilation output. It may call public or explicitly user-provided Registrar, Discovery, and optional trust-query endpoints, but must not expose private node governance materials or read the Root platform’s private indexer. Implementation tracing for the community skill package should start at the public call entry in src/index.ts, follow the inputs and outputs of registration.ts, resource-description.ts, validation.ts, discovery.ts, and lifecycle.ts separately, and then compare them with tests/oan-community-skill-tests.ts and the published-package file list. The skill package organizes and calls; it does not generate unconfirmed facts for the user. Therefore, when adding automatic completion, label suggestions, or retry logic, confirm that inferred content is not written directly into registration materials and that submissions are not repeated unconditionally when the result is unknown. Changes to the community skill package and SDK should also distinguish “helping generate materials” from “writing network facts”. The skill package can organize descriptions, prompt for missing fields, and call public interfaces, but it cannot treat inferred endpoints, labels, authorization domains, or licenses as user-confirmed registration facts; when the request result is unknown, it also cannot create duplicate VCs, duplicate versions, or duplicate publication tasks through unconditional retries.

F.8 Official Website and Public Developer Entry Points

The official website is a public display and operation entry point, corresponding to parts of Chapters 15, 16, 19, 20, 22, and 24. The frontend uses public Registrar, Discovery, Root platform, content distribution platform, and off-chain trust indexer endpoints; the backend provides the aggregation, statistics, access analytics, or proxy capabilities required by the website through /api/* and /health. Production deployment instructions, build and smoke-test scripts, and Nginx and systemd configurations describe build, configuration, reverse-proxy, and verification boundaries. The website’s Home, Register, Discover, Network, and Docs pages can call or display protocol data, but page copy, maps, statistics, cached snapshots, and recommendation ranking belong to the presentation layer.

The website’s registration page can generate or import Local Identity in the browser, construct a DID Document and registration materials, and submit them to a specified Registrar node; private keys must not be sent to the website backend. The discovery page can submit a DID or natural-language task description and display candidate resources and DID Document previews returned by the Discovery node; users must still perform final verification based on the resource DID, VC, Root proof, status, and endpoints. When the Network page displays nodes and metrics, it should distinguish current real-time data, old snapshots, unknown status, and statistical aggregation, and must not treat UI state as governance authority.

Hard checks for website deployment maintenance include: production frontend build variables must not retain local-machine addresses; the backend should be exposed only through a reverse proxy; static assets and backend versions must match; public HTTPS, language switching, registration transmission, discovery queries, the Network summary, and browser routes must all pass smoke tests. SEO, access statistics, and page caching can only be loosely coupled enhancements and must not change the protocol behavior of registration, discovery, governance, or node services. Website issue diagnosis should first distinguish the browser layer, website backend aggregation layer, and node-service layer: frontend pages and frontend/src/api.ts initiate requests and present results; backend backend/src/http/router.rs and the corresponding handlers provide public aggregation interfaces; the Registrar node and Discovery node are the direct handlers of registration/discovery business logic. When access-statistics writes, SEO metadata, browser caching, or old-snapshot reads fail, the page may degrade or omit the record, but must not block registration submission, discovery queries, or node-status judgment; any cross-layer change must run page-route, public-interface, and node-business smoke tests separately. The change boundary between website components and protocol implementation can be checked by interface direction: /api/* from the browser to the website backend is a public aggregation or proxy path, requests from the website backend to nodes are service-to-service calls, and the node’s own /resources/register and /discovery/resources/query are the protocol business entry points. When changing website caching, statistics, SEO, or page copy, verify that failures in these features do not change node request bodies, response semantics, registration/discovery results, or governance status; when changing node interfaces, do not perform only web regression testing while skipping protocol and client tests.

F.9 Specification Chapter and Implementation Module Mapping

The following table provides the primary index for maintenance and release work. Chapter numbers are the entry points for specification responsibility; specific implementations still need to be checked against the preceding repository sections, the current commit, and the target deployment configuration.

Cross-index maintenance follows four rules: first, when adding or modifying a shared field, update the specification and oan-protocol-common first, then check all production services and clients; second, when adding an interface, update the error contract, SDK, community skill package, and fixed request examples at the same time; third, governance status, Root proof, and semantic matching must retain their respective sources of fact and must not be merged in an aggregation layer into an unexplained “trusted” boolean; fourth, passing deployment scripts and smoke tests only proves that the target environment met the conditions checked at that time and must not turn environment variables, domain names, models, node counts, or database selections into fixed protocol requirements.

When implementation and specification diverge, maintainers should state in the change record the affected chapters, input/output differences, compatibility strategy, test evidence, whether data migration is created, and rollback method. Only when code, tests, configuration, and runtime verification jointly support it may “Reference / to be verified” be promoted to “Implemented”; any aggregate result that lacks a source of fact, verification subject, or status boundary can only be observation information and cannot serve as cross-node trust proof.

The minimum tracking record for a cross-repository change can be established in the following order:

Chapter or field change
  -> oan-protocol-common types/validation/errors
  -> Root, Registrar, Discovery, or indexer call paths
  -> SDK and community Skill inputs and outputs
  -> fixtures, unit tests, and integration tests
  -> configuration, systemd/reverse proxy, and deployment smoke tests
  -> compatibility conclusion, release commit, and rollback basis

If a change concerns only website copy, SEO, or access statistics, explicitly record it as a presentation-layer website change and do not list it as a protocol-version change; if a change concerns protocol fields, DID Document, ResourcePackage, authorization domain, error codes, or lifecycle status, it must return to the shared types and all consumers for item-by-item verification. This tracking chain is for maintenance and review and does not change the original responsibility boundaries of the repositories.

“Implemented” in the cross-index should be based on the minimum evidence set: the corresponding code entry point is locatable, there is at least one targeted test or repeatable check, the runtime configuration can resolve the required dependencies, and there is no conflict with current protocol fields or error contracts. If a directory only contains a file but has no call path, test result, or runtime configuration, it should remain “Reference / to be verified”; if only test fixtures pass without service integration, it should be marked “Evaluation support” or “Partially implemented” and must not be promoted directly to production capability.

References