Measure affected customers and records

An error count describes technical volume, not business impact. Fifty failed attempts may be one retried record; one silent failure may be a blocked enterprise customer. Priority, reconciliation, and communication all depend on which records were actually affected, and that set has to survive being challenged.

The scenario

The silent-failure incident is open: ledger entries missing for some payment.settled events. Finance asks the two questions that decide everything: how many settlements are affected, and are any of them still unreconciled? "There were 47 findings" answers neither.

Correlation design

Impact measurement rides on the same hashed correlation that detection uses. The settlement handler reported correlation.sourceEventId, and the ledger worker reported the matching businessObjectId; both became keyed hashes inside your process, and a match means the same hash on both sides:

settlement observation   correlation.sourceEventIdHash   sha256:5f3a9c0d7b2e...ledger observation       outcome.businessObjectIdHash    sha256:5f3a9c0d7b2e...   MATCHsettlement observation   correlation.sourceEventIdHash   sha256:8d2c6b4a9e1f...(no ledger observation carries this hash)                                        MISSING

Seamward never sees a settlement id; it compares hashes it cannot reverse. The design rules that make the numbers defensible:

• Prefer application-owned identifiers already safe for operational logs.
• Keep the identifier stable across the observation and its expected outcome, or nothing links.
• Never transmit raw payloads just to improve impact analysis; the hashes are the mechanism.

Measure the scope

The affected set is derived, not estimated: collect the distinct correlation hashes from the incident window's eligible sources, compare them against observed outcomes, and every record lands in exactly one bucket.

That last row is a feature, not a failure: unknown stays labelled unknown instead of being silently counted either way, which is what makes the confirmed numbers trustworthy when finance, support, or an auditor pushes back.

Track reconciliation

After remediation, the same comparison tracks recovery: a record moves to reconciled only when the required outcome is observed or verified by the system that owns it. Retrying a record is an action; the resulting domain state is the evidence that recovery completed. Keep the two separate, and the missing-outcome incident's auto-resolution confirms the set has drained.

1. Confirm the incident window and affected integration environments.
2. Collect the distinct safe correlation identifiers from linked observations.
3. Compare against expected outcomes or your reconciliation source.
4. Report confirmed affected, confirmed recovered, and unknown, in those words.

Operating boundaries

• Counts include only records linked by available correlation evidence.
• Hashed identifiers are never presented as reversible customer data.
• Unknown scope remains explicit when a workflow cannot be correlated safely.
• Seamward does not notify customers or alter system-of-record data.

Related: Expected outcomes for the matching mechanics, and Security and retention for the isolation this rides on.