Deciding whether an answer is worth blocking.

A condition is written in the shape of a served answer and keyed by the same names the API uses, so what you write here reads like what you get back. Atom and binary keys both work, which is what lets a condition come out of json:decode/1 on an app's config file as readily as out of source:

  #{is_vpn => true}
  #{is_vpn => true, vpn => #{provider => <<"nordvpn">>}}
  #{is_resproxy => true, resproxy => #{hits => #{gte => 5}}}
  #{vpn => #{confidence => [<<"high">>, <<"medium">>]}}
  [#{is_tor => true}, #{is_resproxy => true}]   % a list is OR

A value may be a scalar (equality, strings without regard to case), a list meaning any-of, a map of gte/gt/lte/lt bounding a number, or a nested condition. A member set to false, null or undefined is ignored entirely - a condition states the positive signals you act on, so there is no way to write "block when this is false", which would otherwise read as blocking everybody.

WRITE STRINGS AS BINARIES. An Erlang string is a list of codepoints, so "nordvpn" and an any-of of those numbers are the same term and no library can tell them apart. A bare string is accepted anyway - io_lib decides, exactly as it does when printing - but that makes an any-of of small printable integers unreachable. Binaries have no such ambiguity, and are what json:decode/1 produces.