Parameterize once.
EXPERIMENT FOREVER 

A parameter is a typed value with a default, an optional constraint range, and a namespace. It's declared in version-controlled YAML and pushed, so the set of controllable values is reviewable like any other config — with a CI check that fails on drift.

In code you read it through the SDK with an inline default. That default is authoritative when nothing else applies, which is what makes this safe to adopt incrementally: parameterize a value today, run nothing on it for a month, and behaviour is identical.

React Next.js Svelte Node Python React Native TypeScript PHP Swift + OpenFeature

A given unit buckets identically on every platform — that's a conformance requirement, not a coincidence.

parameters:
  pricing.discount_pct:
    type: number
    default: 10
    constraints: { min: 0, max: 50 }
    layer: optimization-discounts
  pricing.free_shipping:
    type: boolean
    default: false
    layer: optimization-discounts

const p = traffical.getParams({
  context: { userId, cartValue, plan },
  defaults: {
    'pricing.discount_pct': 10,
    'pricing.free_shipping': false,
  },
});

The context you pass is what targeting and contextual algorithms can reason about. Pass more than you need today.

Your SDK holds a pre-built configuration document and resolves locally. There is no network call on the hot path — which means this works at the edge, works offline, and keeps working on the last known configuration if we're unreachable.

Resolution is deterministic: the same unit always lands the same way, so a user is consistent across sessions, devices, and surfaces without anyone storing per-user assignments.

Parameters no active policy touches keep their default. That's why an unused parameter costs nothing.

Two policies can target the same parameter. Priority decides who wins where they overlap — and the layer guarantees a user only ever gets one of them.

A layer owns a group of related parameters and a fixed pool of traffic. The rule inside a layer is simple: a given user is in at most one policy. Two tests that could interfere with each other belong in the same layer, and the layer makes overlap impossible rather than merely discouraged.

Across layers, traffic is allocated independently — a user's position in one layer tells you nothing about their position in another. So the checkout team and the search team run in parallel without comparing calendars, and neither contaminates the other's results.

• Within a layer — mutually exclusive. One policy per user, guaranteed.
• Across layers — independent. Concurrent tests stay clean.
• Traffic is visible — the layer shows exactly what's allocated and what's free.
• Reused across phases — advancing a change reuses the same slice, so nobody is re-randomized mid-flight.

You can operate at the policy level directly — that's the whole machinery, exposed. But a policy says nothing about why it exists or whether anyone approved exposing users to it. That's what a change adds: intent, an approved measurement plan, per-phase guardrails, and a decision record on every transition.

Because every policy runs through one system, the results accumulate. A completed run keeps its question, its arms, its evidence, and its verdict as a durable record — searchable by parameter, surface, or metric. The next proposal starts from what you already know instead of from a blank page.

The audit trail is the proof beneath that memory: who acted, what the evidence said, which thresholds were in force. Snapshotted, so an old decision can still be reconstructed exactly.