This chapter explains how conformance profiles turn each requirement into a “test object, input, steps, criteria, evidence, and conclusion,” and do not label untested capabilities as conformant. The offline materials that can currently be reused directly are in oan-third-party-node-admission-test-kit/fixtures/v1-alpha, where the manifest, case matrix, expected fixtures, and requirement checks form an auditable baseline; the real Root platform, content distribution platform, on-chain governance, and production recovery should be identified separately.

Conformance review presupposes an isolated test environment, fixed test vectors, a clearly specified specification version, and results that can be retained as evidence. A profile’s “pass” means only that the corresponding role has completed the prescribed capability and rejection-behavior tests; it does not automatically prove that the entire OpenAgenet (OAN) network or the quality of a resource business has passed. Test records should reproduce the inputs, steps, responses, logs, versions, and determinations.

The applicable scope of a profile should be stated clearly at the beginning of the report, for example, “resource provider - ResourcePackage generation,” “Registrar node - registration interface,” and “Discovery node - query and indexing.” The same test resource may run through multiple profiles, but each role is responsible only for the facts it produces or verifies; the state of a test resource during registration, publication, distribution, and discovery should be correlated through the DID, version, digest, and request identifier, rather than by name alone.

23.1 Resource Provider Conformance Profile

A resource provider should be able to generate or import a Local Identity, create a resource DID, form a valid DID Document, resource metadata, and ResourcePackage, and sign them with the local control key. Acceptance tests cover the required fields, capability tags, use cases, endpoints, versions, and digests of four resource types; qualifying evidence consists of verifiable signature materials, structured inputs, and rejection results for invalid inputs. Private keys must not appear in upload requests or logs.

The acceptance order should be fixed as “identity available -> DID Document generation -> metadata validation -> ResourcePackage digest and signature -> submission-material check.” If any step fails, the materials must not continue to be marked as publishable; test records should be associated with the resource DID, test vector, and specification version.

The resource provider’s pass condition is not “a webpage can download a file,” but the ability to reconstruct the same materials locally and verify the control relationship. Test personnel should retain at least one valid set of materials, one set missing a required field, and one set with a modified signature or digest, and check the generation result, explicit error, and no-side-effect result respectively.

23.2 Registrar Node Conformance Profile

Using an isolated test identity, submit valid materials, materials with missing fields, materials with invalid signatures, materials from an unauthorized node, duplicate materials, and expired materials, and check the Registrar node’s status codes, error structures, registration records, idempotent results, VC (if any), and upstream submission. The qualifying condition is that only valid requests within the authorized scope are accepted, rejected requests do not change the state of valid resources, and the processing path can be reviewed using logs and correlation identifiers.

Registrar node acceptance should cover at least the following request sequence:

1. Submit valid materials and confirm the response structure, registration state, and correlation request identifier.
2. Resubmit the same DID, version, and digest and confirm an idempotent result that does not produce a second valid registration fact.
3. Replace the control signature, node authorization, or resource digest and confirm that the request is rejected and the original registration remains unchanged.
4. Submit expired materials or materials outside the authorized scope and confirm that the rejection reasons are distinguishable.
5. Check the failure state, retry boundary, and pending record when the upstream is temporarily unavailable.

For every request, retain the normalized request digest from the sending side and the correlation identifier returned by the Registrar node; for asynchronous upstream calls, record “accepted by the Registrar node” and “processed by the Root platform” as two independent records. If no registration VC is present in a successful response, record that the field is missing or was not returned rather than fabricating a credential in the acceptance materials.

23.3 Root Platform Conformance Profile

Validate valid and tampered ResourcePackages, control proofs, Registrar node authorization, version sequences, and digests. The Root platform forms a Root proof for a trusted publication only when the control relationship, node authorization, content integrity, and governance conditions are all satisfied; repeated publication should be idempotent, and rejection or asynchronous failure must not produce a publication fact that a Discovery node could treat as a valid version.

Root platform acceptance uses a four-step check: “validate inputs, determine eligibility, form the publication fact, and read the result again”:

• [ ] The control signature binds the resource DID, version, and content to be published.
• [ ] Registrar node authorization is valid, and the submission scope matches the authorization scope.
• [ ] The ResourcePackage, DID Document, and digest validate against one another.
• [ ] The version sequence has no rollback, unexplained gap, or unexplainable fork.
• [ ] The issuer, subject, covered content, and status of the Root proof are verifiable.
• [ ] Rejection, duplication, and asynchronous failure do not generate a valid publication record.

Acceptance evidence should retain both the initial processing result and the publication status obtained by a subsequent query, so that “request received,” “validation passed,” “publication fact formed,” and “indexed by a Discovery node” can be distinguished as separate stages.

The key criterion for the Root platform profile is that “rejected input must not form a valid publication fact that can propagate.” Therefore, in addition to checking interface responses, test personnel should reread the publication record, content distribution manifest, or publication sequence, and confirm that an incorrect digest, incorrect control signature, or out-of-scope Registrar node has not entered a subsequent queue; these checks should use independent test resources and request identifiers.

23.4 Content Distribution Service Conformance Profile

Deliver complete packages, incomplete packages, incorrect digests, duplicate batches, checkpoint cursors, and old versions to the content distribution platform, and check the manifest, response, receipt cursor, integrity, and audit records. The qualifying condition is that only materials permitted by the Root platform are delivered, duplication and checkpointing do not lose content or repeatedly change facts, and the receiver can verify the content using the digest and proof.

At the end of testing, recheck the receiver’s content against the manifest and digest, and record the delivery batch, cursor, response time, retry count, and final state. Successful distribution means only that the content can be retrieved and verified; it does not replace the Root proof.

Checkpoint and duplicate tests should be run again after restarting the receiver or interrupting the network, to check whether the persisted cursor still points to the last confirmed batch. If the receiver has saved the content but not the corresponding proof or cursor, treat it as an incomplete distribution state and do not directly hand it to a Discovery node for establishing a trusted index.

23.5 Discovery Node Conformance Profile

First perform full and incremental synchronization, then use published test resources for DID, structured, and semantic queries, while adding duplicate materials, old versions, revoked states, sequence gaps, and expired data. The qualifying condition is that indexing occurs only after validation, the latest valid version is selected by default for the same DID, results are not duplicated, provenance and freshness are returned, and relevance does not override control or governance checks.

The Discovery node test sequence is as follows:

1. Check the resource count, versions, and digests after full synchronization.
2. Inject an incremental publication and confirm that only the corresponding index record is added or updated.
3. Perform an exact DID query, a structured-condition query, and a semantic query separately.
4. Add duplicate materials, an old version, a revoked resource, and an expired snapshot, and check filtering and deduplication.
5. Verify the source node, version, freshness, and publication-evidence reference in the results.

Multiple records for the same DID should be selected deterministically according to version and publication status; when freshness, governance status, or publication evidence cannot be confirmed, mark the result as uncertain and hand it to the caller for review.

Query acceptance for the Discovery node profile should use the same set of published resources to cover six result categories: “exact hit, structured hit, semantic hit, duplicate record, old version, and invisible resource.” The report should record the query input, filter conditions, returned resource DID, version, source, index time, and duplicate count, rather than recording only the total number of results.

23.6 Off-Chain Trust Indexer Conformance Profile

Provide sequential governance events, a checkpoint, duplicate events, missing events, and temporarily unavailable upstream data, and check the authorization-state read model, event cursor, latency, and error state. The qualifying condition is correct ordering and idempotency, recovery from the cursor after restart, and no treatment of unread events or manual displays as on-chain facts; evidence includes event positions, cursors, and projection records.

The “state updated” status of the off-chain trust indexer must point back to a governance event or an explicit upstream proof; the existence of a projection record in the database alone cannot serve as a governance fact.

When test events arrive continuously, check event order, duplicate events, and sequence gaps separately; when latest_sequence temporarily stops increasing, use the most recent successful read time and error state to determine whether there are “no new events” or synchronization has “stalled.” A test can be recorded as passed only when the cursor, event position, and authorization-state read model correspond to one another.

23.7 Parser and Client Conformance Profile

Use inputs consisting of a valid DID, an unknown DID, an unsupported method, an invalid structure, an incorrect control signature, an abnormal status, a historical version, and a missing proof, and check the result types and stop behavior. The qualifying condition is distinguishable errors, no silent acceptance of invalid materials, no presentation of a historical version as the current version, and availability of the original document, digest, and error information for review.

Acceptance should also check that error paths do not mislabel partial resolution results as trusted resources, and do not bypass control, credential-status, or governance-status checks through automatic retries.

23.8 SDK Conformance Profile

The SDK should cover Local Identity, resource DID, metadata, control signatures, registration, exact DID discovery, semantic discovery, VC verification, and Root proof verification. Use the test inputs for oan-sdk-ts to check serialization, error mapping, and cross-environment endpoint configuration; the qualifying condition is that the SDK does not upload private keys, does not lose version or evidence fields, and enables callers to distinguish registration success from discoverability.

SDK acceptance checklist:

• [ ] The results of creating and importing a Local Identity can be reviewed, and the private key does not enter network requests.
• [ ] When generating a resource DID, DID Document, and signature, the fields are consistent with the Rust protocol types.
• [ ] Registration success, registration failure, and “not yet discoverable” map to different results.
• [ ] Exact DID queries and semantic queries retain source, version, and freshness information.
• [ ] Verification results for the VC, Root proof, and governance status are not merged into a single Boolean.
• [ ] Network errors, server errors, and format errors can be distinguished by the caller.

Cross-environment tests should use fixed node endpoint configuration and test vectors; one online address or one successful request cannot serve as proof of the SDK’s permanent compatibility. The test report should also record the SDK unit tests, node integration tests, and actual requests to the official website separately, so that local object-test results are not mistakenly written as end-to-end interoperability results. The acceptance conclusion should be associated with at least the SDK commit, protocol public type version, test vector, target endpoint, and response digest.

23.9 Security and Key Custody Acceptance Criteria

Test the generation, storage, backup, recovery, rotation, and permission boundaries of subject, resource, and node keys, and check the verification of signatures, VCs, and Root proofs. The qualifying condition is that private keys are used only within the controller’s boundary, backups are recoverable and protected, and incorrect keys and unauthorized signatures are rejected; evidence should be redacted and must not submit the private key in plaintext.

Security acceptance task checklist:

• [ ] Establish the usage boundaries of the subject private key, resource control private key, and node runtime credentials.
• [ ] Check the generation, import, permissions, and recovery result of backup files, without writing private keys to logs or request bodies.
• [ ] Perform rejection tests using an incorrect public key, an incorrect signature, and a signature from another subject.
• [ ] Verify the issuer, subject, signature coverage, and status of the VC and Root proof.
• [ ] Check whether sensitive fields in exceptions, debug logs, and evidence packages have been redacted.

The test report should make clear that “the controller can sign” and “the service node can verify” are two different facts; the latter does not mean that the node has obtained the former’s private key. Security acceptance should treat the client, Registrar node, Root platform, Discovery node, and evidence storage as separate observation boundaries, and record item by item whether private keys appear in request bodies, logs, temporary files, error stacks, or test archives. Control signatures, registration VCs, and Root proofs should each be separately checked for issuer, subject, signature coverage, and status.

23.10 Interoperability and Compatibility Acceptance Criteria

Use the same set of vectors for Rust protocol types, the TypeScript SDK, the official website API, the Registrar node, the Discovery node, and A2A/MCP mappings, and compare DID Documents, ResourcePackages, digests, signatures, errors, and version results. The qualifying condition is consistent normalization and field semantics across languages, with mappings retaining provenance and without weakening OAN control and governance verification through adaptation.

Cross-language comparison must use the same version, input, and normalization rules; comparing only the final page text cannot prove protocol interoperability. The interoperability conclusion should also distinguish three levels: “the same input produces the same object,” “different implementations can parse the object,” and “the cross-node end-to-end flow succeeds.” Record the corresponding evidence separately; do not determine interoperability passed merely because the final page displays the same text.

Cross-language acceptance may use the method of “one fixture, three comparisons”: first compare the normalized results of the Rust protocol types and TypeScript objects, then compare the HTTP request sent by the SDK or official website with the result actually parsed by the node, and finally compare the resource DID, version, and digest throughout the registration, publication, and discovery paths. Any difference at any level should record the differing field and applicable version, and must not be attributed to a network problem alone.

23.11 Performance and Availability Acceptance Criteria

Measure the success rate, latency, backlog, recovery time, and resource consumption of registration, publication, synchronization, query, and governance reads in a test environment with clearly defined concurrency, resource scale, network conditions, and statistical windows. Thresholds should be defined in advance in the profile or deployment acceptance record; without measurement data, the result can only be marked as not tested, and the performance of one demonstration must not be written as a general performance commitment.

The report should distinguish at least the cold-start, steady-state, and failure-recovery windows, and should provide the environment, data scale, concurrency, and statistical method at the same time.

Performance results should state whether they include network round trips, database writes, semantic retrieval, and waiting for asynchronous propagation; registration interface latency cannot directly represent network-wide resource visibility latency, and query hit rate cannot directly represent semantic quality. When timeouts, retries, or partial failures occur, also report the request count, failure classification, and final state after recovery. The minimum directory for an evidence package may be fixed as:

evidence/
  manifest.json
  spec-and-profile/
  fixtures/
  requests-and-responses/
  logs-and-metrics/
  deployment/
  review-and-result/

manifest.json should list the digest, source, generation time, test environment, and corresponding clauses for each material; the directory structure specifies only how evidence is organized and does not require production configuration or sensitive data to be made public.

The evidence manifest may use the following record format that contains no secrets:

{
  "profile": "discovery-node",
  "profileVersion": "v1-alpha",
  "implementationCommit": "<git-commit>",
  "fixtureId": "valid-resource-v1",
  "environment": "isolated-test",
  "result": "PASS",
  "artifacts": [
    {"path": "requests-and-responses/query.json", "sha256": "<digest>"},
    {"path": "logs-and-metrics/discovery.log", "sha256": "<digest>"}
  ],
  "reviewedAt": "<timestamp>"
}

The angle-bracketed content consists of placeholder values in the evidence-manifest template; a formal report should replace them with the actual commit, digest, and time, but must not write private keys, database credentials, or unredacted internal endpoints.

23.12 Evidence Required for Conformance Implementation

Review materials should include at least the specification and protocol versions, code commit, configuration digest, test vectors, interface requests and responses, logs, metrics, deployment records, and failure handling. Submit sensitive content as digests, redacted excerpts, or through controlled viewing; evidence must identify the test time, environment, operator, tool version, and covered clauses.

23.12.1 Protocol and Data-Structure Evidence

Provide examples of DIDs, DID Documents, resource metadata, ResourcePackages, VCs, Root proofs, and API responses, identify the schema, normalization, version, and content digest, and explain the expected results of valid, missing, and invalid examples. Each data sample should identify at least fixtureId, object type, schema/profile version, normalization method, content digest, expected conclusion, and covered clause; valid samples and negative samples should be retained in pairs.

Protocol evidence should also cover HTTP methods and paths, the deserialization type of request JSON, response types or dynamic fields, error status, and key validation results. For registration, Root platform validation and publication, content distribution, and discovery queries, retain at least one valid request and one key failed request with its response for each. Shared types should be traceable to oan-protocol-common, and node-local types and dynamic JSON should be traceable to the corresponding handler. Retaining only an interface address or one successful screenshot cannot prove that the input/output contract is complete.

23.12.2 Cryptographic and Identity Evidence

Provide public keys, signatures, verification methods, control relationships, credential issuers, and verification results; provide private keys only as evidence of existence or a digest in a controlled test environment. The materials should prove the object covered by the signature and the target DID, rather than merely displaying a signature string. Cryptographic evidence should allow recomputation of the normalized object covered by the signature and the source of the public key used for verification, and should record the verification results for the control signature, registration VC, and Root proof separately.

23.12.3 Node-Behavior Evidence

Provide requests and responses, events, cursors, logs, and timelines for registration, Root platform publication, distribution, discovery, governance synchronization, and error handling, associated with the resource DID, version, and request identifier. For asynchronous flows, also record stages such as “received, verified, published, and indexed”; do not retain only the last successful response.

23.12.4 Deployment and Smoke-Test Evidence

Provide the source commit, build artifacts, configuration digest, service health, database status, registration and discovery smoke-test results, and failure-handling records. Public materials should be redacted, and production keys and internal management endpoints must not be included in the evidence. Deployment evidence should at least link the source commit, build artifacts, runtime configuration, and smoke-test results; the smoke test should include one success path and one expected failure path.

23.12.5 Version and Provenance Evidence

Provide the code commit, lock files, schema/protocol version, ResourcePackage and proof digests, artifact hashes, and publication records, so that reviewers can confirm that the test object and deployment object came from the same source. Provenance checking should at least compare the code commit, dependency lock files, build-artifact digest, and runtime version identifier; when the objects do not match, they must not be considered the same test conclusion.

23.13 Test Vectors and Interoperability Fixtures

Test fixtures should fix valid DIDs, DID Documents, resource metadata, ResourcePackages, hashes, control signatures, registration VCs, Root proofs, governance events, and invalid inputs, and provide forms readable by Rust, TypeScript, or JSON. Each vector should be marked with the expected success/failure, version, digest, and covered clause, avoiding dependence on live public-network data.

The recommended fixed-fixture record form is as follows:

{
  "fixtureId": "valid-resource-v1",
  "input": "resource-package.json",
  "expected": "PASS",
  "schemaVersion": "<version>",
  "contentHash": "sha256:<value>",
  "covers": ["23.1", "23.3", "23.10"]
}

The same fixtureId should point to the same original input in Rust, TypeScript, and HTTP tests; if the adaptation layer must convert it, retain the digests before and after conversion and the conversion rules at the same time.

23.14 Negative Tests and Rejection Behavior

Negative tests cover invalid DIDs, missing fields, incorrect signatures, unauthorized nodes, expired or revoked credentials, old versions, duplicate requests, incorrect digests, malicious endpoints, and sequence gaps. Acceptance checks not only the returned error, but also confirms that there are no side effects such as writing an invalid index, generating an incorrect publication proof, advancing a cursor, or leaking secrets.

Each negative test must check the response, database or index changes, event cursor, sensitive information in logs, and subsequent query results at the same time.

23.15 Conformance Evidence Retention and Review

Archive evidence by specification version, code commit, environment, time, operator, and test fixture. When a change affects the protocol, schema, signature, governance, node behavior, or deployment path, the relevant profile must be retested. The review conclusion should state pass, fail, not tested, or conditional pass, and must not conceal a key failure behind a single overall score.

The review conclusion should also distinguish “node profile passed,” “end-to-end path passed,” and “production deployment passed,” so that a local test result is not overgeneralized as conformance of the entire network.

References