Should earlier decisions be reassessed when an AI system's model…

Direct answer

First record the change's version, purpose, scope and material effect. Then identify which earlier decision classes could change in relation to identity, data, evidence, authority, explanation, security, fairness, legal effect or connected downstream actions. Where possible, measure impact through sampling and comparison tests. Conduct targeted reassessment for critical or continuing outcomes. A new version does not correct a past decision automatically, and a new rule does not automatically make that decision wrong.

In plain language

When weighing-scale software is fixed, you may not need to weigh every box from last year again. But if the old scale is found to have consistently under-weighed a particular range, you recheck important decisions that relied on those measurements.

Why this matters

Blindly repeating every past decision creates disproportionate cost; reopening nothing allows a known error to keep affecting people and systems.

Do not confuse

A version change is a technical event; material impact requires separate evidence.
A correction made today does not change a past decision by itself.
Historical accuracy is assessed against the information and rules at the time; current validity is assessed against today's state.
Retrospective impact analysis identifies the risk population; redetermination decides an individual case again.
Continuing effect means that an earlier decision is still producing consequences for a person or system today.

What should you do?

Compare the changed model, data, prompt, policy, tool and configuration with the previous version field by field.
Record the change's purpose, reason, owner, date and expected decision impact in a change package.
Identify affected decision types, date ranges, groups of people, entities and connected downstream outcomes.
Compare old and new versions on representative cases using the same decision package.
Open targeted review where there is a critical error, wrong person, continuing harm or legal trigger.
Correct reassessed decisions and propagate the result to every affected system.
Document the scope assumed to be unaffected, its exceptions and remaining uncertainty, with reasons.

How do you audit it?

Are all changed components and versions recorded?
Was the change treated as immaterial without testing its effect?
Were the affected dates, decisions, people and downstream systems identified?
Were the old and new versions compared under the same conditions?
Were critical decisions with continuing effects reassessed?
Did the new version silently overwrite historical records?
Is there evidence of the corrected live result and its propagation?

Limit

Retrospective review and the legal effect of a past decision depend on finality, rights, contracts, sector and jurisdiction. A technical change alone does not mean that every decision must be reopened or is invalid.