Pilots

Project Working Document

This document and the documents within this folder are working documents for the project. They provide supporting information for project participants and viewers. They are not part of the project deliverables.

GRID Test Pilots

The GRID pilots are intended to test whether the proposed Global Registry Information Directory can provide a lightweight, decentralised discovery and trust layer for Authoritative Registrars while preserving national control of source data and registry operations.

Pilot participation allows Authoritative Registrars and other participants to explore the technical, operational, legal and business implications of GRID participation before production design decisions are made.

Pilot participation should remain deliberately lightweight. Pilot environments:

1. MUST NOT be part of, or impact, operational solutions.
2. MUST support low-cost, high-velocity iteration.
3. MUST use synthetic or otherwise approved test data, not operational or sensitive data by default.
4. MUST use accessible technology platforms appropriate to experimentation.
5. MUST follow the core design principles of the GRID.
6. MUST keep pilot controls and pilot results distinguishable from production assurance.

The majority of pilot effort is expected to involve stakeholder agreement, governance, test design and interpretation rather than infrastructure build.

How the Pilot Material Fits Together

The Pilot documentation is intentionally organised around four existing surfaces rather than a growing set of standalone documents:

• Pilot Design Architecture explains the pilot architecture, trust boundaries, technical design decisions and production boundary.
• Pilot Participant Guide is the operational guide for taking a participant from approved pilot scope to a functional, testable and supportable Sovereign Node.
• Business Case Template for GTR/GRID Pilots helps a pilot team define the case, hypothesis, scope, stakeholders, success criteria and expected learning before implementation begins.
• Pilot Test Sandbox provides synthetic test data and an executable cross-border supply-chain exemplar for exercising GRID discovery, DIA verification and failure/lifecycle cases.

The material should be used together. The Design Architecture establishes why the pilot behaves as it does. The Participant Guide defines how to execute it. The Business Case defines what a specific pilot is trying to prove. The Sandbox provides a repeatable example and test catalogue.

Pilot Lifecycle and Readiness Gates

A pilot should be managed through the following readiness and operational gates. The gates are pilot execution controls, not requirements for the eventual production GRID unless adopted separately.

Gate	Name	Outcome
G0	Pilot authorised	Purpose, scope, sponsor and participation approval exist
G1	Environment ready	Repository, tools, access and hosting prerequisites are complete
G2	Trust material ready	Signing keys, cryptographic identifiers and custody controls are established
G3	Registrar data ready	Participant metadata is valid, attributable and approved for publication
G4	Sovereign Node published	Public endpoints and CI/CD publication work reproducibly
G5	GRID connected	GRID can authenticate and harvest participant content
G6	End-to-end functional	Directory and DIA/relying-party pathway work as intended
G7	Lifecycle and failure tested	Change, error, historical and recovery behaviours have been exercised
G8	Pilot operational	Support, evidence, cadence and ownership are functioning
G9	Pilot closed or transitioned	Findings, residual risks and disposition are documented

A pilot is functionally established when G0 through G6 are passed. It is operationally complete when G7 through G9 are also passed.

A gate is passed only when the required outcome, ownership and evidence exist. A successful technical action without evidence or accountable ownership does not constitute gate completion.

Pilot Lifecycle

Pilots are expected to operate iteratively. Initial business case, review, design and environment establishment may take several weeks, followed by shorter build, test, learn and redesign cycles.

About the Pilots

The project uses pilots to:

• Explore design assumptions and generate evidence that can improve the GRID recommendations and specifications.
• Demonstrate that the proposed model can be implemented and can support useful trust and discovery outcomes.
• Expose ambiguity in architecture, governance, data semantics, onboarding, lifecycle and verifier behaviour before those ambiguities become production dependencies.

A pilot should not be treated as successful merely because a directory entry is visible. A useful pilot should demonstrate a reproducible participant-to-GRID-to-relying-party path, and should exercise expected failure and lifecycle conditions.

Pilot Participants and Roles

A pilot may involve several organisations, and a single person may hold more than one role in a small pilot. Every mandatory responsibility should nevertheless have a named owner.

Typical roles include:

• Pilot Sponsor
• Participant Pilot Lead
• Authoritative Registrar / Registrar Data Owner
• National or Delegated Register Operator, where operational responsibility is delegated
• Participant Technical Lead
• Key Custodian / Security Owner
• GRID Pilot Lead
• GRID / UNICC Operator
• Test or Relying Party
• Legal / Policy Reviewer where required
• Supply-chain participants such as supplier, buyer, carrier or certification authority depending on the use case

The pilot must distinguish the Authoritative Registrar, which holds legal or formally delegated competence and accountability for the register, from a Register Operator that may operate technical infrastructure on the Registrar's behalf. Technical control of a repository, API or hosting environment does not by itself make the operator the authoritative source.

Pilot Use Cases

Use cases can be considered under two broad headings:

• GRID-related
  • onboarding and listing a Registrar
  • publishing and updating Registrar data
  • authenticating participant-origin changes
  • harvesting and publishing GRID data
  • lifecycle and status changes
• DIA-related
  • issuing a DIA where supported
  • presenting or linking to a DIA
  • verifying a DIA
  • relating the DIA to authoritative registration data
  • testing status, key-change and historical verification behaviour

Each pilot remains responsible for defining the parties and interactions that it intends to test. Optional extensions may involve UNTP credentials and trade documentation such as commercial invoices, Digital Product Passports, Digital Conformance Credentials, Digital Facility Records, transport documents and certificates of origin.

The Pilot Test Sandbox contains a jurisdiction-neutral cross-border supply-chain exemplar that can be adapted to actual pilot participants.

Pilot Success and Evidence

At minimum, a functional pilot should demonstrate that:

• the pilot has an approved purpose and accountable sponsor;
• participant-controlled source and publication environments exist;
• required Registrar metadata is schema-valid and approved;
• cryptographic trust material has a named custodian;
• participant-origin evidence can be authenticated;
• GRID can harvest the participant material;
• the participant appears in the GRID pilot directory;
• where DIA issuance is in scope, the DIA can be retrieved and verified;
• at least one relying-party verification path has been completed; and
• evidence exists for the above steps.

An operationally complete pilot should additionally test lifecycle and failure cases, record unresolved issues and lessons, define support and escalation routes, and make an explicit closeout or continuation decision.

Recommended evidence identifiers include Git commit SHA, merge/pull request ID, CI job/build ID, GRID harvest run ID, public endpoint URL, DIA URL or hash, test-case ID, issue ID and UTC timestamp.

Joining the GRID Pilot

A prospective participant should begin with the Business Case Template, agree its pilot scope and owners, and then follow the Pilot Participant Guide.

GRID-side approval, public-key registration, harvester configuration or other operator-only actions remain the responsibility of the GRID pilot team. The independent-team readiness test is that a technically competent participant should be able to reach G6 using the approved documentation without continuous synchronous implementation assistance, except for those explicit GRID-side actions.

Production Boundary

The pilot environment is experimental. Passing the pilot gates demonstrates that the pilot mechanism works reproducibly under the tested conditions. It does not certify the participant, the GRID implementation, or the pilot cryptographic controls as production-ready.

Pilot findings should be used to identify production requirements for onboarding, key management, status, availability, audit, privacy, historical verification, interoperability, service levels and governance.