Fourteen Months Later, the Auditor Asks
A bank uses a gradient-boosted credit-scoring model to approve small-business credit lines. A regulator's auditor asks the bank to reproduce the exact score and reason codes issued to a specific applicant 14 months ago. The bank has the model's source code in Git and the model artifact in an object store. But the training pipeline ran on a shared cluster with floating library versions and no lockfile; the random seed was set only in the notebook, not in the pipeline; three of the 40 features come from a feature-store table whose definition changed twice since; the training snapshot was deleted by a 90-day lifecycle rule; and the model card lists only the owner and an AUC. The model is still in production and is retrained every quarter. Bank policy says models must be reproducible, but no method is defined.
1. What can the bank actually deliver to the auditor, and how should it frame what it cannot?
Read the worked answer
Separate two claims that the auditor will conflate, and state each precisely.
Decision reproduction - can you reproduce the score issued to that applicant? Likely yes, if the decision log stored the feature vector as scored, the model version and the reason codes. Scoring is a deterministic function of artifact and input, so re-running the artifact on the logged vector reproduces the score and the SHAP contributions even without the training data. That is the claim the auditor actually cares about, and it is defensible.
Training reproduction - can you rebuild the model from scratch? No. The 90-day lifecycle rule deleted the snapshot, there is no lockfile so the numeric libraries may differ, the seed lived in a notebook rather than the pipeline so even identical data would produce a different model, and three of 40 feature definitions changed. Any claim of full reproducibility would be false and would collapse under one follow-up question.
The honest framing: 'We can reproduce decisions as issued; we cannot rebuild the training run.' Present the artifact hash, the commit, the decision log and the reason codes, then list the specific gaps as findings with owners and remediation dates. Auditors generally accept a documented, bounded gap far better than an overclaim, and the gap statement is what turns an incident into a remediation plan.
2. Specify the controls the bank must add to pass the next audit, in priority order, with the reasoning for the ordering.
Read the worked answer
Order by audit exposure answered per unit of effort.
- Decision logging. Cheapest, and it answers the question actually asked. Per decision: feature vector as scored, model version and artifact hash, threshold, score, top reason codes. Had this existed, the current audit would already be closed.
- Environment pinning. Lockfile plus container digest recorded in the training run, not only in the deploy manifest. Without it, 'same code' is not same numerics, and the auditor will ask for the difference.
- Seed and determinism. Seed as a pipeline config parameter logged with the run; disable nondeterministic operations where feasible; store a hash of the trained artifact so silent drift is detectable.
- Data snapshots with retention matched to model lifetime. Content-addressed snapshot per training run, with a lifecycle exception for anything linked to a registered model version.
- Feature versioning with point-in-time correctness. Each feature definition gets a version; the run records which versions it consumed; joins are as-of the decision time.
- Model card schema. Owner, intended use, training window, feature versions, evaluation by segment, known limitations, and reproduction instructions - completed at registration, not retrospectively.
The governance step is to name an owner per control and test them. Run an internal audit annually that picks a random production decision from the previous year and tries to reproduce it end to end. An untested control is a claim, not a control.
3. Retaining full training snapshots for every quarterly model would be expensive. Propose a retention design that is both compliant and defensible on cost.
Read the worked answer
The 90-day rule and the reproducibility policy contradict each other directly. The resolution is to stop treating all training data as one class and to delete by tag with an explicit legal-hold exception.
Retain for the full model lifetime plus two years: the content-addressed snapshot of the exact training data for every model that served traffic, including predecessors still inside the audit window. Note this is one snapshot per promoted model, not per experiment - quarterly retraining yields roughly 8–12 snapshots across the audit horizon, not thousands. Also retain the per-decision feature vectors, which are kilobytes each and are what the auditor actually asked for.
Do not retain: intermediate experiment snapshots, superseded candidate data, per-trial artifacts from tuning sweeps, and duplicate copies of raw source tables. If the snapshot is a versioned table reference the warehouse can still resolve against immutable storage, a snapshot ID is far cheaper than a physical copy.
Cost control: quarterly snapshots of largely overlapping data dedupe and compress well, so the marginal cost of the tenth snapshot is small. The expensive mistake is the current one - retaining everything for 90 days and nothing thereafter, which is maximum cost for minimum compliance.
Implementation: lifecycle rules delete by tag, and promotion applies legal-hold automatically. Untagged data still expires at 90 days. Without that automatic link, the default behaviour wins again, exactly as it did here.