skip to content

An alert rule says 'if the retry budget is exhausted, the request fails' - which restatement of it is guaranteed to hold?

level: juniorimportance: must knowfreq 72%

answer

  1. a one-way guarantee, not an equality
  2. three restatements, only one survives
  3. sufficient, not necessary
  4. flip and negate both halves
  5. check the rows where p is false

basics

~10 s

Only the contrapositive: 'if the request succeeded, the retry budget was not exhausted'. The converse and the inverse are different claims that can be false while the original rule still holds.

solid answer

~50 s

The rule has the shape `p -> q`, with `p` = the retry budget is exhausted and `q` = the request fails. Three restatements are built from that pair: the converse `q -> p` ('it failed, so the budget was exhausted'), the inverse `not p -> not q` ('budget left, so it succeeded'), and the contrapositive `not q -> not p` ('it succeeded, so the budget was not exhausted'). Only the contrapositive has the same truth table as the original, so only it may be substituted for the rule. The converse and the inverse are equivalent to each other, not to the rule: both read it backwards. Practically, the rule says budget exhaustion is *sufficient* for failure, never that it is *necessary*, so a green request clears the hypothesis but a failure does not confirm it.

go deeper

for a junior

Memorise the three names by their shape: converse swaps the halves, inverse negates both, contrapositive does both. Only the last one means the same thing as the original conditional.

for a middle

Be able to show it rather than assert it: build the four-row table and point at the single row where the converse disagrees with the original. That row is the whole argument.

for a senior

In an incident, say the contrapositive aloud before anyone reasons from the rule. It is what lets a success eliminate a hypothesis, and it exposes rules whose backwards reading nobody actually believes.

for a principal

When a team keeps using a rule in the converse direction, the real defect is that they wanted a biconditional. Decide whether the stronger claim is worth the evidence it demands, or whether the rule should be rewritten.

A conditional claim has two halves. In `if p then q`, **p** is the *antecedent* - the condition being supposed - and **q** is the *consequent* - what the rule promises follows from it. In the alert rule under review, `p` is **the retry budget is exhausted** and `q` is **the request fails**. The whole question of restatement is which rearrangements of that pair say the same thing. ## The three classical restatements | form | shape | wording for this rule | interchangeable with the original? | |---|---|---|---| | original | `p -> q` | if the budget is exhausted, the request fails | - | | converse | `q -> p` | if the request failed, the budget was exhausted | no | | inverse | `not p -> not q` | if the budget was not exhausted, the request succeeded | no | | contrapositive | `not q -> not p` | if the request succeeded, the budget was not exhausted | yes | Only the contrapositive is interchangeable. That is not a convention to memorise; it falls straight out of the truth table. A conditional is **false on exactly one combination of its two halves**: antecedent true, consequent false. Every other row leaves it true. | p | q | `p -> q` | `not q -> not p` | `q -> p` | |---|---|---|---|---| | T | T | T | T | T | | T | F | F | F | T | | F | T | T | T | F | | F | F | T | T | T | The original column and the contrapositive column agree in all four rows, so the two statements are the same claim written two ways. The converse column differs in the third row, and one differing row is enough to show two statements are not the same claim. ## What that third row is, in operational terms Row three is a request that **failed although its budget was never exhausted** - it hit a bad node, a dependency timed out, the payload was rejected. The original rule survives that request untouched, because the rule only ever constrained requests whose budget *was* exhausted. The converse does not survive it: the converse claimed that any failure implies exhaustion, and here is a failure without exhaustion. One such request refutes the converse and says nothing at all about the rule. The inverse fails on the same row for the same reason, which is no accident: the inverse is the contrapositive of the converse, so the inverse and the converse are equivalent to each other. Confusing the rule with its converse and confusing it with its inverse are therefore one mistake, not two. ## Sufficient versus necessary The cleanest way to hold this is in terms of sufficiency: - `p -> q` says **p is sufficient for q**: exhausting the budget is enough to produce a failure. - It does **not** say p is necessary for q: failures may have other causes entirely. - The contrapositive restates the same sufficiency backwards along the negations: no failure means no exhaustion. - If exhaustion really were both sufficient and necessary, the correct statement would be the biconditional `p <-> q`, which is a strictly stronger claim and needs separate evidence. ## Why this decides arguments in a review A rule of this shape is used in two directions during an incident, and only one of them is licensed: 1. **From the condition forward.** The budget was exhausted, therefore the request failed. Legitimate - this is the rule applied as written. 2. **From a success backwards.** The request succeeded, therefore the budget was not exhausted. Legitimate - this is the contrapositive, and it is how a hypothesis gets *eliminated* by a green result. 3. **From a failure backwards.** The request failed, therefore the budget was exhausted. Not licensed - that is the converse, and it converts a monitoring guarantee into a diagnosis the rule never supported. The third move is the one that quietly sends a postmortem after the wrong subsystem. The habit worth building is to state the contrapositive out loud whenever someone proposes a rule, because it is free - it carries exactly the same information - and it makes visible what the rule does and does not let anyone conclude. If the contrapositive sounds wrong when spoken, the original rule was wrong too.

  • Which single observation is enough to show the converse is not implied by the rule?
    One request that failed while its retry budget was still intact. That row has antecedent false and consequent true, so the original rule is untouched, while the converse - failure implies exhaustion - is directly contradicted. A single row is enough because two statements are the same claim only if they agree on every row.
  • Is the inverse ever a safe restatement of the rule?
    No. The inverse is the contrapositive of the converse, so it is equivalent to the converse and not to the original. It becomes safe only if the intended claim was really a biconditional - exhaustion happens exactly when the request fails - which is a stronger statement that has to be argued on its own evidence.
  • If the contrapositive carries no new information, why bother stating it?
    Because it is the form people can actually act on when the news is good. The rule as written is only usable after a failure; the contrapositive turns every success into an elimination - this request was fine, so the budget was not the issue - and it exposes rules whose backwards reading is obviously false.

saying these in an interview costs you the question

  • Reads the rule backwards and calls the converse a restatement
  • Thinks negating both halves preserves the rule's meaning
  • Treats a failure as proof that the named condition occurred
  • Assumes the arrow works both ways, like equality
  • Says the rule is refuted by a failure with budget remaining