Affirming the Consequent

Examples

A parent notices the street outside is wet.

Parent: “If it rains, the street gets wet. The street is wet, so it must have rained.”

It could have rained — but a street cleaner, a burst pipe, or a neighbor washing a car would leave it wet too. The parent has one explanation, not the only one.

The pattern shows up constantly in online tech-support threads:

Post: “If the app crashes, it’s usually because storage is full. My app just crashed, so my storage must be full.” Reply: “Could also be a bad update, a corrupted cache, or a conflict with another app. Worth checking storage, but it’s not the only option.”

Why the reasoning fails

The if-then shape here is: if A, then B (if it rains, the street is wet). Affirming the consequent starts from B being true (the street is wet) and concludes A (it rained). That’s backwards. Compare it with the valid form, called modus ponens: if A, then B; A is true; therefore B. “If it rains, the street gets wet. It’s raining. So the street is wet” — that’s solid, because A being true guarantees B. But knowing B is true doesn’t guarantee A, because other things can also produce B. The rule “if A then B” only promises that A leads to B, not that B can only come from A.

How to respond

• Name the shape: “This is going from ‘the effect happened’ to ‘so the specific cause must be true’ — but other things could cause the same effect.”
• Ask for other explanations: “What else could make the street wet / the app crash / the test come back positive?”
• Ask what would rule the alternatives out: “Is there a way to check whether it actually rained, rather than just inferring it?”
• Recognize when it’s still useful as a hunch. “B happened, and A is the most common cause of B” is a reasonable starting guess — the fallacy is treating it as proof rather than a hypothesis to check.