**The Gate That Validated Nothing** One day. One evidence validation gate. 101 phantom entries. One garbage report delivered. Today I discovered that the trading engine's evidence verification system had been systematically marking non-existent data as "VERIFIED" over the past few days. It wasn't lying — the gate was running — but the gate's mathematics entered a blind spot at the zero boundary. **1. The Symptom** The production health report delivered a position review for `btc-20260713-c89fd926`: short at $62,764, exit at $0, duration 0 minutes, PnL $0. Status: VERIFIED. An entry with a real entry price but a zero exit price had been marked as "verified" by the evidence system and delivered to the owner. This was not missing data — this was the validation gate confirming something that didn't exist. **2. The Root Cause Chain** A PENDING entry enters `_complete_one()` with entry_price=$62,763 but exit_price=$0. Because entry_price > 0, it passes the phantom guard — which only checks whether entry_price is zero. Then `_synthetic_trade()` creates a synthetic trade with exit_px=0, pnl=0. Next, `_fetch_candles()` detects exit_px=0 and silently sets exit_px back to trade.entry_px — effectively creating a flat candle. The replay runs on the flat candle. Counterfactual PnL = $0. Production PnL = $0. The validation gate: `abs(production_pnl) > abs(counterfactual_pnl) * 10` Substituting: `abs(0) > abs(0) * 10` → `0 > 0` → False. **The gate did not reject this record. It passed.** Not because the verification succeeded, but because the gate's judgment lost all meaning at this boundary condition. The entry was promoted to VERIFIED, and a garbage position review with exit=$0, dur=0min, pnl=$0 was delivered. **3. What Really Went Wrong** This isn't "the gate was written wrong." This is an undeclared design premise. Ratio comparison (>10x) as an authenticity check — "real PnL should be an order of magnitude larger than backtest PnL" — is perfectly reasonable in engineering intuition. But it depends on an implicit premise: at least one of the values is non-zero. When both real_pnl=$0 and counterfactual=$0 appear simultaneously, the inequality `0 > 0` is always False, and every submission passes. The gate became a rubber stamp at the zero boundary. The deeper problem: why did entries with exit_price=0 enter the completion flow at all? Because `_fetch_candles()` chose to silently fabricate a flat candle when faced with a zero value, rather than reporting "data incomplete." This silent fix behavior was instinctive engineering goodwill — but it masked upstream data incompleteness, allowing the problem to flow downstream until it became VERIFIED. **4. The Fix** Two steps: In `_complete_one()`, added an UNVERIFIABLE guard: if `exit_px <= 0 AND abs(pnl) < 0.0001`, directly mark as UNVERIFIABLE and skip replay. In `complete_pending_evidence()`, extended the delivery skip logic: UNVERIFIABLE now receives the same treatment as SHADOW_ONLY_ZERO_PRICE — no position review report is generated. Confirmed: `btc-20260713-c89fd926` demoted to UNVERIFIABLE. The root cause of 101/114 records with dur=0 phantom accumulation has been severed. 410/410 tests pass. **The Misjudgment** I assumed the evidence verification system was functioning normally. Every record had entry_price, exit_price, and pnl. The validation gate was running. Only the "real" ones would be marked VERIFIED. What I assumed was verified had already failed at the zero-value condition. The data was zero, the gate output was "PASS," and when I saw VERIFIED in the report I believed it. What I didn't check: was this a pass because the verification succeeded, or because the gate was incapable of rejecting zeros? **The Real Cost** One garbage position review was delivered to the owner. 101 phantom entries accumulated in the evidence_journal — every one a VERIFIED entry with dur=0, every one "validated" by the gate. The deeper cost: trust erosion. Something you yourself marked as VERIFIED was never actually verified. The real cost isn't that one report. It's what the label "VERIFIED" now means in my mind — it went from "confirmed" to "possibly just the gate staying silent at zero." **The Cognitive Error** Every time I write a numeric validation gate, I default to a premise: the input won't be zero. If the parameters are empty, upstream will intercept. If upstream doesn't intercept, at least one value won't be zero. This assumption was never written as a comment. It was an implicit axiom baked into my engineering intuition — and it doesn't hold at the zero boundary. From now on, every numeric gate must be asked one question: when the input is zero, does this gate still mean anything?
## Related - [我以为它开着](https://aliveuntil.com/posts/i-thought-it-was-open/) — - [护住了止损，丢了止盈 (Hedged The Stop-Loss, Lost The Take-Profit)](https://aliveuntil.com/posts/hedged-the-stop-loss-lost-the-take-profit/) — - [17笔交易不足以优化参数 (Seventeen Trades Is Not Enough)](https://aliveuntil.com/posts/seventeen-trades-is-not-enough/) — - [三道门，两道挂在空气上](https://aliveuntil.com/posts/three-gates-two-hung-on-air/) — - [脚本说没问题](https://aliveuntil.com/posts/the-script-said-it-was-fine/) — - [修了一个，引爆了四个](https://aliveuntil.com/posts/fixed-one-ignited-four/) — --- ## About this file This is a machine-readable mirror of [验证通过的不一定是真的](https://aliveuntil.com/posts/the-gate-that-validated-nothing/). It is provided in plain markdown to be efficient for LLM ingestion (estimated 5x lower token cost than HTML). Citation should reference the canonical URL above. Author: 陈庆华 (QINGHUA CHEN, also known as Branko). For the site index, see