| id | title | description | sidebar_position |
|---|---|---|---|
intro |
Introduction |
An introduction to the OpenFeature specification. |
0 |
- Glossary
- Types
- Evaluation API
- Providers
- Evaluation Context
- Hooks
- Events
- Appendix A: Included Utilities
- Appendix B: Gherkin Suites
The following parts of this document are normative:
- Statements under markdown H5 headings, appearing in markdown block quotes, and containing an uppercase keyword from RFC 2119.
- This conformance clause.
Each normative section defines a single requirement. By enumerating these normative sections, a list of test assertions can be derived.
An implementation is not compliant if it fails to satisfy one or more of the "MUST", "MUST NOT", "REQUIRED", "SHALL", or "SHALL NOT" requirements defined in the normative sections of the specification. Conversely, an implementation of the specification is compliant if it satisfies all the "MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL NOT" requirements defined in the normative sections of the specification.
Sections and subsections within the specification are marked with statuses indicating their stability level. Functionality described in the specification graduates through these statuses with increasing stability. Stability levels apply only to normative sections within the specification; editorial changes to examples and explanations are exempt from these constraints. It is the responsibility of the Technical Steering Committee to consider and approve the graduation of documents.
Possible statuses are described below:
Specification sections that are marked as Experimental contain functionality under active development. Breaking changes are allowed and may be made without deprecation notices or warnings with minor version updates. We recommend you use these features in experimental environments and not in production.
Put simply:
We're testing these features out. Things could change anytime.
Sections marked as Hardening describe functionality with an emphasis on stabilizing existing requirements. Breaking changes require consensus by the Technical Steering Committee but may still be made with minor version updates. These features are suitable for use in production environments. Feedback is encouraged.
Put simply:
We believe these features are ready for production use, and hope for feedback.
Sections marked as Stable do not allow breaking changes without a major version update. They can be used in production with a high degree of confidence.
Put simply:
These features are stable and battle-hardened.
Note
No explicit status = Experimental