Logic

Hyperlang

Once you've defined a feature flag in your schema, you can add targeting rules to define when the flag should be on.

You build these rules in Hyperlang, our visual, functional, statically-typed configuration language.

Since Hyperlang is a full programming language, you can insert arbitrarily complex rules.

Input types and targeting attributes

When building rules, you can reference targeting attributes that you defined on the input types in your schema, e.g. context.user.id, context.environment or context.organization.plan.

Variables and user segments

You can convert any Hyperlang expression into a variable.

This lets you create user segments, e.g. a list of beta user IDs, that you can reuse across the logic of different flags.

A/B tests, staged rollouts and machine learning loops

Hyperlang also lets you embed A/B tests, staged rollouts, multivariate tests and machine learning loops anywhere in your flag logic. These are all different types of splits.

So you can have a single feature flag with rules to enable the feature for specific users, e.g. employees, QA, beta users, etc, and a final default rule to A/B test the feature on everyone else.

It also means you can reuse a single A/B test across the logic of different feature flags to roll out and test related features in sync.

Logging events

Hyperlang also lets you log events, e.g. SignUpEvent, PurchaseEvent, etc, for Void event trigger flags in your schema, and then build funnels out of them to:

• See drop-off rates between different event types

• Compare conversion rates across different arms of an A/B test or machine learning loop

• Set goals for machine learning loops

Analytics

Live counts are overlaid on your flag targeting logic so you can see how often different targeting rules are evaluated and passed in realtime.

Comments

You can add a comment to any Hyperlang expression, e.g. to explain a feature flag, a specific targeting rule, a list of IDs or a specific ID.

Permissions and roles

You can set permissions on any Hyperlang expression.

This lets you safely empower nontechnical teammates to update specific parts of your flag logic. For example, you could let product managers edit a list of user IDs for a specific flag targeting rule, but not the structure of the rule, or the other rules on the flag.

Type-directed logic builder

The Hyperlang logic builder interface is "type-directed". This means it only lets you insert expressions that satisfy the required type of the hole in the logic tree. So for a Boolean feature flag defined in your schema, you can insert a primitive Boolean expression or an If / Else expression that returns a Boolean. If you insert an If / Else expression, more holes appear.

This results in an intuitive interface such that nontechnical users don't need to know any syntax and can't get into invalid states.

Type-checking

Hyperlang is statically-typed and your logic is type-checked against your schema. Since the logic builder interface is type-directed, you typically won't encounter any type errors.

However, if you make a breaking change to your schema, e.g. by removing or renaming a flag, you'll see a type error that you'll need to fix.

Since your schema and logic are saved and deployed together in a single commit, you won't be able to save your changes if there are any type errors that need fixing.