This root cause analysis template makes those links visible. Separate immediate correction from the action aimed at recurrence, then keep effectiveness review open until its relevant checks are addressed. One passed example cannot stand in for a case nobody has run.
The original fictional case concerns duplicate resource cards in an offline workshop packet. Every investigation and verification record below is an authored training fixture, not a test of real workshop software.
Write the finding before naming the cause
Finding F1: reopening the fictional packet displays a resource card twice even though the source list contains each item once.
The supplied investigation records are:
| Record | Observation in the training fixture | What it supports |
|---|---|---|
| E1 | Source list contains A and B once each; reopened display contains A, B, A, B | The displayed duplication is not present in this supplied source list. |
| E2 | Isolated reproduction retains the old displayed list, then appends A and B again on reopen | A retained-list/appending mechanism reproduces the finding in this fixture. |
| E3 | Clearing the old displayed list before rendering A and B produces one of each | Changing that part of the fixture removes the reproduced duplication. |
E1 challenges the initial explanation “the source contains duplicates.” E2 and E3 support a more specific mechanism in the declared reproduction: old displayed entries remain while rendering appends another copy.
Keep the finding bounded to that mechanism. The packet does not examine every path that could produce a duplicate, identify a person's motive, or demonstrate that a particular real application has this defect.
NASA's corrective-action chapter links documented findings, causes, actions, and validation of the action's success. We use that evidence-to-action distinction in a non-safety training case, without applying NASA's environmental-management procedures or claiming compliance. Read the corrective-action chapter.
Choose an action that addresses the mechanism
The immediate correction removes the duplicate from the affected packet. It improves that copy, but the same append-to-existing behavior could recreate the problem.
The mechanism-directed corrective change is to replace the displayed list from the current source when rendering, rather than append to whatever is already displayed. Its rationale links directly to E2's retained-list behavior.
The action record should keep both entries:
- Correction: clean up the duplicate in this packet.
- Corrective change: replace-from-source rendering in the model, addressing the reproduced retained-list mechanism.
Do not replace the original evidence with the proposed change. Reviewers need to see why that action was chosen and which alternative explanation the evidence did not support.
Define the effectiveness checks before closing
The supplied verification record contains two cases:
| Case | Purpose and expected result | Supplied status |
|---|---|---|
| V1: reopen fixture | Source A, B; render and reopen. Display remains A, B, one each. | Pass in the authored model record. |
| V2: changed-source fixture | Change source to A, C, then render again. Display should become A, C without retaining B. | Not run; no actual result supplied. |
V1 addresses repeated rendering of the same source. V2 asks whether replacement follows a changed source instead of keeping an old item. That second question matters to the action's stated behavior, so its missing result stays visible.
The model reports the corrective change as implemented for V1. Its effectiveness review remains open while V2 is not run. This distinction prevents “change made” from turning into “recurrence prevented” without the supporting check.
Use the investigation trace
Select the finding to follow its evidence, reproduced mechanism, action, and verification cases. Compare packet-only cleanup with the mechanism-directed change. Open V1 and V2 to inspect the difference between a supplied pass and an absent result.
The example presents fixed authored records. It does not quietly run a real system or turn a local animation into an investigation result. The blank scaffold lets you record your own sanitized finding, support and contradiction, action rationale, verification plan, actual results, and remaining questions. Keep temporary notes while switching views and confirm before resetting them.
Copy this prompt to build the investigation record
Create a complete self-contained HTML root-cause-analysis record.
Finding: [bounded discrepancy]. Evidence with sources: [support and
contradiction]. Reproducedmechanism: [actual record or unknown].
Correction/correctiveaction: [separate]. Verification: [planned vs
actual cases/results]. Do not diagnose a cause from plausible wording.
Include a separate original fictional offline resource-card packet.
All records authoredtrainingfixtures, not realsoftwaretest evidence.
F1 reopeningduplicatescards. E1 sourceA,B unique but reopeneddisplay
A,B,A,B. E2 isolatedmodel retainsolddisplay then appendsA,B onreopen.
E3 clearoldlist beforerender givesA,B. E1contradicts source-duplicate
hypothesis; E2/E3support retainedlist+append mechanism inthisfixture
only. Otherpaths unexamined. No personblame or generalizeddiagnosis.
Correction removespresentduplicate. Correctivechange replacesdisplay
fromcurrentsource ratherthanappendstoexisting. Trace action to E2.
V1 sourceA,B render/reopen expectedA,B oneeach, suppliedauthoredrecord
Pass. V2 sourcechangesA,C rerender expectedA,C noB, Notrun noresult.
Implementation doesnotclose effectiveness while relevantV2unrun.
Preserve oldevidence; no claimallrecurrenceprevented or actualappfixed.
Provide finding/evidence/mechanism/action/verification inspectors,
cleanup-vs-mechanismchange comparison, PassvsNotrun details, blank
records with missingfinding/evidencefeedback, retainednotes across
views/validation, confirmedreset. No automaticcause diagnosis or
actualsystem execution. Labeled keyboard-accessible controls, visible
focus, systemfonts at least16px, readable360px layout without horizontal
scrolling, inline CSS/JavaScript, no dependencies. Return complete HTML.
Name the next check in the review copy
Share the prepared record in NOS with the person reviewing the corrective action and point them to V2. Ask what evidence they need from the changed-source case before closing the review. Keep that question beside the supplied V1 result so a completed first check does not hide the work still needed.