Design the object model and public APIs for a feature-flag (toggle) client that an application calls to decide whether a feature is on for a given user and context, evaluating the targeting rules the application was configured with.

Operating context. One in-process SDK. A flag has a default state and an ordered set of targeting rules: enable for a user segment, a sticky percentage rollout, an allow/deny list, or a variant assignment for A/B/multi-variant experiments. Evaluation takes a flag key plus an evaluation context (user id and attributes) and deterministically returns a boolean or a chosen variant. The ruleset is refreshed from a periodic snapshot, while evaluations happen at high frequency from many threads.

Out of scope. The network/polling transport that fetches the ruleset, the flag-management UI, impression/analytics event delivery, encryption of the ruleset, and any server-side flag storage.

What to produce. The class hierarchy (client, flag definition, targeting rules, evaluation context, evaluation result), the public APIs, and the rule-evaluation pipeline. Be explicit about: how new rule kinds plug in without editing the evaluator, how a percentage rollout stays sticky and deterministic per user, and how a ruleset refresh swaps atomically under concurrent reads.