Skip to main content
FireWeave SDKs evaluate control points, optionally register targets, bind a release, and record exposures and signals. A runtime owns lifecycle and talks to fw-server through an adapter. Ask capabilities what this build can do instead of sniffing versions. This page is the map. Each child page answers what the concept is, why it exists, when to use it, how it relates to the others, and what it looks like in code.
OpenFeature and the wire still say flagKey. The product name is control point (ADR-0007). Do not invent controlPointKey.

​
Concept map

Control points

The named decision your code asks FireWeave for. Evaluation uses the parameter flagKey.

Targeting

Who the decision is for: targetingKey, properties, and registration where the API exists.

Releases

Bind this process to a rollout, then start, complete, or fail.

Exposures

Proof a target saw a decision. Opt-in — sendExposure defaults to false.

Signals

Health, error, metric, and outcome telemetry. Outcome is a signal kind, not a separate object.

Capabilities

Discover what this SDK build and adapter can do. Guardrails are a stub.

Adapters

How the runtime talks to a backend: remote, in-memory, and local/dev.

OpenFeature

Portable typed getters. Releases, exposures, and signals stay on the FireWeave client.

​
How the pieces fit

​
Collisions

These names look interchangeable. They are not.

​
Control point vs flagKey

Control point is the product noun: a point of control over a release, not “a boolean.” Evaluation, OpenFeature, the HTTP body (POST /v1/flags/evaluate), and the Decision / Exposure / Signal envelopes still use flagKey. That name is fixed by the OpenFeature spec and the fw-server contract. Say “control point” in prose. Write flagKey in code. Do not rename the parameter.

​
client.flags vs client.controlPoints

On Node, Python, and Web, client.flags is the same object as controlPoints / control_points. The old name is a deprecated alias, not removed in 2.x. Go exposes Flags() only. Java has no controlPoints or flags facade — call evaluate, getBooleanValue, or getStringValue on the client.

​
In-app “feature flag” vs SDK control point

The console glossary says feature flag / managed flag. Official docs use control point. Same job, different corpus. This site does not keep two glossaries.

​
targetingKey vs “cohort key”

The OpenFeature targetingKey is the cohort key. Code always uses targetingKey. “Cohort key” is the console synonym for that same stable ID. There is no SDK parameter named cohort or cohortKey.

​
identify vs registerTarget

Same job, different names. Node: runtime.registerTarget. Python: runtime.register_target. Web: client.identify() then sets context. Go and Java have no registration API on master. This is not OpenFeature identify.

​
Exposure vs OpenFeature tracking

FireWeave exposures are exposures.record / flush and opt-in sendExposure (default false). OpenFeature Tracking (spec §6) is not implemented. Do not document provider.track.

​
Signal outcome vs releases.complete

signals.recordOutcome is a telemetry kind. releases.complete / fail are lifecycle transitions. On Node, complete / fail also record an outcome signal. Do not collapse them into one invented “outcome API,” and do not create a standalone outcomes page.

​
Capability guardrails vs console auto-rollback

The SDK reports guardrails: false. Every guardrails call degrades with UnsupportedCapability. Console copy about live auto-rollback is not an SDK feature.

​
In-app terms that are not SDK APIs

The console and marketing corpus use words the five SDKs do not implement. Mentioned once here so they are not promoted on the concept pages: For the gap list behind those omissions: Go and Java remain unpublished on public registries, Go/Java have no registerTarget, console wrap-vs-promote is unresolved, and fw-server targeting predicates are unverified.
Last modified on August 18, 2026