The 1.9% That Never Existed: Refuse in the Schema, Not in the Guess

A single fabricated number, 1.9 percent, nearly killed an experiment that never ran. Then I found the exact same lie hiding in my Medicare billing engine and my denial classifier. The fix was identical in all three, and it was not a better guess.

01The number that never existed

1.9 percent. That was the baseline conversion rate my ad-experiment engine reported for a test that had never served a single impression. The metrics table was empty. The code reached for a hardcoded default. And 1.9 percent walked out the door wearing a suit.

Here is why that is not cosmetic. The baseline feeds the sample-size formula that decides how long an experiment must run before you are allowed to trust it. Feed that formula a fabricated baseline and the required sample can be wrong by 20x in either direction. You either burn budget on a test that quietly finished weeks ago, or you crown a winner on noise. The experiment was dead before the first impression. The dashboard looked healthy the whole time.

An exception gets a ticket the same afternoon. A plausible number gets a quarterly review, eventually, maybe. A fabricated number does not look fabricated. That is the entire problem.

02One surgery, three industries

The fix was not a better default. There is no better default; an empty table has no ground truth to approximate. The endpoint now returns HTTP 400: pass a real baseline explicitly or do not start the experiment. The refusal moved out of my good intentions and into the contract.

Then I went looking, and found the same disease in two businesses that share nothing with ad tech except me.

My Medicare remote-monitoring reimbursement engine used to treat payer eligibility as a claim gate. But under the product boundary we drew, the practice's own biller owns eligibility verification; my engine literally does not hold that ground truth. Blocking the claim was a guess. Waving it through was a guess. So eligibility stopped being a gate and became a route: those claims now land in a BILLER_DETERMINED state, a named place in the schema where the human who actually has the answer picks up the work. Config-flagged. Logged. Auditable.

The denial-management engine had the ugliest version. Deductible, coinsurance, and copay denials (PR-1, PR-2, PR-3) are not real denials; the balance simply transfers to the patient. My taxonomy had no class for that, so a blanket rule mapped "not a real denial" onto "no action, contractual write-off." The engine was quietly telling billers to write off money patients legitimately owed. The fix was not a smarter prompt. It was a new class: bill_patient. On the 30-case golden set, classification accuracy went from 83.3 percent to 90.0 percent the moment the schema stopped forcing reality into the wrong bucket. In the same push, anchoring recommendations to a deterministic per-code action layer took mapped-action accuracy from 36.7 percent to 76.7 percent.

The model was never the bottleneck. The vocabulary was.

Ad tech. Medicare billing. Denial management. Three domains, three schemas, one surgery: when the system does not know, make it say so in a form a machine can enforce. An HTTP 400. A routed state. A new class. Never a reasonable-looking number.

03The scars

Let me be precise about whose fault the 1.9 percent was: mine. Somebody typed that constant to keep a day-one dashboard from crashing, and somebody was me. It survived two years of code review because it was plausible. Nobody audits a number that looks right.

And the trap does not only live in return values. My local-model training harness trains and evaluates open-source models, Qwen and DeepSeek variants, against my own task pool. I ran a frontier model through it as a reference point and it scored 0.241 on the hardened 54-task set, statistically indistinguishable from all five local models. The plausible default conclusion: the models are weak. The honest conclusion, after digging: 34 of the 54 tasks were failed by every model, including the frontier reference. The exam was broken, not the students. Plausible defaults hide in conclusions just as comfortably as they hide in code.

04What I now believe

1. 1When the system does not know, the refusal belongs in the schema, not in a guess. An error, a routed state, a new class. Never a plausible number.
2. 2An error is information. A default is a lie with good posture.
3. 3Route, do not gate. If someone else holds the ground truth, build them a named state and hand over the work loudly.
4. 4If reality has a case your enum lacks, the enum is wrong. Reality will not add the missing value for you.
5. 5Audit your plausible numbers harder than your exceptions. Exceptions page you at 3 AM. Plausible numbers bill you quietly for a year.

05The builders will recognize this

Nothing here required a bigger model or a cleverer algorithm. It required admitting, in the type system, in the state machine, in the HTTP status code, that the system did not know. That admission is the difference between software that reports reality and software that decorates it.

Every empty table. Every claim you cannot verify. Every case your taxonomy cannot name. Each one is a chance to refuse honestly or to lie fluently, and the lie compiles just fine.

Three industries. Three schemas. One rule: when you do not know, say so in a way the compiler can see. The builders who have already made this mistake know exactly what I mean. The rest are about to. Find each other.