Template
Make every selected record end in an explicit status bucket
A total should account for the awkward records too.
When it fits
- A batch summary lists successes but leaves it unclear what happened to the rest.
When to avoid it
- Retries and duplicate inputs require a defined counting unit. Do not mix business identities, attempts and message counts in one equation.
A template to use
Run and cutoff: [snapshot]. Selected identities: [total]. Applied: [applied]. Rejected: [rejected]. Pending: [pending]. Unaccounted: [unaccounted]. Next action for unresolved identities: [action].
Why it matters
Freeze the selected input population and assign each identity to one mutually exclusive status at a stated cutoff. Include pending and unaccounted states instead of hiding them inside success. This is population accounting; successful accounting is not proof that the resulting field values are correct.
An example
A 200-record run has 183 applied, 9 rejected and 8 pending. It is fully accounted for, but it is not 200 successful updates.
Check your result
The disjoint buckets reconcile to the selected population, and unresolved IDs are retrievable.
Keep this limit in mind
- Retries and duplicate inputs require a defined counting unit. Do not mix business identities, attempts and message counts in one equation.
Evidence and sources
Supports
AWS DMS distinguishes validation-pending, failed, suspended and validated records rather than treating every transferred record as validated.
A population-accounting ledger can expose unaccounted records but cannot replace comparison of their actual values.
AWS DMS data validation · Validation states