Skip to main content
Version: Stage 5 - Deliverable Acceptance Check

Pilot Test Sandbox

Project Working Document

This folder contains synthetic test material used only for pilot demonstration and verification. It is not operational registry data and is not part of the GRID project deliverables.

1. Purpose​

The Sandbox provides an executable, jurisdiction-neutral test environment for the GRID pilot. It is intended to demonstrate not only the happy path, but also the lifecycle, failure and ambiguity cases that a real pilot needs to understand.

The Sandbox complements:

The generated Sandbox GRID shows the current synthetic Registrar records produced by the build.

2. Cross-Border Supply-Chain Exemplar​

The canonical exemplar is a two-jurisdiction commercial-invoice verification flow involving:

  1. two synthetic Authoritative Registrars;
  2. a supplier/exporter in Jurisdiction A;
  3. a buyer/importer in Jurisdiction B;
  4. a commercial invoice;
  5. GRID discovery of the authoritative Registrar(s);
  6. DIA-based identity evidence where the participating Registrar supports it; and
  7. independent relying-party verification.

The companion machine-readable manifest is stored at supply-chain-exemplar.yaml.

The exemplar is deliberately small enough to execute quickly while still separating the distinct propositions that a relying party may need to evaluate.

3. Pilot Hypothesis​

The minimum hypothesis is:

A relying party in one jurisdiction can use GRID to discover the authoritative Registrar responsible for a foreign organisation identifier, authenticate the relevant GRID/Registrar trust path, and verify whether the organisation identity represented in a commercial invoice corresponds to authoritative registration evidence, without treating GRID or the DIA as proof that the commercial transaction itself is truthful.

Secondary questions include whether the same process works reciprocally for the buyer, how lifecycle/status changes are represented, how failures become visible, and whether historical verification can be performed from retained evidence.

4. Trust and Assertion Levels​

The scenario keeps the following levels separate:

  • Registrar-authoritative assertion: a fact or status for which the Registrar is the competent source for the relevant register purpose.
  • GRID participation/discovery assertion: evidence that the Registrar is discoverable/onboarded in GRID and that GRID authenticated the participant-origin material according to the pilot process.
  • DIA binding assertion: evidence issued under the applicable DIA model linking an authoritative entity identifier to the represented subject/cryptographic identifier.
  • Participant business assertion: statements made by supplier, buyer or another business actor in a commercial document.
  • External authority/conformance assertion: claims made by another competent authority or credential issuer, for example certificate-of-origin or conformity evidence.

Verification of one level does not automatically prove the others.

5. Synthetic Actors​

The machine-readable manifest defines the canonical synthetic actors. At a minimum:

  • Supplier/Exporter: Meridian Components Ltd, represented by synthetic authoritative identifier AA.CORP.10000001.
  • Buyer/Importer: Northstar Manufacturing Ltd, represented by synthetic authoritative identifier BB.CORP.20000001.
  • Registrar A: AA Corporate Registry.
  • Registrar B: BB Companies Authority.
  • GRID Pilot: discovery and pilot trust layer.
  • GRID/UNICC Pilot Operations: GRID-side pilot operator.
  • Relying Party: an independent verifier of the business document and identity evidence.

Optional actors can include carrier, certificate issuer, product/conformity credential issuer or trade-finance relying party.

6. Mandatory Business Document​

The minimum exemplar uses one commercial invoice. A canonical synthetic representation can contain:

{
  "invoiceId": "INV-2026-0001",
  "issueDate": "2026-09-22",
  "seller": {
    "name": "Meridian Components Ltd",
    "identifier": "AA.CORP.10000001"
  },
  "buyer": {
    "name": "Northstar Manufacturing Ltd",
    "identifier": "BB.CORP.20000001"
  },
  "currency": "USD",
  "totalAmount": 25000,
  "items": [
    {
      "productCode": "BCM-400",
      "description": "Industrial battery control module",
      "quantity": 100
    }
  ]
}

This document is a business assertion. Its presence, signature or identity references do not by themselves prove the underlying shipment, price, product quality or authority of a person to bind an organisation.

7. Optional Extensions​

A live pilot can extend the scenario with:

  • purchase order;
  • packing list;
  • transport document / bill of lading;
  • certificate of origin;
  • Digital Product Passport;
  • Digital Conformance Credential;
  • Digital Facility Record;
  • carrier identity;
  • exporter/importer or trader identifiers; or
  • trade-finance relying-party checks.

Extensions should preserve the same separation of trust propositions and should identify the authoritative source for each new claim.

8. End-to-End Verification Sequence​

Phase 1: Registrar onboarding​

  1. Registrar A and Registrar B complete the applicable G0-G5 participant steps.
  2. GRID authenticates and harvests their Registrar material.
  3. Both appear in the Sandbox/GRID directory with the correct verification state.

Phase 2: Organisation registration and DIA evidence​

  1. Supplier and buyer are represented by authoritative identifiers in their respective synthetic registers.
  2. Where DIA issuance is in scope, the relevant Registrar issues or exposes the applicable identity evidence.
  3. The authoritative organisation identifier remains distinguishable from the cryptographic identifier.

Phase 3: Business document issue​

The supplier produces the commercial invoice containing its organisation identifier and the buyer identifier.

Phase 4: Relying-party verification​

The relying party:

  1. extracts the supplier identifier from the invoice;
  2. determines which Registrar/register is authoritative for that identifier;
  3. discovers the Registrar through GRID;
  4. confirms the GRID/Registrar source-authentication state;
  5. retrieves the DIA or equivalent Registrar-verification evidence where applicable;
  6. verifies the identity evidence cryptographically;
  7. compares the authoritative identifier and organisation name with the invoice; and
  8. records which propositions are verified, not verified, indeterminate or outside the scope of the identity check.

Phase 5: Reciprocal verification​

Repeat the relevant identity checks for the buyer where the pilot scope includes reciprocal verification.

9. Verification Questions​

A successful test should answer, where applicable:

  • Which Authoritative Registrar is responsible for the supplier identifier?
  • Is that Registrar discoverable through GRID?
  • Did GRID authenticate the participant-origin material used for the current record?
  • Is the Registrar status appropriate for the time being evaluated?
  • Does the DIA or equivalent identity evidence verify cryptographically?
  • Does the identifier in the invoice match the authoritative identifier represented by the identity evidence?
  • Does the organisation name correspond under the comparison rules used by the test?
  • Is buyer identity verified in the same way where reciprocal verification is required?
  • What claims remain business assertions rather than Registrar-verified facts?
  • Can the verifier distinguish a current-state result from a historical/as-of result?

10. Result Vocabulary​

Use a result vocabulary that does not collapse missing evidence into a positive or negative answer:

  • VERIFIED: the required checks were performed and the available evidence supports the proposition being tested.
  • NOT VERIFIED: a required check failed or the evidence contradicts the proposition.
  • INDETERMINATE: the available evidence is insufficient to determine the proposition, including historical cases where required prior state cannot be reconstructed.
  • NOT APPLICABLE: the check is outside the scope of the scenario/test.

The result must identify the proposition being evaluated. "Verified" should never be used as a generic statement that the entire trade transaction is trustworthy.

11. Mandatory Test Catalogue​

TC-SC-001: Discover Supplier Registrar​

Purpose: Resolve the supplier's authoritative register/Registrar from the identifier and GRID data.

Expected: The correct Registrar is found and the basis for treating it as authoritative is visible.

TC-SC-002: Verify GRID Source Authentication​

Purpose: Confirm that GRID's participant record is based on participant-origin material authenticated according to the pilot process.

Expected: Verification evidence identifies the participant source and successful authentication state.

TC-SC-003: Resolve Supplier DIA​

Purpose: Retrieve the supplier DIA where DIA capability is in scope.

Expected: The correct identity artefact is retrieved; absence is explicit where the profile does not provide one.

TC-SC-004: Verify Supplier DIA Cryptographically​

Expected: Proof verification succeeds using the trust material applicable to the pilot.

TC-SC-005: Match Invoice Identifier to DIA​

Expected: The invoice supplier identifier matches the authoritative identifier represented by the identity evidence.

TC-SC-006: Match Organisation Name​

Expected: The comparison rule produces the documented result and does not override identifier mismatch.

TC-SC-007: Verify Buyer Identity Reciprocally​

Expected: Buyer identity can be checked using the same trust separation where reciprocal verification is in scope.

TC-SC-008: Unknown Supplier Identifier​

Expected: No false authoritative match is produced. Result is NOT VERIFIED or INDETERMINATE according to the available evidence.

TC-SC-009: Identifier / DIA Mismatch​

Expected: A valid DIA for a different identifier does not satisfy the invoice identity check.

TC-SC-010: Valid DIA for Wrong Organisation​

Expected: Cryptographic validity alone does not satisfy the organisation-identity proposition.

TC-SC-011: Invalid DIA Signature​

Expected: Identity evidence fails verification and is not treated as valid.

TC-SC-012: Unknown Registrar​

Expected: GRID does not invent or infer authoritative status.

TC-SC-013: Registrar Inactive or Withdrawn​

Expected: The result reflects the applicable status semantics and time being evaluated.

TC-SC-014: Historical Verification​

Expected: The verifier evaluates the state applicable to the historical transaction/verification question using retained evidence. If that state cannot be reconstructed, the result is INDETERMINATE.

TC-SC-015: Registrar Metadata Update​

Expected: An authenticated update is republished, harvested and reflected with traceable evidence.

TC-SC-016: Supplier DID or Cryptographic-Identifier Change​

Expected: The pilot distinguishes control change from legal-identity change and records the applicable binding/rotation evidence.

TC-SC-017: Duplicate or Conflicting Identifier​

Expected: Ambiguity is surfaced rather than silently selecting an authoritative result without basis.

TC-SC-018: Invoice Without DIA Reference​

Expected: The verifier can still use GRID/Registrar discovery and available source mechanisms; lack of a DIA link is not silently treated as verification success.

TC-SC-019: DIA Absent but Registrar Supports Query/Resolver​

Expected: The available authoritative-verification path is tested and the absence of DIA is represented accurately.

TC-SC-020: Registrar Has No DIA Capability​

Expected: GRID discovery can still succeed while the DIA-specific check is NOT APPLICABLE or unavailable.

TC-SC-021: Stale GRID Snapshot​

Expected: The verifier can identify freshness/staleness and does not silently equate stale data with current state.

TC-SC-022: GRID Temporarily Unavailable​

Expected: The test documents what verification remains possible from participant/retained evidence and what becomes unavailable.

TC-SC-023: Participant Registrar Endpoint Unavailable​

Expected: Failure, timeout/retry and stale-state behaviour are visible.

TC-SC-024: Supplier Name Typo with Correct Identifier​

Expected: Name comparison is handled by the documented rule and does not erase the authoritative identifier relationship.

TC-SC-025: Valid Organisation, Fraudulent Invoice​

Expected: Organisation identity may verify while the invoice truth proposition remains unverified. This test demonstrates the limit of identity assurance.

Expected: Control of the presented cryptographic key is not treated as proof of underlying legal registration without the Registrar binding.

TC-SC-027: Authority to Act / Delegated Representative​

Expected: Organisation identity verification does not, by itself, prove that a person or agent was authorised to issue/accept the transaction.

TC-SC-028: Merger / Successor Entity​

Expected: Predecessor and successor identifiers/states remain distinguishable and the relationship is based on an authoritative source, not merely shared key/domain/operator continuity.

TC-SC-029: Entity Termination​

Expected: Current termination/lapse and historical prior validity can be represented as different propositions.

TC-SC-030: Schema Version Compatibility​

Expected: Supported versions parse explicitly, unsupported versions fail explicitly, and historical artefacts retain the schema context needed for interpretation.

12. Extended Document Tests​

Optional extensions can test cross-document supplier identity consistency, carrier identity, certificate-issuer identity, Digital Product Passport issuer identity, Digital Conformance Credential issuer identity and facility-record linkage.

These tests should be introduced only when the relevant document/credential is in the pilot scope.

13. Identity Comparison Rules​

13.1 Identifier comparison​

The primary organisation match should use the authoritative identifier appropriate to the register/scheme. Normalisation rules, if required, must be explicit and deterministic. A different identifier must not be treated as equivalent merely because the organisation name looks similar.

13.2 Organisation-name comparison​

Name comparison can support human review but should not silently override an identifier mismatch. Record exact-match, normalised-match or mismatch behaviour and any locale-specific handling used by the test.

14. Historical and Status Semantics​

For historical tests record:

  • transaction time;
  • verification time;
  • relevant status-effective period;
  • source of status evidence;
  • verification/key material applicable to that period; and
  • later events that change current state without rewriting the historical record.

The test should distinguish a historical observation, an effective historical state and a present determination about that historical state.

15. Privacy and Data Minimisation​

The Sandbox uses synthetic data. Live pilots should retain the same minimisation principle and should avoid introducing personal/sensitive information merely to make an identity test realistic.

Test evidence should reference authoritative logs and artefacts where possible instead of copying sensitive data into issues or reports.

16. Security Considerations​

Do not place private keys or secret token values in the Sandbox, test manifests, screenshots, test reports or issue descriptions.

Negative tests involving signatures, keys, endpoint outages or malformed data should use controlled test paths and must not compromise the main pilot state.

17. Acceptance Criteria​

The minimum supply-chain exemplar is complete when:

  • both synthetic Registrars are discoverable through GRID;
  • participant-source authentication is demonstrated;
  • supplier identity evidence is retrieved and verified where applicable;
  • invoice supplier identifier comparison is completed;
  • at least one negative identity case has been exercised;
  • relying-party output distinguishes verified identity propositions from unverified business assertions;
  • lifecycle/status behaviour relevant to the pilot is recorded; and
  • evidence is retained for the test results.

A live pilot should extend this with the G7 lifecycle/failure cases and G8 operating evidence from the Participant Guide.

18. Verification Report Template​

GRID Supply Chain Verification Report

Document:
Transaction/issue time:
Verification time:

Supplier identity
- Identifier:
- Authoritative Registrar:
- GRID discovery result:
- GRID source-authentication result:
- DIA/equivalent evidence result:
- Identifier comparison:
- Name comparison:
- Supplier identity result:

Buyer identity
- Result:

Additional credentials
- Result(s):

Claims not verified
- ...

Exceptions
- ...

Evidence
- source commit/reference:
- GRID harvest/run:
- DIA/reference/hash:
- test-case IDs:

Overall result for the defined verification proposition:
VERIFIED / NOT VERIFIED / INDETERMINATE / NOT APPLICABLE

19. Adapting the Exemplar to a Live Pilot​

Replace only the jurisdiction, Registrar, organisation, identifiers, endpoints and capability values that have actually been agreed by the participating pilot. Preserve the test IDs and core verification propositions where practical so results remain comparable across pilots.

The manifest contains real_world_mapping and execution-specific fields that are intentionally empty until an actual pilot mapping is approved.