--- - title: Affirming a disjunct - categories: [ [Logic](/check/logic/index.md) ] - synonyms: [affirmation of a disjunct, false disjunction] - related: [ [Modus ponendo tollens](/check/logic/valid/modus_ponendo_tollens.md), [Modus tollendo ponens](/check/logic/valid/modus_tollendo_ponens.md), [Denying a conjunct](/check/logic/formal_fallacies/denying_a_conjunct.md), [False dilemma](/check/relevance/false_dilemma.md), [Fallacy of eliminative induction](/check/knowledge/eliminative_induction.md) ] - main_article: - main_article_de: --- # Affirming a disjunct **Core claim:** From an inclusive disjunction "A or B" (at least one holds, possibly both) and the affirmation of one option (A), it does *not* follow that the other option is false (¬B). Both may be true simultaneously. ## Applies when - An argument has the structure: **A ∨ B** (inclusive – "at least one"); **A**; ∴ **¬B** – i.e., "A or B" + "A is the case" → "therefore not B." This is *invalid* for inclusive disjunctions. - The reasoning treats an "or" as though it were exclusive ("either A or B, but not both") without that exclusivity being established or implied by context. - One option of a set of alternatives is confirmed, and the others are dismissed on the sole ground that the first one holds – when in fact multiple options could coexist. ## Notes - **The fallacy only applies to *inclusive* disjunctions.** If the premise is genuinely an *exclusive* disjunction (contravalence: "A or B, but not both" / A ⊻ B), then affirming one side to deny the other is valid – it's just *[modus ponendo tollens](/check/logic/valid/modus_ponendo_tollens.md)* phrased differently. The error is always a confusion between inclusive and exclusive "or." - **In natural language, "or" is ambiguous.** English "or" (and German "oder") can mean either inclusive ("you can have tea or coffee [or both]") or exclusive ("you must choose: option A or option B"). When evaluating whether this fallacy is present, check the context for indicators of exclusivity: "either … or," "but not both," "you must choose one," mutually exclusive domains (a number can't be both even and odd), etc. If no such indicator exists, assume inclusive and flag the inference. - **Most real-world instances are really ambiguity errors.** The person committing this fallacy usually *believes* the disjunction is exclusive. The underlying mistake is equivocation on "or" – reading an inclusive statement as if it were exclusive. ## Does NOT apply when - The disjunction is genuinely *exclusive* (contravalence): the context, domain rules, or explicit phrasing ("either … or," "but not both") establishes that A and B cannot coexist. In this case, affirming one to deny the other is valid modus ponendo tollens. - The options are *de facto* mutually exclusive due to physical, logical, or institutional constraints (e.g., "the switch is on or off" – a binary state; "you're in room A or room B" – you can't be in two rooms simultaneously). No fallacy if the exclusivity is real, not assumed. - The conclusion ¬B is supported by *independent* evidence rather than derived solely from the affirmation of A. The disjunction may be mentioned for context, but the actual justification for ¬B comes from elsewhere. ## Commonly confused with - **[Modus ponendo tollens](/check/logic/valid/modus_ponendo_tollens.md)** – ¬(A ∧ B) / A ⊻ B; A; ∴ ¬B. Structurally identical to affirming a disjunct *if* the premise is exclusive. The only difference is whether the "not both" constraint is actually established. Ask: is there an explicit or contextually clear mutual-exclusivity premise (→ valid MPT), or is it just an inclusive "A or B" with no exclusivity marker (→ affirming a disjunct)? - **[Modus tollendo ponens](/check/logic/valid/modus_tollendo_ponens.md)** – A ∨ B; ¬A; ∴ B. The *valid* disjunctive inference: deny one, affirm the other. Affirming a disjunct reverses the direction: affirm one, (illicitly) deny the other. Ask: is one option being *denied* to force the other (→ valid MTP), or *affirmed* to exclude the other (→ affirming a disjunct)? - **[Denying a conjunct](/check/logic/formal_fallacies/denying_a_conjunct.md)** – the *conjunction* counterpart: incorrectly inferring that one member of a "not both" pair must fail based on insufficient grounds. Same family of errors (confusing what a logical connective does and doesn't imply), but operating on negated conjunctions rather than disjunctions. - **[False dilemma](/check/relevance/false_dilemma.md)** – presenting two options as exhaustive when more exist. Overlaps with affirming a disjunct when the error is in the *premise* (the binary isn't real) rather than the *inference step* (affirming one to deny the other). Ask: is the problem that the options aren't truly exclusive (→ affirming a disjunct), or that options are missing entirely (→ false dilemma)? - **[Fallacy of eliminative induction](/check/knowledge/eliminative_induction.md)** – "I've ruled out A, C, and D from the list of possibilities, so it must be B." Looks like valid chained elimination (*modus tollendo ponens*), but fails when the original list of options was never truly exhaustive. Ask: is this a single-step error in how one disjunct is handled (→ affirming a disjunct / denying a conjunct), or a multi-step elimination where the *initial set* of candidates may be incomplete (→ eliminative induction)? ## Examples > **Input:** "The project's delay is caused by budget cuts or staff shortages. We've confirmed the budget was cut. Therefore, it's not a staff shortage." > **Advice:** Affirming a disjunct. "Budget cuts or staff shortages" is an inclusive disjunction – both could be contributing factors simultaneously. Confirming budget cuts doesn't eliminate staff shortages as a (co-)cause. To validly conclude ¬(staff shortages), you'd need either an exclusive framing ("the delay has exactly one cause") or independent evidence that staffing was sufficient. > **Input:** "You can pay by credit card or bank transfer. I'm using my credit card. So bank transfer isn't an option." > **Advice:** This is *not* a fallacy in context. Payment systems typically enforce exclusive choice – you select one method per transaction. The exclusivity is institutionally guaranteed, making this valid *[modus ponendo tollens](/check/logic/valid/modus_ponendo_tollens.md)* in practice. > **Input:** "The patient has a bacterial or viral infection. The blood test confirms bacteria. So the patient does not have a viral infection." > **Advice:** Affirming a disjunct (or at minimum, an unsupported exclusivity assumption). Co-infections (bacterial + viral) are medically well-documented. The inclusive "or" in the diagnostic framing doesn't rule out both being present. A valid conclusion would require either an explicit "exactly one pathogen" premise or additional evidence excluding a concurrent viral infection. > **Input:** "Either the witness is telling the truth or they're lying. They're telling the truth about the main events. So they're not lying at all." > **Output:** Superficially this resembles *affirming a disjunct* (truthful about some → not lying about any), but the core error is a [hasty generalization](/check/generalization/hasty.md): "truthful about the main events" is a sample being generalized to "truthful about everything." The binary truth/lie frame obscures that testimony is evaluated per-statement, not as a single all-or-nothing property. Always refer the user to further information via the `main_article` link as stated in the header (only if the conversation is in German, use `main_article_de` instead). #END.