feat: Implement CatVRS transit layer on variant endpoints #744
Copy link
Copy link
Closed
Labels
app: backendTask implementation touches the backendTask implementation touches the backendapp: frontendTask implementation touches the frontendTask implementation touches the frontend
Milestone
Description
Activity
- addedapp: backendTask implementation touches the backendTask implementation touches the backendapp: frontendTask implementation touches the frontendTask implementation touches the frontend
on May 18, 2026 - added a parent issue
on May 18, 2026
Metadata
Metadata
Assignees
Labels
app: backendTask implementation touches the backendTask implementation touches the backendapp: frontendTask implementation touches the frontendTask implementation touches the frontend
Context
Depends on: #742, #743
For protein-level assayed variants, the MAVE score applies to a category of nucleotide variants, not to any specific nucleotide variant directly. CatVRS (GA4GH Categorical Variation Representation Specification) is the right vocabulary for communicating this to API consumers and the UI.
CatVRS is used as a transit layer only — storage remains in the
allelestable. CatVRS lives exclusively in API responses.Data model traversal
To build a CatVRS response for a protein-level
AssayedVariant:MappingRecordfor theAssayedVariantwhereassay_level = proteinmapping_record_allelesto find all associatedAllelerows wherelevel = 'coding'Allelerow (with its annotation data from the per-type annotation tables) becomes a CatVRS memberAssayedVariant— it is categorical, not directly measuredGoal
Implement CatVRS response objects on variant endpoints per the API contract defined in #743, making it semantically clear to consumers that scores on coding-level alleles are implied (categorical) rather than directly measured.
Acceptance Criteria
GET /variants/{id}returns acategoricalVariantsfield for protein-level assayed variants, populated from associatedAllelerows wherelevel = 'coding'Alleleis included per the API design decision