Support case-insensitive string matching in targeting rules

[jonathannorris]

Context

At KubeCon EU 2026, the flagd discussion (recap) identified case-insensitive matching as a missing capability in targeting rules.

Problem

Flag evaluation rules currently use case-sensitive string matching. This can lead to unexpected behavior when targeting context values have inconsistent casing (e.g. user@example.com vs User@Example.com).

Proposal

Add lower and/or upper string transform operations that can be composed with existing operators. This avoids duplicating every string operator with a case-insensitive variant and fits naturally with the JSON Logic model.

Example:

{ "==": [{ "lower": [{ "var": "email" }] }, "user@example.com"] }

This approach is composable with any existing string operator (==, in, starts_with, etc.) rather than needing dedicated equals_ignore_case, contains_ignore_case variants for each.

Related

• [FEATURE] Unified flagd-evaluator PoC (Java/Python/...) – reduced maintenance, PoC, and reference #1842: Unified flagd-evaluator PoC

[toddbaert]

I understand the value of this proposal, because we've run into some of the issues it implies already.

However, implementing lower/upper in the targeting rule engine carries some significant cross-implementation risks. flagd evaluators currently exist in Go, Java, Python, and Rust, etc, and their stdlib casing functions do not behave consistently:

• Go uses simple case mapping (1:1 codepoint only), while Java, Python, Rust, and JS all use full case mapping (1:many). For example, the German eszett ((ß is unchanged by Go's strings.ToUpper, but becomes "SS" in every other language.
• Java's toUpperCase() is locale-sensitive by default, using the JVM's runtime locale. On a Turkish-locale JVM, "i".toUpperCase() produces a dotted capital I (U+0130), not ASCII "I". This would need to be explicitly pinned to Locale.ROOT.
• Each runtime ships with a different Unicode version, meaning case mappings can subtly differ across implementations.

If we do add this, I'd recommend restricting it to ASCII-only case conversion (ie: A-Z / a-z only). This is trivially consistent across every language and runtime, avoids all locale and Unicode version concerns, and covers the primary use case: normalizing things like email addresses and non-IDN domain names (which are ASCII per RFC 5321 and DNS respectively). We should document that this is specifically intended for ASCII data like emails and domains, not general-purpose Unicode case transformation.

The alternative is to push this to userland entirely; applications can normalize context values before passing them to the evaluator, which keeps the evaluator simple and sidesteps these issues altogether.