Representatives of the GA4GH Technical Alignment Subcommittee (TASC) met at the Wellcome Genome Campus in Hinxton, UK, from 7 to 10 July 2026 for the annual TASC workshop. Over four days, the group defined what interoperability means for GA4GH, agreed on its role in reviewing products through the new Product Development and Approval Process Version 2 (PDAP v2.0), and approved four new requirements for technical products. Issues raised in this report are tracked in the GA4GH TASC repository.

Day 1: Tuesday 7 July

Workshop introduction

TASC's work on the PDAP v2.0 was framed as the overriding priority for the workshop. The group discussed what PDAP v2.0 means for products already approved, agreeing that the distinction lies in the approval rather than the product: an approval granted under v1.0 reflects a different process from one granted under v2.0, and that difference should be recorded and communicated openly. Existing products remain approved GA4GH products.

Day 2: Wednesday 8 July

Defining interoperability  

A definition of interoperability was agreed upon and written into the 2026 TASC Interoperability framework. Interoperability is defined as “the ability of two or more autonomous systems, applications, or components to securely, reliably, and efficiently exchange data and subsequently utilise that information without requiring custom, ad-hoc integrations.” This definition decomposes into three layers: syntactic (common formats and protocols); semantic (a shared information model, identified as the most critical hurdle); and behavioural (alignment on execution state and business rules). Three development paths were also decided, based on a product's status. New products receive a forward-looking assessment through PDAP v2.0. Existing active products receive backward-looking gap closure. Existing inactive products receive only an internal audit, with no active TASC participation. The new-product path was developed in detail; the other two will be worked through at a future TASC meeting.

TASC’s role in the PDAP

The PDAP three-tier risk model was adopted, with TASC defining its own profile for each tier, ranging from low or no overlap risk up to confirmed concerns that require formal sign-off at Gate 2 and external audit. Tiers are dynamic and can be reassessed in either direction as circumstances change. TASC takes no action and requires no dedicated notification for Tier 1. The proposed registry for tracking interoperability points was parked pending a Tech Team prototype. It was agreed with no dissent that every member reviews every dossier, with TASC responding as one aggregated position. TASC was also confirmed as the de facto forum for resolving cross-product conflicts.

Technical Product Dossier, Section 5.4 (Dossier to be published)

Section 5.4 of the PDAP Technical Product Dossier was drafted: screening questions at Triage will cover the three interoperability layers plus data domains and anticipated overlap. The full questionnaire will be completed during the Draft stage for Tier 2 and 3 products. Tier 2 mitigations must argue for reclassification. Tier 3 mitigations must include a forum, a defined frequency, and a conflict-resolution mechanism. TASC agreed that Checkpoint 1 should be resequenced so that Foundational Work Streams and TASC reviews precede the Independent Review Panel (IRP). Architecture Decision Record (ADR) items must be resolved or addressed before progression, with a stated plan acceptable at that stage. Nothing goes to open comment until majors are cleared. Whether products approved under PDAP v1.0 might come across to v2.0 was set aside for later, with a streamlined route noted as worth exploring.

Day 3: Thursday 9 July

Mock run of the TASC review process

The team rehearsed the full review workflow using a fabricated submission, building the supporting infrastructure live. The agreed flow: (1) members raise issues privately, (2) discuss internally at a TASC meeting, (3) aggregate into a single umbrella product review document listing required ADRs, (4) raise cross-linked issues in the product repository. The umbrella review is explicitly not itself an ADR. Internal drafting is consolidated so teams receive one coherent position; public visibility comes later, at the open comment period. Naming and labelling conventions remain open.

Technical product requirements (Approved)

Four GA4GH Technical product requirements were approved for products entering PDAP v2.0. Every technical product must have:

  • a GitHub repository conforming to the TASC template — this absorbed several previously separate rows, a template plus guidance being more durable than an expanding document list (The template and its guidance are still to be produced, so this requirement takes effect once they are published);
  • a website on a ga4gh.org subdomain;
  • a starter kit — explicitly not required to be a code template, so that non-software products such as ontologies can comply;
  • a conformance suite.

The requirements are issued as TASC directives rather than PDAP line items, keeping the PDAP stable while directives evolve. No curated list will sit inside the PDAP, and the requirements document will not be versioned.

Citing GA4GH Standards (Issue #39) (Approved)

The Citing GA4GH Standards recommendation formalises a process that already operates informally. DOIs for GA4GH products and documentary outputs are minted via Crossref within a consistent namespace, with defined metadata requirements. Crossref was selected because it supports standards as an identifiable object type. The scope of who may request DOIs was widened from Work Streams to originating groups, since other groups including TASC produce outputs that need them. DOIs are issued through the Tech Team, which maintains a register of assigned identifiers to prevent clashes. Scope excludes datasets, tools and other research resources. Multiple DOIs per product are permissible: the landing page as the conceptual entity, versioned releases, and documentation. The choice depends on whether a citer wants a stable landing point or a version-pinned identifier. A DOI's identity is permanent, though its resolution target can be updated.

Tech Team harmonisation show and tell (Issues #54 and #85)

Three pieces of work were presented. A central documentation directory site was accepted, rendering Markdown from product repositories through a standard template. Legacy domains will be preserved as redirects, with reverse proxies for harder migrations. The Registry redesign was demonstrated, moving to a single source of truth. Implementations become a superset covering services and deployments, schemas and people are newly introduced, and open access is replaced by Passport-verified submission. The Analytics Dashboard was shown, with a model in development to distinguish primary citations from passing mentions.

Moving a standard to maintenance mode (Issue #49)

Deferred without objection. Revisions to the PDAP product lifecycle diagrams mean the question needs reframing before it can be revisited.

Verified implementations (Issue #74) (In progress)

Verified implementations progressed substantially but did not close. The group settled that the framework concerns codebases rather than deployments, since otherwise every redeployment of an existing implementation could claim verification, though a separate track for verified deployments remains open. The group also reviewed the PDAP's existing evidence-of-use requirements and confirmed they were content with them as written, removing the duplicate wording from the verified implementations document rather than restating it. Terminology must be harmonised with the requirements and dossier documents before approval, so this should be read as a working position rather than settled policy.

Day 4: Friday 10 July

Wrap-up, outstanding issues, and next steps

Four ADRs were commissioned, covering the product requirements decisions, the interoperability framework, the role of TASC in the PDAP, and the Technical Product Dossier Section 5.4 decisions. It was settled that directives will remain fixed and canonical in a single known location. Any document that gathers them together for convenience, such as a proposed PDAP cheat sheet, is treated as a separate packaging layer and can be rewritten freely without touching the directives themselves. All items were converted to assigned GitHub issues.

The workshop closed with broad agreement that TASC now has both a shared definition of interoperability and a practical means of acting on it. Near-term, these outcomes will be presented as part of the main plenary session rather than a separate TASC session, so the wider community hears them directly.

Next Steps

  • Generate one ADR for each of the four approved decisions on product requirements
  • Generate ADR for the interoperability framework
  • Generate ADR for the role of TASC in the PDAP: what we do and what to expect from TASC
  • Generate ADR for the PDAP Technical Product Dossier Section 5.4 decisions
  • Build the infrastructure for PDAP reviews, including GitHub Projects for tracking reviews through assigned reviewers, and identify what can be automated
  • Consolidate TASC directives into a PDAP cheat sheet, giving product teams a single navigable view of what is required
  • Generate repository template and accompanying guidance
  • Agree Schema Registry's schema for implementation in the GA4GH Registry (Issue #79)
  • Streamline the remaining two DaMaSC recommendations (Issues #80 and #81)
  • Determine next steps for Service Registry and Service Info, including geolocation with OpenTRE, and whether this constitutes a PDAP-level change or a minor release
  • Confirm owner for geolocation item