Your property data changed. Did the property?

A revised bedroom count or construction date can reflect better information without any physical change to the building. Release handling needs to preserve that distinction.

An insurer opens a refreshed dataset and finds that a property now has four bedrooms rather than three. A lender sees a revised construction date. A portfolio report shows more homes in a particular category than it did last month.

These changes deserve attention, but they do not all mean the same thing. Acting on every revised value as though a homeowner has altered the property can create unnecessary referrals and misleading portfolio commentary.

Understand why the value moved

Three explanations are particularly useful to separate.

New evidence may have become available. A more recent certificate or another relevant record can improve the description of a property that has remained physically unchanged.

The estimation method may have changed. A revised model can produce different bedroom, bathroom or construction-date estimates from broadly similar inputs. That is a change in the assessment, not necessarily the asset.

The property itself may have changed. An extension, conversion or other work can make the earlier description obsolete. Even then, the date when a source reveals the change may be later than the date when the work occurred.

Chimnie's August 2026 release recorded revisions to bedroom, bathroom and construction-date models. That is the kind of release context users need when interpreting changes across a book. A comparison of values alone cannot explain the cause.

Keep an event separate from a revision

Consider two fictional homes that both move from three bedrooms to four in a refreshed file. At the first, a new EPC describes a recently completed conversion. At the second, the value changes because the estimation model has been revised.

The first case may justify checking whether the insured description or collateral record remains appropriate. The second calls for understanding the model update and its effect on existing rules. Neither should automatically create the same 'building altered' event.

Where available, retain the old value, new value, evidence type, source date and release version. Add a reason for the revision only when the evidence supports it. 'Reason not established' is more useful than an invented explanation.

For modelled fields, compare confidence and coverage alongside the value. A move from an estimate to a supported observation is different from a change between two estimates.

Review the effect before changing a decision

Start with a representative comparison between releases. Measure how many records changed, which segments moved and whether the changes affect actual eligibility, pricing or referral rules. Check missing values, category changes and consistency between related fields.

A stable national distribution does not prove that individual decisions are unaffected. The same total number of four-bedroom homes could conceal substantial movement between properties. Conversely, a large number of revised exact dates may produce little change in the broader age bands an insurer uses.

Define proportionate responses. Some changes can be accepted through normal release management. Others warrant a sample review or a controlled comparison before entering production. Preserve the previous release where the agreement permits it so that earlier decisions remain explainable.

The useful question is what changed in the evidence or method, and what consequence follows for the user. Answering it helps customers benefit from improvements without treating every correction as a new physical event.

Speak to Chimnie about the fields and release information needed for your portfolio's change-review process.