IFO4
Loading...A runtime-evaluated control that gates the activation of a code path on a per-request, per-cohort, or per-environment basis, decoupling the act of deploying code from the act of releasing functionality. Feature flags are operational primitives, not test scaffolding: a flag in production is a permanent control surface that must be governed, observed, and retired. The federation requires that long-lived flags be inventoried and that stale flags be retired within a fixed window under TGS-002:1.7.
Term in software engineering literature since the early 2000s; popularised by the trunk-based development and continuous-delivery movements of the early 2010s.
Federation members must publish a feature-flag inventory, identify long-lived flags, and document a retirement cadence. Flags older than ninety days without a retirement plan are reported under MEV-Annex:3.2.
@misc{ifo4_glossary_feature_flag,
title = {{Feature Flag}},
author = {{IFO4 Federation Editorial Board}},
howpublished = {{IFO4 Federation Glossary, slug \texttt{feature-flag}}},
year = {2026},
url = {https://ifo4.org/glossary/feature-flag},
note = {Category: DevOps; key: FeatureFlag}
}Federation members and accredited practitioners may challenge any entry under TGS-002:1.7. Filed challenges are routed to the editorial board, triaged into the revision register, and resolved in writing on the public docket. The slug remains stable through any revision.