> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.
# Feature Flag Operations
> Stage Starfire AI capabilities by environment, plan, organization, cohort, or user without confusing rollout with entitlement or permission.
# Feature flag operations
Feature flags let Starfire ship and test capabilities without exposing every change to every account at once.
## Flag vs entitlement vs permission
These are different layers:
* **Feature flag** — is the capability rolled out to this context?
* **Entitlement** — does the plan include the capability?
* **Permission** — may this user/resource perform the action?
A missing feature can be caused by any of the three.
## Common targeting dimensions
Depending on the current flag system, rollout can consider:
* environment
* plan
* organization
* user/account
* internal/experimental cohort
* percentage or named rollout group
## Change a flag safely
1. Identify the exact feature and current default.
2. Identify the target population.
3. Confirm dependent backend/UI components are deployed.
4. Start with the smallest useful cohort.
5. Verify behavior and health.
6. Expand gradually.
7. Remove temporary overrides when the rollout becomes the default.
## User overrides
A user-specific override is useful for support/testing, but it can make behavior differ from the plan/organization default. Record why it exists.
## Disable during incident
A feature flag can sometimes provide fast mitigation when one capability is failing. Disabling a feature is not a substitute for incident tracking and root-cause work.
## Avoid permanent flag debt
Retire old rollout flags after the feature becomes stable. Long-lived forgotten flags make support and access reasoning harder.
Never use a feature flag to bypass a security permission. Flags control rollout, not authorization.
See how flags combine with plan, policy, permissions, and provider health.