Schema
Building a signal taxonomy that survives audit
9 min read · Schema Designlab Journal
Most fraud signal audit apps begin tidy and end as a museum of half-retired experiments. Taxonomy is the discipline that slows that drift. It is not a colour-coding hobby. It is a shared language for what a signal claims to prove.
Three fields that must exist
We ask every cohort to enforce three fields before inventing more: claim (what behaviour this signal asserts), evidence (which data must be present to evaluate the claim), and failure mode (how the signal errs and who absorbs the cost). Without those, dashboards become decorative.
Names should be boring. Prefer velocity.checkout.same_device_1h over clever internal jokes. Clever names age into private languages that new joiners cannot challenge.
Versioning without theatre
When a threshold changes, keep the identifier stable and record the change in an audit note. Creating _v3 clones for every tweak floods the inventory and hides ownership. Your fraud signal audit app should show history; it should not require archaeology.
Where teams get stuck
Vendor overlays arrive with their own labels. Map them into your taxonomy explicitly, even if the mapping is “vendor score band B ≈ our claim X with confidence low.” Leaving vendor names untouched is how orphan signals multiply after a contract ends.
If you want structured practice, the taxonomy rewrite in Module 2 of Signal Audit Desk is built for this exact friction.