Three hundred and ninety-one tests passed over an integration that had never written a single row. Later, five hundred and three passed over a write that could not have executed at all.
Silent success is the first family in this series and the most expensive, because every surface involved shows you the thing you wanted to see. A success code, a green suite, a dashboard with no error on it — each reports on a transport layer or a test harness, and none reports on whether a write landed. An acknowledgement means a receiving system accepted your bytes, not that it kept them, parsed them, or acted on them.
That gap is where all four instances below lived, in one case for 90 days. A 2xx and a green build are each the absence of one particular failure, which is not evidence of a result. A Zero From an Unvalidated Instrument Is Void opens this series with all twenty instances and the taxonomy; this post takes the first family, and the technique that closes it costs one deliberate act of vandalism per repair.
| # | Instrument | What it said | What was true |
|---|---|---|---|
| 10 | 391, then 503 passing tests | the integration works | it had never written anything; the write could not have executed |
| 12 | An audit log | no rows — no new leads arrived | every enrolment failed; the audit line only fired on success |
| 16 | GA4 Measurement Protocol | HTTP 204, success | the payload was discarded on a lowercase enum |
| — | Four independent health surfaces | the won-job conversion leg is healthy | a dropped conversion is classified healthy in all four |
391 green, 503 green, nothing written
Two suites, one estate — the system we build and operate for a storm-restoration contractor. The suite reporting 391 passing tests covered an integration that had never written anything to its target. The later suite at 503 passing covered a write that could never have executed, because one of its fields was structurally invalid and the operation would have been rejected on shape before any business logic ran.
Every assertion in both suites was true. They asserted that functions returned what those functions were written to return.
A sibling defect on the same estate makes the shape unmistakable: 347 passing tests sat over a message-sending path on which every message ever sent to a real lead had silently failed, because no test ever fed the transformation a badly-formed number. The repair fails closed, and the receipt that matters is its regression test: restoring the old line turns 3 of the test's 7 cases red.
The audit line that only fired on success
On the same estate a scheduled enrolment sweep left no rows in the audit log, and the reading taken from that was "no new leads arrived" — when every enrolment had in fact failed, because the audit line sat on the success branch only and total failure and an empty input set produce byte-identical output. Underneath it sat an allowlist defect, and the ledger carries the phrase worth stealing: green means nothing happened OR everything failed. An audit log that records only successes is a scoreboard.
The 204 that was proof of transport and nothing else
Our own site, and the cleanest instance in the set: between 2026-06-09 and 2026-08-02 our pipeline database recorded eight successful HTTP 204 responses from GA4's Measurement Protocol while GA4 held zero of the target lead event across 90 days, the payload being discarded on a lowercase consent enum by an endpoint that answers 204 either way. The 204 That Lied carries the realtime read, the three-send isolation and the fix; the arithmetic is what belongs here — eight recorded successes, 90 days, zero events, and nothing in the shipping path able to say otherwise.
Exposure was checked rather than assumed: one client pipeline normalises the value correctly, and the other does not send Measurement Protocol events at all. The fix was casing only, and one contradiction stays open — in that module the absent-consent default is "granted" while another defaults to denied on unknown input.
Four green surfaces over one dropped conversion
At an HVAC contractor, the leg carrying won jobs back to Google Ads has produced exactly one successful non-validation upload in its lifetime — on 2026-07-14, on a synthetic dry-run click identifier generated by the arm test itself — and a dropped won-job conversion there is classified healthy in four independent places, the class the corpus calls silent-by-construction. The Match Key Is the Product walks the miss-recorder, the reprocessor and the 135 rows in its queue — rows in an upload queue, not a count of jobs — of which 35 sat outside the instrument's reach on the live read of 2026-08-17.
What is written off is ad-platform attribution, not revenue: every dollar stays recorded in the CRM, the committed export and the operational database. What exists is a growing backlog of won jobs the bidding algorithm cannot see, and no dollar total on it is safe to publish while the repair waves are still landing out of order.
The technique: Re-Break It
1. Name the write. Before writing a test, state the row, event or record whose existence proves the integration ran. On the loopback leg that is a row at the signed stage, and there has never been one from a real job — a fact that became sayable only once the write was named.
2. Assert on the artifact, not the acknowledgement. The assertion that mattered for GA4 was an event count read from GA4, not a 204 stored in our own database. Our database was the one participant guaranteed to agree with us.
3. Re-break the repair on purpose and require red. The normaliser above is the pattern, and the GA4 regression lock was held to the same bar — verified to fail against the pre-fix source before anyone trusted it. In our harness audit of 2026-07-29 through 2026-07-31, roughly 58 kill-verified mutations ran against the suite; four survived, every one a test defect, each closed by strengthening the test.
4. Quantify over the system's own keys. A hand-written list of names starts decaying at merge. The replacement enrolment test iterates the cadence map's own keys, so a template added next quarter is covered the moment it exists — a structural coverage claim rather than a clerical one.
A repair is not finished when the suite goes green. It is finished when you have broken it again on purpose and watched it go red.
What would prove this wrong
- A GA4 read showing the target lead event inside 2026-06-09 to 2026-08-02. Then the eight 204s were delivery receipts and the enum was not the mechanism.
- Restoring the old normaliser line and getting a green suite. That red result is the whole warrant for the repair.
- An enrolment sweep where every enrolment fails and the audit log records rows. Then the success-only audit line was not why the failure was invisible.
- One upload at the signed stage matched on a real, customer-originated click identifier. Then that leg is under-exercised rather than structurally blocked.
- Any of the four health surfaces reporting the dropped conversion as unhealthy. That retires silent-by-construction here, which would be good news and would be published in the same place.
Break it in a branch before you trust it
Choose one integration you believe works, break it on purpose in a branch, and run the suite. If it stays green you have a description of the code rather than a test of it, and every number downstream of it inherits that status. The branch is disposable and the answer arrives the same day you ask for it, which is the cheapest order those two facts will ever come in.
Get the kit, not just the theory.
We'll send the build checklist behind this post — and the next pillar when it ships. One email, no drip sequence. Unsubscribe in one click.
