The number was right. Can you prove what it was last March?
Why model governance needs versioned inputs and record dates, not just accurate ones.
Propalt Team · For secured lenders
A valuation being correct today is not the same as being able to show what it was, and where it came from, on a date in the past. Model validation and internal audit rarely ask whether a figure is right now. They ask how it was derived, which version of the input produced it, and whether the same query run against the same date would return the same answer. A data source that only ever shows the current state cannot answer any of that, however accurate the current state happens to be.
The honest concession is that most data feeds were built to serve the latest value, because that is what production systems consume. But a validated model has a second consumer: the people who have to defend it. Serving current values and preserving a reconstructable history are not in tension. A feed can do both, and when it does, the governance burden shifts from reconstructing evidence to simply retrieving it.
Versioning is what makes a change explainable
An endpoint that changes silently is a problem for any validated model, because an input can shift underneath the model with no record of when or why. Versioned endpoints with a change notice turn that silent shift into a documented event. When a schema changes, you know it changed, you know when, and you can point to the version the model was validated against. That is the difference between explaining a movement and discovering one.
A documented schema does the same work at the field level. If every field has a definition and a stated meaning, a validator does not have to infer what a value represents or reverse-engineer it from behaviour. The model documentation can reference the field definition directly, and the two stay consistent because they describe the same thing.
| Field (illustrative) | Value | Record date | Endpoint version |
|---|---|---|---|
| Property valuation | 285,000 | 14 March 2026 | v3 |
| EPC rating | D | 1 February 2026 | v2 |
| Tenure | Leasehold | 20 November 2025 | v3 |
The table is illustrative. The record date and version columns are the ones an auditor reaches for first, because they are what make the value reproducible.
Reconstruct as at a date, not just as of now
Record dates on every field are what let you answer the question audit actually asks: what did this figure look like as at a given date. With a record date attached, a value is not just a number, it is a number with a timestamp you can filter to. Reconstructing the state of an input on the date a decision was made becomes a query, not an archaeology project.
For a risk function operating under PRA expectations on model risk management, that is the practical core of an audit trail. A validator can take a lending decision, retrieve the inputs as at the decision date, at the endpoint version in force, against a documented schema, and confirm the figure was what the model consumed. The evidence is not assembled after a challenge; it exists before the challenge is made, which is the whole point of governing the data rather than just the model.
An accurate number you cannot reconstruct as at a past date is an assertion, not evidence.
Govern the inputs, not just the outputs.
Try the Audit-ready data trail → · propalt.ai
Property and valuation data is drawn from HM Land Registry, the EPC register and the Propalt intelligence layer. Figures shown are illustrative. This article is general information for lending risk professionals.
Audit-ready data trail
Provides endpoint versioning with change notice, a documented schema, and record dates on every field, so any figure can be reconstructed as at a given date for model validation and internal audit.
🎯 Best used for
Model validation and internal audit evidence
🔌 Propalt APIs used
get_property get_valuation_by_property_id
