Agent feature flags: inspect stable targeting

Current evaluation evidence

This local provider uses an illustrative hash and explicit rule precedence. It is not the ADK or an OpenFeature SDK. See OpenFeature evaluation and error fallback and targeting context for the API concepts.

Evaluate a subject, not a random request

This local provider evaluates a Boolean flag for twelve named subjects. Each subject has a stable targeting key and an EU or US region. The flag selects an agent behavior branch; no agent runs and no deployment occurs. Percentage allocation compares an inspectable bucket with the configured percentage. Repeated evaluations with the same salt, key and policy return the same result. A finite group of twelve need not contain exactly the requested percentage of enabled subjects. The list records ON or OFF, the reason, any error and the bucket when allocation is reached.

Calculate the exact allocation

The teaching hash starts at zero and visits each UTF-16 code unit in salt, a vertical bar and the subject key. At each step it replaces the accumulator with (31 times accumulator plus code unit) modulo 100. This simple hash is deliberately inspectable and is not a vendor algorithm or a cryptographic function. With salt agent-v2, user-01 has bucket 63. At 63 percent that subject is OFF; at 64 percent it is ON. Set 0 percent for no split subjects and 100 percent for all eligible subjects. Increasing the percentage with fixed salt preserves existing split memberships. Changing the salt can reassign people and should be treated as a separate experiment.

Apply rules in a visible order

The local policy checks provider availability first, then whether the flag is enabled, then the subject key, then the user-01 override, then region eligibility, then percentage allocation. Choose EU to exclude US subjects before bucketing. Force user-01 ON at zero percent and observe a TARGETING_MATCH instead of SPLIT. Force OFF at 100 percent to observe the opposite override. Disable the flag: every subject is OFF, including that override. These precedence rules belong to this lesson, not to a universal feature flag standard. A flag is also not an authorization boundary; protected tools must enforce permissions independently.

Distinguish a disabled flag from a provider error

Provider state can be Ready, Not ready or Flag missing. On either error this evaluator returns the configured fallback Boolean and records a separate error code; it never reports that the allocation rule succeeded. With fallback OFF, Not ready yields zero enabled subjects and twelve errors. Turn fallback ON: twelve subjects are enabled but all twelve errors remain. The enabled checkbox is provider configuration, so an unavailable provider cannot read it. Disable the flag while provider state is Not ready and fallback is ON to see that distinction explicitly. OpenFeature defines default-value error handling, while the particular targeting and bucketing policy here is our local fixture.

Inspect time and preserve the evidence

Play reveals one evaluated subject every five inspection seconds for a sixty-second run. Pause freezes the view; Next subject advances to the next boundary and pauses. Restart rewinds with your settings retained. Speed changes only the inspection pace, with quarter, half, normal and double rates. The timeline seeks and pauses. Editing a policy setting rewinds and pauses; Restore defaults restores the original policy. This is a teaching schedule, not measured flag evaluation latency. Export JSON includes all twelve predictions plus the separately labeled current inspection. Capture baseline retains the visible result and control settings, while the notebook lets you record a hypothesis. All outcomes are readable text and the controls support keyboard operation.