A model can be accurate at deployment and wrong later. The important question is not whether change exists. It is whether the change is large enough to alter prediction, planning or mission success.
Dynamics change in ordinary operation
Payload changes inertia. Contact surfaces change friction. Components wear. Communication and actuation acquire delay. The same command can therefore produce a different response from the one represented in the deployed model.
A monitoring system can reveal the symptom. A self-model can go further by comparing predicted and observed response under the command that was actually sent.
Not every mismatch deserves an update
Sensor noise, temporary disturbance and poor observations can also create prediction error. Updating a model whenever error increases would make the system unstable and difficult to govern.
A consequential mismatch should persist under a defined statistic, affect a relevant part of the machine and matter to the mission. Ambiguous cases should request more evidence or abstain.
Start in shadow mode
The first deployment should compare predictions with real telemetry without giving the model execution authority. This establishes nominal error, false-trigger behavior and the operating envelope before any candidate repair is routed.
Controlled and reversible changes are the right first test. They create a clear baseline while the machine's existing controller and safety system remain authoritative.
Sources
NIST AI Risk Management Framework ↗A lifecycle framework for mapping, measuring and managing AI risk.
Functional Mock-up Interface ↗An open interface for exchanging and co-simulating dynamic system models.