Prove project-authored OpenCRVS and DHIS2 integrations end to end

[jeremi]

Context

Registry Stack 1.0 intends to ship Registry Stack-supported, unofficial integration profiles for pinned OpenCRVS and DHIS2 journeys. Both journeys must be proven after the generic Relay source-adaptation and Registry project authoring model is final. Earlier evidence produced through transitional product-specific executors does not by itself prove the corrected 1.0 path.

The normal adopter workflow must remain the same for both products: author one Registry project, test it offline, build product artifacts, activate Relay, and evaluate the resulting consultation-backed Notary claim. Protocol-specific behavior belongs in reviewed integration files or reusable protocol helpers, not product-dispatch Rust.

Scope

• Start from registryctl project init or a checked-in starter and run the normal project test, project check, and project build workflow.
• Cover one pinned OpenCRVS DCI-shaped journey and one pinned DHIS2 journey through the final generic Relay runtime.
• Exercise the generated Relay source adaptation, consultation contract, and generated Notary consultation reference. Do not use retired Notary source connectors or source-adapter commands.
• Run the applicable common interoperability and negative-security matrix against an independent implementation or instance.
• Prove success, no-match, applicable ambiguity and selector-mismatch behavior, wrong caller/scope/purpose denial before source access, contract mismatch denial, bounded failure behavior, and secret/output redaction.
• Keep deterministic offline fixtures in ordinary CI. Keep live credentials in the process environment or a local ignored file and never place secret values in Git, command lines, logs, fixtures, or evidence.
• Record the exact tested product version and operation, ownership, limitations, and upgrade notes.

Acceptance criteria

• OpenCRVS and DHIS2 each complete the applicable E2 matrix through the final project-authored Relay-to-Notary path.
• A country developer can reproduce the workflow without editing generated Relay or Notary YAML and without reading Rust source.
• OpenCRVS and DHIS2 use the same authoring workflow, with protocol details confined to their integration files or stable helpers.
• Normal CI remains deterministic and network-independent.
• Public wording says “Registry Stack-supported unofficial integration profile” unless the relevant product maintainers accept the exact profile as official.

Non-goal

This does not require every future country system to have a built-in connector. Custom systems must remain possible through the same one-request HTTP or reviewed Rhai scripting surface.

[jeremi]

Baseline after merged #355 and PR #364: the generic project-authoring compiler, product-neutral Relay source runtime, compiler-pinned Notary consultation contract, offline OpenCRVS/DHIS2 fixtures, and source-built integration proofs are implemented. Do not repeat that foundation here. The remaining 1.0 blocker is the applicable common E2 matrix against exact pinned product versions and operations using one published Registry Stack release and its generated Relay/Notary artifacts, with independent-instance evidence, negative paths, redaction, and no generated-YAML edits. Source-built or transitional evidence remains useful but does not satisfy the published-adopter proof.

[jeremi]

1.0 execution packet: independent OpenCRVS and DHIS2 evidence

This issue is prepared but not executable as closing evidence yet. A frozen, published 1.0 candidate and owner-approved independent instances are still required. Source-built or synthetic-fixture runs do not close this issue.

Exact public integration matrix

Integration	Exact baseline	Read operation	Governed result
OpenCRVS	DCI adapter v1.9.0-rc.1 at 5e31d1e381d4bd8c7c74112d714fd49d263c6df7; Core v1.9.5 at 7243ccb79eb84254420878ff5146c6e50f084554; Farajaland v1.9.5 at 3c1a5612d8d7bebddd43463682860b38ef14bcb4	OAuth token, JWKS, then signed POST /registry/sync/search for one exact UIN	one verified result = match; zero = no_match; more than one = ambiguous
DHIS2 Tracker	2.41.9 at ce6404687f6a5806e2661cffe4bc7a1d9b2ad2ed	one bounded GET /api/tracker/trackedEntities/{uid} with the reviewed field projection	matching UID = match; 404 = no_match; different UID = subject_mismatch

If an available independent instance runs a different tuple, stop and repin the profile and matrix to the owner-attested version. Both profiles remain “Registry Stack-supported unofficial integration profiles.”

The current OpenCRVS starter uses a synthetic /dci/v1/birth/search path, while the exact adapter exposes /registry/sync/search. A compatibility probe against the exact tuple is therefore a pre-freeze requirement. The DHIS2 starter still contains DEMO_* metadata UIDs and needs instance-owned values before execution.

Candidate acceptance cases

The public runner must cover:

• authorized match and no-match for both integrations;
• OpenCRVS ambiguity, with the DHIS2 singleton rationale proven by contract and fixture;
• invalid selector, wrong caller, missing scope, wrong purpose, and stale contract, each denied before source contact;
• selector/subject mismatch after the one permitted source call;
• source authorization failure and deadline enforcement;
• automated redaction proving that no credential, seeded canary, subject identifier, raw source body, or sensitive header enters public evidence.

For every pre-source denial, source-side audit or request-counter evidence must independently prove that the source was not contacted. Application logs alone are insufficient.

Proposed public harness ownership

• release/conformance/integrations/README.md
• release/conformance/integrations/schema/run-result.schema.json
• reviewed OpenCRVS and DHIS2 profile inputs under release/conformance/integrations/
• release/scripts/integration-e2-runner.py
• release/scripts/test_integration_e2_runner.py

The runner should verify downloaded candidate assets, initialize both projects with the candidate registryctl, apply only reviewed authored changes, prove generated output was not hand-edited, run offline test/check/build, deploy one Relay plus one Notary plus PostgreSQL per authority using candidate digests, execute the live cases, capture structured hashes/timings/audit correlations, scan redaction, and perform scoped teardown even after failure.

Prerequisites before live execution

• [1.0] Extend project-authoring golden journey and documentation drift coverage #360 maintained command matrix and golden journey are merged
• Migrate all maintained images to Debian 13 and end Debian 12 support before 1.0 #380 runtime migration and executable image checks are complete
• the required registry-backed Implement and prove registry-backed OID4VCI issuance for 1.0 #57 runtime invariant is present
• exact candidate assets are published and independently verified
• OpenCRVS compatibility probe passes against the selected exact tuple
• owner-approved, non-production OpenCRVS and DHIS2 instances, stable test records, metadata, credentials, and source audit access are available
• restricted raw-evidence storage, retention, redaction review, and scoped teardown are approved

Public evidence will contain exact versions and operations, candidate/project/bundle hashes, sanitized results, timings, limitations, and teardown status. Instance origins, subjects, credentials, raw responses, detailed source audits, and named approvals remain in restricted release evidence.

[jeremi]

Maintainer decision: public validator, operator-owned live wrapper

The July 17 proposal that the public runner itself download, initialize, deploy, exercise, inspect, and tear down the live systems is superseded by the boundary now merged on main.

The accepted split is:

• the checked-in profiles and integration-e2-runner.py own the portable contract, exact candidate authentication, closed case matrix, sanitized result validation, canary scanning, and candidate/public-evidence bindings;
• the approved operator wrapper owns instance credentials, network and deployment details, source-side probes, restricted raw evidence, generated-file comparison, and scoped teardown;
• a maintainer compares the public hashes and flags with the restricted evidence before promotion.

This keeps the public tool deterministic and reusable without introducing a provider-specific deployment framework, a secret-bearing plugin surface, or a second orchestration DSL. A generic public deployer would not make owner-specific source audit APIs, credentials, network policy, or teardown portable; it would only move those details behind another abstraction.

This decision does not relax closure. #72 still requires a frozen published candidate, both owner-approved independent instances, the exact pinned product operations, the full positive and negative matrix, independent source-contact proof, no generated-YAML edits, redaction review, successful bounded teardown, and maintainer review of restricted evidence. The ordinary country-developer path remains the same public project init / test / check / build workflow and requires no Rust knowledge. The live evidence wrapper is release-operator infrastructure, not part of the product authoring API.