Terminology

Use these terms in public documentation, user interfaces, and new extension code.

Term	Meaning
model architecture	A modeling approach such as ChromBPNet, Cherimoya, or AlphaGenome.
model instance	A trained model or configured model scope used in one analysis, such as a K562 ChromBPNet model.
model binding	The lightweight package that tells Altar how an architecture is configured, run, and interpreted.
runtime	The executable environment containing a heavyweight model framework and its command-line program.
scoring job	A request to score variants with one or more model instances.
model run	The part of a scoring job associated with one model instance.
task	One independently executable unit of work.
shard	One of several equivalent partitioned tasks. Use only when work is genuinely partitioned.
score	A value produced by a model for one variant.
annotation	External reference information attached to a variant.
variant–gene link	A typed relation connecting a variant or regulatory element to a target gene.
variant result	The assembled record containing a variant's model scores and prioritization provenance.
prioritized	A declared rule matched. It does not mean pathogenic, causal, or clinically significant.
execution backend	An implementation that submits and observes container tasks.
score store	Storage for attributable per-model scores and assembled result reads.

Python identifiers sometimes retain lower-level wording such as materialize() or reconcile_once(). Explain the public concept first—assemble results or advance dependent tasks—then name the API used to perform it.

Avoid using “axis,” “plan triple,” “data lake,” “surface,” “seam,” or “fan-in” as the primary explanation of the system. Those terms describe implementation history more than a reader's scientific or engineering goal.