A transit-ridership forecasting model has been deployed for several months. The team wants to detect if the statistical properties of live production input data, like average trip distance or time-of-day distribution, have shifted away from what the model was originally trained on. Which capability addresses this ongoing concern after deployment?

Mechanism: detecting whether live production data has drifted from the statistical properties of the original training data requires continuous, post-deployment comparison, capturing incoming inference data over time and evaluating it against a stored training baseline to flag meaningful shifts in things like average trip distance or time-of-day distribution as they emerge. Why the wrong options fail by concept: DataBrew re-profiling the training dataset a single time before deployment is a pre-deployment, one-time activity, it establishes a snapshot but has no mechanism for continuously comparing that snapshot against data arriving months later in production. A standardization transform applied once to the original training data rescales numeric ranges at preparation time, it's a static preprocessing step with no ongoing monitoring behavior, it doesn't watch anything after the model ships. Ground Truth relabeling the original training dataset from scratch addresses label quality for historical data, it has nothing to do with observing how new production input data behaves relative to that historical data over time. Scope caveat: drift detection flags that a shift occurred, it doesn't automatically explain whether the shift reflects a genuine change in ridership behavior worth retraining for, or a temporary anomaly like a service disruption. Operational check: review the drift-monitoring reports on a recurring cadence and confirm whether flagged features correspond to a sustained trend rather than a single noisy reporting period.