Question bank — Model versioning and registries

FALSE — training is a stochastic process; without a pinned seed (and deterministic GPU ops) the same code produces different weights. This is precisely why the seed is part of the 4-tuple.

FALSE — you still need the hyperparameters and the seed. All four elements plus a deterministic pipeline are required for byte-identical weights; drop one and re-runs can diverge.

FALSE — Git still versions the text/code; the registry versions the binary artifact + lineage. They are linked (the version stores its code commit hash), not substitutes.

FALSE — promotion flips a stage/alias pointer. The artifact never moves; that's why the change is atomic and instant, and why rollback is equally fast.

FALSE — the metrics are only comparable if measured on the same frozen eval set (same eval-data hash). Different eval data makes 0.93 vs 0.91 an apples-vs-oranges comparison.

FALSE — versions are immutable and append-only. To "fix" something you register a new version; only the mutable stage label may change on the existing one.

FALSE — the hash is an exact machine identity (immutable, byte-derived); v3 is a convenient human counter. The registry deliberately keeps both, mirroring Git's SHA vs branch-name split.

FALSE — it can be reloaded but not rebuilt: it omits the data snapshot, code commit, seed, and library versions. Unpickling under a different library version can silently change predictions.

FALSE — deleting it destroys your rollback target and audit evidence. Archived ≠ deletable; immutability is what makes emergency rollback a pointer flip instead of a rebuild.

Overwriting destroys the previous version, so there is no rollback and no audit trail. Fix: keep versions immutable/append-only and let only the alias/path pointer change.

A hash is not an ordered counter — you can't "add one" and it has no notion of newer/older. The monotonic v1, v2 label is layered on top of the hash, not derived by arithmetic from it.

A new input schema is a breaking change → it must bump MAJOR. MINOR is for retraining on new data with the same interface; consumers pinning <2.0.0 would break silently.

A metric without its eval-data hash is uninterpretable and can't be compared across versions. Always store the frozen eval-set identity next to the metric.

Checking out the code is one of four pins. Without the data snapshot, hyperparameters, and seed, retraining can yield different weights whose hash won't match the audited one.

A wrapper/serving bug fix with unchanged weights and interface is a PATCH, not MAJOR. Over-bumping MAJOR wrongly signals a breaking contract change to consumers.

The hash is deterministic and collision-resistant — it changes iff the bytes change, so it can never lie about identity. Filenames are human-mutable and routinely reused/overwritten, giving false identity.

So the exact model (weights+lineage) is preserved forever for audit/reproduction, while the role it plays (Staging/Production/champion) can be reassigned cheaply and atomically — separating "what it is" from "what job it has now."

Because the old version's artifact is still stored (immutable), so rollback just flips the champion/stage pointer back — no rebuild, retrain, or file copy is needed.

Offline eval metrics can hide live problems (traffic skew, latency, upstream feature drift). Sending a small traffic slice first surfaces real-world failure before it hits all users.

It lets them automatically receive safe retrains/patches (MINOR/PATCH) while the <3.0.0 bound guards against a breaking interface change (MAJOR). It trusts the SemVer contract.

Reproduction requires walking backward through provenance edges (model → data → code → run) until every input is a pinned immutable node; the DAG structure captures those multi-parent dependencies with no cycles.

Training reads data and randomness too; different data snapshots or an unpinned seed (or non-deterministic GPU ops) make identical code produce different weights.

No — the reproducibility guarantee assumes a deterministic pipeline. Non-determinism breaks the byte-identical claim; you'd fall back to reproducing statistically similar (not identical) weights unless you also force deterministic ops.

Identical artifact bytes → the same content hash. Content-addressing means it's the same immutable content; the registry may still expose a new human label, but the hash de-duplicates it.

In practice no — SHA-256 is collision-resistant, so distinct models producing the same hash is astronomically unlikely and treated as impossible. The design leans on this exact property.

It registers as v1/Production with its full lineage; there's simply no rollback target yet. The immutability rule still applies so that the next deploy has something to fall back to.

If the wrapper is part of the hashed artifact bundle, the bytes change → new hash → new version, but SemVer-wise it's a PATCH (interface and weights unchanged). If the wrapper is versioned separately, only the wrapper's version bumps.

Reproduction fails — the data hash points to a node that no longer exists, breaking the lineage DAG. This is exactly why data snapshots must be immutably retained (see Data versioning (DVC)), not just referenced.

No — the registry records the model as it was; the degradation is drift in incoming data, not a change to the model. Detecting it is the job of Model monitoring and drift detection, which then triggers a new version.

It destroys the previous version, so you lose rollback and audit; versions must be immutable/append-only with only the pointer mutable.

A hash is an unordered fingerprint, not a counter; the monotonic v1/v2 label is layered on top of the hash, not computed from it.

Byte-identical reproducibility — pinning the 4-tuple only reproduces exact weights when the pipeline is deterministic.

SHA-256 is collision-resistant, so distinct artifacts colliding is astronomically improbable and treated as impossible by design.

MAJOR — it's a breaking interface change, so consumers pinning below the next major version won't silently break.