Cause Hypothesis Log diagram showing suspected causes tracked through evidence, verification tests, results, and keep, drop, or retest decisions.

A Cause Hypothesis Log is a simple record used to manage suspected causes during problem solving.

It keeps the team from confusing:

  • an idea;
  • an observation;
  • a verified cause.

The objective is to make causal thinking visible and traceable.

Capture each hypothesis clearly

A useful hypothesis describes a relationship.

For example:

If fixture pressure falls below the required range, the seal defect rate increases.

This is more testable than:

Fixture problem.

Hypothesis-Driven Problem Solving helps convert assumptions into statements that can be tested with evidence.

Record why the cause is suspected

Possible supporting evidence includes:

  • timing;
  • correlation;
  • Gemba observation;
  • defect location;
  • recent change;
  • physical mechanism.

Is-Is Not Analysis can help identify differences between where the problem occurs and where it does not.

The log should show why a hypothesis deserves testing.

Define the test

Each hypothesis should have a planned verification method.

Examples include:

  • controlled trial;
  • comparison;
  • measurement;
  • temporary reversal;
  • inspection.

Cause Verification emphasizes testing whether the suspected cause actually changes the problem.

A hypothesis should not become a root cause simply because the team agrees with it.

Record the result

Useful statuses include:

  • supported;
  • rejected;
  • inconclusive;
  • needs more data.

Keep rejected hypotheses visible.

They prevent future teams from repeatedly testing the same idea without knowing it was already examined.

Separate evidence from opinion

The log can include columns for:

  • hypothesis;
  • evidence;
  • test;
  • result;
  • decision.

This structure helps the facilitator challenge unsupported statements without dismissing contributors.

Use the log to manage parallel investigation

Complex problems may have several plausible causes.

A shared log helps the team:

  • divide testing work;
  • avoid duplication;
  • see progress;
  • identify evidence gaps.

Problem Decomposition may reduce the problem first so the hypotheses apply to a specific subproblem rather than an overly broad issue.

Stop weak hypotheses early

Do not spend equal time on every possible cause.

Prioritize based on:

  • evidence strength;
  • physical plausibility;
  • impact.

The log should support disciplined narrowing.

Carry verified causes forward

Only causes supported by evidence should move into permanent corrective action.

Countermeasure Management can then connect the verified cause with actions, owners, and effectiveness checks.

Common mistakes

Writing causes as vague nouns, treating brainstorming votes as verification, failing to record rejected hypotheses, changing the hypothesis after the test, running tests without defining expected results, and choosing corrective actions before evidence supports the cause are common mistakes.

Practical sequence

  1. define the specific problem.
  2. list plausible causal relationships.
  3. record supporting evidence.
  4. prioritize the strongest hypotheses.
  5. define a verification test.
  6. define the expected result.
  7. run the test.
  8. record the evidence.
  9. accept, reject, or refine the hypothesis.
  10. move only verified causes into countermeasure work.

The practical lesson

A Cause Hypothesis Log keeps problem solving honest.

Ideas are welcome, but only evidence should decide which causes survive.