Root Cause Analysis Template for Evidence and Follow-up

Build an evidence-led causal record

Move from observation to conclusion without turning chronology, correlation, or one plausible explanation into an untested root cause.

1. Bound the problem and preserve evidence

   State expected and observed behavior, impact, scope, detection, and the investigation window. Give every evidence item a stable ID, timestamp, source, digest, and redaction confirmation before interpretation changes the record.

   Sources: [rca-pack], [osha-investigation], [nasa-swe-204]

2. Order events and test competing hypotheses

   Build a timestamped timeline linked to evidence. Record plausible explanations before testing, then retain supported, rejected, and inconclusive results so the conclusion can be challenged instead of reconstructed from memory.

   Sources: [rca-pack], [nasa-swe-204]

3. Separate factors from root causes

   Describe causal factors that directly produced the outcome and contributing conditions that increased likelihood or impact. Promote a root cause only when evidence supports an underlying, addressable condition and a recurrence test explains why changing it should matter.

   Sources: [rca-pack], [nasa-swe-204], [nist-rca]

4. Link actions to factors and verify effectiveness

   Use corrective actions to repair the demonstrated failure and preventive actions to reduce recurrence. Link each action to factors, a role-based owner, dates, dependencies, evidence, a verification method, an expected result, and an observed result.

   Sources: [rca-pack], [nist-actions], [osha-investigation]

5. Close the loop with follow-up

   Recheck the affected behavior after implementation, retain result evidence, and mark ineffective actions honestly. Implementation alone does not prove effectiveness, and follow-up completion does not certify compliance or every future operating condition.

   Sources: [rca-pack], [nasa-swe-204], [nist-actions]

6. Validate the portable record

   Run the dependency-free checks before sharing or automating the record. The pack declares JSON Schema Draft 2020-12, closes every object shape, reserves test-domain links for fictional evidence, and rejects broken references, unsafe values, and contradictory states.

   Sources: [rca-pack], [json-schema-2020-12], [rfc-2606]

The root cause analysis boundary

Use this record after an observed problem needs causal learning. It can feed a broader retrospective or postmortem, but it does not own that meeting, its wider decisions, or team-learning record. Keep adjacent intake, response, recovery, assurance, and personnel processes with their accountable owners.

Three ways to apply the record

The same evidence-to-verification graph can support different technical investigations while preserving the ownership boundary.

Decide whether the conclusion is reviewable

Structural validity cannot make the causal judgment for the team, but it can expose missing evidence, orphaned references, and premature closure.

1. A proposed cause has no linked evidence, tested hypothesis, or recurrence test.

   Choose: Keep it as a hypothesis and collect discriminating evidence before publishing it as a root cause.

   Tradeoff: Closure waits, but plausibility does not become an unsupported organizational fact.

2. An action has no linked factor, role owner, due date, or verification method.

   Choose: Keep the action planned and repair its ownership and evidence contract before implementation.

   Tradeoff: Execution may start later, but the team can tell what the action is meant to change.

3. The action was implemented but its verification has not passed.

   Choose: Record implementation evidence without marking the action effective or the follow-up complete.

   Tradeoff: The record stays open, but activity is not confused with demonstrated risk reduction.

4. The analysis drifts into response, blame, legal, audit, or compliance decisions.

   Choose: Restore the RCA boundary and link the separate accountable process instead of absorbing its verdict.

   Tradeoff: The RCA is narrower, but each decision retains its proper evidence and owner.

5. The analysis is being treated as the entire retrospective or postmortem.

   Choose: Use the RCA as one evidence-led input, then keep the broader meeting record, decisions, team learning, and follow-through in the process that owns them.

   Tradeoff: The team maintains two bounded records, but causal conclusions are not confused with every lesson or organizational decision.

What the template cannot prove

A strict record improves traceability. The conclusion remains limited by evidence quality, system observability, hypothesis design, reviewer judgment, implementation, and follow-up duration.

• A chronological sequence can suggest where to investigate, but timing alone does not prove causation.
• Five Whys or another causal technique can organize questions, but it cannot replace evidence or competing-hypothesis tests.
• A passed verification demonstrates its recorded conditions, not every future workload, dependency, operator, or environment.
• Role-based ownership does not assign personal blame or establish legal, employment, audit, safety, or compliance findings.
• The template does not capture every purpose of a retrospective or postmortem, such as facilitation, team feedback, broader decisions, and organizational learning.
• This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.

Sources and verification record

The pack is the source for its fictional records and tests. The external sources support systems-oriented investigation, causal analysis, corrective action, verification, and the formats used by the pack without certifying this template.

1. [rca-pack] Playcode:Root cause analysis fictional example

   Checked August 1, 2026. Supports: The locally reviewed fictional record, closed schema, role ownership, validation rules, action states, follow-up model, and deterministic tests. Public availability remains unverified until deployment.

2. [nasa-swe-204] NASA Software Engineering Handbook:SWE-204 Process Assessments

   Checked August 1, 2026. Supports: NASA guidance for high-severity software nonconformances on timelines, root causes, causal and contributing factors, causal methods, corrective actions, closed-loop follow-up, and verification. It is not a universal certification of this template.

3. [osha-investigation] Occupational Safety and Health Administration:Incident Investigation

   Checked August 1, 2026. Supports: A systems approach that looks beyond immediate causes and blame toward underlying factors and corrective action.

4. [nist-rca] National Institute of Standards and Technology:Root Cause Analysis glossary

   Checked August 1, 2026. Supports: The systems-oriented definition of root cause analysis and underlying risk.

5. [nist-actions] National Institute of Standards and Technology:Corrective and Improvement Actions program

   Checked August 1, 2026. Supports: NIST states that this in-development suborder establishes a process for documenting and implementing corrective and preventive actions for actual and potential Safety Management System nonconformities. It does not certify this template or its effectiveness model.

6. [json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12

   Checked August 1, 2026. Supports: The schema dialect declared by the downloadable closed JSON Schema.

7. [rfc-2606] RFC Editor:RFC 2606 Reserved Top Level DNS Names

   Checked August 1, 2026. Supports: Use of reserved test domains in fictional evidence links.

Root cause analysis template questions