01 The core claim
A pharmacogenomic statement is a chain of inferences, not a lookup. Genomic annotation establishes what a variant does to transcripts. Allele function establishes what a haplotype does to a protein's activity. Phenotype assignment combines two alleles under a published framework. Clinical guidance translates that phenotype into a prescribing recommendation for one drug. And outcome depends on everything else about the patient.
Each step loses information, and each is supported by a different kind of evidence — computational prediction, functional study, consensus framework, clinical trial. A tool that presents the output of the first step in the language of the fourth is not a shortcut. It is a category error, and it is the most common failure in this area.
02 Evidence that supports it
Two of the four analyses produced concrete cases where a layer boundary matters, which is why I think the claim is worth more than an assertion.
synonymous_variant, which would ordinarily suggest no effect on the protein. The allele's loss of function is a splicing defect. A pipeline reading the transcript annotation and stopping there would classify a well-established no-function allele as benign.
Both cases point the same way: the annotation layer cannot be read as the function layer, and the failure is silent in each direction. Nothing errors. The output simply means something narrower than it appears to.
03 What is missing
I would rather set this out plainly than let the programme look more complete than it is.
- No real genotype data. Everything works from reference records and curated tables. The programme has never been run against a VCF, which is how the problem actually presents.
- No systematic evidence grading. CPIC levels and PharmGKB clinical annotation levels are referenced, but not yet parsed from source into a structured field with provenance per claim.
- Star-allele calling is not implemented. The tools work one allele or one diplotype at a time. Going from variant calls to a diplotype requires phase, and for CYP2D6 copy number — which is the part that genuinely matters and the part I have not built.
- No validation set. There is no collection of known genotype–phenotype pairs against which the assignment logic is checked. That is the single most useful next piece of work, and its absence is why I describe the programme as in development rather than published.
04 Where it goes next
In the order I would actually do it, each step chosen because it closes a specific gap above.
- Build the validation set first. Known diplotype–phenotype pairs from CPIC's own supplementary tables, so the assignment logic can be tested rather than trusted. Doing this before adding features is the whole point.
- Parse the allele definition and function tables from source rather than curating by hand, with the file version recorded so a result can be traced to the table that produced it.
- Accept a VCF and call star alleles from genotypes, which forces the phase problem into the open instead of assuming it away.
- Handle CYP2D6 structural variation, or state clearly that the tool cannot and should not be used for that gene — which may well be the honest outcome.
- Attach provenance to every claim: which table, which version, which guideline, so a reader can audit any statement the tool makes.