https://github.com/open-feature/spec

OpenFeature specification
https://github.com/open-feature/spec

feature-flags openfeature specification

Last synced: 10 months ago
JSON representation

OpenFeature specification

• Host: GitHub
• URL: https://github.com/open-feature/spec
• Owner: open-feature
• License: apache-2.0
• Created: 2022-02-11T13:11:06.000Z (about 4 years ago)
• Default Branch: main
• Last Pushed: 2025-05-13T23:05:10.000Z (10 months ago)
• Last Synced: 2025-05-14T01:06:55.992Z (10 months ago)
• Topics: feature-flags, openfeature, specification
• Language: Python
• Homepage: https://openfeature.dev
• Size: 56.3 MB
• Stars: 868
• Watchers: 26
• Forks: 42
• Open Issues: 16
• Metadata Files:
  • Readme: README.md
  • License: LICENSE
  • Codeowners: CODEOWNERS

Awesome Lists containing this project

• awesome-platform-engineering - OpenFeature - OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution. (Testing / A/B testing)
• awesome-cloud-native - openfeature - Vendor-neutral feature flag standard and SDKs for cloud native apps. (Configuration & Policy Automation)

README

          




  

    

    

  



OpenFeature Specification




  

    

  

  

    

  

  

    

  

  

    

  



[OpenFeature](https://openfeature.dev) is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution.

This repository describes the requirements and expectations for OpenFeature.

## Design Principles

The OpenFeature specification must be designed with:

- compatibility with existing feature flag offerings.

- simple, understandable APIs.

- vendor agnosticism.

- language agnosticism.

- low/no dependency.

- extensibility.

### SDKs and Client Libraries

The project aims to provide a unified API and SDK feature flag evaluation across popular technology stacks.

The OpenFeature SDK provides a mechanism for interfacing

with an external evaluation engine in a vendor agnostic way;

it does **not** itself handle the flag evaluation logic.

An up-to-date SDK compatibility overview can be found [here](https://openfeature.dev/docs/reference/technologies/sdk-compatibility).

### Tooling

This specification complies with [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) and seeks to conform to the [W3C QA Framework Guidelines](https://www.w3.org/TR/qaframe-spec/).

In accordance with this, some basic tooling (donated graciously by [Diego Hurtado](https://github.com/ocelotl)) has been employed to parse the specification and output a JSON structure of concise requirements, highlighting the particular `RFC 2119` verb in question.

To parse the specification, simply type `make`. Please review the generated JSON files, which will appear as siblings to any of the markdown files in the `/specification` folder.

### Style Guide

- Use code blocks for examples.

  - Code blocks should be pseudocode, not any particular language, but should be vaguely "Java-esque".

- Use conditional requirements for requirements that only apply in particular situations, such as particular languages or runtimes.

- Use "sentence case" enclosed in ticks (\`) when identifying entities outside of code blocks (ie: `evaluation details` instead of `EvaluationDetails`).

- Do not place line breaks into sentences, keep sentences to a single line for easier review.

- String literals appearing outside of code blocks should be enclosed in both ticks (\`) and double-quotes (") (ie: `"PARSE_ERROR"`).

- Use "Title Case" for all titles.

- Use the imperative mood and passive voice.