Pilot Participant Guide

This guide is the operational guide for GRID Pilot Participants. It explains how to take an approved pilot from initial environment setup to a functional, testable and supportable participant Sovereign Node.

Read the Pilots overview and Pilot Design Architecture first. A specific pilot should also have an approved business case or equivalent charter based on the Business Case Template.

Pilot boundary

This guide describes an experimental pilot environment. It does not define a production deployment architecture or certify a participant as production-ready.

1. Definition of a Functional Pilot

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

Gate	Name	Pass condition
G0	Pilot authorised	Scope, sponsor, owners and approval exist
G1	Environment ready	Repository, access, tooling and CI work
G2	Trust material ready	Signing and cryptographic trust material verify
G3	Registrar data ready	Metadata is valid, attributable and approved
G4	Sovereign Node published	Reproducible HTTPS output exists
G5	GRID connected	GRID can authenticate and harvest the participant
G6	End-to-end functional	Discovery and applicable DIA/relying-party verification work
G7	Lifecycle and failure tested	Required negative, lifecycle and recovery tests are complete
G8	Pilot operational	Support, evidence, cadence and ownership are functioning
G9	Closed or transitioned	Findings and disposition are recorded

A successful technical action without the required owner or evidence is not sufficient to pass a gate.

2. Roles and Responsibility

One person may hold multiple roles in a small pilot, but every mandatory responsibility should have a named owner.

2.1 Pilot Sponsor

Accountable for authorising participation, confirming institutional support, resolving governance or resource escalations, and approving continuation or closeout.

2.2 Participant Pilot Lead

Responsible for coordinating the participant pilot, maintaining the plan and issue log, coordinating with GRID leads and ensuring gate evidence is complete.

2.3 Authoritative Registrar / Registrar Data Owner

Accountable for the correctness and meaning of Registrar metadata, authority to publish pilot data, the legal or formal basis represented by the record, and approval of material changes.

2.4 National or Delegated Register Operator

Where a separate operator exists, it may operate the repository, APIs, hosting, CI/CD and support infrastructure under delegated authority. The operator must not be represented as the authoritative source solely because it controls the technical environment.

2.5 Participant Technical Lead

Responsible for repository and CI/CD setup, publication endpoints, schema validation, technical troubleshooting and implementation documentation.

2.6 Key Custodian / Security Owner

Accountable for participant signing keys, private-key protection, public-key registration, rotation, compromise handling and security evidence.

2.7 GRID Pilot Lead

Responsible for participation coordination, pilot suitability, GRID-side onboarding expectations, project-level ambiguities and interpretation of pilot findings.

2.8 GRID / UNICC Operator

Responsible for GRID-side harvester configuration, participant endpoint and verification-material registration, GRID pipelines, diagnostics and any GRID-side DIA processing assigned by the pilot design.

2.9 Test / Relying Party

Responsible for independently consuming and verifying published GRID/DIA material and recording usability or verification failures.

2.10 Legal / Policy Reviewer

Where needed, confirms that pilot claims do not overstate legal effect, that test material does not imply unintended production authority and that the data policy is appropriate.

3. Minimum RACI Rules

The full RACI can be adapted to local project governance, but the following rules apply:

• no mandatory gate should pass if its accountable role is unnamed;
• a security-sensitive action must have a named security/key owner;
• Registrar data publication requires approval by the responsible data owner;
• GRID-side actions must not be assumed to have occurred without GRID operator evidence; and
• where a Register Operator exists, legal/status decisions remain attributable to the Authoritative Registrar even if the operator implements the technical change.

4. Baseline Environment

The baseline hosted pilot is intentionally lightweight. A typical participant deployment consists of:

1. a participant-controlled Git repository;
2. Registrar metadata under version control;
3. a DID document or equivalent cryptographic-identifier material where the DIA profile requires it;
4. authenticated participant source changes;
5. CI/CD that validates and publishes machine-readable output;
6. predictable HTTPS hosting, typically GitLab Pages, GitHub Pages or equivalent;
7. GRID-side harvesting and source authentication; and
8. GRID directory and applicable DIA outputs.

A dedicated participant application server is not required for the baseline hosted profile.

4.1 Hardware and service baseline

Component	Pilot baseline	Notes
Administrator workstation	Current workstation capable of Git, browser and cryptographic tooling	No high-performance hardware required
RAM	4 GB practical minimum, 8 GB recommended	Not a GRID protocol requirement
Local free storage	About 1 GB for pilot source/tooling	Excludes unrelated development tooling
Git hosting	GitLab or GitHub	Participant-controlled project/repository
CI/CD	Hosted GitLab CI or GitHub Actions	Recommended for zero-server baseline
Static HTTPS hosting	GitLab Pages, GitHub Pages or equivalent	Must expose predictable URLs
DNS	Optional for platform-hosted profile; required for participant-controlled domain profile	Must be under appropriate control
TLS	Hosting platform or participant	Public endpoints should use HTTPS
Git client	Current supported release	Record version
Cryptographic client	Tool required by the pilot source-authentication profile	Record version
HTTP client	Browser plus curl or equivalent	Used for endpoint verification
HSM/KMS	Not required for baseline pilot	Production-target or advanced control

4.2 Optional self-hosted profile

If a participant self-hosts a runner, web endpoint or supporting services, record at least the OS/version, host identifier, CPU/RAM/storage, container runtime, firewall rules, DNS, TLS source/renewal, runner and web-server versions, logging, backup/restore, time synchronisation, patch ownership, service accounts and monitoring.

A practical starting point for a small self-hosted pilot is 1-2 vCPU, 2-4 GB RAM and 10 GB storage, subject to participant measurement and policy.

4.3 Software Bill of Materials

Each participant should maintain a small software inventory recording component, purpose, product, version, source, runtime location, owner, update policy and evidence.

At minimum record the versions of Git, cryptographic/signing tools, SSH where used, YAML/JSON tooling, schema validator, CI runner/image, shell/runtime, Node.js or other build runtime where used, hosting platform, HTTP client, DID tooling and any credential/DIA verification tool.

Pilot automation should avoid unnecessary non-determinism. Pin dependencies where practical or capture the resolved version. Floating versions should be recorded as a reproducibility risk.

5. Configuration, Access and Secrets

5.1 Configuration register

Maintain a configuration register for items such as repository URL, default branch, public base URL, Registrar endpoint, DID, DID document URL, GRID participant ID, harvester URL, public-key fingerprint, schema version and participant profile.

Recommended fields are:

• ID
• Item
• Value/Reference
• Owner
• Classification
• Source of truth
• Change method
• Last verified

5.2 Secrets register

Do not place secret values in the register. Record only metadata such as purpose, owner, storage mechanism, scope, expiry, rotation trigger and recovery/reissue path.

Mandatory pilot rules:

• private signing keys must never be committed to the repository;
• private keys must not be sent to GRID;
• secret values must not appear in screenshots, issues, logs or test reports;
• CI logs should be checked for accidental credential disclosure;
• tokens should be minimum-scope and time-bounded where supported;
• staff offboarding must remove pilot access; and
• pilot-specific tokens should be revoked at closeout unless continuation is explicitly approved.

6. G0: Pilot Authorised

Objective

Establish a legitimate, bounded pilot before technical deployment begins.

Required inputs

• candidate use case;
• candidate Registrar(s);
• sponsor;
• participant contacts;
• intended test/relying parties;
• desired GRID/DIA capabilities.

Procedure

1. Appoint the Pilot Sponsor and Participant Pilot Lead.
2. Identify the participating Authoritative Registrar / Data Owner.
3. Identify the Technical Lead and Key Custodian / Security Owner.
4. Identify relying-party/test participants.
5. Record any separate Register Operator and delegation basis.
6. Document the pilot use case and what the pilot is intended to learn.
7. Define what is explicitly out of scope.
8. Confirm the data policy, using synthetic/non-sensitive data by default.
9. Confirm the pilot will not represent itself as a production GRID implementation.
10. Identify legal/policy constraints.
11. Define success criteria and expected duration/review cadence.
12. Submit the planning/business-case material required by the GRID project.
13. Obtain pilot approval.

The Business Case Template includes a minimum execution charter for this purpose.

Exit criteria

• named owners exist;
• scope is approved;
• data policy is approved;
• success criteria exist; and
• GRID participation has been accepted where approval is required.

Evidence

Business case or pilot charter, approval record, named-contact register and initial risk/issues log.

7. G1: Environment Ready

7.1 Create the participant repository

Create a participant-controlled GitLab or GitHub project. Record repository URL, owner, visibility, default branch and administrator list.

7.2 Access controls

Recommended pilot controls are individual accounts, MFA where supported, minimum privilege, at least two administrators where practical, and a documented offboarding path.

7.3 Protect the default branch

Recommended controls include protected main, merge/pull requests for normal changes, prevention of force-push and branch deletion, optional approval for Registrar metadata changes, and logged administrative override.

7.4 Repository structure

A practical baseline is:

/
├── README.md
├── .gitignore
├── .gitlab-ci.yml                 # GitLab profile
# or
├── .github/workflows/
│   └── publish.yml                # GitHub profile
├── .well-known/
│   └── did.jsonl                  # did:webvh append-only verifiable key history
├── registrars/
│   └── example.json
...

Do not store private keys or secrets under evidence/ or elsewhere in the repository.

7.5 Verify tooling

Capture versions for the tools used by the participant, for example:

git --version
gpg --version
ssh -V
curl --version

7.6 Verify network and CI

Confirm the participant environment can reach the Git service, public hosting endpoints, GRID pilot public endpoints and package registries used by CI. Run a minimal CI job successfully before building the publication pipeline.

Exit criteria

Repository works, access is controlled, branch policy is set, baseline structure exists, tooling versions are recorded and CI can execute.

Evidence

Repository link, branch-policy export/screenshot, software BoM, successful CI job ID/URL and administrator/access list.

8. G2: Trust Material Ready

8.1 Participant-origin signing material

Generate or designate the signing material required by the current pilot source-authentication profile. Record fingerprint or public-key identifier, creation/expiry, algorithm, owner, storage category and recovery method.

Protect the private material according to participant policy. Routine repository users should not automatically receive private-key access.

8.2 Signed source change

Configure the repository so the participant can produce an authenticated test change and verify it locally. Capture evidence without exposing private material.

8.3 DID or other cryptographic identifier

Where DIA issuance is in scope, record the provisioning model:

• applicant-controlled;
• Registrar-provisioned; or
• managed/delegated.

Record who generates and controls the private key, who may rotate or revoke it, how control is verified, how it is bound to the authoritative organisation identifier, and what happens when control changes.

Control of a DID or key is not equivalent to legal identity or authority to represent an organisation.

8.4 DID publication

Where did:webvh is used, publish the hash-chained history log at /.well-known/did.jsonl. Verify HTTP 200, TLS, JSONL formatting, sequential hash-chain continuity from the SCID to the log tip, and valid cryptographic pre-commitments in nextKeyHashes.

Where did:web is used, publish the DID document at the path required by the DID method and verify HTTP 200, TLS, JSON syntax, verification methods, public-key material, controller and identifier consistency.

Do not assume that placing did.json at a repository root is sufficient unless the resulting public URL maps to the intended DID.

8.5 Public-key handoff to GRID

Provide only the public material required by the pilot, such as public signing key/fingerprint, repository/endpoint references and DID information. A deploy/read token should be supplied only when a private repository requires it.

Exit criteria

Participant source-authentication material exists, custody is assigned, a signed/authenticated source change verifies, applicable DID material resolves, and required public trust material is ready for GRID registration.

9. G3: Registrar Data Ready

Example:

UN_member_state: "AT"
subdivision_code: null
registrar_full_name: "Sea Companies Registrar of Atlantis"
registrar_identifier_code: "ACR"
register_name: "National Company Registry"
register_type: "Organisation"
legal_basis: "https://example.invalid/organisation-act"
authoritative_body: "https://example.invalid/ministry"
register_id: "AT.ACR"
registered_id_pattern: "https://registry.example.invalid/company/{id}"
did: "did:webvh:QmOriginSCID123456789AtlantisExample:registry.example.invalid"
did_log_endpoint: "https://registry.example.invalid/.well-known/did.jsonl"
query_endpoint: "https://registry.example.invalid/lookup?id={id}"
registrar_notes: "Synthetic participant record for GRID pilot testing."

Step 3: Configuring the CI/CD Pipeline

Use synthetic/example domains for synthetic pilots.

9.1 Data-quality review

The Data Owner should check jurisdiction, Registrar and register names, register type, Registrar identifier, authoritative identifier semantics, legal basis, accountable body, pilot/test status, DID association, contacts, supplementary identifiers and any field that could accidentally imply production authority.

9.2 Trust semantics

Confirm that:

• GRID or a pilot credential does not appear to replace the authoritative register;
• the basis on which the register is treated as authoritative is recorded;
• authoritative and supplementary identifiers are distinguishable;
• asserted information is not represented as Registrar-verified unless it was actually verified;
• key control is not represented as legal identity or authority to act; and
• pilot material cannot reasonably be mistaken for an operational legal attestation.

9.3 Working data-quality classes

Where the payload/schema permits, pilot data can distinguish:

• Authoritative: data for which the Registrar is the legally competent source or custodian for the relevant register purpose.
• Verified: data checked against an identified source/process but not itself the authoritative register fact.
• SubjectAsserted: data supplied by the applicant ("subject") without an authoritative or independently verified basis.

Classification does not by itself determine legal effect.

9.4 Schema validation

Validation should run locally where practical, in CI, before publication and before GRID harvesting where possible. Invalid Registrar data must not be promoted as an accepted record.

Exit criteria

Registrar file exists, Data Owner approval exists, schema validation passes, applicable cryptographic identifiers match the published trust material, and no unapproved sensitive/production data is present.

10. G4: Sovereign Node Published

10.1 Publication pipeline

The participant pipeline should perform the following functional stages:

validate -> build -> test -> publish

It should validate Registrar sources, fail on parse/schema errors, convert approved source to machine-readable output, publish applicable DID material, generate predictable paths, preserve source-to-output traceability and avoid leaking secrets.

10.2 GitLab profile

The current pilot can use GitLab Pages. Participants should pin or record the CI image and tool versions rather than relying on unnecessary floating dependencies. Ensure the final Pages URL is stable and compatible with any did:web mapping used by the pilot.

10.3 GitHub profile

A GitHub Actions + GitHub Pages implementation is acceptable where it provides equivalent functional controls and GRID can authenticate and consume the resulting source/endpoints according to the agreed pilot method.

10.4 Endpoint verification

For each Registrar endpoint verify HTTP 200, TLS, JSON validity, schema, source/output consistency and absence of secrets. Verify the DID endpoint separately where applicable.

10.5 Reproducibility test

Make an approved harmless source change and confirm:

source change
 -> authenticated commit/change
 -> CI validation
 -> build
 -> public endpoint update

Record source commit, CI/build ID and publication timestamp.

Exit criteria

CI is green, public endpoints are reachable, applicable DID endpoint resolves, public output matches source, no secrets are exposed and an approved update can be republished reproducibly.

11. G5: GRID Connected

11.1 Participant onboarding package

Provide the agreed package through the approved channel. Recommended contents are:

Pilot name
Member State / jurisdiction
Registrar name(s)
Participant repository URL
Public Pages/base URL
Registrar JSON endpoint(s)
Primary DID, where applicable
DID document URL, where applicable
Participant public signing key/fingerprint
Repository access requirement: public/private
Deploy/read token reference and expiry, only if required
Participant Pilot Lead
Technical contact
Security/key contact

Do not include a private signing key.

11.2 GRID operator checks

GRID operations should confirm participant identity/contact through the pilot process, endpoint reachability, public-key fingerprint, repository access, authenticated participant source, schema-valid Registrar data and successful harvest/pipeline completion.

11.3 Private repository access

If a private repository requires GRID access, use a read-only, repository-scoped, expiring token where possible. Store it only in the approved secret mechanism and verify that it does not appear in CI logs.

11.4 Authentication acceptance

A participant must not be marked cryptographically verified unless the GRID-side process successfully verifies the participant-origin evidence using the registered trust material.

Record source commit/reference, signer/fingerprint or equivalent identifier, verification result and harvest run/build ID.

Exit criteria

GRID has the required participant configuration, can access the source, authenticates it successfully, ingests the Registrar data and exposes failures visibly rather than silently accepting them.

12. G6: End-to-End Functional

12.1 Directory verification

Confirm that the participant appears in the intended GRID pilot view, displayed fields match the participant source, links resolve, status is correct and the displayed verification state reflects the actual GRID-side authentication result.

12.2 Credential-level clarity

Distinguish GRID-to-Registrar participation/discovery evidence from Registrar-to-entity identity evidence. Do not describe them as though they have the same issuer, subject, liability meaning or verification purpose.

12.3 DIA checks, where applicable

Retrieve the DIA and check valid JSON, issuer, subject, identifier semantics, source-Registrar association, proof structure, dates/time fields, links and intended claims. Verify it using the pilot mechanism and record tool/version, input, trust material, timestamp and result.

12.4 Relying-party test

An independent tester should be able to:

1. start from GRID or a known DIA reference;
2. locate the relevant Registrar record;
3. identify the authoritative Registrar;
4. retrieve the DIA where applicable;
5. verify the credential using the pilot process;
6. follow relevant source links; and
7. record whether the trust chain and meaning are understandable.

Generator success is not equivalent to relying-party usability.

Exit criteria

Participant is discoverable, displayed values are accurate, applicable DIA is retrievable and verifies, and at least one independent relying-party path is complete.

13. G7: Lifecycle, Negative and Resilience Testing

A pilot that exercises only the happy path is incomplete.

At minimum test the cases relevant to the pilot:

Test	Expected result
Valid metadata update	Authenticated update is harvested and reflected
Invalid/unregistered signature	Change is rejected or clearly unverified
Invalid schema	CI rejects before publication
Missing DID where DIA is required	Registrar may remain discoverable but DIA is not issued
Participant endpoint unavailable	Failure, timeout/retry and stale-state behaviour are observable
Key rotation	Successor key becomes usable through an authenticated change path
Suspected compromise	A clear containment, replacement and historical-impact path exists
Registrar status change	Authorised change is reflected and DIA/status behaviour is understood
Repository token expiry	Harvest failure and secure recovery are observable where token is used
CI dependency failure	Dependency drift/failure does not silently change accepted output
GRID pipeline failure/re-run	GRID-side recovery is repeatable
Entity restructuring/successor	Predecessor and successor remain historically distinguishable
Entity termination/lapse	Current and historical state are represented distinctly
Schema compatibility	Supported/unsupported versions behave explicitly

13.1 Temporal and historical verification

Distinguish issuance time, transaction time, verification time and status-effective time.

Where historical reliance is in scope, retain enough evidence to determine whether the relevant organisation, Registrar, credential and verification material were valid for the time being evaluated. If the historical state cannot be established, return INDETERMINATE rather than inferring from current state.

13.2 Key rotation and compromise

Do not conflate planned rotation with compromise. Record activation/retirement times and whether old public verification material remains available for historical validation.

Exit criteria

Mandatory failure/lifecycle tests have been executed, outcomes are captured, defects are logged, unresolved issues have owners, and no critical unresolved security problem is treated as a successful pilot result.

The Pilot Test Sandbox provides a reusable test catalogue.

14. G8: Pilot Operations

14.1 Operating cadence

A practical minimum is a regular participant technical review during build, periodic cross-pilot review, event-driven escalation for trust/security failures and a formal checkpoint at each gate.

14.2 Health checks

At an agreed interval check repository availability, last CI state, public endpoint availability, Registrar JSON parsing, DID resolution where applicable, key/token expiry, last GRID harvest, directory record and DIA retrieval where applicable.

14.3 Change classes

Routine changes include non-semantic documentation and typo corrections.

Material changes include Registrar identifier, legal basis, DID, public key, status, schema version and participant endpoint. These require explicit owner review and evidence.

Security-sensitive changes include keys, tokens, repository visibility, access control and CI secret configuration. These require security-owner oversight.

14.4 Incident classes

P1 Trust/security critical examples include suspected private-key compromise, GRID accepting invalid participant evidence, credential generation from unauthenticated content or secret exposure. Stop affected trust operations, preserve evidence and re-establish the trust basis before resuming.

P2 Functional blocking examples include failed harvesting, DID resolution failure, persistent CI failure or DIA-generation unavailability. Assign a technical owner, diagnose participant versus GRID responsibility, recover and retest.

P3 Non-blocking examples include display defects, documentation inconsistencies and non-critical warnings. Backlog and prioritise.

14.5 Evidence

Retain enough evidence to reconstruct:

who changed what
 -> when
 -> under whose authority
 -> using which key/configuration
 -> through which CI run
 -> what was published
 -> what GRID harvested
 -> what GRID produced
 -> what the relying party verified

15. Minimum Security Controls

The pilot is non-production, but its trust experiments have little value if security assumptions are undefined.

Minimum controls include MFA for repository administrators where supported, named accounts, protected default branch, authenticated participant source changes, private-key protection, scoped tokens, secret masking, non-sensitive test data by default, dependency/version recording, validation before publication, HTTPS endpoints, a security contact, compromise process, evidence retention and access removal at closeout.

Maintain a key register recording key ID, fingerprint/identifier, purpose, owner, algorithm, created/activated/retired/compromised state, GRID registration state and historical-validation policy. Do not record private-key material.

16. Acceptance Checklist and Definition of Done

A functional pilot is Done only when:

1. G0 through G6 are passed;
2. all mandatory acceptance items through end-to-end verification are complete;
3. critical defects are resolved or explicitly accepted by an accountable owner;
4. the participant can reproduce an approved Registrar metadata change;
5. GRID can authenticate and harvest that change;
6. a relying party can independently inspect and verify the resulting GRID/DIA artefact as applicable; and
7. evidence exists for each step.

A pilot should not be described as end-to-end functional solely because a directory entry was manually made visible.

17. G9: Closeout or Transition

At closeout answer:

• Did the architecture work as expected?
• Which steps required undocumented assistance?
• Which configuration was fragile or could not be reproduced?
• Which trust assumptions were validated and which were simulated?
• What failed during negative testing?
• Which responsibilities remained ambiguous?
• Which controls are pilot-only and which appear production-relevant?
• Which legal/policy questions remain unresolved?
• What did relying parties misunderstand?
• What should change in the GRID specifications, Pilot Design or Participant Guide?
• What should be automated and what should remain a governance decision?

Closeout actions should include freezing the final pilot state, recording the final source reference and public endpoints, exporting relevant test evidence, documenting defects and lessons, making a close/continue/transition decision, revoking unneeded pilot secrets, retiring keys where appropriate, removing obsolete GRID credentials and user access, marking retained public material as historical/test, and publishing agreed non-sensitive findings.

18. Reusable Templates

18.1 Gate record

Gate:
Pilot:
Date:
Owner:
Approver:

Inputs:
Activities completed:
Tests:
Evidence:
Exceptions:
Risks:
Exit criteria:
Decision: PASS / CONDITIONAL / FAIL

18.2 Test case

ID:
Title:
Requirement:
Owner:
Date:
Preconditions:
Steps:
Expected result:
Actual result:
Evidence:
Result: PASS / FAIL / BLOCKED
Defects / follow-up:

18.3 Configuration register

ID | Item | Value/Reference | Owner | Classification | Source of truth | Change method | Last verified

18.4 Key register

Key ID | Purpose | Fingerprint/Identifier | Owner | Created | Activated | Expires | Retired | Compromised | GRID registered | Historical validation policy | Notes

18.5 Secrets register

Secret ID | Purpose | Owner | Storage mechanism | Scope | Expiry | Rotation trigger | Recovery/reissue | Status

18.6 Risk register

Risk ID | Description | Cause | Impact | Likelihood | Owner | Mitigation | Residual risk | Status

Initial risks may include signing-key compromise, incorrect Registrar representation, accidental production-data publication, dependency drift, URL changes, DID-resolution mismatch, token expiry, schema divergence, harvester silent failure, lifecycle-semantic divergence and a pilot credential being mistaken for production/legal attestation.

19. GRID Operator Onboarding Checklist

For each participant, GRID/UNICC operations should capture evidence that:

• pilot approval and participant contacts are confirmed;
• repository/public endpoints are received;
• applicable DID and public trust material are received;
• fingerprint or equivalent trust identifier is verified;
• repository access token is accepted only if actually required;
• participant source can be retrieved;
• participant-origin evidence verifies;
• Registrar metadata parses and validates;
• GRID generation completes;
• participant appears in the directory;
• DIA is produced only when the applicable conditions pass; and
• operator evidence and participant notification are complete.

GRID Ops should maintain a participant inventory containing participant ID, pilot name, jurisdiction, Registrar ID, repository/source URL, visibility, harvest URL, DID, public-key identifier, verification method, secret/token reference, last successful harvest, last verified source reference, status and operator owner. Secret values remain in the approved secret store, not the inventory.

20. One-Page Execution Sequence

For teams already familiar with the architecture:

1. Approve: name owners, agree scope/data and obtain pilot approval.
2. Create: establish repository, branch controls and CI.
3. Secure: create/register participant source-authentication material and record its public identifier.
4. Identify: create/publish cryptographic identifier material where the DIA profile requires it.
5. Describe: create, validate and approve Registrar metadata.
6. Publish: expose predictable HTTPS machine-readable output.
7. Connect: provide GRID onboarding package and establish source authentication.
8. Harvest: run the GRID harvester and confirm the participant record appears.
9. Anchor: where applicable, generate/retrieve and verify the DIA.
10. Consume: run independent relying-party verification.
11. Break: test invalid signature, malformed data, outage, missing identifier, status change and key change.
12. Operate: run health checks, maintain evidence and issues.
13. Conclude: capture findings and close, continue or transition.

21. Independent-Team Readiness Test

Give the approved documentation and onboarding contact to a technically competent Registrar team with no prior GRID implementation experience. Except for actions explicitly assigned to GRID, the team should be able to reach G6 without continuous synchronous implementation assistance.

Repeated questions such as "what exactly should I install?", "who owns this?", "which key is this?", "where does this secret go?", "how do I know GRID authenticated my source?" or "what evidence proves this gate is complete?" should be treated as documentation or operating-model defects and fed back into the pilot material.