Core concepts

f69’s domain has six building blocks plus two billing axes. Understanding them is enough to model almost any rollout.

Workspace

A workspace is the top-level container for billing, human members, and projects. Workspace members get a WorkspaceRole (viewer, member, admin, owner) that controls who can manage members, create projects, or delete the workspace.

Workspace owner and admin automatically have owner privileges on every project in the workspace. Other users need explicit project membership to see project resources.

Project

A project lives inside a workspace and owns the things you work with day-to-day:

• Environments
• Features (flags) and segments
• Entities
• Service accounts

Every workspace has a default project and a default project membership ladder (viewer, member, admin, owner). Most teams will use a single project; multiple projects are useful when you want to isolate billing axes or membership across products.

Environment

An environment is a per-project stage - typically dev, staging, prod, but you can name them however you like (lowercase, hyphenated, unique within the project). A flag has a different rule set per environment, and a service-account token is bound to exactly one environment for the life of the token.

Feature flag

A flag has:

• A key (unique within the project, e.g. new-checkout).
• A default value (true / false) used when no rule matches.
• An ordered list of rules per environment. The first rule whose predicates all hold wins.

A rule’s outcome is either a fixed boolean (Outcome::Value) or a deterministic rollout that hashes the entity into a basis-point bucket and picks a variant.

Segment

A segment is a reusable named group of entities that you can reference from rules via in_segment. Segment membership is computed by checking exclusions first, then explicit inclusions, then any of its rule groups (ORed groups of ANDed predicates). Segments may reference other segments, but the reference graph must be acyclic.

Entity

An entity is a thing you evaluate flags for - usually a user or workspace. Entities are upserted via POST /v1/identify (edge) and are keyed (environment, type, external_id). Identifying an entity persists its attributes; the evaluation API uses those stored attributes server-side, so request bodies don’t have to ship the full context every time.

flowchart LR
  Workspace --> Project
  Project --> Environment
  Project --> Flag
  Project --> Segment
  Project --> Entity
  Project --> ServiceAccount["Service account"]
  Environment -->|binds| ServiceAccount

Manifest

The manifest is the snapshot of flags, rules, and segments for a given project + environment, plus a version string. The dashboard publishes manifests; the edge evaluator reads them. Because the manifest is versioned and the evaluator is pure, every runtime that holds the same manifest produces the same answer.

Service account

A service account is the credential your servers use to talk to edge. Each account has:

• A role: reader (evaluate only) or writer (also identify).
• An environment binding: requests resolve flags against this environment automatically.
• A bearer token of the shape xxxxxxxx@f69:<uuid>.<secret>. The secret is shown once at creation and stored as an Argon2 hash; if you lose it, mint a new one.

Billing axes

f69 meters usage on three axes:

Axis	What it counts
MTEs (monthly tracked entities)	Distinct entities evaluated in a billing period
Evaluations	Each flag result returned counts as one evaluation
Service accounts	The number of active workspace API keys

Plans gate environments, retention, seats, SSO, and advanced rule types on top of those numbers - see the pricing page for the public limits.