The Anti-False-Positive Law: One Noisy Flag and Trust Dies

What you'll be able to do: write one named, testable law for any checker you build — the law that guarantees the tool never cries wolf — and explain why every module needs exactly such a law.

Choose your door

Builder — Builder Track: normalize two phone numbers by hand and watch the false alarm vanish.
Architect — Architect Track: the trust-budget model.
Translator — Bridge below.
Validator — Gates at the bottom.

The story this comes from

The Local module of a tool I built compares the phone number a page shows visitors against the number its structured data tells Google. Real mismatches matter. But the same number wears many outfits: tel:+15125551234 in the code, (512) 555-1234 on the page. A naive comparison flags those as different — and the flag is false.

So the module carries a named law: the same phone in different formats must NEVER flag as a mismatch. Numbers are stripped to bare digits before any comparison. A flag therefore always means genuinely different numbers. The law isn't a comment or a hope — it's a test (part of the 32/32 green suite), enforced on every future change.

Translator Bridge

Think of a smoke detector. A detector that misses one fire is a tragedy — but a detector that shrieks at every slice of toast gets its battery pulled, and then misses the fire. The false positive doesn't just annoy; it disarms the whole system, because humans stop believing it.

Where the analogy ends: you can hear a smoke detector cry wolf and judge for yourself — there's toast right there. A software flag arrives with no kitchen attached: the client can't smell the toast. They either trust the report or they don't. That asymmetry is why software needs the law written and machine-enforced, not just a builder's good intention.

Builder Track (DO FIRST)

Write these on paper: tel:+15125551234 and (512) 555-1234.
Compare them character by character. Different? Wildly. A naive checker flags this.
Now normalize: delete everything that isn't a digit, drop the leading country-code 1. Both become 5125551234.
Compare again. Identical. The flag disappears — and now invent a real mismatch (change one digit) and confirm the flag survives normalization. That last step is the law: kill false alarms without killing true ones.
Name your law in one sentence, like the original: "Same number, different costume, never a flag."

Architect Track (MODEL FIRST)

Model the client's trust as a budget: it starts small and every honest, verifiable flag earns a deposit. But the exchange rate is brutal — one false flag withdraws more than ten true flags deposit, because the client generalizes: "if it's wrong about my phone number, what else is it wrong about?"

Design consequences:

Every checking module needs one named anti-false-positive law — named so it can be discussed, tested so it can't regress.
The law lives in the conformance corpus: fixture inputs where the right answer is known, including the tricky same-thing-different-costume cases.
CI (Lesson 1) runs the corpus on every change, so the law holds even when a future edit — by human or agent — forgets it exists.

Naming matters: an unnamed rule is folklore; a named law is architecture.

Validator Gates

Gate 1: State the phone-number law from memory, in one sentence.
Gate 2: Why does a false positive cost more trust than a false negative in a client-facing report?
Gate 3: What are the two directions the Builder Track's step 4 protects, and why do you need both?
Gate 4 (own words): You're building a checker that compares business hours on a website vs. its schema. Write its anti-false-positive law. (Hint: "9am–5pm" vs "09:00–17:00".)

Lesson complete — you can now design a flag people keep believing. Next: Lesson 4 — who enforces your law when nobody's looking.