{"version":"2.1.246","anchor":"feature-flags-can-explain-where-their-value-came-from","canonical_anchor":"feature-flags-can-explain-where-their-value-came-from","heading":"Feature flags can explain where their value came from","tier":"soon","area":"Internals","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/feature-flags-can-explain-where-their-value-came-from","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Feature flags can explain where their value came from\n\nFlags can explain whether their value came from an override, the server, a cache or the default.\n\n**What**\n\nA new table turns a flag's origin into a sentence: a local override, the experiment payload fetched this session, the on-disk cache left by an earlier session, the built-in default because experiments are off (a third-party model provider, or telemetry opted out), or the built-in default because the cache was cold. The check that decides whether to consult it is a constant returning false in this build, so the accessor always reports the default path.\n\n**Evidence**\n\n`from GrowthBook (the disk cache of an earlier session)`\n\n- Area: Internals\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 0\/5\n- Present in the build but not switched on"}