I have started thinking the most dangerous word in a codebase is a field called verified.
Because it usually means one of two completely different things, and they get stored in the same column.
Sometimes it means proven: a signature checked out, a cryptographic assertion held. That is arithmetic. It is either true or the maths failed.
Sometimes it means inferred: heuristics agreed, the fingerprint looked normal, the score was low enough. That is judgement, and judgement a capable adversary patches in an afternoon.
Once those share a field, somebody downstream branches on it — and they are now treating a guess exactly like a certainty. That is how a system starts refusing real customers on a hunch while its own code reads as though it knew something.
What I do now is keep a single boolean that means only "this was settled cryptographically", and never let anything inferred touch it. Everything else lives in a score or a set of signals, where it is obviously an opinion. It costs an extra field and removes a whole category of mistake.
The same applies to is_bot, is_fraud, trusted — any name that sounds like a fact but holds an estimate.
Does anyone have a naming convention that actually holds up over a few years and a few engineers? _proven versus _likely suffixes feel clumsy but at least they are honest.
Top comments (0)