ROOT CAUSE ANALYSIS WORKSHEET
Original completed fictional exercise and blank form. Checked 2026-10-28.
https://showmeyoursaas.com/articles/root-cause-analysis-template/
References: https://asq.org/quality-resources/root-cause-analysis
https://sre.google/sre-book/postmortem-culture/
Every event and result below is invented teaching material. No application was tested.

COMPLETED EXERCISE — QUEUENOTE
Problem: one logical export job J-204 has two application completion-notification records, N-501 and N-502.
Scope: the synthetic workspace and job in the companion timeline.
Impact established by fixture: two notification side effects were recorded.
Unknown: whether a recipient read either message; broader prevalence; why acknowledgement was absent.
Clock assumption: one UTC clock for all exercise records.

EVIDENCE
EV1: first attempt completed export for J-204.
EV2: first notification N-501 recorded.
EV3: delivery record has no acknowledgement for the first attempt.
EV4: retry runs for the same logical job J-204.
EV5: second application notification N-502 recorded.
EV6: operator record pauses the affected future notification path.
EV7: fictional design review states completion notification lacks an enforced logical uniqueness rule.
The CSV contains observations, not an executed reproduction or a complete real log.

COMPETING EXPLANATIONS
H1: two separate user jobs.
Support to seek: distinct origin/job records.
Exercise evidence: records point to the same logical job, not two distinct jobs.
Limit: a real system's origin and idempotency semantics would need inspection.

H2: worker retry repeats the side effect.
Support: EV1, EV2, EV3, EV4, EV5, EV7.
Exercise interpretation: a retry path can repeat the notification because the completion side effect is not guarded once per logical job.
Still unknown: the cause of missing acknowledgement and prevalence beyond this fixture.

H3: provider duplicates one submitted message.
Support to seek: one application notification with multiple downstream deliveries.
Exercise evidence against this explanation: EV2 and EV5 are distinct application side-effect records.
Limit: downstream delivery and reading are not established by this dataset.

CONTRIBUTING CONDITIONS
Retry after absent acknowledgement is part of the exercise policy.
Missing enforced completion uniqueness allows another notification.
A weak attempts-to-job view makes investigation harder.
These are exercise assumptions and interpretations, not findings about a real service.

PROPOSED ACTIONS — ALL PENDING
A1 Engineering: enforce the intended once-per-completion side-effect contract with an appropriate atomic uniqueness design, scoped to workspace, logical job, and side-effect type.
Verify: replayed completion produces one notification; a distinct authorized job still works.
A2 QA: add completion/ack-loss/retry fixture and inspect final stored side effects.
Verify: failure path and normal path match the actual contract.
A3 Operations: improve the permitted view connecting attempts, logical job and side effects.
Verify: a reviewer can trace the synthetic incident without private payloads.
Containment: pausing future notifications is separate from prevention and does not undo prior side effects.

BLANK FORM
Incident / problem reference:
Precise observed problem:
Period / service / population:
Established impact:
Unknown impact:
Evidence sources and access:
Timeline and clock assumptions:
Hypothesis:
Supporting evidence:
Conflicting evidence:
Alternative explanations:
Contributing conditions:
Proposed corrective action / owner:
Verification that could disprove it:
Actual verification result (leave pending until checked):
Remaining unknown:
Review trigger:
Keep secrets and unnecessary personal information in their approved systems, not in a shared worksheet.