Some flags are meant to be enabled for specific customers, on-demand, depending on what type of contract is signed, under NDA and so on. Over time, many department that aren't "engineering" need to be able to change some flags. That doesn't imply your culture is broken.

I think most would say that’s configuration, not feature flags. The differences can be subtle but I at least don’t think they’re the same thing

That seems like code which should check customer account information, not a feature flag thats turned on or off.

Flags at this level are not simple toggles, they will embed some business logic - that's the custom logic and attributes that I mentioned. This is standard fare in Statsig, Split, Launchdarkly, and most other commercial providers. You then collect metrics for each group to monitor features.

You use these to manage gradual rollouts, or phased rollouts by customer segments, and to run A/B tests on smaller cohorts.

Activating only for beta users or opted-in users is a supported use-case on OpenFeature using the dynamic context (https://openfeature.dev/specification/glossary#dynamic-conte...).

If your goal is to end up with the flag enabled on all requests, the only difference is the rollout strategy. You can prioritize accounts, manually enable things with one customer that you know likes to test your alpha features, and so on.