GA4GH Categorical Variation Product Group

Agendas & Meeting Minutes - 2026-2027

Others: 2023 | 2024/2025

Overview

This is the running agenda and minutes document for the GA4GH Categorical Variation Product Group. The scope of this work will be to develop a terminology and schema to represent all variation types across participating genomic knowledgebases, and to develop reference implementations for expressing and validating categorical variation objects.

For further information or to get involved, please contact info@ga4gh.org.

—--

Agendas & Meeting Minutes 2023: [ARCHIVED] Categorical Variation - Minutes document - 2023

Agendas & Meeting Minutes 2024-2025: ARCHIVED] Categorical Variation Group - Minutes document - 2024-2025

Table of Contents:

Overview

Table of Contents:

Meeting Protocols

Resources

List of meetings

2026-10-20

2026-10-07

2026-09-02

2026-08-05

2026-07-21

2026-07-01

2026-06-16

2026-05-19

2026-04-21

2026-03-17

2026-03-04

2026-02-04: Adjacency constraint relations

2026-01-20: Adjacency constraint follow up

2026-01-07: Adjacency Constraint

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards for Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

Resources

• Utility of the JAX Clinical Knowledgebase in capture and assessment of complex genomic cancer data - PMC 
• Categorical Variation Study Group Roadmap
• Link to the slide show  on categorical variation including the targeted breakdown of some of the categories of variants in CIViC
• A link to a lucid chart doc with the typology figure and a short blurb on how it was generated.
• GitHub repository for Cat-Vrs

List of meetings

2026-10-20

Leads: Brendan Reardon, Daniel Puthawala

Participants: Kori Kuzma, Senkei Umehara, Daniel Cameron, Sachi, Beth Pitel, Larry Babb, Alex Wagner (joined midway), Bob Dolin

Link to meeting recording: https://us02web.zoom.us/rec/share/bZmROqmcQdAhXsd4jOhAeZeb8gh6nwIFNV8C4UE-Ca5xazDLU1r54zVSnmr1fl0w.SS1I67SlMhrloJLZ 

Meeting summary:

1. Announcements (Brendan)

• Rebrand: Cat-VRS, VA-Spec and GKS Core are now grouped under the Genomic Knowledge Model (GKM).
• GKM Starter Kit was announced at Plenary and Connect and was well received. Brendan thanked Kori and Larry for leading it.
• Schedule change: from November, GKM meetings move to the 1st and 3rd Thursdays of each month, 11:00-12:00 ET. A formal email and Slack notice will follow. One more meeting is expected on the current schedule.

2. Connect debrief (Daniel)

Releases and docs

The group discussed the recent releases:

• 🎉  Version 1.1.0 introduced two new constraints: the function constraint and adjacency constraint.
• It also introduced two recipes: the function variant recipe and the gene fusion recipe.
• 🎉  Version 1.1.1, published the previous week, primarily updated references from GKS Core/GKS to GKM. No functional changes to classes or schema instantiations were introduced.

The new constraints and recipes are available for implementers to try. Feedback from implementations will help the group refine them and determine whether they are ready to progress to trial use.

Documentation improvements

Daniel highlighted the extensive documentation refactoring led primarily by Brendan, with additional contributions from Larry. The aim has been to improve consistency across GKM products and make the documentation easier to navigate and use.

One encouraging outcome was that an AI assistant was able to generate useful Cat-VRS Python implementation guidance from the updated documentation, whereas an earlier attempt had struggled. This suggests that the improvements are making the specifications more accessible to both human users and AI-assisted development tools.

New adopters

• MaveDB / MaveMD (counted with an asterisk; discussions began at Spring Connect).
• Pan-Asia Variant Review Panel Expert Board (from the BioHackathon in Japan): software to support VCEP-style ACMG/AMP classification across East and Southeast Asia, independent of US/NIH tooling and with multilingual support. It uses VA-Spec pathogenicity propositions, with Cat-VRS for the subject variants, at the publication and reuse step. Still a pilot; national-level reviews are next.

The project has an interest in:

• Supporting international expert review and classification.
• Enabling multilingual workflows.
• Producing classifications in an internationally recognisable and reusable format.
• Reducing reliance on software infrastructure that may not be appropriate for all participating countries.
• DARA (Thai population genomics project): was identified as another emerging adopter. Uses Phenopackets for phenotypes, VRS for specific alleles and Cat-VRS for categorical variants characteristic of populations.

The project combines population and electronic health record data, including:

• Phenotypic data represented using Phenopackets.
• Specific alleles represented using VRS.
• Population-characteristic or potentially population-specific categorical variants represented using Cat-VRS.

The project is exploring how these standards can support representation and reuse of genomic and phenotypic information in population genomics.

The team will be returning to Thailand to continue the work. The group expressed interest in hearing further implementation updates as the project progresses.

• Larry asked how the expert board separates annotations from evidence. Daniel said the project defines annotations as VEP and gnomAD data tied to a VCF row, and evidence as accompanying material such as PubMed papers. Larry noted this is the project's own usage: GKM does not formally define "annotation", even within VA-Spec, and needs to before claiming support for the distinction.

Current and upcoming work

• Cat-VRS paper is under review at npj Genomic Medicine. The editor invited 10+ reviewers; two accepted, one review is in, and a third reviewer is being sought. Responses may be due around November.
• Co-occurring categorical variant model (today's main topic).
• Requested by implementers but not yet pushed: cDNA variant type recipe, zygosity and pathogenicity constraints.
• Ongoing: training materials, the GKM Starter Kit, and representation of systemic biomarkers.

3. Synthetic data

• Several groups at the BioHackathon, Plenary and Connect asked whether GKM has a standard synthetic data set. It does not.
• Uses raised: testing pipelines and edge cases, study replicability (reproducible pseudo-randomised data), benchmarking tools, demos and training, and sharing in less secure environments.
• Beth compared it to positive controls in clinical labs (e.g. a commercial RNA fusion control with ~18 fusions and splice variants) used to rule out chemistry problems.
• Bob asked whether phenotype data would be included. Daniel said it could be; he saw a UK tool with synthetic patients and phenotypes.
• Different studies need different properties, so scope is unclear. One idea: derive variants from ClinVar, separate them from their classifications, and use them to test whether pipelines reach the known answer. Larry noted this is easy with the data sets now being produced.
• Brendan asked whether Starter Kit vignettes might cover the need; Larry noted that "nothing is frozen", as vignettes point to externally controlled data.
• Not on the active roadmap. Daniel will open a GitHub discussion to collect input.

4. Composite categorical variants, phase and star alleles (Brendan)

• From the spring implementer survey, co-occurring variants and star alleles are blocking: co-occurrence for the project Brendan leads, a Japanese individual-centric genomics platform and (less urgently) Epic; star alleles for ClinVar-GKS and MaveDB. Alex noted the ClinGen PGx group was missing from the slides; Brendan confirmed Larry's feedback was on ClinGen PGx's behalf and had been mis-attributed.
• Brendan used Claude to help draft the slides, which he and Daniel reviewed and edited.
• Approach follows Alex's guidance: implementer use cases first, then the information model, then the schema.
• Updates to the open PR: optional phase relation (cis / trans / unknown) on the composite categorical variant; compound-het examples; a draft star allele recipe and a diplotype (star allele set) recipe, each with one example, based on Larry and Alex's scratch branch.
• Larry asked for clear definitions of the co-occurrence types (haplotype, compound het, genotype, co-occurring in general). He noted a diplotype is a specific type of genotype.
• Star alleles: open question whether to describe the full reference set (including reference-matching positions) or only the defining variants. Larry said the "star map" should always give the full reference of all haplotype locations and will need versioning. ClinPGx will sign off on final star alleles.
• Phase is proposed to live on the composite rather than on recipes. James Stevenson cautioned in the PR that any categorical variant could be expressed as a composite, which is not the intent.
• Overlap with VRS: VRS has a cis-phased block (formerly "haplotype", renamed at the SV-SIG's request). Whether these concepts belong in Cat-VRS or VRS is unresolved.
• Bob asked whether multi-gene co-occurrence (e.g. EGFR mutation plus MET amplification) is in scope. Brendan confirmed it is, with examples such as BCR-ABL1 plus a specific amino acid change, and LOH events.
• Wild type: Bob asked for a definition. GKM has none; the examples use a negated sequence location within a composite. Larry said gene location representation must be settled before any gene-specific Cat-VRS work, and defined wild type as the reference sequence bases underlying the feature. Bob asked whether wild type can be called if only WES was performed.
• Beth asked how reversion and resistance mutations fit (e.g. versus TP53 wild type plus MDM2 amplification). Larry argued compound hets are a distinct category: in trans, within the same gene, with a special relationship to a primary allele; as a package it is a genotype, possibly a systemic rather than molecular variant. Beth shared EGFR L858R + T790M and a BRCA1 reversion example.
• Brendan noted JSON Schema may not be able to enforce such constraints (e.g. both members within one location).
• Daniel clarified the three-way split (star alleles, compound hets, composites) reflects implementer requests; the proposed model handles all with one mechanism.
• Key cross-spec question (Daniel): VRS is modelling genotypes and haplotypes as assayable observations, while PGx star alleles are categorical knowledge entities. The two specs must stay aligned so VRS cis-phased blocks can be decomposed and recomposed as composite categorical variants.
• In chat, Larry suggested hardening the existing categorical variant classes and making Cat-VRS work well and pragmatically with molecular subclasses before composites. Brendan agreed this matters but said a draft composite model is still needed to unblock implementers.

Decisions and consensus

• No final decisions on the composite model were taken; open questions move to the integrated GKM meetings from November, with async work in between.
• Co-occurring variants and star alleles stay the top development priority because they block implementers; a draft model should be released for implementers to try.
• Phase relation is an optional attribute on the composite categorical variant, not on recipes (current PR direction).
• Compound hets should be treated as a distinct category, not lumped in with general co-occurrence (Larry, with Beth's agreement).
• Synthetic data is not on the active roadmap; input will be collected through a GitHub discussion.

Action items

Open questions

• Do composites, haplotypes and star alleles belong in Cat-VRS, VRS, or both with defined interoperability?
• Should star alleles describe the full reference set or only defining variants, and how is the star map versioned?
• How should reversion and resistance mutations be classified: composite, compound het, co-occurring, or a separate category?
• How should GKM define "annotation" versus "evidence", and "wild type"? Can wild type be asserted when only WES was performed?
• Can JSON Schema enforce constraints such as both members of a composite falling within one location?
• How do we stop composites being used for every categorical variant?
• Are there implementer use cases for co-occurrence not yet captured?
• What would a GKM synthetic data set need to contain to be useful?

AI generated notes

2026-10-07

Leads: Brendan Reardon, Daniel Puthawala

Participants: Kori Kuzma, Alex Wagner, Beth Pitel, Larry Babb, Mrinal Thomas, Bob Dolin

Link to meeting recording: https://us02web.zoom.us/rec/share/u0LPOopNT7Gay9cpGEP8B4q851G8FbgQ7Bs2JFho_SVF4wCUcAWjQjC8KomSEatG.1vBKxecXrMg77rIc 

Meeting summary:

1. Announcements (Brendan)

• Rebrand: Cat-VRS, VRS, VA-Spec and GKS Core are now grouped under GKM (Genomic Knowledge Model).
• GKM Starter Kit was announced at Plenary and Connect and was well received. Kori and Larry got special thanks for driving it over the summer.
• Schedule change: from November, GKM meetings will be 11:00–12:00 Eastern on the 1st and 3rd Thursdays of each month. A formal email and Slack notice will follow. There is one more meeting on the current schedule before the switch.
• v1.1.1 patch released last week. It replaces GKS / GKS Core references with GKM. There are no functional changes to classes or schemas.
• Bob Dolin is back after five months away.

2. Connect debrief and progress since spring (Daniel)

• v1.1.0 (about 1–1.5 months ago) added two new constraints (function and adjacency) and two new recipes (functional variant and gene fusion). Implementer feedback is wanted so these can eventually move to trial use.
• Documentation: Brendan led a refactor to make docs consistent across GKM products, and Larry reworked docs for v1.1.1. A side benefit: LLM coding assistants can now use the Cat-VRS-Python docs well, which they couldn’t a few months ago.

New adopters

• MaveDB / MaveMD (counted as a win, though talks with Alan began at Spring Connect).
• Pan-Asia Variant Review Panel Expert Board (from the Biohackathon in Japan). This is a software suite for international VCEP-style curation across East and Southeast Asia (e.g. the Philippines, Thailand, Japan) using the ACMG 2015 guidelines. It’s deliberately independent of NIH tooling and includes multilingual translation. It uses VA-Spec pathogenicity propositions with Cat-VRS for subject variants at the publish/reuse step (step 6). It’s in pilot, with national-level reviews next.

• Larry’s question: how does the project tell “annotations” apart from “evidence”? Daniel’s answer:

• Annotations are VEP and gnomAD data tied to rows in the VCF.
• Evidence comes in separate accompanying files (PubMed IDs, therapeutic indications, study results).

• Larry warned that GKM itself has never formally defined “annotation”, even in VA-Spec. He wants care taken before claiming support.

• DARA (Thai population genomics project). It holds population EHR data, with phenotypes in Phenopackets, VRS for specific alleles, and Cat-VRS for population-characteristic categorical variants.

Current and upcoming work

• Cat-VRS paper is under review at npj Genomic Medicine. More than 10 reviewers were invited and 2 accepted. One review is in, and the editor is looking for a third reviewer. Responses are likely around November.
• Co-occurring / composite categorical variants (the main topic below).
• Requested but not yet prioritised: a cDNA variant type recipe, plus oncogenicity and pathogenicity constraints.
• Continued work on training materials, the integrated GKM Starter Kit, and representing systemic biomarkers.

3. Synthetic data (Daniel), raised for discussion only

• Synthetic data came up repeatedly at the Biohackathon, Plenary and Connect. People asked whether GKM has a reference synthetic dataset, which it doesn’t.
• Possible uses:

• testing and validating pipelines and edge cases
• study replicability (reproducible pseudo-random datasets)
• benchmarking
• demos and training
• security and governance

• Beth: clinical labs routinely use synthetic positive controls, such as a commercial RNA fusion control with about 18 fusions and splice variants, as a quality-control baseline. GKM could offer a similar “smoke-tested” VCF so implementers can confirm their tools produce the expected output.
• Bob: asked whether phenotype data would be included. Daniel said it could be. He cited a UK researcher (possibly Edinburgh) with a synthetic patient tool.
• Daniel’s example: take ClinVar variants, separate them from their classifications, and use them as a test set for variant-matching pipelines. The catch is that different uses need different dataset properties.
• Brendan: the Starter Kit vignettes may cover part of this need, though they point to external content and aren’t frozen.
• Outcome: not on the roadmap. Shelved for now, with a GitHub Discussion to be opened.

4. Composite categorical variants and star alleles (Brendan)

Context

• The spring implementer survey found that co-occurring variants and star alleles are the only two features blocking implementers:

• Brendan’s own project (transcribed “Vic”) and James Stevenson need co-occurrence.
• A Japanese individual-centric genomics platform (name unclear) needs it.
• Epic needs it, though less urgently.
• Star alleles are blocking for ClinGen PGx (Brendan corrected his earlier attribution to ClinVar GKS) and MaveDB.

• Following Alex’s earlier suggestion, the approach is: implementer use cases first, then the information model (required vs optional properties), then the data model.
• Brendan said the slides were drafted with Claude and then reviewed by him and Daniel.

Updates to the open Cat-VRS pull request

• Phase relation (cis / trans / unknown) added as an optional attribute on the composite categorical variant, as several implementers including Epic asked.
• Compound heterozygote examples.
• A draft star allele recipe and a diplotype / star allele set recipe, each with an example. These build on Larry and Alex’s summer scratch branch.
• A draft Read the Docs build is in the PR.

Open questions (not to be resolved today)

• Are there implementer use cases still missing?
• Should star alleles describe the full reference set, including reference-matching positions, or only the variant positions?

• Larry said in chat that the star allele map is meant to always give the full reference for all haplotype positions, and needs versioning because it changes over time.

• Does phase belong on the composite or on the recipes? The current view is on the composite.
• Single-variant haplotypes. James noted in the PR that any categorical variant could in principle be wrapped as a composite, which isn’t the intent.
• Cat-VRS vs VRS: VRS already has a cis-phase block (essentially a haplotype). Which spec should own these concepts?

Discussion

• Bob: asked whether co-occurrence covers things like an EGFR mutation plus MET amplification, which have distinct treatment implications. Brendan said yes, that’s an explicit use case. Other examples include BCR-ABL1 plus ABL1 T315I, LOH events, and wild-type representations.
• Bob: asked for a working definition of “wild type”. There isn’t one across GKM, and it’s under active discussion. In the drafts it’s modelled as a negated sequence location within a composite. Larry added that the group must first agree how to represent gene locations before doing gene-specific variants.
• Beth: asked where reversion and resistance mutations fit. They’re close to compound hets but not both loss-of-function, and differ from cases like TP53 wild-type plus MDM2 amplification. Are they composite, compound het, co-occurring, or something else?
• Larry: said they’re a separate category. A compound het is a special relationship: two alleles in trans, within the same gene but not necessarily the same position, with the partner allele combined with the primary one. Treated as a package, it becomes a genotype, which raises the question of whether it’s a molecular or a systemic variant. He cautioned against lumping these together and pushed for clear definitions of haplotype vs compound het vs genotype vs general co-occurrence.
• Brendan: JSON Schema may not be able to enforce these relationships, such as both members being constrained to one location, even with subclassing or recipes.
• Daniel: the three-way split (star alleles, compound hets, general composites) reflects what implementers asked for. The proposal is one unified composite model in Cat-VRS that covers all three.
• Daniel’s key concern for GKM leadership: keep Cat-VRS and VRS aligned. VRS models genotypes and haplotypes as assayable observations, while PGx star alleles are categorical knowledge entities. Composites should be able to decompose to and recompose from VRS cis-phase blocks so the two specs stay interoperable.
• Brendan’s closing point: better subclassing matters, but because these are the only blocking features, a draft model needs to go out soon so implementers can start using it.

Action items

(AI generated notes)

2026-09-02

Leads: Brendan Reardon, Daniel Puthawala

Participants: Kori Kuzma, Kyle Ferriter, Catherin Procknow, Beth Pitel, Melissa Cline

Link to meeting recording: https://us02web.zoom.us/rec/share/CyzJt1jQmV3rYloi9Tl9CmulCQSmLio_m6XZ6hXYifmh2aZ9s_a4hNVpS1r-xvGV.6bqqRh-3zJMQdOvt

Action items:

• Brendan - Open/share the GitHub discussion from Alex on definitional vs. supporting properties for group review, if helpful.
• Group (all) - Gather more clinical examples of phasing/AND-OR logic use cases, especially outside pharmacogenomics/oncology (e.g. rare disease), and identify relevant guideline references.
• Daniel / Brendan - Continue reconciling proposed phase-relation data model (criterion-level vs. composite-level vs. inherited subtype) against the existing HGVS "two-list" cis/trans convention that Kyle surfaced.
• Work Stream leadership - Resolve the scope boundary between VRS (new genotype object) and Cat-VRS (categorical variants/star alleles), including how the two will interact.
• All - Use the Plenary (Singapore, late Sept–early Oct) and the September 23 think tank to continue cross-product discussion on phasing/star alleles, particularly with the MaveDB team present.
• Team - Continue development on the open PR for composite categorical variants (negation normal form model) and associated Read the Docs documentation/examples.

Meeting summary:

1. Administrative / Organisational Updates

• GA4GH Plenary is coming up in Singapore (late Sept-early Oct), currently sold out. Attendees from this group include Kori and Melissa and Daniel.
• Rebranding: VRS, Cat-VRS, VA-Spec, and GKS Core are being reorganised under a new umbrella name, GKM (Genomic Knowledge Model), reflecting the addition of new GA4GH products (e.g. future VCF, BAM/CRAM/SAM) into GKS. This isn't a full rebrand so much as a new organisational layer distinguishing the "genomic knowledge modeling" tools from "file format" tools within the broader workstream.
• Meeting consolidation: Moving toward one meeting per week across all GKM products, on a four-week rotation, scheduled to span time zones more efficiently ("meeting time liquidity"). Goal is tighter cross-product agenda alignment and a shared narrative across VRS/Cat-VRS/VA-Spec, which are increasingly seen as one product across multiple repos. Not yet finalised.
• Slack consolidation: Likely merging the various -dev (GitHub alert) channels into a single GKM-Dev channel, and separate product Slack channels into one general GKM channel. Not yet confirmed.
• Next Cat-VRS meeting: September 15 (pending workstream scheduling changes). A think tank is scheduled for September 23, timed to include Plenary attendees (including the MaveDB team).

2. Co-occurring Categorical Variants (CatVars) - Core Feature Discussion

• Recap of implementer survey data (reorganised so rows = implementations, columns = features): Senkei's platform, Macron College Almanac, and Vic need co-occurring categorical variants; ClinVar/GKS and MaveDB need star alleles (a specialised application of co-occurring categorical variants); this is a blocking feature for Dana-Farber's project and for MaveDB.
• Development approach (borrowed from Alex's framework):

• (1) nail down use cases,
• (2) define the information model (definitional vs. supporting attributes),
• (3) define the data model/spec representation.

• Current draft model (open PR) defines two classes:

• Composite Categorical Variant: a set of 1–n elements joined by AND/OR (can nest).
• Categorical Variant Criterion: wraps an individual categorical variant with a present/absent flag (this is how negation is handled - no default value allowed, forcing an explicit yes/no).

• Negation Normal Form (NNF): Daniel presented slides explaining why negation is restricted to only apply at the individual-variant level (not over composite sets). This guarantees any schema-valid composite categorical variant is automatically in NNF, making it canonicalisable and matchable - avoiding the ambiguity/inconsistency problem that CIViC's Molecular Profiles feature has (CIViC only handles this via documentation/best-practice guidance, not schema enforcement, since it was addressed too late in their design process).
• Group identified this as an application of De Morgan's Law.

3. Phasing, Star Alleles, and Compound Heterozygotes

• Extending the model to support phase relationships (cis/trans/unknown - Catherine Procknow noted "unknown" needed since phasing isn't always performed, especially in pharmacogenomics).
• Debate on whether phase relation is definitional (leaning yes - e.g., "trans" only makes sense for exactly two elements) and where it should live in the schema - at the criterion level (per-variant) vs. the composite/relation level (between two sets) vs. as an inherited subtype of Composite Categorical Variant.
• Beth Pitel (clinical lab perspective) noted complexity: phasing isn't always assessable, ClinVar reporting conventions may restrict how results can be combined, guidelines evolve, and short-read sequencing often can't resolve phase for close variants. Real-world value case: two frameshift variants in a tumor suppressor gene in trans is clinically meaningful and would use AND logic; loss of heterozygosity is also relevant.
• Kyle found that HGVS already has partial support for describing phase (grouping variants into two lists - same list = cis, different lists = trans), which the group flagged as a useful existing pattern to reference/reconcile with.
• Open question raised by Daniel: is a simple "two lists" (cis-within, trans-between) model sufficient, or are there cases requiring independent phase assertions between arbitrary variant subsets requiring more expressive architecture?

4. VRS/Cat-VRS Scope Boundary

• VRS is independently building support for genotype objects, which overlaps with Cat-VRS's work on star alleles/categorical variants. The group needs to determine the workstream-level division of responsibility between VRS and Cat-VRS (e.g., how Cat-VRS's categorical variants should interact with or incorporate a new VRS genotype object). This will need to be resolved at the workstream level in the coming weeks/months.

(Zoom AI generated)

2026-08-05

Leads: Brendan Reardon

Participants: Kori Kuzma, Melissa Cline, Larry Babb, Beatrice Amos, Catherine Procknow

Apologies: Daniel Puthawala

Link to meeting recording: https://us02web.zoom.us/rec/share/wEcH5lUuT-lbgr7oJ0HQzFdDUXikFIcAvDHmKs2y2TK-RiiSvi6Nqf2LrApC3TaJ.le4MGwG-jPJ1S2sp 

Announcements

• 14th Plenary: Singapore: GKS has fewer sessions; Brendan not attending, but Larry, Daniel, and Alex will be there.
• Implementer survey: Discussions from this year’s survey are being added to GitHub - please review and contribute.
• Shout-out: Senkei’s company featured in a GA4GH Product Showcase post for incorporating GKS standards🎉.
• Upcoming releases: All main GKS products getting minor releases (Cat-VRS → 1.1; VRS and VA Spec also updating). Triggered by a backwards-incompatible change in GKS Core trial-use data types (Mappable Concept and Concept Set now inherit from Element instead of Entity, adding a required type attribute).
• PDAP discussion: Breaking/trial-use changes may need “PDAP Light” rather than full PDAP. Larry and Melissa confirmed trial-use items get special handling; process details still being clarified.

Meeting summary:

Main topic: Composite Categorical Variant (co-occurring / categorical co-variants)

Brendan opened a PR in Cat VRS implementing the proposal discussed previously. Goal is dedicated review time (especially feedback from implementers James, Mrinal, and Senkei, who flagged it as near-term/urgent).

Core design:

• New class: Composite Categorical Variant.
• Similar to CAIC molecular profiles but limited to AND and OR (no NOT at the composite level).
• Elements can be nested composites or a Categorical Variant Criterion wrapper.
• Criterion wraps a single categorical variant + a presence flag (present/absent) for negation.
• Supports nesting; designed to avoid multiple equivalent representations of the same logic (avoids ambiguous parenthesization of AND/OR/NOT).
• Six real-world examples included (e.g. BCR-ABL1 fusion + ABL1 missense; hormone-receptor positive status with OR combinations; KIT D816V absence; multi-position / whole-gene wild-type; TP53 wild-type + MDM2 amplification).

Open design points / discussion:

• Supporting single-element negation via the criterion (vs. a separate pure-negation construct). This keeps flexibility for real use cases but means VA Spec will need to support the new composite type.
• Wild-type modeled as absence of variation in a sequence/gene region.
• Distinction between “affirmatively absent” vs. “not measured / unknown” (possible future “ambiguous” value or measurement constraints, especially relevant for IHC protein markers like HER2).
• Phasing / compound hets / star alleles: Not in current scope. Phasing, cis/trans, zygosity, and allelic state would need additional fields or new classes (possibly involving VRS). Star-allele work is deliberately slowed pending more engagement; current design intended as a backwards-compatible building block.
• Larry raised compound heterozygous cases (rare in ClinVar, require trans + heterozygous state, usually same gene). Brendan will check ClinVar examples.
• Catherine noted Epic does not use Slack; Brendan will email her and Mrinal with links instead. Suggested possible “show-and-tell” of how different implementers currently model these cases.
• Plan: Keep draft PR open ≥2 weeks for async feedback; re-engage star-allele thread; gather modeling examples from Catherine/Mrinal and compound-het cases.

Prostate-cancer / oncogenicity side discussion (Melissa)

Brendan described plans (independent of a pending DoD/VA-related grant) to perform oncogenic assessments for prostate-cancer HRD genes (BRCA1/2 + others such as ATM, CHEK2, PALB2, RAD51C/D, PTEN, etc.). Many lack functional screens; he tracks emerging papers (Melissa shared a CHEK2 functional-assay effort by Czech researchers). Representation approach: protein-sequence-consequence / amino-acid-change defining alleles under gene concepts, with VA Spec oncogenicity statements. Once the composite feature lands, their knowledge base can fully validate against GKS. They already collaborate closely with Veterans Affairs tumor boards.

Main action items:

• Brendan: Check ClinVar for compound heterozygous (compound het) examples and discuss the use case on Slack with Larry.
• Brendan: Email Catherine / Mrinal with the PR/discussion content and links.
• Brendan: Re-ping / re-engage the star-allele Slack thread to solicit feedback.
• Brendan / group: Keep the Composite Categorical Variant draft PR open for at least 2 weeks to gather async feedback.
• Catherine / Mrinal: Share examples of how they currently model co-occurring variants, phasing, cis/transrelationships, etc.

(AI-generated summary)

2026-07-21

Leads: Daniel Puthawala, Brendan Reardon

Participants: Larry Babb, Daniel Cameron, Senkei Umehara, Kori Kuzma, Worawich

Link to meeting recording:

Meeting notes:

Senkei’s work with the Individual-Centric Genomics Platform was highlighted in a blog post on GA4GH Products in Action!

In the example, you have KRAS wildtype. Is this restriction on NOT problematic for expressing druggability. Eg.g NOT tp53 wildtype && KRAS mutant && BRCA wildtype

You (Jul 21, 2026, 8:25 AM)

Where:

() = criterion - possibly negated individual cater

[] = ComplexCategoricalVariant

AND[(NOT TP53 wildtype), (NOT KRAS wildtype), (BRCA wildtype) ]

KRAS wild type and NOT NRAS wild type

You (Jul 21, 2026, 8:33 AM)

MDM2 inhibitors: (MDM amplified or oveexpressed) AND TP53 wild type

[ AND [OR (MDM Amplification Variant), (MDM Expression Variant) ], TP53 Wildtype]

Meeting summary:

Quick recap The meeting focused on discussing a proposal for modeling co-occurring categorical variants with Boolean operators in Cat-VRS. Brendan presented the initial pitch, which included new objects like a complex categorical variant and a categorical variant criterion to handle AND, OR, and NOT logic. Daniel Puthawala explained the design decision to restrict negation to individual categorical variants to ensure normalized and comparable representations. Daniel Cameron raised concerns about the practical usability of this approach, particularly regarding the representation of "not wild type" conditions for drug eligibility criteria. The group also discussed potential names for the feature, with "composite categorical variant" receiving initial support. The conversation ended with an invitation for further community input on the proposal and examples to test the model.

Full summary:

Categorical Variant Modeling Discussion

The team discussed upcoming events, including the 14th plenary in Singapore from September 28th to October 2nd, and noted that Senkei and Daniel will be attending. They highlighted Senkei's recently published blog post about the Cat-VRS and VSPack, and discussed the potential inclusion of a starter kit in the near future. The main focus of the meeting was to review a proposed modeling approach for co-occurring categorical variants with Boolean operators, which will be further discussed in the Asia-specific think tank session and potentially shared in the categorical variant channel for feedback.

Co-occurring Categorical Variants Implementation

Brendan discussed implementing co-occurring categorical variants, which is a long-standing GitHub issue that the specification currently does not support. He explained the need to represent combinations of biomarkers or categorical variants using Boolean logic (AND, OR, and NOT) and provided examples like BCRABL1 and hormone receptor status. The team discussed design options for implementing this feature, including using arrays or nested sets, and considered whether to build or modify the existing concept set feature from GKScore.

Categorical Variant Implementation Proposal

The team discussed a proposal for implementing complex categorical variant objects with properties including type, array elements, and operators. Brendan presented a graphical layout of the governance process and demonstrated how real-world examples like BCR-ABL1 and hormone receptor positive status would be modeled using the proposed feature. The discussion highlighted challenges with negation logic and Daniel recommended creating a wrapper object for representing negated or present categorical variants rather than using complex negation operators.

Categorical Variant Normalization Challenges

The team discussed challenges with normalizing complex categorical variant sets, particularly around handling negation operations. Daniel Puthawala explained that allowing broad scope for logical relations like "not" could create redundant representations, so they proposed requiring negation normal form where individual components can be negated but not entire sets. Brendan demonstrated this approach using the NRAS and KRAS example, showing how to specify negated tags under each array element. Daniel Cameron raised concerns about practical usability, questioning whether this approach would adequately support complex drug eligibility criteria involving multiple gene variations.

Representing Non-Wild Type Mutations

The group discussed how to represent "not wild type" mutations in their sequencing assay system. Daniel Cameron explained that in drug treatment contexts, they need to determine whether genes are intact or have single/double hits, and suggested using AND operations to represent combinations like "KRAS wild type and not NRAS wild type" rather than creating separate composable blocks. The discussion focused on whether to allow "not" to have scope over multiple categorical variants or restrict it to individual variants, with Daniel Cameron noting that using separate primitives for "gene is broken" and "gene is not broken" might be simpler.

Categorical Variant Representation Discussion

Daniel Puthawala and Daniel Cameron discussed the logical correspondence between broad and narrow negation in representing categorical variants, particularly focusing on how to represent wild type versus non-wild type individuals at the base categorical variant level. They explored two approaches: using gene function constraints or examining molecular sequences through allele constraints. Larry joined the discussion and confirmed that a gene wild type could be represented as an allele where the sequence matches the reference with no variations. Brendan clarified that the example discussed was from FDA documentation.

Categorical Variant Composition Feature

The team discussed implementing a new feature to allow composition of categorical variants in Cat-VRS, with Daniel Cameron providing specific examples of how this would be useful for representing drug usability criteria like MDM2 inhibitors and TP53 mutant drugs. Brendan announced that a draft implementation would be developed in the first week of August, with two weeks left for community feedback before implementation. The team also discussed potential naming options for the feature, with "composite categorical variant" receiving initial support, though final naming decisions were left open for further community input.

Generated by AI

2026-07-01

Leads: Daniel Puthawala, Brendan Reardon

Guest speaker: Jennifer Bowser

Participants: Beatrice Amos, Worawich, Kyle Ferriter, Alex Wagner, Kori Kuzma, Catherine Procknow, Mrinal Thomas, Arpad Danos, Terry O’Neill

Link to meeting recording:

https://us02web.zoom.us/rec/share/KJh7B8Gc74hY6l_eF8Jl9DiYT75I__GAFsF3sln0o9x3DGE4317iUmkszEwvbKnF.q_-B2UPVGA7V4DRW

Meeting summary:

Announcements:

• GA4GH 14th Plenary: Singapore, Sept 28–Oct 2. Register soon (especially Connect).
• Cat-VRS/GKS overview paper rejected by Nature Biotechnology (fast rejection welcomed); resubmitting to Nature Genetics, then possibly MPJ Genomic Medicine.
• New implementation guidance for all Cat-VRS concepts live in Read the Docs.
• Roadmap discussion topics opened (new constraints, recipes, etc.) - review in agenda, GKS Cat-VRS Slack, and GitHub.
• GKS Core issue #128: Proposed changes to Maple concept/Concept Set - please review and comment.

Jennifer Bowser presentation: slides 

Jennifer Bowser from Alex Wagner’s lab at Nationwide Children’s Hospital (NCH) presented on AnyVar and the related AnyVLM project, highlighting their integration with Cat-VRS.

AnyVar is a user-friendly, open-source REST API for variant storage and retrieval. It accepts variants in multiple formats (HGVS, VCF, SPDI, etc.), normalizes them to VRS, and stores them with rich mappings including liftover between GRCh37/GRCh38 and traversal of the central dogma (genomic ↔ coding ↔ protein). It supports lookups by VRS ID, genomic range, and mapping relationships. For Cat-VRS integration, AnyVar is implementing support recipe-by-recipe (starting with canonical alleles and protein sequence consequences), using dedicated endpoints/tables and custom classes for stricter validation and ID handling rather than relying directly on the Cat-VRS Python models.

AnyVLM is a ready-to-deploy VLM network node built on top of AnyVar. It enables knowledge bases to share cohort allele frequency (CAF) data for rare disease research by simplifying variant ingestion, storage via AnyVar, and standardised query/response handling across the network. Jennifer noted interest in leveraging Cat-VRS canonical alleles and liftover mappings to streamline multi-build CAF responses in the future.

The team is actively developing this and welcomed feedback on the approach.

Q&A summary:

Brendan questioned the ID property and user-supplied IDs, initially viewing AnyVar as a centralised/authoritative store (potentially on top of Variant Normaliser).

Jennifer clarified deduplication occurs on content, while Alex emphasised AnyVar is a standalone, deployable instance per site/resource (e.g., MGB clinical cohort, VLM nodes, future Molecular Oncology Almanac), not one global database.

Kyle noted the idea is to share underlying VRS objects while allowing Cat-VRS structures to be stored multiple times with different IDs.

Catherine asked about the backend; Jennifer confirmed Postgres as primary, with DuckDB support (Snowflake being phased out).

Beatrice asked about recording the presentation for the GKS YouTube channel; Jennifer agreed.

Daniel asked about coordination between VLM/AnyVLM and Beacon.

Alex (with input from Kyle and Beatrice) explained ongoing discussions and some API alignment (Beacon-adjacent elements in VLM query/response formats). However, VLM networks are private, reciprocal “share-and-share-alike” networks focused on single-variant lookups for participating hospitals/research groups, making broad open discovery standards like Beacon lower priority. Use cases are related but not fully aligned.

Kyle asked what richer search features people want beyond region searches.

Discussion highlighted Cat-VRS-enabled queries (molecular consequences in genes), copy number alterations (with noted representation tensions), k-nearest/approximate matches for rare variants, and future support for RSIDs, star alleles, fusions, etc. (not immediate priorities but open to community needs).

Daniel confirmed AnyVar supports VCF file uploads and gnomAD-style VCF strings, which was key for ingesting large public datasets like GREGoR.

Brendan asked how best to provide feedback on AnyVar and Cat-VRS integration. Jennifer recommended GitHub discussions on the AnyVar repo.

Additional implementation notes from Jennifer:

• Each Cat-VRS recipe gets its own registration/retrieval endpoints and storage tables for cleaner validation.
• IDs should come from users/external references (e.g., ClinGen) rather than being auto-generated.
• Future work includes more Cat-VRS recipes for AnyVar and leveraging canonical alleles/liftover relations in AnyVLM to streamline cross-genome-build CAF queries.

(Aided by Zoom AI)

2026-06-16

Leads: Daniel Puthawala, Brendan Reardon

Participants: Beatrice Amos, Kori Kuzma, Senkei Umehara, Mrinal Thomas, Wes Goar

Action Items:

• Brendan to coordinate with Melissa and schedule a meeting to finalise submission steps.
• Review and merge the implementation guidance pull request after incorporating feedback from the meeting (Brendan).
• Add brief implementation guidance for non-concrete classes (e.g. Canonical Variant and Constraint), directing users to relevant subclasses (Brendan).
• Clarify guidance on map concepts, including their use for regions other than genes (e.g., exons, domains) when sequence locations are unavailable (Brendan).
• Revise wording in the Functional Constraint guidance, replacing "annotate" with clearer terminology such as "define" (Brendan).
• Improve documentation navigation, particularly by making examples easier to find and streamlining the user journey (future documentation work).
• Add additional adjacency examples, including exon-level fusion representations relevant to implementer use cases (Brendan, with Wes as reviewer). GitHub Issue created.
• Tag Daniel for re-review once updates are committed, with the goal of merging later in the week (Brendan/Daniel).

Link to meeting recording: https://us02web.zoom.us/rec/share/p7aREgUZuM8mNdZw9Vnn11WxCXt1w8fn0mQsitUCzSJX9yOT0pd5EXJtaYwWnySc.CSr4vct1zrsIWxK7 

Meeting summary:

Manuscript:

The Technology paper has not yet been submitted; a short extension was granted to allow final reviews. All but one reviewer have completed their comments, with the final feedback expected tomorrow. Once remaining comments are reviewed and resolved, the paper will be submitted later this week. Overall, the paper is essentially ready, with letters completed and only final review/submission activities remaining.

The group used the meeting to review and provide feedback on new Cat-VRS implementation guidance documentation. Feedback was overwhelmingly positive, with participants highlighting the improved examples, tables, and overall usability for newcomers.

Key discussion points included:

• adding brief guidance for non-concrete classes,
• clarifying use of map concepts beyond genes,
• refining wording around functional constraints, and
• expanding examples for exon-level fusion matching.

Additional feedback focused on improving the documentation journey by surfacing practical examples earlier. Brendan will incorporate the suggested changes and continue refining the documentation before merging the pull request, with further review expected later this week.

2026-05-19

Leads: Brendan Reardon, Daniel Puthawala

Participants: Senkei Umehara, Beatrice Amos, Larry Babb, Alex Wagner, Tristan Nelson, Worawich

Action Items:

Link to meeting recording: https://us02web.zoom.us/rec/share/8M0BrtEBTMPYPu8QTsQnQjuLz5s1yrcWEY2j6nn8mrFb9d2bG7lbo_Iee0SWAw_6.Ov_fo7_depzT9d_a

Meeting summary:

The meeting focused on reviewing results from an implementer survey and using them to help shape roadmap priorities leading toward a 1.1 release. Responses were received from implementations, and because the original survey lacked clear prioritisation, follow-up messages were sent asking respondents to classify requested features as blocking, near-term (3-12 months), or future. The most frequently requested and highest-priority themes were

• support for pathogenicity/oncogenicity features,
• co-occurring variants, and star alleles,
• with co-occurring variants and star alleles also receiving the only clear “blocking” signals in the dataset.

Discussion highlighted that co-occurring variants and star alleles likely share overlapping representation challenges, even if they are conceptually distinct in some contexts, suggesting potential for shared underlying mechanisms and parallel development. Other notable requests included pathogenicity and oncogenic constraints as the next most common near-term needs. The group agreed these findings point to a clear demand for more complex Cat-VRS modelling capabilities, and proposed setting up dedicated discussion threads and issues for each feature area, with contributors from the responding implementations invited to participate in detailed design discussions.

The discussion moved into clarifying how pathogenicity and oncogenicity constraints should function within Cat-VRS and how they relate to existing VRS concepts. Larry sought to confirm whether these constraints effectively define clinically significant variant categories using frameworks like ACMG. Daniel clarified that the intent is not to encode clinical interpretation or guideline-based assertions, but rather to provide a way to label and match variants based on functional or biological properties already determined by implementers (e.g. oncogenic, gain-of-function). These labels would act as searchable constraints rather than authoritative judgments, and would sit alongside, but separate from, evidence-based assertions handled by VA spec.

Participants further distinguished between Cat-VRS as a system for defining categorical variant sets (e.g. “oncogenic TP53 mutations”) and VA spec as the place where supporting evidence and clinical interpretation are recorded. The group agreed that oncogenicity and pathogenicity constraints would be applied over feature-based variant sets (gene, exon, or region-level definitions), allowing users to filter and retrieve variants based on those properties. Discussion also touched on how multiple constraints could be combined (e.g., gene + functional effect + pathogenicity) to create more specific queryable sets, without requiring a formal “recipe” mechanism in the core message format.

Finally, there was reflection on whether constraints should be classified as “defining” versus “optional,” with Larry proposing a clearer conceptual separation between core defining features (such as gene or location, which establish the variant set) and additive qualifiers (such as pathogenicity or oncogenicity). Daniel noted that the underlying VRS constraint model does not enforce such a distinction formally, but that implementers can choose how to treat constraints in practice, often using recipes for convenience rather than as a required structural element. The conversation closed with some concern from Larry that consumers need a consistent entry point for interpreting categorical variants, emphasising the importance of a simple, predictable model for downstream users rather than relying heavily on external documentation or optional configuration patterns.

The discussion opened with a continued reflection on how to structure Cat-VRS constraints, with Brendan revisiting earlier debates about whether constraints should be grouped into required versus optional categories. While acknowledging prior hesitation around onboarding complexity, he suggested that clearer categorisation could improve documentation and usability as the project matures. He also defended the role of “recipes” as valuable onboarding tools that provide quick-start patterns for common variant types, even if they may be less useful for downstream consumers who are focused on interpreting raw data rather than constructing it.

Larry agreed in part but reiterated his concern that recipes do not support computational consumption well, since users ultimately receive data without knowing which recipe produced it. This led into a broader discussion about how implementers interpret and consume categorical variants in practice. Alex then shifted the conversation toward roadmap alignment with real implementation work, highlighting ongoing efforts such as the AnyVar project and suggesting that feedback from production usage should directly inform which models are prioritised for maturation between draft, trial, and 1.1 readiness stages. This was broadly welcomed, with agreement that implementer feedback loops should play a central role in roadmap decisions.

The group then discussed upcoming collaboration opportunities, including potentially inviting implementers working on AnyVar and related systems to present their experiences in early June. Brendan outlined several ongoing roadmap activities, including creating dedicated discussion threads for each requested feature, improving documentation accessibility, and refining implementation guidance ahead of the 1.1 release. He also noted planned improvements such as clearer navigation between “latest” and “stable” documentation, better onboarding support, and aligning documentation updates with the 1.0 publication baseline.

Additional technical discussions covered friction points in current modelling, including copy number constraints, annotation of concept types, and ongoing debate about how relations and match characteristics should be represented in defining allele and location constraints. Some of these were identified as likely “spicy” discussion topics for upcoming implementation guidance meetings due to differing implementer needs and evolving specifications. The group also highlighted the need to simplify and externalise high-level messaging about Cat-VRS particularly for non-technical stakeholders, including clearer value proposition narratives to support adoption decisions.

Towards the end of the meeting, participants reflected on the tension between stabilising the model and continuing iteration based on early implementation feedback. Alex framed this in terms of a maturity model approach, suggesting that focused testing and refinement between 1.0 and 1.1 would help stabilise the system for broader adoption. Brendan and Daniel agreed, emphasising ongoing documentation work and the importance of making the system easier to explain, trial, and adopt, while still actively incorporating feedback from implementers. The meeting closed with a shared recognition that early adopters are essential to shaping the system, and that continued discussion and iteration with implementers will be central to progressing toward a more mature and usable release.

(Generated by Zoom AI)

2026-04-21

Leads: Brendan Reardon, Daniel Puthawala

Participants: Senkei Umehara, Parijat Kundu, Larry Babb

Action Items: (Zoom AI generated)

• Senkei: Write a report-out/write-up for colleagues about the activities of GA4GH (including internal Discussion session).
• Daniel: Help Senkei with writing the report-out/write-up for GA4GH as needed.
• Brendan: Open an issue to add a maturity dashboard to the example/documentation page.
• Larry: Share the code and/or do a one-off demonstration of the maturity dashboard workflow/action for the team.
• Daniel and Brendan: Reach out to implementers who requested features in the survey to determine urgency, timeline, and effort commitment for each requested feature, and form development teams for roadmap items.
• Daniel and Brendan: Populate the GitHub project board with specific features, assigned teams, and timelines based on implementer input.
• Team (implied Daniel/Brendan/Larry): Audit all documentation/examples to replace made-up examples with real, live examples and clearly explain the value proposition and use case for each.
• Larry and Alex: Meet to start prepping the fundamental design for star alleles (whether in Cat-VRS, VRS, or genotypes/haplotypes), as part of ongoing collaboration with the ClinGen PGx team.

Link to meeting recording: https://us02web.zoom.us/rec/share/fLK-WyD8sEQTqCiRNTi6iakiJG5t8WDdv4NQ1NAS992rBeVhTf_PmSIfhLKOTJ_e.4I28DBvaRfIX1olJ 

Meeting summary:

Connect, Montreal was productive and full of valuable discussions.

Brendan - the implementer survey had been reopened during Connect (10–11 responses received so far). The group agreed that the current input was sufficient to begin identifying priorities and guiding upcoming development work.

Daniel recapped the pre-Connect hackathon held in Montreal, highlighting it as highly productive with multiple breakout groups working on different issues. In his group with Brendan and Melissa, the focus was on improving GKS documentation, particularly by creating a more accessible “quick start” experience to lower the barrier to entry for new users.

Melissa developed a redesigned quick start page aimed at orienting beginners and pointing them toward key resources like schemas, repositories, implementations, and examples.

Brendan worked on automating documentation processes by generating JSON versions of examples (instead of YAML) and creating auto-updating README-style indexes for projects like Cat-VRS and related specifications, making it easier for users to find examples tied to specific constraints. This also addressed prior feedback about improving navigation and clarity, while aligning better with software development practices by separating examples from schema directories.

Daniel’s contribution centered on building an interactive quick start guide using Google Colab, designed to cater to three main audiences: experienced developers, semi-technical stakeholders (like project managers making a case for adoption), and newcomers such as students. The notebook requires no installation and runs entirely in the browser, allowing users to immediately explore Cat-VRS concepts through hands-on examples. It walks users step-by-step through schemas, constraints, and simple data exploration, including interactive exercises and small in-memory datasets to demonstrate searching and functionality. The goal is to provide both practical experience and intuitive understanding, enabling developers to quickly start building, giving less technical users a clear sense of value, and helping newcomers learn by doing. The resource is already available for use - he encouraged feedback to refine it further or expand it to additional topics.

Cat-VRS - Beacon alignment efforts: Daniel explained that Beacon leads are interested in improving support for more complex variant types, such as fusions, long-read variants, and systemic variants, which have been challenging in Beacon V2. The proposed approach is to leverage Cat-VRS for representation and matching capabilities, allowing Beacon to build its query system on top rather than reinventing these components. While there is clear interest from both sides, the group emphasised the need to engage existing Beacon users to validate demand and ensure adoption. Rather than immediately scheduling recurring meetings, the preference is to first define a clear problem statement and project brief, then organise collaboration more purposefully. Any resulting technical outputs, such as API endpoint templates, are expected to be reusable beyond Beacon-specific use cases.

The broader roadmap:

The group reflected on accomplishments over the past year, including the Cat-VRS 1.0 release, governance improvements, new constraints (e.g. function and adjacency), additional recipes, and a preprint publication. Survey feedback highlighted priority areas such as oncogenicity/pathogenicity constraints, support for complex categorical variants, and biomarker-related features.

Planned improvements also include clearer documentation through plain-language glossaries, better implementation guidance, and more user-friendly onboarding materials. The team discussed releasing incremental updates (likely a patch release) and continuing work on testbed implementations and documentation overhauls. A key upcoming focus is enabling complex variant support via Boolean logic, which will be explored further in the coming months.

Additional ideas included developing a “maturity dashboard” to track schema readiness across releases, with Larry suggesting an automated, low-maintenance approach using generated JSON and lightweight visualisation. There was also strong emphasis on prioritisation: future work will be tied more explicitly to concrete implementer needs, including identifying who requested features, their urgency, and their willingness to contribute. The team plans to follow up with survey respondents to form focused working groups and populate a project board with clearly owned and scoped tasks.

A major takeaway from the roadmap session was the need to improve documentation by replacing artificial examples with real-world use cases and clearly articulating value propositions. This is especially important for early adopters, who must justify adoption to stakeholders. The group agreed that documentation should emphasise practical benefits, minimal viable examples, and cross-product integration rather than treating components like Cat-VRS in isolation.

In closing, the group briefly discussed dependencies between Cat-VRS and VRS for handling complex variants such as star alleles and genotypes. While some capabilities may depend on developments in VRS, there is parallel work that can proceed within Cat-VRS, particularly around structuring and combining variant constraints. These areas are expected to be a major focus in upcoming development cycles, with ongoing collaboration across teams.

The meeting ended with agreement on next steps and an emphasis on continued coordination and community involvement.

2026-03-17

Leads: Brendan Reardon, Daniel Puthawala

Participants: Tristan Nelson​, Kori Kuzma, Senkei Umehara, Larry Babb​, Parijat Kundu

Link to meeting recording: https://us02web.zoom.us/rec/share/80sc_VhpzvTWOOVq87iC2G8c3hg51QDU5WQc-iD5zBIbyCdaRiFpq1VUphsWHAFb.sPnuDy3j7hUAF_DV 

Action Items:

• Daniel: Publish the finalised implementer feedback form and distribute the responder link to relevant stakeholders and the Secretariat for broader distribution.
• Brendan: Add a question to the implementer feedback form asking if implementers are using their own custom recipes, and if so, what those are.
• Brendan: Add a question to the implementer feedback form about whether implementers are using Cat-VRS independently or only with Variant Annotation (VA).
• Daniel: Rephrase or clarify the question about complex categorical variants to specifically address co-occurring mutations or haplotypes, as suggested by Parijat.
• Brendan: Add a question to the implementer feedback form regarding the design philosophy of Cat-VRS (whether it is working or not working for implementers), as suggested by Tristan.
• Brendan: Ensure the Google Doc listing Cat-VRS sessions at Connect 2026 is shared with appropriate access and add session times to each entry.
• Brendan: Update the Cat-VRS documentation (Read the Docs) to fully incorporate and highlight described variation examples, as discussed.
• Brendan: Consider developing quick start guides (as a hackathon project) for GKS products, including a flow chart for representation paths (e.g. when to use described variation).

Meeting summary (Zoom generated)

GKS Feedback Form Discussion

Daniel presented a feedback form for GKS implementers to gather input on how the system is working and what could be improved. The form includes questions about constraints, recipes, and additional thoughts, with a focus on balancing detailed feedback with user convenience. Brendan suggested adding a question about custom recipes, which Daniel agreed to implement. The discussion also touched on the distinction between constraints (which require careful consideration) and recipes (which can be more flexible and user-defined).

Cat-VRS Text Variant Handling

The team discussed how to handle text-based variants without computational sequence anchors in Cat-VRS. Larry raised concerns about the handling of described variations and the need for a fallback or placeholder system similar to Versatile's approach. Brendan mentioned that described variation examples exist in the GitHub repository and README, and he planned to improve documentation by highlighting described variation and adding it to the Read the Docs. The discussion clarified that recipes in Cat-VRS define methods for applying schemas rather than just listing variant definitions, with Daniel explaining that recipes allow users to create custom approaches within the overall CAPRA schema constraints.

Cat-VRS Feedback and Features Discussion

The team discussed a feedback form for the Cat-VRS project, focusing on how to compare and work with categorical variants across different implementations. Daniel explained that recipes allow different systems to define constraints for filtering and accepting variants, while maintaining compatibility with general constraint-based methods. The group reviewed potential new features to implement, including co-occurring mutations and haplotype representations, and discussed levels of involvement from implementation teams. Larry suggested adding a question about whether people are using Cat-VRS independently or only with variant annotation.

2026-03-04

Leads: Brendan Reardon, Daniel Puthawala

Participants: Beatrice Amos, Larry Babb, Bob Dolin, Kori Kuzma, Kyle Ferriter, Worawich, Beth Pitel, Mrinal Thomas

Link to meeting recording: https://us02web.zoom.us/rec/share/SUfHzFdWptfc8LFDY2MRwIsJpuVn-8ALZjCVLcoUuQbrQcYVEcYISctTrz8V1jZx.OWHeMSQL0HFCB_BS 

Meeting summary:

The meeting focused on a dedicated reading session for the paper draft, allowing co-authors to provide feedback during a scheduled hour rather than requesting additional time from busy team members.

The team discussed updates to the manuscript, including changes to figures and terminology, with Larry suggesting replacing "recipe" with "category variant type" and "template" with "schema" to align with the VA specification.

Bob provided positive feedback on the AI-assisted figures and discussed potential real-world implementation opportunities with cautious company and Rick for post-student project deployment.

2026-02-04: Adjacency constraint relations

Leads: Brendan Reardon, Daniel Puthawala

Participants: Beatrice Amos, Alex Wagner, Larry Babb, Bob Dolin, James Stevenson, Catherine Procknow, Kori Kuzma, Mrinal Thomas, Worawich, Beth Pitel, Bob Freimuth,

Link to meeting recording: https://us02web.zoom.us/rec/share/-Vu2-H1mEGIL89PRwlzE7EsGJ_sy1udWvTPDdFhu6i-AUwjsrOFwzu8qxAzZQNwQ.DeLs8L6yQjuGjm6N 

Meeting summary:

The meeting focused on finalising design decisions around the adjacency constraint, building on productive discussions and feedback from implementers via GitHub and Slack. The primary objective was to explore and define potential relations for the gene fusion recipe; if relations are defined, the adjacency constraint would be treated as a defining constraint.

Key proposals included adding a relations property to the adjacency constraint, renaming it to the defining adjacency constraint, and requiring the gene fusion recipe to include an “instance” relations term for this constraint.

The group also suggested following up with core implementers in about six months to review how categorical gene fusions are being represented. 

The discussion examined how the relations field should function within adjacency constraints for gene fusion modeling. Relations were defined as directional links describing how categorical variant members relate to a defining element, similar to how genomic variants may “transcribe to” cDNA in other recipes.

Existing recipes (e.g. canonical allele, protein sequence consequence) already prescribe specific relation terms, but gene fusion modeling presents challenges because implementers often represent fusions at the gene level while members capture breakpoint adjacencies at sequence locations, creating a weaker computable link, especially when genes are modeled only as mappable concepts.

Brendan proposed using the coded term instance (from NCI Thesaurus) as the most suitable available relation to express that a specific assayed adjacency is an instance of a categorical fusion, though feedback was sought.

Conceptual modeling questions:

Are defining relations necessary for adjacency constraints? How do categorical variant “recipes” function as class-like definitions? How do implementers or databases interpret and bucket variants computationally?

Larry emphasised the need for clearer categorical classes (e.g. gene fusions vs. sequence variants) and constraints that define what members are valid, while Daniel clarified that recipes and constraints already enable implementers to specify what they accept.

Additional complexity arose around gene representation itself, particularly defining gene boundaries for linking sequence breakpoints, acknowledged as unresolved but out of scope.

The group ultimately leaned toward delaying firm design decisions on relations until more evidence is available.

Alex proposed a data-driven approach: implement draft models, test fusion matching and downstream consumption, and use real implementation feedback to guide decisions. This suggestion received broad agreement. Plans is to continue discussion on GitHub, especially regarding handling multiple known gene partners and data provenance, with further review expected in upcoming meetings.

(Zoom AI generated meeting notes)

2026-01-20: Adjacency constraint follow up

Leads: Brendan Reardon, Daniel Puthawala

Participants: Beatrice Amos, Senkei Umehara, Larry Babb, Parijat Kundu, James Stevenson

Link to previous Meeting Minutes 2024-2025: ARCHIVED] Categorical Variation Group - Minutes document - 2024-2025

Link to meeting recording: https://us02web.zoom.us/rec/share/83cvsRbmlVLG-Bw5YmqywC5049mCKeihkDBmrv_KcSzvd8S1hPK_11O2kEGSsZNZ.DV-ISDItX_ACkYQ9 


Meeting summary:

• Upcoming release is likely a snapshot, not a full release.
• Updated adjacency constraint: removed multiple known gene elements object and replaced it with a concept set; added implementation guidance and a gene fusion recipe.
• Added a realistic BCR-ABL1 transcript fusion example using de-identified, license-compliant data.
• Constrained adjoined elements to specific types (concept set, location, known gene element); Terminus noted as a remaining gap.
• Open questions before merging:

1. How concept sets affect categorical variant matching (implementer-dependent).
2. Whether this should be a defining adjacency constraint (likely no).

The discussion focused on how categorical gene fusion variants, particularly NTRK fusions, should be modelled so their meaning is stable, unambiguous, and useful for matching over time. Larry raised concerns that categorical variants should have fixed definitions and not silently evolve as new fusion partners are discovered, questioning whether a changing or non-exhaustive partner list undermines that stability.

Brendan and Parijat contrasted this with real-world practice, where knowledge bases often associate clinical meaning with a primary gene (e.g. NTRK) regardless of partner, and where concept sets can serve either as illustrative examples or as deliberately constrained, clinically meaningful lists.

Much of the discussion centered on whether concept sets should be interpreted as exhaustive constraints or as non-exhaustive, illustrative lists, and how that interacts with matching semantics. Daniel said that treating concept sets as non-exhaustive risks collapsing multiple distinct representations (unknown partner, empty set, populated set) into effectively the same thing, creating ambiguity and redundancy in the model.

Larry said that constraints should mean exactly what they say: if a categorical variant specifies a list, matching should not extend beyond it; if “anything” is intended, that should be modelled explicitly with a wildcard-like construct rather than an open-ended list.

The group explored alternatives, including renaming “unknown gene element” to something more precise (like “any location” or “unspecified partner”), clearly separating assay uncertainty from intentional wildcards, and treating concept sets as exhaustive while allowing non-exhaustive examples to live in members or documentation. There was broad agreement that aligning concept names exactly with external guidelines is less important than ensuring Cat-VRS enables clear, efficient, and predictable matching, even if that means diverging slightly in terminology.

Overall, everyone agreed this is a genuine modelling tension that likely needs real-world implementation feedback to resolve. The path forward is to document the open questions, potentially introduce a clearer wildcard construct, treat concept sets as true constraints, and invite implementers (and absent subject-matter experts) to test the approach and report back before the design is finalised.

2026-01-07: Adjacency Constraint

Leads: Brendan Reardon

Participants: Beatrice Amos, Kori Kuzma, Larry Babb, Kyle Ferriter, Bob Dolin, Melissa Cline, Alex Wagner, Catherine Proknow, Mrinal Thomas, Salem Bajjali, Senkei Umehara, Beth Pitel

Apologies: Daniel Puthawala 

Link to previous Meeting Minutes 2024-2025: ARCHIVED] Categorical Variation Group - Minutes document - 2024-2025

Action items (Zoom AI generated - please amend as necessary!):

• Brendan: Set a reminder to follow up with Catherine and Daniel about submitting a Beacon/Cat-VRS session for Connect 2026 once Daniel is back.
• Brendan: Update the agenda item with the hyperlink to the GKS Roadmap survey once the email is sent out.
• Brendan: Synthesise the discussion and update the design decision discussion thread regarding the decision to focus on recipes/profiles rather than standalone/dependent constraints.
• Brendan: Add a gene fusion recipe to the adjacency constraint pull request.
• Brendan: Redo the "multiple known gene elements" section in the adjacency constraint implementation to use a concept set as recommended by Larry, and include it as an option for the joined elements.
• Brendan: Circle back with Bob regarding the concept set within GKS Core and how it manifests in the implementation, particularly in relation to constraints versus related information.
• Brendan: Send a summary of both main conversations (recipes/profiles and adjacency constraint updates) and update the respective pull requests and discussion threads.

Link to meeting recording: https://us02web.zoom.us/rec/share/MONtOzdj_FGM0hQeqgSqzyQuQHOBVFnY6bBIAjq66Axi0B5G0q8a1osyprNxJwwz.np12U-jw7Y-wiEq6 

Summary:

Adjacency Constraint [Link to Slides]:

Brendan outlined two agenda items: a brief FYI about a newly opened discussion thread on distinguishing types of constraints in the spec, and a longer review of recent changes to the adjacency constraint, which the group hopes to merge as a draft.

He summarised an ongoing concern that some constraints (e.g. function or copy change) can be used alone without clearly defining what biological entity they apply to, and proposed requiring at least one “foundational” constraint to establish scope, with other constraints acting as refinements. Bob questioned how to distinguish required vs optional constraints, prompting clarification that optional constraints should not stand alone.

Larry raised broader concerns about treating constraints too independently, arguing instead for higher-level “recipes” or profiles that bundle constraints together, emphasise an initial scope or anchor for each categorical variant, and make concepts easier to understand, reuse, and compare.

Larry (in chat):

- Anchoring is basically Defining

- The super flexibility of not requiring anything is a bit irresponsible in terms of helping implementers understand what this thing is and how it should work.

- I really had to hold my nose when I created CategoricalVariants for clinvar when I didn’t have a “recipe” to use. I felt like I was cheating and not really providing much help to anyone that would consume them.

Brendan welcomed Larry’s framing and emphasised that the core issue is a design and onboarding question: whether Cat-VRS should primarily guide users via anchoring constraints or via higher-level “recipes” that bundle constraints together.

Brendan explained that the proposed schema change is not meant to correct bad implementations - no one is misusing constraints today - but to address recurring conceptual confusion when onboarding new users who struggle without a clear anchor.

Alex argued strongly for leading with recipes, using an analogy to LEGO sets: most users want clear, predefined builds first, while still allowing advanced users to assemble new combinations later. He suggested recipes should be front-and-center, driven by real, common use cases identified through GA4GH processes.

Bob raised questions about how GA4GH would decide which recipes to standardise versus what remains the responsibility of external knowledge bases, to which Alex replied that this should be handled through roadmap prioritisation informed by community feedback.

Larry then cautioned against an overly “build-your-own” model, arguing that GA4GH’s role as a standards body implies endorsing a controlled set of standard recipes, while allowing custom ones only as proposals for future inclusion. He stressed the practical difficulty of expecting implementers to write fully generic, constraint-introspecting code today.

Catherine emphasised the need for openness to new recipes, a point Larry agreed with, advocating balance between flexibility and governance.

The group broadly converged on a strategy of maintaining modular constraints while orienting standards, guidance, and shared exchange around curated, community-approved recipes, a direction Brendan endorsed.

Larry (in chat):

The question is “Is our job to provide a design environment of cat-vrs or an implementation environment”.  I think we want to separate that. So that the designer-folks can work in a “lab-like” environment until they can produce recipes.

Senkei:

It was actually helpful to see sample objects (e.g. ClinVar GKS) to understand what it tries to mean, as an early implementer.

Larry (in chat):
So there’s a whole maturity process for getting recipes to draft/trial use/normative so that implementers can use them. Do we want the standards community to deal with “custom” recipes? (Maybe in 10 years?)

We have a charter to build standards. Not standards to create custom things

Alex:

I think this is very analogous to VA Spec in terms of “build your own”

Kyle (in chat):
LEGO lets people propose their own recipes

https://beta.ideas.lego.com/product-ideas/getting-started 

Mrinal (in chat):
I like the idea of relying more heavily on recipes, rather than allowing for arbitrary combinations of constraints. It also solves the issue of redundant constraints (e.g., gene + defining allele)

—

Brendan noted that, in light of the earlier discussion, the group should add an explicit gene fusion recipe to the adjacency constraint pull request.

Alex agreed, recommending that recipes and examples be grounded in real implementer data and reflected consistently in tests and documentation.

Brendan summarised recent schema updates driven by gene fusion use cases from multiple implementers, including support for order-known joins, terminus-based joint elements, and new classes for multiple known gene elements and unknown gene elements. He explained that limitations in existing VRS objects required re-implementing parts of adjacency to support gene-level concepts, and that documentation and examples were updated accordingly, including illustrative fusions such as BCR-ABL1.

Discussion then went on to modeling limitations and open conceptual challenges. Bob asked about representing breakpoints and transcript-level detail in fusions, which Brendan acknowledged as a current limitation tied to unresolved gene representation across GKS, though transcript-referenced locations are supported.

Larry strongly emphasized the need for the community to finally standardise gene concepts and sequence features, arguing that progress on fusions and adjacencies depends on it. He questioned whether chromosome-level translocations adequately represent gene fusions and suggested relying on external gene authorities (e.g. HGNC-style concepts) rather than over-specifying sequence scope.

Further discussion highlighted tensions between knowledge-centric lists of known fusion partners and the notion of constraints as strict, testable conditions, with Bob expressing concern that some examples felt more like annotations than true constraints.

Brendan closed by acknowledging these as ongoing issues, committing to follow-up discussions, updating pull requests and threads.