What must a rebuild record pin, besides the code revision, to reconstruct the underwriting model version that declined an application?

## What a pin set is A **pin set** is the complete argument list of one training run, recorded while the run happens and stored beside the model version it produced. It exists to answer one question months later: *what exactly was this version built from?* The pin set is not documentation and not a description of the run - it is the input to re-executing it. The governing rule is **identity, not description**. A description names something that may move; an identity names bytes that cannot. "The applications table, as of the third of November" is a description - the table may have been corrected since, and the meaning of "as of" depends on which timestamp column the reader picks. A content digest of the snapshot is an identity: it either matches or it does not. ## The five pins 1. **Code revision** - an immutable revision identifier for the training source, never a branch or tag name that can be repointed. 2. **Training-data snapshot identity** - the resolved snapshot the fit consumed, referenced by a content digest such as a SHA-256 over the snapshot's manifest. Resolved at run *start*, before the fit reads anything. 3. **Resolved configuration** - the hyperparameter map as the run saw it after defaults, sweep values and environment overrides were applied, plus the seed the run set. Not the defaults the script declares. 4. **Environment digest** - the base image digest plus a digest over the fully resolved dependency versions. Declared ranges are not a pin; the resolution is. 5. **Artifact digest** - the digest of the model artifact the run emitted, which gives a later rebuild something to compare its output against. These five hang off a single **training-run identifier**, and the model version served in production resolves to that identifier. One indirection, both directions: version to run, run to pins. ## Identity against description | Recorded as a description | Recorded as an identity | |---|---| | "latest" or a branch name | An immutable code revision identifier | | Table name plus a date | A content digest over the snapshot manifest | | A dependency range in the script | A digest over the resolved dependency versions | | "the production image" | The base image digest | | "the champion model" | The artifact digest | Every row on the left resolves to something different a year later; every row on the right resolves to the same bytes or fails loudly. ## When the pin set is written It is written **by the run, during the run**, not assembled afterwards by whoever promotes the version. Two reasons. First, several pins only exist during execution: the resolved config, the resolved dependency set, the snapshot identity a relative window collapsed to. Second, a pin set assembled at promotion time records what the promoter believes rather than what the job did, and the two diverge exactly when it matters. A useful discipline is that the pin set is written before the fit starts, and the artifact digest is appended when the run finishes. A crashed run then still leaves a complete record of what it attempted. ## Testing the pin set A pin set that has never been used is a guess. Two cheap tests keep it honest: - **The cold-machine test.** Hand the pin set to a worker with no project state and no human available. If it can start the run without a single additional lookup, the set is complete; if it has to ask which snapshot "the November data" means, it is not. - **The scheduled rebuild.** Periodically pick a live model version, rebuild it from its pins and compare against the recorded artifact digest and a stored audit sample. This turns rebuildability from a claim into a monitored property, and it catches decay - an expired image, a deleted snapshot - while there is still time to react. ## The gaps that show up in practice - The **environment** is the pin most often missing, because the training script looks pinned when it declares dependencies; the resolution happens elsewhere and is never written down. - The **seed** is recorded as "the default" when no seed was set at all. - The snapshot is pinned by a **name that was later repointed**, which is worse than no pin, because the rebuild silently succeeds on the wrong data. - The pin set is complete but nothing **links the live model version to it**, so an auditor holding a version stamp has no path to the run. ## What the pin set is not It is not the record of what one prediction did - the inputs, score and outcome of a single application belong to the decision record, which serves a different question and has its own retention. And it is not a substitute for the trained artifact: storing the artifact makes the version *servable*, while storing the pins makes it *rebuildable*. An audit that can only serve the old version can show what it does today; only a rebuild shows where it came from.