A nightly-rebuilt snapshot table reflects today's state, not decision-time state. How do you train on it safely?

## Why a snapshot leaks A **snapshot table** stores the current value of each field for each entity. A rebuild replaces it wholesale, so what you read tonight is the state of the world tonight. A **history table** instead stores every change with the time it happened, so you can ask what a field held on any past date. If your training rows are drawn from a snapshot but your labels refer to events in the past, then every mutable column has had time to be overwritten by consequences of those events. A hospital record's discharge disposition code is a good example: written or amended after the episode concludes, so by the time the snapshot is rebuilt it may encode the readmission you are trying to predict. Nothing about the row looks odd. The value is genuine — it is simply as of the wrong moment. This is the hardest form of target leakage to argue about, because the usual detection instincts fail: - Inspecting rows fails. Each row is internally consistent and plausible. - Column-name heuristics fail. The offending fields are ordinary operational statuses. - A single-feature ablation may fail too, since the contamination is spread across many mutable columns rather than concentrated in one. You detect it from the *build semantics* of the table — is it a full rebuild, is there an effective-date or valid-from column, is there an upstream change log — not from the data. ## The three-bucket triage **Bucket one: write-once fields.** Values set at creation and never amended — date of birth, application channel, original loan term, admission date, the product bought. These are safe by construction, and they are the floor you can always build on. **Bucket two: mutable with recoverable history.** Many operational systems keep a change log or an audit trail even when the analytics snapshot does not. If it exists, you can reconstruct each field as it stood on the decision date and recover most of the modelling value. This is real engineering work, and it is usually the highest-return work on the project. **Bucket three: mutable with no history.** Exclude them. Not "use them carefully" — exclude them, and record why, because the next person to build a table here will otherwise pull them straight back in. ## The number you report Once you drop buckets two and three, the model is usually much weaker. The instinct to soften that is exactly the failure this question tests. Report two numbers with an explicit meaning for each: the snapshot-trained score, labelled as unachievable because it uses information the system will not have; and the honest score, labelled as what the business would get on day one. Never let the first number become the target anyone plans against. ## The strategic choice This is where the judgment lives, and there is no single right answer. Three defensible paths: **Ship the honest, weaker model now.** Justified when even the reduced model beats the current process — often a manual rule or nothing at all. It also starts generating the operational evidence that funds the next step. **Instrument first, model later.** Begin logging the exact feature values used at each decision, at the moment the decision is made. In a few months you own a clean, leakage-proof training set by construction. This is the durable fix, and it needs a sponsor because the payoff is delayed. **Decline, or narrow the scope.** If the safe fields carry almost no signal and the decision is high-stakes, the responsible answer is that this problem cannot be modelled from this data yet. Saying so early is cheaper than a year of unexplained production underperformance. Most mature teams run the first and second in parallel: a modest model shipped on write-once fields, plus decision-time logging switched on the same week. ## What to say in the room Frame the constraint before the technique. The organisation did not choose to lose history — the snapshot exists because it is cheap and answers the operational question "what is true now". Modelling asks a different question, "what was true then", and that requires a different storage decision. Presenting it that way turns an argument about a broken feature into a funding conversation about instrumentation, which is the conversation you actually want.