There's a lot of gray area, though. Consider the statement: "This person (does/does not) have the ability to see Widget X on their homepage." From the perspect

There's a lot of gray area, though. Consider the statement: "This person (does/does not) have the ability to see Widget X on their homepage." From the perspective of someone implementing the frontend or backend? It has all the characteristics of a feature flag. But what if Widget X shows something we are not allowed to sell to that person (say, per a specialized contract with their organization, or regional/legal limitations)? Then it's long lived, has extraordinary consequences for failure, and needs careful design to be able to model the person's membership in different (often overlapping) labels or organizations. We implement a `resolve_config` function used across our codebase, where different entities in our data model have a well-defined precedence order when they can override the value iff they match part of the hierarchical context. It's designed to be a near-zero-cost abstraction (cached locally so lookups can be done synchronously). That way, doing something that will roll out to some partners over time, and never to other partners, is as simple as using this function instead of a constant or literal. Edits at any level are audit-logged and can, when necessary, have approval procedures applied. It's an authorization system, at its core, but with arbitrarily typed values rather than boolean authorized-or-not flags. And I can't imagine building a B2B or B2B2C business without it.