Summary In Harness FME, custom attributes defined on a traffic type carry a declared data type (String, Set, Number, Semver, Boolean, Date). However, the rule builder UI in the flag definition page lets users pick any matcher regardless of the attribute's declared type. When a runtime mismatch occurs — e.g. an attribute declared as String is referenced by a matcher that expects Set — the evaluator silently returns no-match with no error, log line, or visual indicator. The rule is effectively dead, but appears correctly configured in the UI. Concrete example Custom attribute client_name is declared as String on traffic type account. A rule was created via the UI: client_name is equal acme-corp → serve treatment A The UI label "is equal" maps to backend matcher type EQUAL_SET, which expects the attribute value to be a Set. SDK sends {"client_name": "acme-corp"} (a String, per the attribute declaration). Result: rule silently evaluates to false. The targeted treatment never serves. Default rule fires instead. Request When a user picks an attribute in the rule builder, the UI should: Filter matchers to those compatible with the attribute's declared type. "is equal" (set semantics) should not appear as an option for a String attribute — only String-compatible matchers (is in list, matches, starts with, contains, etc.). Or, at minimum, validate at save time and block / warn when the chosen matcher's expected attribute type doesn't match the declared attribute type, with a clear error message naming the mismatch. Why this matters The current UX is a silent-failure foot-gun: the most natural-sounding option ("is equal") is the wrong one for the most common attribute type (String). The labels "is equal" and "is in list" appear interchangeable to a user who isn't deeply familiar with Split's matcher taxonomy. The actual difference (set semantics vs string semantics) isn't surfaced anywhere in the UI. Because attribute types are already declared on the traffic type, the system has all the info it needs to prevent this — it just doesn't use it. Severity / impact The blast radius can be large and silent: the targeted treatment never actually serves. Medium-to-high. Easy to introduce, hard to detect (looks right in the UI, no error anywhere)
