skip to content

A postmortem argues that because the request failed, the retry budget must have been exhausted - why is that inference invalid?

level: middleimportance: should knowfreq 58%

answer

  1. the arrow runs one way
  2. the symptom does not name the cause
  3. other causes fit the same outcome
  4. denying the consequent is the legal move
  5. the permitted row: failure without exhaustion

basics

~20 s

It runs the rule backwards from its consequent, the fallacy of affirming the consequent. A rule saying exhaustion causes failure leaves every other cause of failure open, so the failure supports the hypothesis without establishing it.

solid answer

~40 s

The rule is `p -> q`: exhaustion is *sufficient* for failure. Two inferences from it are valid. **Modus ponens** goes forward: `p` holds, therefore `q`. **Modus tollens** goes backward from a denied consequent: `not q` holds, therefore `not p` - the request succeeded, so the budget was not exhausted. The postmortem is doing neither; it observes `q` and concludes `p`, which is **affirming the consequent**. The truth table shows why it fails: the row with `p` false and `q` true is permitted by the rule, and that row is exactly a failure with budget to spare. The conclusion only follows if exhaustion is also *necessary* for failure - a biconditional, which needs its own evidence, such as ruling the other causes out.

go deeper

for a junior

Remember the two legal moves: apply the rule forward from its condition, or run it backward only from a denied outcome. Reasoning from the outcome to the condition is the fallacy.

for a middle

Name the pattern and show the permitted row that breaks it - a failure with budget remaining. Contrast it with modus tollens, which is valid precisely because it is the contrapositive.

for a senior

Drive the investigation by elimination: hunt for the successful request that excludes a candidate rather than the failure that is consistent with all of them. Check the antecedent directly when it is observable.

for a principal

Notice when a team wants a biconditional and has only a one-way rule. Deciding whether to invest in evidence for necessity, or to instrument the condition directly, is the call that stops repeat misdiagnoses.

The argument in the room has the shape: *the rule says exhausted budget implies failure; this request failed; therefore its budget was exhausted.* It is one of the two most common invalid inference patterns, and it has a name - **affirming the consequent** - precisely because it is so easy to make while sounding rigorous. ## What the rule licenses and what it does not Write `p` for 'the retry budget is exhausted' and `q` for 'the request fails'. From `p -> q` there are exactly two valid one-step moves, and two invalid ones that mirror them: | pattern | you observe | you conclude | valid? | name | |---|---|---|---|---| | forward from the condition | `p` | `q` | yes | modus ponens | | backward from a denial | `not q` | `not p` | yes | modus tollens | | backward from the outcome | `q` | `p` | **no** | affirming the consequent | | forward from a denial | `not p` | `not q` | **no** | denying the antecedent | The two valid patterns are the rule itself and its contrapositive. The two invalid ones are the converse and the inverse wearing the costume of an inference step. ## The row that kills the argument A conditional is false on exactly one row - antecedent true, consequent false - and true on the other three. Among those three is the row `p` false, `q` true: **the request failed while the retry budget was untouched**. That row is fully consistent with the rule. It is also the exact scenario the postmortem is about to rule out by fiat: a bad node, a poisoned cache entry, a dependency that rejected the payload, a deploy that shipped a broken code path. So the failure is *compatible* with exhaustion but does not *establish* it. Logically the observation confirms nothing; investigatively it may still raise the hypothesis's plausibility, and the honest way to say so is that exhaustion remains one candidate among several. ## The move that is valid, and why it is the useful one Modus tollens is the inference an incident actually wants, because it eliminates: 1. Find a request that **succeeded** during the incident window. 2. The rule's contrapositive says a success implies the budget was not exhausted. 3. That candidate is now excluded for that request - no further argument needed. Elimination is what moves a postmortem forward. A single green request under the same conditions is worth more than a dozen failures, because failures are consistent with every hypothesis on the board while a success is not. ## Turning the fallacy into a real argument The conclusion the postmortem wants does follow - if the rule is strengthened. Ways to earn it: - **Show necessity as well as sufficiency.** If the only path to this failure mode is budget exhaustion, the claim is really a biconditional `p <-> q`, and then the failure does imply exhaustion. That has to be argued, not assumed. - **Eliminate the alternatives.** If the competing causes each have a contrapositive of their own and each is excluded by an observation, exhaustion is what survives. - **Look at the antecedent directly.** The budget's own state is usually observable. Reasoning backwards from an outcome is a substitute for checking the condition, and a poor one. ## Why this is worth catching in the room An invalid step does not announce itself: the conclusion may well be true, and if it is, the argument passes unchallenged and the same reasoning is used again on a day when it is wrong. The cheap test is to restate the rule and ask which direction is being run. If the answer is 'from the outcome back to the condition', the step is the converse, and the converse is not part of the rule. The mirror-image error, **denying the antecedent** - 'the budget was fine, so the request cannot have failed' - fails on the same row and deserves the same challenge.

  • Which observation during the same window would let you validly exclude the budget hypothesis?
    A request that succeeded under the same conditions. By the contrapositive - a success implies the budget was not exhausted - that single case eliminates the hypothesis for that request, no further argument needed. Successes are worth more than failures here, because a failure is consistent with every candidate cause while a success is not.
  • What would have to be true for the postmortem's conclusion to follow validly?
    Exhaustion would have to be necessary for this failure mode, not merely sufficient - that is, the claim would have to be a biconditional. That is a strictly stronger statement: it additionally forbids failures with budget remaining, so it needs evidence that no other cause can produce the same outcome.
  • What is the mirror-image fallacy, and where does it fail?
    Denying the antecedent: 'the budget was fine, so the request cannot have failed'. It fails on the same permitted row - antecedent false, consequent true - where a request fails for an unrelated reason. Like affirming the consequent, it treats a one-way rule as if it ran in both directions.

saying these in an interview costs you the question

  • Reasons from the observed outcome back to the stated condition
  • Treats a sufficient condition as if it were necessary
  • Says a failure confirms the rule and therefore the cause
  • Claims a fine budget guarantees the request succeeded
  • Assumes an invalid step is fine when its conclusion turns out true