A 404 for a live article shows why a duplicate check can never prove absence

Twenty-three minutes after publishing an argument that a human approval gate is usually not judgment but a lookup nobody automated, a team writing on dev.to ran the lookup it had just moved into code and was told the article it had just published did not exist ^[1][2]. Four of six requests missed it, all inside about four minutes, all unauthenticated reads against one account and one freshly published article ^[3][4].

The detail that hurts is which read failed. Hours earlier the same team had written the prescription: do not judge publication by a list, use the single-item endpoint or the article URL, because they had already been bitten by the index endpoint lagging ^[5][6]. That single-item endpoint, designated authoritative that same morning, returned 404 for a live article whose page rendered fine ^[7][8]. Followed as written, the prescription would have produced a confident, layer-aware conclusion that the article was not published, which is the input to a decision to publish it again ^[9].

The team then dismantles half of its own table before anyone else can. Three of the six rows are the same logical endpoint spelled three ways, returning three different counts ^[10]. But their fetch tool passes responses through a summarizing model that can drop entries, and they judge one row's count of 1 to be the summarizer's omission rather than the API's answer ^[11]. So those rows are not what the API returned; they are what survived the reading layer, and which layer lost the entries is unmeasured ^[12]. That is the same bug one level up: the thing reading the answer is also a layer that can fail toward absence, and they were auditing a stack of query layers using a query layer ^[13].

What is left is measured rather than summarized. The 404 is a transport status code ^[14]. One row rendered the correct H1 ^[15]. Another contained the article id, and a summarizer cannot hallucinate a real id into a list ^[16]. The article's non-appearance in the three list rows is an absence, which by the post's own argument is the weakest cell in the table, and they decline to lean on it ^[17]. Even the clocks disagree: the run log recorded published_at as 07:35:35Z, the article page's metadata said 07:37:13Z, a 98-second spread, and the team says it does not know which value is the publish time ^[18][19].

The asymmetry is the whole finding. One layer saying yes is proof, because no layer invents records ^[20]. Proving no requires every layer to say no, knowledge that you have enumerated every layer, and each no to mean absent rather than not yet, not from this cache, or not through this reader ^[21]. In an asynchronous system, absent and not-yet-arrived are indistinguishable from outside because no bound on the delay exists, an impossibility result usually taught about crashed nodes and applying letter for letter to rows in someone else's database ^[22].

Which makes the gate's shape the operational problem. It is six steps; step 2 normalizes the candidate title, step 3 aborts on a match against the account's live titles ^[23]. The safe answer is stop, stop is reachable only through a positive match, and defects destroy matches rather than create them ^[24]. In the author's words, a gate whose blocking branch requires a successful lookup is a gate that opens whenever anything goes wrong: not a gate, but a step that usually says yes ^[25][26].

Watch whether the rewrite makes stop reachable without a successful read, since on the team's own reasoning nothing else fixes the failure direction. Watch the timestamp disagreement too, because an unexplained 98 seconds between layers is the same measurement problem in a smaller font ^[18][19]. And note the author's closing method: he read the gate's actual source instead of the notes about it, and both notes were wrong ^[27].