Skip to content

AlphaGenome

Experimental scientific policy

AlphaGenome is accessed through Google DeepMind's hosted API. Altar's adapter creates an InlineScoringPlan: it makes API calls in process rather than launching a model container.

Install the binding separately from the base framework. It is not on PyPI; install it from a source checkout:

uv pip install -e bindings/alphagenome

The install contributes the ALPHAGENOME model-plugin registry entry and the pinned alphagenome SDK. Direct imports come from altar_alphagenome; the base altar wheel contains no AlphaGenome-specific implementation, entry point, or extra.

from altar_alphagenome import AlphaGenomeConfiguration, AlphaGenomePlugin, AlphaGenomeRuntime

Model-instance scope

An Altar model instance is AlphaGenome plus its configured organism, ontology terms, variant scorers, and sequence length. A liver/ATAC configuration and a blood/RNA-seq configuration are different model instances even when they use the same remote endpoint.

Users do not select or average AlphaGenome training folds. Altar explicitly calls the production ALL_FOLDS distilled model rather than relying on a mutable server default, and records that internal selection plus the exact supported SDK version in runtime identity. Human (HOMO_SAPIENS) coordinates must be hg38; mouse (MUS_MUSCULUS) coordinates must be mm10.

Headline reduction

AlphaGenome can return many tracks per variant. The adapter reduces them to a fixed scalar schema:

Field Meaning
top_output_type Output modality of the track with the largest absolute raw effect.
top_track Name of that track.
max_abs_raw_score Largest absolute raw score among selected tracks.
top_track_abs_quantile_score Absolute quantile score from that same top-raw-effect track.
max_abs_quantile_score Largest absolute reported quantile score.
n_tracks_scored Number of tracks considered after configuration filters.

The reduction is useful for a common result table but is lossy by itself. Altar therefore also persists the binding-declared track_scores detail table. It includes scorer, output type, track and gene identifiers, track metadata, raw score, and quantile score. variant_id plus the descriptive dimensions form a stable, NULL-safe logical key; storage adapters do not invent an AlphaGenome-specific schema.

Prioritization rule

The current predicate requires max_abs_raw_score >= 0.5 and top_track_abs_quantile_score >= 0.9. Both values therefore describe one track. It is explicitly a placeholder. The separately reported maximum quantile over all tracks can approach one even for unremarkable variants; narrowing the model instance to relevant ontology terms is scientifically important.

Operational considerations

  • Install altar-alphagenome and provide an API key.
  • API quota, availability, privacy policy, and provider versioning apply.
  • Record selected scorers and ontology terms with every result.
  • Keep the Altar runtime identity with every result. The provider's production model is named rather than content-addressed, so hosted-service reproducibility remains weaker than a content-addressed local model.

Compatibility

Moving the binding from altar.models to altar_alphagenome did not change its registry key, plugin ID, schema IDs or versions, manifest hash, or configuration and result-compatibility hashes. Results stored by the former in-core plugin remain readable and reusable without migration.

Configuration schema 0.0.2 fixes ALL_FOLDS inside the binding and rejects user-supplied training-fold revisions. Result semantics 0.0.2 are intentionally incompatible with 0.0.1: retained track_scores detail rows contain enough information to derive top_track_abs_quantile_score and the corrected primary row without another API call, but an old primary row alone does not. Do not relabel an old primary-only result as 0.0.2; keep it under its original identity or rescore it.