Model identifiers

An eval model identifier has three parts, and each one moves for a different reason: a family that names the kind of judgement, a version we publish, and a horizon that belongs to your data. The response carries a fourth signal — the fingerprint — which is not part of the identifier and cannot be asked for.

§1Anatomy

a8-0-2@20260715t140322z
a8 The family — what kind of claim the model makes. a8 is satisfies: does this output meet the stated criterion?
0-2 The version, written A8 0.2 in prose — major and minor, ours to publish.
2026…z The horizon — every correction you sent up to that moment. Yours. Its zero is the word reference: none of it.
Figure 1. The three parts of a fully-qualified identifier. The horizon is optional: a8 alone means the current version we publish, at the current state of your corrections.

§2What each part promises

PartMoved byPromise
FamilyUs, rarelyA different family is a different question, not a better answer. Families coexist; one never replaces another.
VersionUs, plannedAnnounced. A minor may move verdicts but never the request or response contract; a major changes the contract itself.
HorizonYou, by fine-tuningThe model reflects your supervision up to that moment — and nothing after it. @reference is the zero: none of your supervision at all.
FingerprintAnything, including us unplannedObservable, never addressable. It changes whenever something that could move a verdict moved.

Table 1. The four signals, by who controls them. The split is deliberate: your data and our releases move on separate clocks, so neither forces the other.

§3What moves what

When this happensFamilyVersionHorizonFingerprint
You send a correction··✓✓
We correct a bug and retrain···✓
We publish shared knowledge, or change how evaluation works·✓·✓
We change the request or response contract·✓·✓
We introduce a different kind of judgement✓✓·✓

Table 2. Row two is the reason the fingerprint exists. A correction has to be able to reach you without breaking the promise a published version made — so it moves nothing addressable, and announces itself in the one signal that is not a promise.

§4Two models, one substrate

Because the horizon axis has a zero, two models are addressable at any time:

ModelAsk forContains
Workinga8, or a horizonThe shared baseline plus every correction you have sent.
Referencea8-0-2@referenceThe shared baseline alone — what a brand-new account is served.

Table 3. The same substrate read two ways. Training moves the working model and never touches reference; see horizons §4.

§5Holding still

Pinning a8-0-2@{horizon} holds three of the four: the family, the version, and your data. Later fine-tuning does not reach it, and neither does shared knowledge we publish afterwards.

The fourth is not held: a pin freezes what the model learned, not the software that reads it. If we find a defect and correct it, that correction reaches pinned callers too — the alternative would be leaving known-wrong verdicts in place for anyone who had fine-tuned the model at all. When it happens, the fingerprint changes and the identifier does not. That is the signal to re-check a stored baseline.

The rule in one line The identifier says what the model knows. The fingerprint says which build knew it.

§6Versions and horizons do not cross

A horizon belongs to the version that fitted it. When a new minor is published it starts its own line and fine-tunes forward from there — it does not backfill your earlier horizons, so an identifier from one version is not askable under another. Your existing pins keep working on the version that minted them; moving to a new minor means fine-tuning forward on it.

§7Related concepts

  • Horizons — listing horizons, pinning, and the provisional snapshot.
  • Reproducibility — reading the fingerprint.
  • Fine-tuning — the only thing that moves your horizon.
Next
Horizons Listing snapshots, and pinning one →
U22A8 · built by @onebit0fme · Terms · Privacy