4. Evaluation API
Overview
Section titled “Overview”Three calls answer almost every question an application asks, mirroring OpenFeature’s typed getters:
client.isEnabled("sso", ctx) // → booleanclient.getLimit("seats.max", ctx) // → number | UNLIMITEDclient.requireWithin("seats.max", current, 1, ctx) // → details, or throws EntitlementLimitExceededEach one has a …Details form that returns the full resolution details, the counterpart of OpenFeature’s FlagEvaluationDetails. Four more round out the API: requireEnabled (throws instead of returning false), getEnum, guard (§5), and requiredPlan.
4.1. Client
Section titled “4.1. Client”Requirement 4.1.1
Section titled “Requirement 4.1.1”An SDK MUST provide a way to create a client from a provider and a catalog. It MAY also accept a default context, hooks, a clock, and a lock.
Requirement 4.1.2
Section titled “Requirement 4.1.2”The client MUST expose the metadata of its provider (at least
name).
Requirement 4.1.3
Section titled “Requirement 4.1.3”Evaluation methods MUST follow their language’s idiom for I/O. An SDK whose providers may perform network I/O SHOULD expose evaluation as asynchronous.
4.2. Methods
Section titled “4.2. Methods”Requirement 4.2.1
Section titled “Requirement 4.2.1”
isEnabled(featureCode, context?) → booleanandisEnabledDetails(featureCode, context?) → ResolutionDetails<boolean>MUST evaluate per Requirement 3.2.1. They MUST NOT throw.
Requirement 4.2.2
Section titled “Requirement 4.2.2”
requireEnabled(featureCode, context?) → ResolutionDetails<boolean>MUST throwFeatureNotEntitledwhenisEnabledwould returnfalse, and return the details otherwise.
Requirement 4.2.3
Section titled “Requirement 4.2.3”
getLimit(privilegeKey, context?) → integer | UNLIMITEDandgetLimitDetails(privilegeKey, context?)MUST NOT throw. Called on a privilege that is not of typeinteger, they MUST return0with reasonERRORand error codeTYPE_MISMATCH.
Requirement 4.2.4
Section titled “Requirement 4.2.4”
requireWithin(privilegeKey, current, requested, context?) → ResolutionDetails<Limit>MUST evaluate per §3.3. It MUST return the details when the check passes, and MUST throwEntitlementLimitExceeded(§8.1) when it fails.
Requirement 4.2.5
Section titled “Requirement 4.2.5”
getEnum(privilegeKey, context?) → stringandgetEnumDetails(privilegeKey, context?)MUST NOT throw. Called on a privilege that is not of typeenum, they MUST return the empty string with reasonERRORand error codeTYPE_MISMATCH.
Requirement 4.2.6
Section titled “Requirement 4.2.6”
requiredPlan(privilegeKey, need, context?) → planId | absentMUST return the plan defined by §3.4, whereneedistrue, a{current, requested}pair, or an enum option.
Requirement 4.2.7
Section titled “Requirement 4.2.7”
getDetails(privilegeKey, context?) → ResolutionDetailsMUST resolve a privilege of any type, with no type expectation, and MUST NOT throw. For a privilege that is not in the catalog, the value MUST be absent (null), with reasonERRORand error codePRIVILEGE_NOT_FOUND.
This is the generic call that admin tools, support consoles, and the conformance suite use.
4.3. Resolution details
Section titled “4.3. Resolution details”Requirement 4.3.1
Section titled “Requirement 4.3.1”Resolution details MUST contain:
field type meaning privilegestring the privilege key that was resolved (the gate, for isEnabled)valueboolean · integer · UNLIMITED· stringthe resolved value reasonReason why this value (§4.4) grantslist of {id, amount, subjectId?}grants that were added, possibly empty staleOverrideslist of override ids Requirement 3.1.9, possibly empty
Requirement 4.3.2
Section titled “Requirement 4.3.2”Resolution details MUST contain the following fields when they apply, and MUST omit them otherwise:
feature(when evaluated throughisEnabled),planId,planValue(Requirement 3.1.8),overrideId(when the reason isOVERRIDE, orGRANTon top of an override),requiredPlan(Requirement 3.4.1),errorCode, anderrorMessage(when the reason isERROR).
Requirement 4.3.3
Section titled “Requirement 4.3.3”Resolution details MUST be serializable to JSON, with
UNLIMITEDencoded per Requirement 1.2.3.
4.4. Reasons
Section titled “4.4. Reasons”Requirement 4.4.1
Section titled “Requirement 4.4.1”
reasonMUST be one of:
reason when PLANthe value is the plan value OVERRIDEan override replaced the plan value GRANTgrants were added to a finite base (plan, override, or default) FIXEDa fixed provider answered, for example a self-hosted install where everything is on and nothing can be overridden DEFAULTno plan, or the plan sets no value, so the privilege’s defaultwas usedERRORresolution failed, so the defaultwas used (Requirement 3.1.11)
4.5. Error codes
Section titled “4.5. Error codes”Requirement 4.5.1
Section titled “Requirement 4.5.1”
errorCodeMUST be one ofPROVIDER_NOT_READY,PRIVILEGE_NOT_FOUND,FEATURE_NOT_FOUND,TYPE_MISMATCH,INVALID_CONTEXT, orGENERAL.