Use cases
Measure affected customers and records
Use safe correlation evidence to measure the scope of an integration incident.
An error count describes technical volume, not business impact. Incident priority often depends on which environments, customers, records, or expected outcomes were actually affected during the failure window.
This use case applies privacy-safe correlation to the incident evidence. It helps the team move from a technical symptom to a defensible affected set that can guide remediation, reconciliation, and communication.
Before you begin
- An integration incident
- Safe customer or record correlation
- An expected outcome or reconciliation source
Why impact analysis matters
Move from a technical failure count to the customers, records, and outcomes that require action.
A large number of failed attempts may affect one retried record, while one silent failure may block a high-value customer workflow. Counting observations alone can therefore overstate or understate the response required.
Impact analysis is a distinct use case because it asks a different question from detection: not only what changed, but which real entities and outcomes can be connected to that change with evidence.
When to use this workflow
Choose impact analysis when incident priority or remediation depends on verified business scope.
Use this workflow after an incident boundary is known and the team needs a supported affected set for prioritisation, reconciliation, customer support, or follow-up reporting.
- Prioritise an incident by affected customers rather than request count.
- Identify records that need reconciliation after a silent failure.
- Separate affected environments or releases during a partial rollout.
- Track which outcomes were restored after remediation.
Design safe correlation
Choose stable, non-sensitive identifiers that connect observations with domain outcomes.
Choose correlation evidence already produced by the application workflow and safe for operational use. The same representation must appear on the triggering observation and the downstream result that will confirm impact or recovery.
- Prefer application-owned identifiers that are already safe for operational logs.
- Hash sensitive identifiers before transmission.
- Keep identifiers stable across the observation and expected outcome.
- Do not transmit raw payloads only to improve impact analysis.
Measure the affected scope
Identify the environments, customers, and records linked to the failure window.
Use the incident window and correlation evidence to identify affected environments, customers, and records. Count only records supported by linked evidence, and keep unknown scope explicit.
- Confirm the incident window and affected integration environments.
- Collect the unique safe correlation identifiers supported by linked observations.
- Compare those identifiers with expected outcomes or the reconciliation source.
- Separate confirmed affected, confirmed recovered, and unknown records.
Track reconciliation
Confirm which expected outcomes were restored or still require remediation.
After remediation, compare the expected outcomes with the affected record set. Mark a record reconciled only when the required result is observed or verified by the system that owns it.
Keep remediation action and recovery evidence separate. Retrying or updating a record is an action; the resulting domain state is the evidence that recovery completed.
Operating boundaries
Count only evidence-linked records and keep incomplete correlation visible as unknown scope.
- Counts include only records linked by available correlation evidence.
- Hashed identifiers are not presented as reversible customer data.
- Unknown scope remains explicit when the source workflow cannot be correlated safely.
- Seamward does not notify customers or alter system-of-record data automatically.