Support case-insensitive string matching in targeting rules

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

• #1842: Unified flagd-evaluator PoC

Start by reading the existing targeting-rule string operators and the JSON Logic model, then review the related unified evaluator PoC in #1842. Determine how a lower or upper transform would compose with operators such as ==, in, and starts_with, and define tests showing case-insensitive matching without duplicating each operator.