Which must an audit-selection decision log keep to survive a feature-definition change: the raw return figures or the computed features?

## The two candidates A scorer for tax-audit selection is handed a filed return, derives features from it, and produces a score. When you write the decision row, you can store what came in, what the model was fed, or both. The question sounds like a storage-cost trade-off. It is really a question about which of the two is defined by something outside your control. - **The raw submitted figures** — gross income, deductions claimed, filing type — are what the filer sent. Their meaning is fixed by the return form, not by your repository. They mean the same thing in five years as they did on the day. - **The computed feature vector** — `deductionRatio`, `incomeBand` — is the output of a function you wrote and will rewrite. Its meaning lives in the definition, not in the field name. ## What a redefinition does to a stored vector Take one concrete revision. Under the definition in force in early 2025, `deductionRatio` divided deductions by **gross** income. In 2026 it was revised to divide by **adjusted** income, because the sector team argued that was the comparison that mattered. | the same return | gross-income definition | adjusted-income definition | |---|---|---| | deductions 61,450 · gross 148,200 · adjusted 96,300 | `deductionRatio` = 0.41 | `deductionRatio` = 0.64 | Now consider a row from 2025 that stored only `{"deductionRatio": 0.41}`. A reviewer in 2026 reads it under the definition they know, sees 0.41, and concludes the filer's deductions were modest. They were not. Nothing signals the mismatch: the field name is identical, the type is identical, every schema check passes. And the value cannot be repaired, because 0.41 cannot be inverted back to the two numbers the other definition needs. The row that also kept `{"grossIncome": 148200, "deductionsClaimed": 61450, "adjustedIncome": 96300}` can produce either figure on demand. That is the sense in which the raw snapshot *survives* the change. ## Why the computed vector is still worth storing If raw figures are the durable evidence, why keep the vector at all? Because the raw figures tell you what the model *could* have been given, not what it *was* given. The feature pipeline sits between them, and the interesting failures are in that gap: a join that silently returned null and was filled with a default, a unit that was parsed as thousands, a lookup that timed out and fell back to a global average. Recomputing from the raw figures reproduces the intended features, not the ones that were actually scored — so the bug becomes invisible exactly when you are investigating it. So the vector is the fidelity record and the raw snapshot is the durable one. They answer different questions and neither substitutes for the other. ## The third category nobody stores Some inputs are neither submitted nor computed: they are **looked up** at decision time. A prior-audit count read from an online store, a sector median read from a reference table. These are part of what the model saw, and the store has moved on since — the prior-audit count for that filer is now 1, not 0. Recording only the request payload therefore produces a row that looks complete and is not. Put looked-up values in the same input snapshot, marked as looked up rather than submitted, so the boundary between "the filer told us this" and "we fetched this" is visible to whoever reads the row. ## What to store, in one list 1. The **raw submitted figures**, verbatim, subject to the privacy limits on what may be retained. 2. Any **values looked up at decision time**, in the same snapshot, marked as such. 3. The **computed feature vector** exactly as passed to the model. 4. The **feature-definition version** that links 1 and 2 to 3. 5. The **model version**, so the score is interpretable against the right scorer. ## The costs, stated honestly Keeping raw figures is the expensive choice on two axes. It is larger — a full return snapshot is many times the size of a short feature vector — and it is the privacy-heavy part of the row, because submitted figures are exactly the fields a retention policy is about. Teams that store only the vector usually got there by optimising one of those two, not by deciding the vector was sufficient. The answer that shows judgment names that trade-off rather than pretending it does not exist: the raw snapshot is what makes the log defensible under challenge, so it is retained under a stated window with direct identifiers tokenised, not dropped to save space.