e-volv Launch

e-volv Launch serves feature flags to every service and app in a workspace. A flag has named variants, targeting rules that pick a variant per subject, and a kill switch for incidents. Server SDKs receive the full ruleset and evaluate locally; browser and mobile SDKs receive evaluated values for one context and never hold targeting logic. The full delivery contract lives in the Launch SDK contract.

Projects and environments

A Launch project groups flags for one product area. Each project has environments - typically production and staging - and every environment has its own ruleset: the same flag can be on in staging and off in production with different defaults in each. Every SDK request is scoped to one environment by the key it presents.

Flags and variants

A flag declares a type - boolean, string, number or JSON - and named variants of that type, e.g. on/off or a/b. Rules and rollouts reference variants by name, so renaming a variant does not rewrite targeting.

Precedence

First match wins:

Order	Step	Reason
1	Flag absent from the ruleset	`FLAG_NOT_FOUND`
2	killed	`KILLED`
3	An unmet prerequisite	`PREREQUISITE_FAILED`
4	Ordered rules; the first whose clauses and segments all match	`RULE:n or ROLLOUT`
5	That rule's rollout if it has one, else its variant	`ROLLOUT or RULE:n`
6	The environment's defaultVariant	`DEFAULT`
7	The caller's fallback if the default variant does not exist	`ERROR`

Two properties are load-bearing. A kill beats everything below it - during an incident the operator must not reason about whether an allowlist rule outranks them. And evaluation never throws and never performs I/O: it sits on the customer’s request path, so a malformed payload returns the fallback with reason ERROR; it does not raise.

Rollouts and bucketing

bucket(flagKey, subject, salt) → 0-9999, sha1(flagKey[:salt]:subject), first 8 hex digits, modulo 10 000. The flag key is inside the hash deliberately: without it every flag at 5% selects the same 5% of subjects. A rollout with no targetingKey cannot be deterministic, so it serves the environment default with reason DEFAULT rather than guessing.

Segments

A segment is a named, reusable set of rules referenced from any flag: an allow list of keys, a deny list that beats it, and rule clauses with optional percentage weights. Huge membership lists stay in the store as external segments; an SDK asked to evaluate one locally treats the subject as not a member: the narrower, safe answer.

The kill switch

The kill switch forces a flag to its off variant for everyone, ahead of every rule, and is stored separately from targeting: killing during an incident does not destroy the targeting underneath, and un-killing restores exactly what was there before.

Reasons

Every evaluation returns a reason, which is what makes the evaluation debugger answer “why is this on for me” without a support ticket:

Reason	Means
`KILLED`	The kill switch is on; everyone gets the off variant.
`OFF`	The flag is off; everyone gets the off variant.
`PREREQUISITE_FAILED`	A flag this one depends on is not serving one of the required variants.
`TARGET_MATCH`	The subject was on an individual target list.
`RULE:n`	Targeting rule n matched and served its variant.
`ROLLOUT`	A percentage rollout placed the subject in a slice.
`DEFAULT`	The flag is on and nothing else matched; the environment default variant was served.
`FLAG_NOT_FOUND`	The flag does not exist (or is absent from the payload); the caller’s default was returned.
`TYPE_MISMATCH`	The served value was not of the requested type; the caller’s default was returned.
`ERROR`	The payload was malformed; the caller’s default was returned.

Server and client keys - which key each platform gets and how origin allowlists work. The HTTP API - bootstrap, streaming, exposures and ping, for any language we do not ship an SDK for. SDKs - one client per platform, installable from its registry.