Grade the Defect on Detectability, Not on Recoverability

The sanity check came back clean. Cancelling the order worked. A replacement behaved completely normally.

I left the severity at High.

That is not stubbornness. A remedy that works and a remedy that gets used are different facts, and severity conversations almost never separate them.

The default question is the wrong question

Ask a room how bad a defect is and the discussion converges within a minute on two things: how bad is the end state, and can we undo it.

Both are reasonable. Both are about recovery. And a working undo argues the number down every single time — "it's recoverable, so it's Medium" is a sentence I have heard in more triage calls than I can count, and usually it is correct.

It is wrong in exactly one case, and that case is invisible from inside the question.

The failure mode with no signal

Here is what the affected order looked like.

Every orchestration item ended as Skipped. Not Failed. Skipped is a legitimate terminal state — it is what a step does when its entry condition says it should not run, and it is how the platform expresses "nothing to do here."

So the plans closed cleanly. No exception was raised, so nothing reached an exception report. No item sat in an error queue. The order carried no red flag, no warning, no anomalous status.

It looked like any other in-flight order.

Now put the recoverability finding next to that. Yes, cancelling works. Yes, a replacement behaves normally. But those are remedies, and a remedy needs someone to decide to apply it.

Nobody would ever know to.

Recoverability is a property of your fix. Detectability is a property of the system.

That is the sentence I keep coming back to.

Recoverability tells you what a competent person can do once they are told. It measures the size of the repair, and it is genuinely useful information — for planning the fix.

Detectability tells you whether anyone is ever told. It measures the distance between the defect occurring and a human learning about it, and that distance is what actually determines how much damage accumulates in production.

A recoverable, undetectable defect does not cost you one order. It costs you every order that hits the same path between release and the first customer complaint — and the complaint is the detection mechanism, which means the customer is doing your monitoring for you.

An unrecoverable but loud defect costs you the orders in flight when the alert fires. Then it stops, because somebody turns it off.

Graded on end state, the first one looks better. Graded on how many times it happens before anyone notices, it is not close.

The three questions I ask now

Before I put a number on a finding, three questions in this order:

• What does the system look like when this happens? Describe the record, the status, the plan, the log line. If the description is "it looks normal," you have your answer and the rest of the triage is a formality.
• Who or what learns about it, and how long does that take? Name the mechanism. An exception report, a failed step, a monitoring alert, an integration error, a customer phone call. If the only honest answer is the last one, the severity is not about recovery any more.
• What would have to exist for me to agree to lower this? This is the useful one, and it belongs in the ticket.

That third question is the whole technique, and it changes what the conversation is about.

Name the signal that would lower the severity

The worst version of a severity disagreement is two people trading adjectives about a number. High. Medium. It's recoverable. It's still bad. Nobody moves, someone senior decides, and the reasoning is not written anywhere.

So write the condition into the ticket, plainly:

"Held at High on detectability. Every item ends Skipped, plans close cleanly, nothing reaches an exception report — there is no signal that would cause anyone to invoke the remedy. I will agree to Medium once this state produces a Failed step or an entry on the exception report."

Three things happen when that sentence exists.

The argument stops being about a number and becomes about adding detection — which is a smaller, cheaper, more shippable piece of work than most severity fights are worth. Detection is often a genuinely modest change, and it converts a silent failure into a loud one, which is most of the value you were arguing for anyway.

The developer gets an actionable exit. "Make it Medium" is not a task. "Make this step fail instead of skip, or write it to the exception report" is.

And if the ticket is deferred anyway, the deferral is now on the record as deferring the detection, not as accepting a recoverable inconvenience. Those read very differently six months later.

Why this one escapes

Because the sanity check that proves recoverability feels like diligence — and it is. Testing the undo is the right instinct. I did it, it worked, and every instinct said the finding had just got smaller.

The trap is that the sanity check answers a question you asked in a state you already knew about. You knew the order was broken, because you broke it. You had context nobody in production will have.

Skipped is what makes it hold together. It is a normal, healthy, entirely legitimate status, which is why it survives review: nothing about it looks like a failure to anyone reading the plan afterwards. The absence of an error is not evidence that nothing went wrong. It is the reason nobody will find out.

Take the last defect you agreed to downgrade because it was recoverable. In production, who would have told you it happened?