Gate a Feature by License

Create the entitlement

delivery-tracking is a BOOLEAN entitlement: included in a tier, or not. It carries no aggregation method, no reset period, and its grants carry no overage allowance — nothing to count.

1. Open Entitlements and click New Entitlement.
2. Name: Delivery Tracking · Slug: delivery-tracking · Description: Real-time delivery tracking for end customers. Turn User facing on, and click Next.
3. On the Type configuration step, choose Type Boolean, and click Create Entitlement.

Grant it on two Licenses

The grant is the contract: how much of this entitlement a given License gives. Starter gives none, Premium gives it.

1. Open Licenses, expand Starter, and open its version. Under Entitlements & limits, click Add entitlement: Entitlement Delivery Tracking, Value Disabled, then Add.
2. Expand Premium, open Premium v2 — premium-v2, the version the Premium family serves — and add the same entitlement with Value Enabled.

The console writes a boolean grant as Enabled or Disabled; the API reads and writes the same grant as true or false.

A grant belongs to one License version. Grant the entitlement explicitly on every version, false included, so the fact a rule reads is always present. The Kaiten Sushi Shop dataset grants it on all six: false on Starter and on Standard v1 — the version Demo Restaurant runs —, true on Standard v2 and on every version of Premium.

✕

✕

Create the flag that reads the grant

The flag is the runtime decision. Its single targeting rule reads the delivery-tracking grant through the server-provided __kaiten facts, so the rule never names a customer or a License.

1. Open Feature Flags and click New Feature Flag. On Basic Information — Name: Delivery Tracking Enabled · Slug: delivery-tracking-enabled, which the console fills in from the name · Type: Boolean. Leave the switch in the header on Enabled.
2. On Variants Configuration, a boolean flag starts with two variants named true and false, whose values are locked: rename them on and off. On Default Variant, keep Simple Variant and choose off.
3. On Targeting Rules, click Add First Rule: Targeting Type Basic Targeting, Name Delivery tracking entitlement granted, Variant on, and the CEL Expression below. Click Save, then Create Feature Flag.

__kaiten.entitlements['delivery-tracking'] == true

A BOOLEAN entitlement reaches the rule as the boolean the License grants: true under Premium and Standard v2, false under Starter and Standard v1. Compare it directly — the lint refuses a field on it, such as .limit. No match means the default, off.

✕

✕

Evaluate for both customers

Evaluation is the call your product makes on every check, over OFREP. The context names the customer as targetingKey and the instance under kaiten.instanceSlug, and nothing else — the License and its grants are facts the server adds, read from the customer's oldest instance. Ninja Osaka runs ninja-osaka-prod under Starter:

curl -X POST "$KAITEN_API/ofrep/v1/evaluate/flags/delivery-tracking-enabled" \
  -H "Authorization: Bearer $KAITEN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"context": {"targetingKey": "ninja-osaka", "kaiten": {"instanceSlug": "ninja-osaka-prod"}}}'

{
  "key": "delivery-tracking-enabled",
  "value": false,
  "variant": "off",
  "reason": "DEFAULT"
}

Starter grants false, so the entitlement reads false, the rule does not match, and the default serves. Sakura Tokyo runs sakura-tokyo-prod under Premium v2:

curl -X POST "$KAITEN_API/ofrep/v1/evaluate/flags/delivery-tracking-enabled" \
  -H "Authorization: Bearer $KAITEN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"context": {"targetingKey": "sakura-tokyo", "kaiten": {"instanceSlug": "sakura-tokyo-prod"}}}'

{
  "key": "delivery-tracking-enabled",
  "value": true,
  "variant": "on",
  "reason": "TARGETING_MATCH"
}

The same flag and the same rule give two decisions; the only difference between the two calls is which License the customer's instance runs under. In your product, an OpenFeature SDK configured with the OFREP provider makes this call — the SDK hub points to the setup.

Read both decisions in the audit trail

Every evaluation is recorded — the flag, the variant, the reason, and the rule that matched — without the evaluation context, so nothing the caller sent enters the trail. The entry is recorded for the organization, without an Instance: Kaiten follows the OpenFeature Remote Evaluation Protocol, in which an evaluation is addressed by a targeting key. An evaluation is therefore read in the organization's audit trail, and never in an Instance's — neither on the instance's Audit Trail tab nor through GET /instances/{instanceSlug}/audit-trails.

1. Open Audit trail, at the bottom of the sidebar. The page refreshes by itself; an evaluation appears a few moments after the call.
2. In Event type, choose Feature flag evaluated. The two newest entries are the evaluations of step 4, with a dash under Instance and Customer.
3. Click each row to expand it. Under Full payload, the newest one — Sakura Tokyo's — reads variant: on, reason: TARGETING_MATCH and matched_rule_name: Delivery tracking entitlement granted; the one before it — Ninja Osaka's — reads variant: off and reason: DEFAULT, with no rule.

An entry names the flag and the decision, not the subject: tell the two apart by their order and their result. Recording the Instance sent in the evaluation context on the audit entry is in progress Coming soon.

✕

✕

No REST operation lists the organization's trail; Answer who had access shows the query that does.

The same page holds the rest of the chain of custody: the grants recorded in step 2 — Entitlement assigned to a license (LICENSE_ENTITLEMENT_ASSIGNED), one per License version, recorded without an Instance too, because a grant changes the License and not one instance — and the creation of the flag with its rule. What ties a decision to a customer is the contract, and that part is on record per Instance: the Audit Trail tab of sakura-tokyo-prod holds the entry that placed it under Premium v2. When support asks why a Sakura Tokyo user saw delivery tracking and a Ninja Osaka user did not, the answer is the License each instance was given, the grant on that License, and the rule of the flag — Answer who had access walks that read.

Change the contract and evaluate again

Ninja Osaka upgrades. Nothing about the flag changes: move ninja-osaka-prod to a License that grants delivery-tracking and evaluate again. Standard v1, the version the Standard family serves, grants false; Standard v2 grants true — the version Ninja Osaka's delivery pilot, ninja-osaka-delivery, already runs.

1. Open Customers → Instances, then ninja-osaka-prod, and click Edit. On Choose the license, set License to Standard v2, and click Update Instance.
2. Re-run the evaluation from step 4 for Ninja Osaka: "value": true, "variant": "on", "reason": "TARGETING_MATCH". ninja-osaka-prod is the customer's oldest instance, the one the License facts are read from.

The commercial change and the runtime behavior are one record apart, and both are on record: the INSTANCE_UPDATED entry, carrying the new licenseSlug, on the instance's Audit Trail tab, and the new decision on the organization's Audit trail page. Move the instance back to Starter afterwards if you want the seeded scenario intact.