A retired 70% gate kept running for three months because deprecation does not reach copies

A rule that rejected the output of a simulated reviewer panel whenever its internal consistency score fell under 70 percent was overturned the same day it produced a false reject, and then reappeared inside a different rule written about a week later ^{[4][9][11][12]}. According to the account published on dev.to, the reappeared copy sat active for roughly three months and was found by a sweep rather than by an incident ^[14][15]. That is the part worth attention: a superseded rule that has been copied does not fail. It succeeds.

The setup is deliberately boring. The author keeps operating judgment in small versioned files, one per decision, each carrying a status, a list of what it supersedes, and a change history ^[1]. One of those files governed a panel of eight simulated reviewers convened for open-ended judgment calls ^[2]. The panel returns an internal consistency score, roughly how much the eight answers agree with each other ^[3]. The original gate said: under 70 percent, do not adopt the panel's conclusion on its own ^[4].

The gate broke on contact. An architecture question came back at 21 percent ^[5], 49 points below the cutoff ^[1]. Read individually, three of the eight answers flagged things the author had not considered: a missing measurement step behind a database-performance claim, a conflation of a plan's stated purpose with its surface description, and a terse near-empty answer that turned out to be a signal that the question was not well formed for consensus ^[6]. A fourth answer hallucinated a decision flow that existed nowhere in the plan and was discarded on its own merits, not by the score ^[7]. None of the three catches would have survived the gate ^[8]. The replacement rule, written the same day, reframed consistency as a diversity reading and named "reject any response scoring under some cutoff" as the anti-pattern it was correcting ^[9]. A separate check later came back at a comfortable 79 percent and still hid a real disagreement ^[10], so the threshold was wrong in both directions.

About a week after that, the author wrote an unrelated rule about diagnosing app growth after launch, which also calls the same reviewer panel ^[11]. That rule needed its own discard checklist, and one of its four conditions was: reject if internal consistency is under 70 percent ^[12]. The author says this was not a conscious copy-paste but a re-derivation from memory, written as a self-contained bullet instead of a pointer to the rule that had already retired it ^[13]. A quarter of that checklist contradicted a decision made seven days earlier ^[2].

This is the failure mode that status fields cannot see. A status is a property of one node; the inlined bullet in the second file is a different node with its own status, and it read "active" truthfully ^[14]. Nothing alerted, because nothing broke. A gate that discards a good input emits no error, produces no log line saying a signal was lost, and shows up in no dashboard. The detection came from a full sweep across every rule file, undertaken specifically to walk supersession chains ^[15]. The repair was one paragraph: strike the bullet, cross-reference the rule that made it obsolete, and state that the score is a diagnostic reading ^[16]. The same sweep found that the overturning rule had never recorded which rule it superseded, so the link worked forward but not backward ^[17].

Two things to watch. First, whether the sweep becomes scheduled work with a literal-value search across every file, prompt, and config, since the number was re-derived from memory once and can be again ^[13][15]. Second, whether missing back-references get backfilled, because a supersession graph you can only traverse in one direction will not answer the question the sweep was asking ^[17].