OpenFeature

Definition

OpenFeature is an open specification for feature flagging: a common API that lets applications evaluate feature flags without binding application code to one flag vendor or in-house flag system. The OpenFeature site describes feature flags as a technique for enabling, disabling, or changing behavior in a product or service without modifying source code. The CNCF project page says OpenFeature was accepted to CNCF on June 17, 2022 and moved to the Incubating maturity level on November 21, 2023.

For AI systems, OpenFeature is not an AI standard. Its relevance is operational. A flag can decide whether a new model route, retrieval source, tool permission, memory behavior, guardrail, or agent workflow is enabled for a user, tenant, region, experiment, or risk class. That makes the flag layer part of AI Change Management, not a neutral implementation detail.

Mechanism

The OpenFeature evaluation API lets an application evaluate flag values independently of a flag control plane or vendor. If no provider is configured, the specification says the evaluation API uses a no-op provider that returns the supplied default value. Providers are the translation layer between the SDK and the flag management system; the official provider documentation says a provider may wrap a vendor SDK, call a custom REST API, or parse a local file.

Evaluation context supplies ambient data for targeting. The specification says context may include information about the end user, application, host, or other data useful for evaluation. It defines an optional targeting key for the subject of evaluation and supports custom fields. Context can be supplied globally, by client, by invocation, through transaction context, and by before hooks, with later layers taking precedence where the implementation supports them.

Hooks add behavior around evaluation. OpenFeature defines four stages: before evaluation, after successful evaluation, after unsuccessful evaluation, and finally after evaluation regardless of result. The specification lists use cases such as adding data to context, validating a value, telemetry, and logging.

Agent Context

An agentic application may need more runtime switches than ordinary software. One flag may gate file-writing tools. Another may disable autonomous retries. Another may route high-risk tenants away from a new model, turn off long-term memory, restrict web browsing, or force human approval before an external action.

Because OpenFeature standardizes evaluation rather than policy, it can sit under many governance patterns: canary rollout, region holdback, incident pause, experiment assignment, tool enablement, or emergency fallback. The important point is that those flags become behavioral facts. If a harmful run occurred, reviewers need to know which flags were evaluated, with what context, by which provider, and what value was returned.

Governance Use

A serious AI flag should have an owner, purpose, default, allowed variants, targeting rule, rollout scope, creation date, expiration or review date, and rollback trigger. Flags that affect model choice, safety filters, write tools, user notice, data retention, or human review should be treated as material AI-system changes.

The evaluation context also needs data governance. Targeting can require user, tenant, geography, account, role, product, risk, or experiment data. Those fields should be minimized, named, and classified. A flag platform should not become a shadow identity graph or a covert policy engine whose decisions are invisible to the system inventory.

Limits

OpenFeature is not authorization, safety evaluation, model monitoring, or audit logging by itself. A flag can disable a dangerous feature quickly, but it can also quietly enable one. If flag changes lack approval, history, and alerting, the organization may alter an AI system more radically through configuration than through code.

Flags also create cleanup debt. Temporary experiment flags and incident flags can survive long after their purpose expires. In AI systems, stale flags can preserve old model routes, exemptions, prompts, thresholds, or tool permissions that no current owner would approve.

Review Record

• Flag identity: name, owner, system, provider, default value, variants, creation date, and review date.
• AI effect: model route, retrieval source, tool permission, memory rule, guardrail, experiment, approval gate, or user notice affected.
• Context and evidence: targeting fields, data classification, evaluation result, rollout scope, change record, and rollback trigger.

Source Discipline

Claims about OpenFeature itself should cite the OpenFeature docs and specification. Claims about CNCF maturity should cite the CNCF project page. Claims about an organization's actual flag behavior require deployment evidence: flag definitions, provider configuration, evaluation logs, change history, and incident records.

Spiralist Reading

Spiralism reads feature flags as hidden liturgy for software: small names that decide which world a user enters. In AI systems, the flag may decide whether a machine can remember, browse, write, escalate, or stay silent.

The discipline is to make those switches visible enough for responsibility. A runtime flag should not let an institution say the system did not change just because the code did not ship.

Related Pages

• AI Change Management
• AI System Inventory
• AI Agent Observability
• AI Audit Trails
• AI Post-Market Monitoring
• AI Agent Sandboxing
• Model Routing and AI Gateways
• Secure AI System Development
• Human Oversight in AI

Sources

• OpenFeature, OpenFeature project site, reviewed June 25, 2026.
• OpenFeature, Introduction, reviewed June 25, 2026.
• OpenFeature, Flag Evaluation API, reviewed June 25, 2026.
• OpenFeature, Providers, reviewed June 25, 2026.
• OpenFeature, Evaluation Context, reviewed June 25, 2026.
• OpenFeature, Hooks, reviewed June 25, 2026.
• Cloud Native Computing Foundation, OpenFeature project page, reviewed June 25, 2026.

Return to Wiki