The CDC field is still called `amount`. When did its units change?

First, I would not let the report explain the spike. We have two meanings under one field name and type. A 500 might mean five units of a currency with two decimal places or five hundred major units. Structural schema compatibility only says the records can be read in a compatible shape. It cannot tell us that an integer has kept its business meaning. Confluent's schema evolution guide is useful for that distinction.

Stop publication of affected aggregates and answers, then find the earliest producer deployment and the exact source transactions it emitted. Partition the investigation by producer identity and version, currency, event time, ingestion time, operation type, and replay path. Compare raw database values and the payment ledger against the CDC payload. Do not infer the unit from whether the number is divisible by 100 or from a sudden change in its magnitude. Small payments, refunds, zero amounts and currencies with different minor-unit conventions make those heuristics dangerous. If provenance cannot prove the unit for a record, put it in an unknown bucket and keep it out of trusted totals.

The repair needs a ledger of what changed, not a quiet rewrite of the old stream. Preserve raw events and their transaction identity. Produce a versioned normalized amount with an explicit currency and unit, plus the source version and transformation version. Recompute affected aggregates from an identified cutoff and reconcile counts and monetary totals to an independent financial system. CDC updates, deletes, duplicate deliveries and historical replays all need stable event identity and an idempotent normalization rule. A replay of an old record must retain its old meaning even after all live producers have cut over.

For the migration, I would introduce amount_minor_units as an explicitly defined field or a new event version with the unit in the contract. The conversion is currency-aware and based on known source semantics. It is not a blanket division by 100. New producers write the new contract, while a compatibility adapter serves old consumers from records whose provenance is known. If old consumers expect the ambiguous amount, mark a retirement date and measure who still reads it. During dual running, compare new and old reports against ledger truth, not merely against each other. Release reporting only after unknown records are resolved or visibly excluded under an approved accounting rule.

The hard push is a record from the rollout window with no producer version. I would not assign it a unit by confidence score just to make the dashboard green. Resolve it from the source transaction or a durable deployment log. If neither exists, quarantine it and show the resulting coverage gap. The AI layer should inherit the trusted dataset's provenance and coverage, and refuse a precise revenue conclusion when the underlying units are undecidable. A retrieved table gives the right row and the wrong number asks how to read a table cell. Here the table can be perfectly parsed while the underlying event contract has changed its meaning.