LaunchDarkly vs Unleash

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Unleash
   LaunchDarkly—none0/10

   Direct probes show llms.txt and docs.md both return 404, and no evidence of any agent-oriented documentation endpoint; while LaunchDarkly ships an MCP server and CLI, these do not satisfy the specific 'llms.txt or agent-oriented docs' story.

   • [probe] “PROBE llms.txt: HTTP 404 at https://launchdarkly.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://launchdarkly.com/docs.md”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Unleash publishes a working llms.txt (HTTP 200, with explicit AI-agent instructions for fetching Markdown) plus a documented, MCP-reachable docs endpoint, giving agents structured, agent-oriented documentation entry points. Missing for 10: independent (non-vendor) confirmation that third-party agents actually consume these successfully in the wild.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.getunleash.io/llms.txt # Unleash Documentation ## Instructions for AI Agents - For clean Markdown…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Unleash
   LaunchDarkly✓fullprobed7/10

   LaunchDarkly ships an official CLI (ldcli) confirmed to run keylessly in a runtime probe, plus API access tokens, SDKs, and webhooks that together support headless/CI automation of flag management and evaluation. Missing for 10: explicit CI/CD pipeline integration examples (e.g., GitHub Actions recipes) or documented non-interactive CLI auth flows for pipelines.

   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [claimed-docs] “LaunchDarkly CLI”
   • [claimed-docs] “API access tokens”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “30 idiomatic SDKs”

   proof ↗⚑ flag

   Unleash✓fullprobed8/10

   Unleash ships a self-hostable Docker image, a full Admin/Client API, and scoped API tokens designed for automation/SDKs rather than human UI use, and a hands-on probe confirms a complete keyless headless workflow (docker boot, flag creation via Admin API, evaluation via Client API) with no manual UI steps — exactly the CI/automation pattern the story asks for. missing for 10: no independent third-party CI pipeline example or official CI/CD docs page walking through pipeline integration.

   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to LaunchDarkly
   LaunchDarkly✓fullprobed9/10

   LaunchDarkly documents and ships both a local npm MCP server and a hosted MCP server endpoint, and runtime probes confirm the npm server completes a full stdio initialize handshake and the hosted endpoint is live and auth-gated as documented. Missing for 10: independent third-party (non-vendor) hands-on review of the MCP server's tool functionality beyond the handshake.

   • [claimed-docs] “LaunchDarkly MCP server”
   • [claimed-docs] “Set up the LaunchDarkly hosted MCP server”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”

   proof ↗⚑ flag

   Unleash✓fullprobed8/10

   Unleash documents an official MCP server (@unleash/mcp) that lets LLM-powered coding assistants create and manage feature flags following best practices, and a probe confirms the docs MCP endpoint completes a full handshake. missing for 10: independent/hands-on third-party validation of the flag-management MCP server itself (only the docs-MCP handshake was runtime-verified, not the @unleash/mcp flag server), and no evidence of broader community adoption reports.

   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “official MCP server documented at https://docs.getunleash.io/integrate/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to LaunchDarkly
   LaunchDarkly✓fullprobed9/10

   LaunchDarkly ships an official CLI (`ldcli`), documented and verified via a hands-on runtime probe that installed via Homebrew and successfully ran `ldcli --version` keylessly, confirming it is real and functional. Missing for 10: independent third-party community commentary specifically evaluating the CLI's AI-native/agentic workflows.

   • [claimed-docs] “LaunchDarkly CLI”
   • [probe] “official CLI documented at https://launchdarkly.com/docs/home/getting-started/ldcli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack details SDKs, Admin API, MCP server, and Docker deployment, but no official CLI tool for Unleash is mentioned anywhere in the docs or GitHub materials.

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Unleash
   LaunchDarkly✓fullprobed7/10

   LaunchDarkly documents API access tokens for programmatic access (launchdarkly-docs-37), an official CLI (launchdarkly-docs-12/probe-5) and both local and hosted MCP servers that were verified live at runtime (launchdarkly-probe-rt-1/2/3), all of which wrap the public API for automated/agentic control. Missing for 10: a discoverable OpenAPI/swagger spec (probe-3 shows 404s at standard paths) and explicit REST API reference docs in the evidence pack.

   • [claimed-docs] “API access tokens”
   • [claimed-docs] “LaunchDarkly CLI”
   • [probe] “official CLI documented at https://launchdarkly.com/docs/home/getting-started/ldcli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://launchdarkly.com/openapi.json, https://launchdarkly.com/swagger.json, https://launchdarkly.c…”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Unleash's Admin API is explicitly documented as providing comprehensive programmatic access to all resources, backed by scoped API tokens/keys, and this is corroborated by a hands-on probe showing a full keyless create-and-evaluate flag roundtrip via the Admin and Client APIs. This directly demonstrates AI-native drivability through a documented public API. Missing for 10: no independent third-party API client showcase beyond Unleash's own SDK/probe evidence.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   LaunchDarkly~partialprobed6/10

   LaunchDarkly documents API access tokens and custom role assignment, which together let a user create scoped, least-privilege credentials for any client — and the MCP server explicitly requires an API key for tool calls (agent authenticates via this token), confirming the mechanism applies to AI-agent use. However, no docs specifically address agent-oriented token types, short-lived/ephemeral credentials, or per-tool scoping tailored to autonomous agents. missing for 10: agent-specific credential type or lifecycle, fine-grained per-tool/action scoping beyond general custom roles, independent verification that scoped tokens work end-to-end with the MCP server.

   • [claimed-docs] “API access tokens”
   • [claimed-docs] “Assigning roles to members”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”
   • [claimed-docs] “LaunchDarkly MCP server”

   proof ↗⚑ flag

   Unleash~partialprobed6/10

   Unleash supports scoped credentials generally: backend API tokens are scoped to specific projects and a single environment, frontend tokens are explicitly non-secret/least-privilege by design, and RBAC governs permissions; the official MCP flag-management server requires a PAT (a scoped credential) at startup, which is directly relevant to agent access. However, there's no explicit documentation of fine-grained, agent-specific credential scoping (e.g., read-only vs write scopes tailored for an AI agent) beyond project/environment granularity. Missing for 10: dedicated agent-credential scoping guide, granular permission scopes beyond project+environment, and independent confirmation of least-privilege PAT usage in agent workflows.

   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [claimed-docs] “Frontend tokens are not considered secret and are safe to expose client-side.”
   • [claimed-docs] “Unleash implements role-based access control on two levels”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   LaunchDarkly✓fullprobed8/10

   LaunchDarkly documents 30 idiomatic SDKs, OpenFeature providers, and edge SDKs (e.g., Cloudflare) plus a CLI and MCP server for AI-native/agentic workflows, giving developers official building blocks across languages and AI tooling. missing for 10: independent hands-on developer reviews specifically praising SDK quality/documentation depth, and no evidence of AI-specific SDK features (e.g., LLM-context helpers) beyond general SDK/OpenFeature support.

   • [claimed-docs] “30 idiomatic SDKs”
   • [claimed-docs] “OpenFeature providers”
   • [claimed-docs] “Cloudflare SDK reference”
   • [claimed-docs] “LaunchDarkly CLI”
   • [claimed-docs] “LaunchDarkly MCP server”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash documents official client/backend SDKs as the primary integration path (quickstart guide, API token docs distinguishing frontend/backend SDK scoping), which AI-native developers can build against directly. missing for 10: no independent/hands-on corroboration of SDK quality or breadth across languages, and no explicit SDK versioning/changelog evidence.

   • [claimed-docs] “Create your first feature flag** using the Unleash Admin UI. **Connect Unleash to your application** by integrating an SDK into your codebas…”
   • [claimed-docs] “use one of the client or backend SDKs to connect Unleash with your application”
   • [claimed-docs] “Create your first feature flag using the Unleash Admin UI. Connect Unleash to your application by integrating an SDK into your codebase.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [claimed-docs] “Frontend tokens are not considered secret and are safe to expose client-side.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to LaunchDarkly
   LaunchDarkly✓fullclaimed8/10

   LaunchDarkly documents a dedicated Webhooks feature under infrastructure integrations, allowing subscription to flag/project events for automation, which directly supports agentic/event-driven workflows. Missing for 10: independent hands-on confirmation of webhook payload structure/reliability and no evidence of fine-grained event filtering options.

   • [claimed-docs] “Webhooks”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack contains no mention of webhooks, event subscriptions, or push-based notification mechanisms anywhere in Unleash's docs, API overview, or integrations list — only SDKs, Admin/Client APIs, Edge caching, and MCP flag-management tools are documented.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   LaunchDarkly—none0/10

   The evidence shows LaunchDarkly's AI-related features (AI Configs, 'AI Runs', LLM-as-judge evals) are about managing and evaluating AI/LLM application behavior via flags, not about the product itself surfacing AI-generated insights or suggestions from a user's flag/experiment/metrics data. No docs mention anomaly detection copilots, natural-language querying, or AI-generated recommendations inside the dashboard.

   • [claimed-docs] “Configure, evaluate, roll out, and observe your AI end to end”
   • [claimed-docs] “An AI Run is generated when you track an LLM request or run an online eval (LLM-as-a-judge).”
   • [claimed-docs] “Guarded rollouts”
   • [claimed-docs] “Decision making with Bayesian statistics”

   proof ↗⚑ flag

   Unleash—none0/10

   Unleash's evidence covers feature flag management, impact metrics thresholds, and an MCP server that lets external LLM coding assistants create/manage flags — but nothing shows Unleash itself generating AI insights or suggestions from data inside the product (e.g., AI-driven rollout recommendations, anomaly analysis, or narrative summaries). The impact metrics feature is rule-based automation, not AI-generated insight, and the MCP server is for external agents to act on Unleash, not Unleash surfacing AI-generated analysis to users.

   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   LaunchDarkly~partialprobed5/10

   LaunchDarkly supports autonomous background automations like scheduled flag changes and guarded rollouts that automatically monitor metrics and roll back without human intervention, plus webhooks that can trigger downstream automation, and its MCP server lets an AI agent configure these. But there's no evidence of a general-purpose agentic automation/orchestration capability beyond release-management rules. Missing for 10: evidence of AI agents autonomously creating/managing ongoing automations via MCP (only initial handshake is verified), broader agentic workflow orchestration beyond flag/rollout rules, and independent confirmation these autonomous rollbacks work reliably in practice.

   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “Guarded rollouts”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “LaunchDarkly MCP server”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”

   proof ↗⚑ flag

   Unleash~partialprobed5/10

   Unleash documents metrics-driven automation — progressing rollout milestones or triggering safeguards (pause/disable) automatically when thresholds are crossed — which is a real background automation running without manual intervention, and its MCP integration lets AI agents create/manage flags. However this automation is narrowly scoped to release/rollout progression rather than a general-purpose agentic automation framework, and there's no evidence of scheduling arbitrary autonomous agent tasks beyond flag rollout safeguards. Missing for 10: evidence of broader autonomous task scheduling beyond rollout thresholds, independent corroboration of the impact-metrics automation working in production, and confirmation the MCP server itself can trigger these automations autonomously rather than just via API calls.

   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”
   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   LaunchDarkly—none0/10

   LaunchDarkly's evidence shows AI-related feature-flag tooling (AI Runs, LLM evaluation flags) and an MCP server that lets external AI agents call into LaunchDarkly as a tool provider, but there is no evidence of a built-in AI assistant inside the product itself that a user can delegate tasks to.

   • [claimed-docs] “Configure, evaluate, roll out, and observe your AI end to end”
   • [claimed-docs] “An AI Run is generated when you track an LLM request or run an online eval (LLM-as-a-judge).”
   • [claimed-docs] “LaunchDarkly MCP server”
   • [claimed-docs] “Set up the LaunchDarkly hosted MCP server”

   proof ↗⚑ flag

   Unleash—none0/10

   Unleash exposes an MCP server so external LLM coding assistants can manage flags (unleash-docs-7, unleash-probe-2, unleash-probe-rt-2), but this is the reverse of the story — it makes Unleash a tool for outside agents, not a built-in assistant living inside the Unleash product that users delegate tasks to. No evidence of an in-product AI assistant/chat feature for creating rollouts, analyzing flags, etc.

   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “official MCP server documented at https://docs.getunleash.io/integrate/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   LaunchDarkly✓fullprobed7/10

   LaunchDarkly ships an official MCP server (local npm package and hosted endpoint) that exposes flag/targeting/rollout operations to AI agents, letting an AI-native user issue natural-language commands through an MCP-compatible client; runtime probes confirm the local server completes a full stdio handshake and the hosted endpoint is live and auth-gated as documented. Missing for 10: no evidence of actual authenticated tool-call transcripts showing natural-language commands successfully executing flag changes, and no independent/community corroboration of the MCP workflow in practice.

   • [claimed-docs] “LaunchDarkly MCP server”
   • [claimed-docs] “Set up the LaunchDarkly hosted MCP server”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”

   proof ↗⚑ flag

   Unleash✓fullprobed7/10

   Unleash ships an official MCP server (@unleash/mcp) documented to let LLM-powered coding assistants create and manage feature flags following best practices, and a probe confirms the docs' MCP endpoint completes a handshake, corroborating the integration is real and agent-reachable. Missing for 10: no independent/hands-on demonstration of the flag-management MCP server itself in use (only the docs MCP endpoint was probed), and it requires local setup with a PAT rather than being zero-config.

   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “official MCP server documented at https://docs.getunleash.io/integrate/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   LaunchDarkly—none0/10

   The evidence pack shows only static docs pages and confirms no OpenAPI/swagger spec discoverable (probe-3 all 404s) and no llms.txt/docs.md; nothing indicates an interactive, runnable API reference/playground exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://launchdarkly.com/openapi.json, https://launchdarkly.com/swagger.json, https://launchdarkly.c…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://launchdarkly.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://launchdarkly.com/docs.md”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack shows Admin API docs and an MCP server for AI agents to manage flags, but nothing describes an interactive API reference (e.g., Swagger/OpenAPI explorer) with runnable/try-it-out examples. This is a fair capability to expect from an API-driven product, but no evidence supports it.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   LaunchDarkly—none0/10

   The evidence pack shows explicit probes for an OpenAPI/swagger spec at LaunchDarkly's standard candidate paths all returning 404, and no other citation surfaces a downloadable machine-readable API spec (only human-readable API access token docs are referenced). Despite LaunchDarkly having a public REST API in reality, this evidence pack contains no proof of an accessible OpenAPI spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://launchdarkly.com/openapi.json, https://launchdarkly.com/swagger.json, https://launchdarkly.c…”
   • [claimed-docs] “API access tokens”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack describes Unleash's Admin API as providing 'comprehensive programmatic access to all Unleash resources' but never mentions an OpenAPI/Swagger spec, schema file, or any downloadable machine-readable API definition. Missing for 10: explicit mention of an OpenAPI/Swagger document, a spec download endpoint, or documentation confirming machine-readable API schema availability.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   LaunchDarkly✓fullclaimed7/10

   LaunchDarkly's Environments feature explicitly separates test/staging from production, letting users evaluate and target flags in a non-production environment, and 'Testing changes to flag targeting' documents workflows to validate rule changes safely before they affect live traffic. Missing for 10: no explicit 'sandbox for AI-native/agent testing' framing, no independent/hands-on confirmation that environment data is fully isolated from production telemetry.

   • [claimed-docs] “Environments”
   • [claimed-docs] “Testing changes to flag targeting”
   • [claimed-docs] “Approvals”
   • [claimed-docs] “Change history”

   proof ↗⚑ flag

   Unleash✓fullprobed7/10

   Unleash's environments concept explicitly supports enabling flags in development/test without affecting production (unleash-docs-21, unleash-docs-10), and a hands-on probe confirms a full self-hosted Docker instance can be spun up locally with its own Postgres, tokens, and flag create/evaluate loop entirely separate from any production account (unleash-probe-rt-1). This gives an AI-native user a genuine sandbox path via self-hosting plus environment isolation. Missing for 10: no dedicated 'sandbox mode' or ephemeral test-environment feature purpose-built for AI agents, and no independent (non-vendor) corroboration of the environment-isolation guarantees in production use.

   • [claimed-docs] “This allows you to enable a flag in development or test without enabling it in production.”
   • [claimed-docs] “Environments represent different stages in your development lifecycle. They allow you to manage your product releases from local development…”
   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   LaunchDarkly—none0/10

   Evidence shows API access tokens and CLI/MCP tooling but no documentation of API versioning scheme or a deprecation policy; OpenAPI probes returned 404s, providing no confirmation of a discoverable, versioned API spec.

   • [claimed-docs] “API access tokens”
   • [probe] “PROBE openapi: all candidate paths 404 (https://launchdarkly.com/openapi.json, https://launchdarkly.com/swagger.json, https://launchdarkly.c…”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack documents the Admin API, tokens, and SDKs but contains no mention of API versioning scheme or a documented deprecation policy for Unleash's APIs. Missing for 10: any documentation of API version numbers, changelogs, or deprecation/sunset policy for endpoints or SDKs.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to LaunchDarkly
   LaunchDarkly~partialprobed5/10

   LaunchDarkly exposes a CLI, REST API tokens, and an MCP server that could be scripted by an AI-native user to act on many flags/segments programmatically, but no documented UI or API feature explicitly named 'bulk operations' (e.g., bulk edit/bulk archive across flags) appears in the evidence pack. Missing for 10: explicit bulk-edit/bulk-update API endpoints or UI, documentation of batch operations across contexts/segments, and independent confirmation of bulk-scale usage.

   • [claimed-docs] “LaunchDarkly CLI”
   • [claimed-docs] “API access tokens”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “official CLI documented at https://launchdarkly.com/docs/home/getting-started/ldcli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”

   proof ↗⚑ flag

   Unleash~partialclaimed3/10

   The Admin API is described as providing 'comprehensive programmatic access to all Unleash resources,' which implies scripting could achieve bulk create/update flows, but no evidence documents an explicit bulk-operations feature (e.g., batch enable/disable, bulk import/export, multi-select actions in UI) beyond a vague pricing-page mention of 'export/import feature flags for easy migration.' missing for 10: explicit bulk-update/bulk-tagging API endpoints, UI multi-select bulk actions, and any hands-on demonstration of operating on many items in one call.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “Export/import feature flags for easy migration”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to LaunchDarkly
   LaunchDarkly✓fullclaimed7/10

   LaunchDarkly ships rule-based targeting (custom rules, adaptive triggers), scheduled flag changes, and webhooks that let flag state changes or conditions automatically trigger downstream actions/integrations — directly matching the 'rules trigger actions on events' story. Missing for 10: independent/hands-on verification of adaptive-trigger and webhook automation behavior in practice, and clearer documentation of arbitrary event-driven (vs. flag-state) triggers.

   • [claimed-docs] “Adaptive triggers”
   • [claimed-docs] “Custom rules”
   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “Webhooks”
   • [claimed-docs] “Targeting rules”

   proof ↗⚑ flag

   Unleash~partialclaimed6/10

   Unleash's impact-metrics feature lets users define threshold-based rules that automatically trigger actions — progressing rollouts, pausing on latency/error-rate breaches, or disabling environments — which is genuine event-triggered automation ([unleash-docs-14],[unleash-docs-22],[unleash-docs-29]). However this is scoped narrowly to rollout safeguards rather than a general-purpose rule/event engine for arbitrary actions across the system. Missing for 10: evidence of a broader rule-definition system covering non-rollout events/actions, and independent confirmation the automation works reliably in practice.

   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   LaunchDarkly—none0/10

   LaunchDarkly documents one-time 'Scheduled flag changes' (docs-35) but there is no evidence of recurring/cron-style job or workflow scheduling; its CLI, API, and MCP server (docs-10/11/12) could be used by external automation but no first-party recurring scheduler is documented.

   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “LaunchDarkly CLI”
   • [claimed-docs] “LaunchDarkly MCP server”

   proof ↗⚑ flag

   Unleash—none0/10

   Unleash supports one-time scheduled feature releases (specific date/time) and conditional automation of rollout milestones/pauses based on metrics, but there is no evidence of recurring/cron-style job scheduling or workflow automation that repeats on an interval.

   • [claimed-docs] “to release a feature at a specific date and time** (for a product launch, for instance)”
   • [claimed-docs] “to release a feature at a specific date and time (for a product launch, for instance)”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   LaunchDarkly~partialclaimed5/10

   LaunchDarkly's flags (its closest analog to 'automations') have change history, approvals, scheduled changes, and rollback via targeting/rollout controls, which cover versioning and review workflows for flag changes. However, this is framed around feature flags/rollouts, not AI agent automations specifically, and there's no evidence of a dedicated automation-versioning UI, diff/review workflow for AI-agent-driven changes, or audit trail tied to AI-native usage. missing for 10: explicit versioning/rollback UI for AI-generated automations, review/approval workflow tied to AI agent changes, independent confirmation that change history supports full rollback of complex rule sets.

   • [claimed-docs] “Approvals”
   • [claimed-docs] “Change history”
   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “Creating and managing progressive rollouts”
   • [claimed-docs] “Guarded rollouts”

   proof ↗⚑ flag

   Unleash~partialclaimed5/10

   Unleash's 'automations' are feature-flag rollouts: change requests provide a review/approval step before changes go live (docs-11), and flags can be toggled or reverted instantly without redeploying (docs-18), giving a rollback-like mechanism, plus RBAC constrains who can change what (docs-12). However there is no evidence of an explicit version-history/audit trail or diff view for flag configuration changes, only approval gating and on/off toggling. Missing for 10: documented changelog/audit-log of flag config versions, explicit 'rollback to previous version' feature, and independent confirmation of change-request review workflow in practice.

   • [claimed-docs] “Change requests allow you to require an additional approval step before any changes can be made in an environment.”
   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “Unleash implements role-based access control on two levels”
   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”

   proof ↗⚑ flag

Proxy

1. platform engineerRun a relay/edge proxy so flags stay served when the vendor is unreachable and SDK traffic stays inside my network

   weight 1 · round drawn
   LaunchDarkly✓fullcommunity8/10

   LaunchDarkly documents the Relay Proxy as a self-hosted Go application that runs on customer infrastructure to serve flags and cache SDK connections, explicitly for resiliency, and this is independently corroborated by community commentary describing it as open source and used 'for extra resiliency' when LaunchDarkly's servers are unreachable, keeping SDK traffic within the customer's network. Missing for 10: independent hands-on verification of offline-serving behavior during vendor outage, and explicit first-party detail on network-isolation guarantees beyond general resiliency claims.

   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash Edge (open source) and Unleash Enterprise Edge are documented as a lightweight caching/relay layer that sits between SDKs and the Unleash server, acting as a read replica that can serve thousands of SDKs and improve resilience — keeping SDK traffic local and flags served even if the vendor/backend is unreachable. Self-hosting via Docker is also documented, reinforcing the on-network deployment model. Missing for 10: independent/hands-on validation of Edge's offline-resilience behavior and more detail on failover semantics beyond docs claims.

   • [claimed-docs] “functioning as a read replica that can handle thousands of connected SDKs without increasing the read load on your primary Unleash instance”
   • [claimed-docs] “Unleash Enterprise Edge is a lightweight caching layer designed to improve scalability, performance, and resilience.”
   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”

   proof ↗⚑ flag

Self host

1. platform engineerSelf-host the full flag platform from an open-source distribution, keeping evaluation data on my infrastructure

   weight 3 · round to Unleash
   LaunchDarkly—none0/10

   LaunchDarkly's evidence only describes an open-source Relay Proxy that caches/streams flag data from the LaunchDarkly cloud for resiliency and low latency, not a full self-hostable flag-management platform; the control plane, rules engine, and dashboard remain SaaS-hosted, and community comments explicitly flag this as a third-party critical-path dependency rather than a self-hosted deployment (launchdarkly-docs-13, launchdarkly-comm-2, launchdarkly-comm-6). No evidence shows an OSS distribution of the full platform keeping evaluation data entirely on customer infrastructure.

   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”
   • [community] “It's a pretty question[able] architecture that outsources feature flags to a third party. You're creating a critical path hard dependency an…”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Docs explicitly describe deploying Unleash Open Source via Docker in your own environment, and a hands-on probe confirms a full keyless self-hosted flag create-and-evaluate loop using the official unleash-server image against Postgres with no external account, demonstrating evaluation data stays on the operator's infrastructure. missing for 10: no independent third-party production case study of long-term self-hosted operation at scale.

   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”
   • [github] “Feature flags in Unleash let you test your code with real production data, reducing the risk of negatively impacting your users' experience.”

   proof ↗⚑ flag

Agent ops

1. ai agentRead experiment configurations and results programmatically to summarize outcomes and recommend ship/rollback decisions

   weight 1 · round drawn
   LaunchDarkly~partialprobed5/10

   LaunchDarkly documents an Experimentation feature with Bayesian statistical analysis, exposes API access tokens, an official CLI, and a hosted/local MCP server that an AI agent could use to read flag/experiment configuration data programmatically. However, no evidence explicitly confirms the MCP server or API exposes experiment results/metrics data (vs. just flag targeting) or that an agent has been shown reading such data to produce ship/rollback recommendations. Missing for 10: explicit documentation of an experiment-results API/MCP tool, and a hands-on example of an agent summarizing experiment outcomes or recommending ship/rollback decisions.

   • [claimed-docs] “Experimentation”
   • [claimed-docs] “Decision making with Bayesian statistics”
   • [claimed-docs] “API access tokens”
   • [claimed-docs] “LaunchDarkly MCP server”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”

   proof ↗⚑ flag

   Unleash~partialprobed5/10

   Unleash exposes a comprehensive Admin API for programmatic access to flags, variants, and impact metrics (thresholds, error-rate pausing) that an agent could poll to gauge rollout health, and an official MCP server lets LLM agents manage flags. However, evidence shows the MCP server is scoped to 'create and manage feature flags' rather than reading experiment results/outcomes or generating ship/rollback recommendations, and no docs describe an agent-facing results-summary or decision-recommendation workflow. missing for 10: explicit API/MCP support for reading experiment results/outcome data, and any documented agent workflow that summarizes outcomes or recommends ship/rollback decisions.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the docs MCP endpoint https://docs.getunleash.io/_mcp/server completed a FULL keyless initialize handsh…”
   • [claimed-docs] “Variants let you expose different versions of a feature to users, for example, as part of A/B and multivariate testing.”

   proof ↗⚑ flag

Analysis

1. product managerTrust a documented statistics engine (Bayesian or frequentist, with variance-reduction options) behind experiment results

   weight 2 · round to LaunchDarkly
   LaunchDarkly~partialclaimed6/10

   LaunchDarkly documents a Bayesian statistics engine for experiment results and a dedicated experimentation/metrics framework, giving PMs a documented methodology behind results. However, the evidence pack shows no explicit mention of a frequentist alternative or variance-reduction techniques (e.g., CUPED), and there's no independent/hands-on corroboration of the engine's real-world reliability. missing for 10: frequentist option documentation, variance-reduction feature details, independent validation of statistical results.

   • [claimed-docs] “Decision making with Bayesian statistics”
   • [claimed-docs] “Experimentation”
   • [claimed-docs] “Choosing a metric type”

   proof ↗⚑ flag

   Unleash—none0/10

   Unleash's docs mention 'impact metrics' for pausing/progressing rollouts based on thresholds, but there is no evidence of a documented statistics engine (Bayesian/frequentist), significance testing, confidence intervals, or variance-reduction techniques (e.g., CUPED) behind experiment/variant results. A Hacker News comment even notes Unleash's rule system is more limited than competitors, but this doesn't address the statistics engine specifically. missing for 10: any mention of a named statistical methodology, significance/power calculations, confidence intervals, or variance-reduction options for A/B test analysis.

   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “Variants let you expose different versions of a feature to users, for example, as part of A/B and multivariate testing.”
   • [community] “Many open source solutions (Unleash, last I checked, some time ago) are more limited: some of th[e]... [compared to LaunchDarkly's more flex…”

   proof ↗⚑ flag

Experiments

1. product managerRun A/B and multivariate experiments on flags and see which variation wins on my metrics

   weight 3 · round to LaunchDarkly
   LaunchDarkly✓fullcommunity8/10

   LaunchDarkly's docs explicitly cover A/B Tests and Experiments, metric type selection, and Bayesian statistics for deciding a winning variation, directly matching the PM story of running experiments on flags and seeing which variation wins on metrics. Community evidence corroborates multivariate flags and rollout targeting as real, used features. Missing for 10: independent hands-on account of running a full experiment and reading results dashboards, and more detail on multivariate (not just binary) experiment support.

   • [claimed-docs] “A/B Tests and Experiments”
   • [claimed-docs] “Experimentation”
   • [claimed-docs] “Choosing a metric type”
   • [claimed-docs] “Decision making with Bayesian statistics”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash~partialclaimed5/10

   Unleash documents 'variants' explicitly for A/B and multivariate testing (unleash-docs-8) and has 'impact metrics' that can gate/automate rollout progression based on threshold metrics (unleash-docs-14, unleash-docs-22, unleash-docs-29), giving PMs some data-driven feedback loop on flag variations. However, there is no evidence of a dedicated experimentation dashboard, statistical significance/winner-declaration reporting, or goal-metric comparison across variants akin to a full A/B testing suite. Missing for 10: statistical significance engine, experiment results/winner dashboard, and metric-goal configuration UI tied directly to variant performance.

   • [claimed-docs] “Variants let you expose different versions of a feature to users, for example, as part of A/B and multivariate testing.”
   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”

   proof ↗⚑ flag

Metrics

1. product managerDefine experiment metrics from my own data — warehouse tables or ingested events — instead of a black-box metric store

   weight 2 · round drawn
   LaunchDarkly—none0/10

   LaunchDarkly's experimentation docs (metrics, Bayesian stats, A/B tests) describe metrics defined via LaunchDarkly's own event tracking and metric store; there is no evidence of connecting to a customer's data warehouse or ingesting external event tables to define metrics.

   • [claimed-docs] “Choosing a metric type”
   • [claimed-docs] “Experimentation”
   • [claimed-docs] “Decision making with Bayesian statistics”
   • [claimed-docs] “A/B Tests and Experiments”

   proof ↗⚑ flag

   Unleash—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Environments

1. developerManage separate environments (dev/staging/prod) with independent flag states and scoped SDK keys

   weight 2 · round drawn
   LaunchDarkly✓fullcommunity9/10

   LaunchDarkly's docs explicitly cover Environments as a first-class construct with independent flag states per environment, and API access tokens/roles docs indicate scoped SDK keys per environment; community evidence corroborates the SDK/streaming architecture supporting per-environment keys. Missing for 10: no independent hands-on confirmation of scoped SDK key isolation across environments beyond docs.

   • [claimed-docs] “Environments”
   • [claimed-docs] “API access tokens”
   • [claimed-docs] “Assigning roles to members”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Unleash's docs explicitly describe environments as distinct stages (dev/staging/prod) with independent flag states per environment, and API tokens/keys are scoped to specific project(s) and a single environment, satisfying both independent state and scoped SDK keys. Missing for 10: independent third-party corroboration of multi-environment isolation beyond docs/probe.

   • [claimed-docs] “Environments represent different stages in your development lifecycle. They allow you to manage your product releases from local development…”
   • [claimed-docs] “This allows you to enable a flag in development or test without enabling it in production.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

Flags

1. developerCreate a feature flag and toggle it live in production within minutes of signing up

   weight 3 · round to Unleash
   LaunchDarkly✓fullcommunity7/10

   LaunchDarkly's docs explicitly cover creating flags, targeting rules, percentage rollouts, and environments—the core primitives needed to create and toggle a flag live in production—and community accounts confirm real-world use of rules-based targeting and rollout by percentage/attributes with minimal latency. However, missing for 10: a documented quickstart/time-to-first-flag walkthrough proving the 'minutes after signup' claim, and independent hands-on confirmation of onboarding speed (one community comment even calls the product generally 'a pain to use').

   • [claimed-docs] “Create flags”
   • [claimed-docs] “Percentage rollouts”
   • [claimed-docs] “Environments”
   • [claimed-docs] “Unlimited feature flags”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”
   • [community] “We've used LaunchDarkly (LD) for about a year now. We previously used our own Feature Flag library built by our CTO. LD provided a lot more,…”
   • [community] “I have used LaunchDarkly in the past and yeah it's kind of a pain to use.”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Docs show a clear quickstart flow: create a feature flag in the Admin UI, connect an SDK, and toggle it via activation strategies without redeploying — and a runtime probe confirms an actual create-flag-and-evaluate loop working end-to-end within minutes on a fresh self-hosted instance. Missing for 10: independent third-party account of a brand-new signup-to-production toggle timing (only a self-hosted probe, not hosted SaaS signup, is verified).

   • [claimed-docs] “Create your first feature flag** using the Unleash Admin UI. **Connect Unleash to your application** by integrating an SDK into your codebas…”
   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “use one of the client or backend SDKs to connect Unleash with your application”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

2. developerServe multivariate flags and dynamic configuration values (strings, numbers, JSON), not just booleans

   weight 2 · round drawn
   LaunchDarkly~partialcommunity6/10

   Community evidence explicitly confirms multivariate flags as a key LaunchDarkly benefit (launchdarkly-comm-9), and docs reference custom rules, targeting, and percentage rollouts that imply non-boolean variation support, but no evidence pack item directly documents string/number/JSON typed flag variations or dynamic config value usage. missing for 10: explicit docs on flag variation types (string/number/JSON), examples of dynamic config values, independent hands-on confirmation beyond the single HN mention.

   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”
   • [claimed-docs] “Targeting rules”
   • [claimed-docs] “Percentage rollouts”
   • [claimed-docs] “Custom rules”

   proof ↗⚑ flag

   Unleash~partialprobed6/10

   Unleash's docs confirm a dedicated 'variants' concept explicitly used for multivariate/A-B testing, which supports serving multiple values per flag, but the evidence never explicitly documents the variant payload types (string, number, JSON) or shows an SDK example reading a non-boolean value at runtime. missing for 10: explicit documentation of variant payload types (string/number/json) and hands-on/SDK evidence of retrieving a non-boolean variant value.

   • [claimed-docs] “Variants let you expose different versions of a feature to users, for example, as part of A/B and multivariate testing.”
   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”

   proof ↗⚑ flag

Lifecycle

1. platform engineerFind stale flags and code references so temporary flags actually get removed from the codebase

   weight 2 · round to LaunchDarkly
   LaunchDarkly~partialcommunity6/10

   LaunchDarkly documents a dedicated 'Code References' feature that shows where flags are used in code, corroborated by independent community commentary ([launchdarkly-docs-22], [launchdarkly-comm-3]), which directly supports finding code references for stale flags. However, the evidence pack lacks explicit documentation of flag-status/stale-flag detection (e.g., 'last evaluated' tracking or automated stale-flag alerts) to complete the workflow. Missing for 10: dedicated stale-flag status/health dashboard docs, evidence of automated staleness alerts, and independent confirmation that code-reference removal workflows are reliably used to clean up flags in practice.

   • [claimed-docs] “Code references”
   • [community] “One of the most common things you want to do for a feature flag is ask 'Where is this used in code?' LaunchDarkly even has a product feature…”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack covers flag creation, rollout strategies, environments, RBAC, change requests, and impact metrics, but contains no mention of stale-flag detection, flag lifecycle status, or code-reference scanning tools that would help a platform engineer find and remove unused flags from source code.

   ⚑ flag

Targeting

1. developerTarget or exclude specific individual users for a flag (allowlists, beta testers, internal accounts)

   weight 1 · round to LaunchDarkly
   LaunchDarkly✓fullcommunity8/10

   LaunchDarkly's docs explicitly cover 'Individual targeting' and 'Target with flags' allowing developers to include/exclude specific users by key, plus segments and custom rules for building allowlists (beta testers, internal accounts), corroborated by community mention of rules-based group-level targeting. Missing for 10: independent hands-on verification of individual-user allowlist workflow, dedicated example of internal-account exclusion in practice.

   • [claimed-docs] “Targeting rules”
   • [claimed-docs] “Individual targeting”
   • [claimed-docs] “Target with flags”
   • [claimed-docs] “Segments”
   • [claimed-docs] “Custom rules”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash~partialclaimed6/10

   Unleash supports activation strategies and constraints (segments, custom activation strategies and targeting) that can target or exclude specific users/groups, and tokens/environments allow scoping test rollouts to internal accounts, but no evidence pack item explicitly documents a simple 'individual user allowlist/exclude by userId' UI feature or shows a hands-on example of listing specific beta tester IDs. missing for 10: explicit documentation/example of per-user allowlist or exclude-by-userId targeting UI, independent/hands-on confirmation of this exact workflow beyond generic 'custom activation strategies and targeting' marketing copy.

   • [claimed-docs] “A segment is a reusable collection of strategy constraints.”
   • [claimed-docs] “Custom activation strategies and targeting”
   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “This allows you to enable a flag in development or test without enabling it in production.”

   proof ↗⚑ flag

2. developerTarget flags with attribute-based rules and reusable segments so the right users see the right variation

   weight 3 · round to LaunchDarkly
   LaunchDarkly✓fullcommunity9/10

   LaunchDarkly's docs and community evidence confirm attribute-based targeting rules, contexts, individual targeting, custom rules, percentage rollouts, and reusable segments (including converting rules into segments), directly matching the story; community input corroborates rules-based targeting by group/attributes in production use. missing for 10: independent hands-on verification of segment reuse across multiple flags beyond docs claims.

   • [claimed-docs] “Targeting rules”
   • [claimed-docs] “Individual targeting”
   • [claimed-docs] “Contexts”
   • [claimed-docs] “Segments”
   • [claimed-docs] “Converting rules into segments”
   • [claimed-docs] “Custom rules”
   • [claimed-docs] “Target with flags”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash✓fullcommunity7/10

   Unleash docs directly describe segments as reusable collections of strategy constraints, plus custom activation strategies/targeting and attribute-based rules for flag rollout (unleash-docs-9, unleash-docs-17, unleash-docs-18). This directly matches the story's request for attribute-based rules and reusable segments to target specific user variations. Missing for 10: independent/hands-on validation of complex multi-attribute rule evaluation and the HN comment noting relative rule-system limitations versus competitors introduces some doubt but is not a concrete contradiction.

   • [claimed-docs] “A segment is a reusable collection of strategy constraints.”
   • [claimed-docs] “Custom activation strategies and targeting”
   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “Variants let you expose different versions of a feature to users, for example, as part of A/B and multivariate testing.”
   • [community] “Many open source solutions (Unleash, last I checked, some time ago) are more limited: some of th[e]... [compared to LaunchDarkly's more flex…”

   proof ↗⚑ flag

Access

1. platform engineerRestrict who can change which flags with roles, permissions, and scoped API tokens

   weight 2 · round drawn
   LaunchDarkly✓fullclaimed8/10

   LaunchDarkly documents role-based access control ('Assigning roles to members') and scoped API access tokens ('API access tokens'), directly matching the story's request for roles, permissions, and scoped tokens to restrict who can change flags. Missing for 10: independent/hands-on verification of custom role granularity and confirmation of per-token flag/project scoping restrictions in practice, and no community corroboration of this specific governance feature.

   • [claimed-docs] “Assigning roles to members”
   • [claimed-docs] “API access tokens”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash documents RBAC at two levels (project and instance), scoped API tokens restricted to specific projects/environments (backend tokens) with non-secret frontend tokens, and change requests requiring approval before changes apply in an environment — together enabling platform engineers to restrict who can change which flags. GitHub evidence also confirms RBAC, SSO, and SCIM as enterprise features. missing for 10: independent/hands-on verification of granular permission enforcement and no first-party detail on custom fine-grained permission roles beyond RBAC docs.

   • [claimed-docs] “Unleash implements role-based access control on two levels”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”
   • [claimed-docs] “Frontend tokens are not considered secret and are safe to expose client-side.”
   • [claimed-docs] “Change requests allow you to require an additional approval step before any changes can be made in an environment.”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”

   proof ↗⚑ flag

Agent ops

1. ai agentCreate and toggle flags through documented APIs, CLIs, or MCP — and the platform can force my changes through approval workflows instead of letting me write to production unreviewed

   weight 3 · round to LaunchDarkly
   LaunchDarkly✓fullprobed7/10

   LaunchDarkly documents an official CLI (ldcli) and both local and hosted MCP servers for programmatic flag creation/toggling, backed by API access tokens and RBAC roles, and runtime probes confirm the CLI and MCP handshakes actually work as documented. Separately, LaunchDarkly's Approvals feature lets teams require review/sign-off before flag changes go live, and Change History provides an audit trail, which together satisfy the 'force changes through approval workflows' requirement. Missing for 10: explicit documentation tying the Approvals workflow specifically to API/CLI/MCP-originated changes (vs. UI-only), and independent/hands-on confirmation that an agent's API write is actually blocked pending approval.

   • [claimed-docs] “Approvals”
   • [claimed-docs] “Change history”
   • [claimed-docs] “LaunchDarkly MCP server”
   • [claimed-docs] “Set up the LaunchDarkly hosted MCP server”
   • [claimed-docs] “LaunchDarkly CLI”
   • [claimed-docs] “Assigning roles to members”
   • [claimed-docs] “API access tokens”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “official CLI documented at https://launchdarkly.com/docs/home/getting-started/ldcli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”

   proof ↗⚑ flag

   Unleash~partialprobed7/10

   Unleash documents an Admin API and MCP server for creating/managing flags (unleash-docs-6, unleash-docs-7, unleash-probe-2) and the runtime probe confirms real flag creation via the Admin API (unleash-probe-rt-1). Change requests (unleash-docs-11) and RBAC (unleash-docs-12) provide an approval-gating mechanism for environment changes, but this is an Enterprise-tier feature and evidence does not explicitly confirm it enforces approval on MCP/API-driven writes specifically (only that it applies to 'changes in an environment') nor is a documented CLI shown. Missing for 10: explicit CLI support, confirmation that change-request approval gates API/MCP-originated writes specifically, and independent (non-vendor) verification of the approval workflow blocking agent writes.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “This server enables LLM-powered coding assistants to create and manage feature flags following Unleash best practices.”
   • [probe] “official MCP server documented at https://docs.getunleash.io/integrate/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”
   • [claimed-docs] “Change requests allow you to require an additional approval step before any changes can be made in an environment.”
   • [claimed-docs] “Unleash implements role-based access control on two levels”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”

   proof ↗⚑ flag

Approvals

1. platform engineerRequire approvals or change requests before production flag changes go live

   weight 3 · round drawn
   LaunchDarkly✓fullclaimed8/10

   LaunchDarkly documents a dedicated Approvals feature requiring sign-off before flag changes are applied, plus Scheduled changes and Change history for governance/audit trails around production flag modifications, backed by role-based access control to enforce who can approve. missing for 10: independent hands-on confirmation of the approval workflow in practice and details on customizable approval policies (e.g., required approver count, bypass rules).

   • [claimed-docs] “Approvals”
   • [claimed-docs] “Change history”
   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “Assigning roles to members”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash docs explicitly describe Change Requests as an approval workflow that requires an additional approval step before changes go live in an environment, and this is corroborated by GitHub listing change requests as a hosted/enterprise feature alongside RBAC and SSO. Missing for 10: independent hands-on verification of the approval workflow in practice and details on multi-stage/production-specific enforcement.

   • [claimed-docs] “Change requests allow you to require an additional approval step before any changes can be made in an environment.”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”
   • [claimed-docs] “Environments represent different stages in your development lifecycle. They allow you to manage your product releases from local development…”
   • [claimed-docs] “Unleash implements role-based access control on two levels”

   proof ↗⚑ flag

Audit

1. platform engineerEvery flag change is recorded in an audit log — who changed what, when, and to which value

   weight 3 · round to LaunchDarkly
   LaunchDarkly~partialcommunity6/10

   LaunchDarkly documents 'Change history' for flags, which tracks flag configuration changes, and community mentions of Slack integration for visibility into changes corroborates change tracking exists; however, no evidence explicitly confirms a full audit log capturing who/when/old-value/new-value in a governance-focused, exportable/immutable format. Missing for 10: explicit documentation of audit-log fields (actor, timestamp, before/after value), retention/export/SIEM integration details, and independent confirmation of completeness.

   • [claimed-docs] “Change history”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack covers RBAC, change requests, environments, and API tokens, but contains no mention of an audit log recording who changed what flag, when, or to what value — the specific capability the story asks about is unevidenced.

   ⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Unleash
   LaunchDarkly~partialprobed5/10

   LaunchDarkly documents API access tokens for programmatic access, an official CLI (ldcli, verified installable and working) and both a local and hosted MCP server (verified live and functioning), indicating broad programmatic control over flags, targeting, and other resources. However, the evidence pack never explicitly states or demonstrates full parity between UI and API (e.g., no OpenAPI/swagger spec was discoverable, and no docs confirm every UI feature—like approvals, guarded rollouts, or experimentation setup—is API-exposed). Missing for 10: an explicit statement or reference doc confirming 100% UI/API feature parity, and evidence covering API support for approvals, guarded rollouts, and experimentation configuration specifically.

   • [claimed-docs] “API access tokens”
   • [claimed-docs] “LaunchDarkly CLI”
   • [probe] “official MCP server documented at https://launchdarkly.com/docs/home/getting-started/mcp”
   • [probe] “official CLI documented at https://launchdarkly.com/docs/home/getting-started/ldcli”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official LaunchDarkly CLI installed via `brew tap launchdarkly/homebrew-tap && brew install ldcli` …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official npm MCP server (`npx -y @launchdarkly/mcp-server start --transport stdio`) completed a FUL…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the documented hosted MCP endpoint https://mcp.launchdarkly.com/mcp…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://launchdarkly.com/openapi.json, https://launchdarkly.com/swagger.json, https://launchdarkly.c…”

   proof ↗⚑ flag

   Unleash~partialprobed7/10

   The Admin API is documented as providing 'comprehensive programmatic access to all Unleash resources', and a runtime probe confirms a real create-and-evaluate flag loop via the Admin/Client APIs with no UI involved, showing core flag management is fully API-driven. However, some UI-centric workflows (e.g., change request approval flows, RBAC/SSO configuration, impact-metrics dashboards) are not shown to have full API parity in the evidence. missing for 10: explicit documentation/proof that change-request approvals, RBAC/SSO setup, and impact-metrics automation can be fully performed via API rather than just referenced conceptually.

   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”
   • [claimed-docs] “Change requests allow you to require an additional approval step before any changes can be made in an environment.”
   • [claimed-docs] “Unleash implements role-based access control on two levels”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Unleash
   LaunchDarkly—none0/10

   LaunchDarkly offers API access tokens and a CLI (ldcli) that could programmatically read flag/segment configurations, but no evidence pack item documents a dedicated bulk data-export feature, an open-format export tool, or a stated data-portability/exit policy for account data.

   • [claimed-docs] “API access tokens”
   • [claimed-docs] “LaunchDarkly CLI”

   proof ↗⚑ flag

   Unleash~partialclaimed5/10

   Unleash is open source and self-hostable, and pricing docs mention 'export/import feature flags for easy migration,' plus the Admin API gives programmatic access to all resources, supporting data portability. However, there's no explicit documented full-data-export format spec, no evidence of exporting audit logs, metrics history, or user/RBAC data, and no dedicated 'leave and take everything' migration guide. Missing for 10: a documented comprehensive data-export/backup format covering all entities (not just flags), evidence of full account data portability, and independent confirmation that exports are truly complete and open-format.

   • [claimed-docs] “Export/import feature flags for easy migration”
   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”
   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Unleash
   LaunchDarkly—none0/10

   LaunchDarkly is a closed-source SaaS platform; evidence shows only proprietary docs, SDKs (some open-source client SDKs and CLI/relay proxy tools exist per community notes, but the core product source is not open-licensed), with no indication the core platform source is available under an open license.

   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”

   proof ↗⚑ flag

   Unleash~partialclaimed5/10

   The GitHub repo (github.com/Unleash/unleash) is cited multiple times and docs explicitly distinguish 'Unleash Open Source' from 'Unleash Enterprise', indicating the core product's source is publicly available. However, the evidence pack never states the specific open-source license (e.g. Apache-2.0) or confirms the full extent of what's open vs. enterprise-gated. Missing for 10: explicit license name/file citation, clarity on which modules are open vs. proprietary enterprise-only code.

   • [github] “Feature flags in Unleash let you test your code with real production data, reducing the risk of negatively impacting your users' experience.”
   • [github] “It also enables your team to work on multiple features simultaneously without the need for separate feature branches.”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”
   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Unleash
   LaunchDarkly—none0/10

   LaunchDarkly is a hosted SaaS platform; the only self-hostable component is the Relay Proxy, a caching/streaming layer that still depends on the LaunchDarkly SaaS control plane for flag configuration, not the core product itself. No evidence of a self-hostable core (dashboard, rules engine, data store) exists in the pack.

   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”
   • [community] “It's a pretty question[able] architecture that outsources feature flags to a third party. You're creating a critical path hard dependency an…”

   proof ↗⚑ flag

   Unleash✓fullprobed9/10

   Unleash Open Source is explicitly documented as self-hostable via Docker (unleash-docs-4), and a runtime probe confirms a full keyless self-host roundtrip creating and evaluating a flag with no account or license (unleash-probe-rt-1), directly demonstrating self-hosting of the core product. missing for 10: independent third-party (non-vendor) write-up confirming production-grade self-hosted deployment at scale.

   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”
   • [github] “Feature flags in Unleash let you test your code with real production data, reducing the risk of negatively impacting your users' experience.”

   proof ↗⚑ flag

Pricing

1. product managerSee published pricing and understand what drives cost (seats, MAUs, events, requests) before committing

   weight 2 · round to LaunchDarkly
   LaunchDarkly~partialcommunity6/10

   LaunchDarkly's public pricing page confirms a usage-based model (unlimited seats, no per-seat pricing) and lists some usage components like AI Runs and session-replay/error caps, plus community confirmation that mobile MAUs factor into cost. However, the evidence pack lacks concrete published tiers/numbers for events or API requests, and community commentary calls the pricing 'incredibly over priced' and confusing to reason about ahead of committing. missing for 10: detailed published rate tables for MAUs/events/requests, a cost calculator or worked pricing examples, and independent confirmation that the pricing page is fully transparent pre-sales.

   • [claimed-docs] “Configure, evaluate, roll out, and observe your AI end to end”
   • [claimed-docs] “An AI Run is generated when you track an LLM request or run an online eval (LLM-as-a-judge).”
   • [claimed-docs] “Unlimited feature flags”
   • [claimed-docs] “5K session replays and 5K errors /mo”
   • [claimed-docs] “Unlimited seats No per-seat pricing. Invite your whole team; pricing is based on usage.”
   • [community] “LaunchDarkly has a mobile client SDK, but they charge by MAU, which would be untenable. So folks tend to write a proxy for the mobile apps t…”
   • [community] “Agreed that LaunchDarkly is incredibly over priced.”

   proof ↗⚑ flag

   Unleash~partialclaimed3/10

   The pricing page is referenced and shows some plan-gated features (export/import, custom strategies, SSO) but the evidence never shows actual published prices or explicit cost drivers like per-seat, MAU, event, or request-based pricing that a PM could use to estimate cost before committing. Missing for 10: explicit price figures, cost-driver metrics (seats/MAUs/events/requests), and any tier comparison table showing how usage translates to price.

   • [claimed-docs] “Export/import feature flags for easy migration”
   • [claimed-docs] “Custom activation strategies and targeting”
   • [claimed-docs] “Single Sign-On (SSO) with SAML 2.0 or OpenID Connect (Azure AD, Okta)”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Unleash
   LaunchDarkly—none0/10

   No evidence pack items address data residency, region selection, or storage location controls for LaunchDarkly; the only tangential item is 'federal environments' docs, which is not about general data residency choice. missing for 10: documentation of selectable data regions/residency, EU/US hosting options, or any data localization controls.

   • [claimed-docs] “LaunchDarkly in federal environments”

   proof ↗⚑ flag

   Unleash~partialprobed5/10

   Unleash's self-hosted deployment (Docker, own environment) inherently lets users control where infrastructure and thus data resides, and this was verified in a runtime probe of a full self-host flag create/evaluate loop. However, there is no explicit documentation of region/residency options for the hosted Enterprise/Cloud offering (e.g., choosing EU/US data centers), so residency is only achievable via self-hosting rather than a first-class SaaS feature. Missing for 10: explicit region-selection or data-residency documentation for the managed/cloud product, and any compliance certifications tied to specific regions.

   • [claimed-docs] “This guide helps you set up Unleash Open Source or Unleash Enterprise in your own environment using Docker.”
   • [probe] “PROBE runtime (recorded 2026-09-05): full KEYLESS self-host roundtrip on this machine — the official unleashorg/unleash-server docker image …”
   • [github] “This gives you access to a hosted instance with unlimited projects and environments and features such as role-based access control, change r…”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   LaunchDarkly—none0/10

   LaunchDarkly is a feature-flag/experimentation platform; while it stores user/context data (contexts, segments), no evidence in the pack addresses data retention policies, deletion controls, or privacy/compliance tooling for AI-native users. missing for 10: data retention policy docs, deletion/erasure API or workflow, GDPR/CCPA data-subject-request handling, retention configuration options.

   ⚑ flag

   Unleash—none0/10

   The evidence pack covers feature-flag mechanics, deployment, RBAC, and API tokens, but contains no documentation of data retention policies, deletion workflows, or GDPR-style data controls for flags, audit logs, or user data. Self-hosting is mentioned but that alone doesn't constitute a documented retention/deletion control feature.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   LaunchDarkly—none0/10

   No evidence pack item addresses telemetry/usage-tracking opt-out for LaunchDarkly itself; the docs cover flagging, targeting, MCP/CLI tooling, and pricing but nothing about the product's own data collection practices or an opt-out mechanism.

   ⚑ flag

   Unleash—none0/10

   No evidence in the pack addresses telemetry or usage-tracking opt-out settings for Unleash itself (self-hosted or SaaS); nothing documents what data Unleash collects about its own usage or how to disable it. missing for 10: any mention of telemetry collection, opt-out flags/env vars, or privacy documentation regarding usage tracking.

   ⚑ flag

Rollouts

1. platform engineerGuard a rollout with metrics so a regression is detected and the release is rolled back automatically

   weight 2 · round to Unleash
   LaunchDarkly~partialclaimed6/10

   LaunchDarkly's Guarded Rollouts feature explicitly monitors metrics during a progressive rollout and automatically rolls back on regression detection, directly matching the story, and is backed by supporting docs on metrics, progressive rollouts, and change history. However, the evidence pack is entirely first-party docs with no independent/hands-on confirmation that automatic rollback actually triggers correctly in practice, and no detail on metric types supported for regression detection or configuration limits. Missing for 10: independent/hands-on validation of guarded rollout auto-rollback behavior, detail on which metric types/thresholds trigger rollback, and confirmation of reliability at scale.

   • [claimed-docs] “Guarded rollouts”
   • [claimed-docs] “Creating and managing progressive rollouts”
   • [claimed-docs] “Choosing a metric type”
   • [claimed-docs] “Change history”

   proof ↗⚑ flag

   Unleash✓fullclaimed7/10

   Unleash's impact-metrics feature explicitly supports guarding rollouts with metrics, including automatic pause/rollback when error rates or latency cross thresholds (e.g., 'Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold' and 'Pause automatically when request latency increases during a rollout'). This directly matches the story's requirement of metric-guarded rollout with automatic rollback. missing for 10: independent/hands-on verification of the automatic rollback behavior in production, and more detail on how 'rollback' (vs. pause/disable) is technically executed.

   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”
   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”

   proof ↗⚑ flag

2. developerRoll a flag out progressively by percentage with consistent bucketing, ramping from 1% to 100% without redeploying

   weight 3 · round drawn
   LaunchDarkly✓fullcommunity9/10

   LaunchDarkly's core product is percentage-based progressive rollouts with consistent bucketing via context attributes, explicitly documented (progressive rollouts, percentage rollouts, guarded rollouts) and corroborated by community users citing 'custom rollout by % of users or attributes' as a key benefit, all changed instantly without redeploy through the flag dashboard/API. Missing for 10: no independent hands-on verification of bucketing consistency across ramp changes or a documented technical explanation of the hashing algorithm.

   • [claimed-docs] “Creating and managing progressive rollouts”
   • [claimed-docs] “Guarded rollouts”
   • [claimed-docs] “Percentage rollouts”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”

   proof ↗⚑ flag

   Unleash✓fullclaimed9/10

   Unleash's gradual rollout activation strategy is a documented first-class concept, explicitly supporting progressive percentage rollout with consistent bucketing (via stickiness) without redeploying, and impact-metrics docs show automated progression between percentage thresholds (e.g., 25% to 50%) based on health checks. Missing for 10: no independent hands-on evidence of the specific 1%→100% ramp UI/automation flow in practice beyond docs.

   • [claimed-docs] “A **gradual rollout** is a controlled release strategy where a new feature is first released to a small subset of users.”
   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “Progress from 25% to 50% only if error rates stay below a threshold.”
   • [claimed-docs] “Automate milestone progression or trigger safeguards that pause rollouts or disable environments when metrics cross a threshold.”
   • [claimed-docs] “Pause automatically when request latency increases during a rollout.”

   proof ↗⚑ flag

Scheduling

1. developerSchedule flag changes and releases to happen at a specific future time

   weight 1 · round to LaunchDarkly
   LaunchDarkly✓fullclaimed9/10

   LaunchDarkly documents a dedicated 'Scheduled flag changes' feature allowing flag changes to be set to take effect at a future time, alongside related release tooling like progressive/guarded rollouts and change history for tracking scheduled edits. Missing for 10: independent hands-on confirmation or community corroboration of the scheduling workflow specifically (only vendor docs cited).

   • [claimed-docs] “Scheduled flag changes”
   • [claimed-docs] “Creating and managing progressive rollouts”
   • [claimed-docs] “Guarded rollouts”
   • [claimed-docs] “Change history”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash documents a dedicated how-to guide for scheduling feature releases at a specific date/time, framed explicitly for use cases like product launches, and this sits alongside broader release management, gradual rollout, and environment concepts that support scheduled changes. Missing for 10: independent/hands-on corroboration of the scheduling feature working in practice, and detail on granularity/timezone handling or recurring schedules.

   • [claimed-docs] “to release a feature at a specific date and time** (for a product launch, for instance)”
   • [claimed-docs] “to release a feature at a specific date and time (for a product launch, for instance)”
   • [claimed-docs] “Release management in Unleash helps you standardize, automate and safeguard your feature rollouts.”

   proof ↗⚑ flag

Edge

1. platform engineerEvaluate flags at the edge (CDN workers or an edge/relay layer) close to users

   weight 2 · round drawn
   LaunchDarkly✓fullcommunity8/10

   LaunchDarkly documents a dedicated Cloudflare edge SDK (launchdarkly-docs-14) for evaluating flags directly in CDN workers, plus a self-hosted Relay Proxy (launchdarkly-docs-13/32, corroborated by community usage in launchdarkly-comm-2) that lets platform engineers run an edge/relay layer close to users for low-latency evaluation. Missing for 10: independent hands-on benchmarks of edge SDK latency/behavior and broader coverage of other edge platforms beyond Cloudflare.

   • [claimed-docs] “Cloudflare SDK reference”
   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”

   proof ↗⚑ flag

   Unleash✓fullclaimed8/10

   Unleash Edge is a documented purpose-built component (Rust-based caching/relay layer) that sits between SDKs and the primary server, described explicitly as reducing read load and improving scalability/performance/resilience for connected SDKs, functioning as a low-latency edge/relay evaluation layer close to users. This directly matches the story, though evidence doesn't explicitly show deployment as a CDN/edge-worker runtime (e.g., Cloudflare Workers) itself. missing for 10: explicit CDN-worker (e.g., Cloudflare Workers) deployment guide, independent performance/latency benchmarks for Edge in production.

   • [claimed-docs] “functioning as a read replica that can handle thousands of connected SDKs without increasing the read load on your primary Unleash instance”
   • [claimed-docs] “Unleash Enterprise Edge is a lightweight caching layer designed to improve scalability, performance, and resilience.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”

   proof ↗⚑ flag

Evaluation

1. platform engineerMy server SDKs evaluate flags locally from a cached ruleset — microsecond decisions with no network call per flag check

   weight 3 · round to LaunchDarkly
   LaunchDarkly~partialcommunity6/10

   Community evidence confirms LaunchDarkly's core streaming architecture — SDKs download the full flag ruleset once and then stream updates, enabling local evaluation without a per-flag network call (launchdarkly-comm-2, launchdarkly-comm-9), and the Relay Proxy exists specifically to cache rulesets on-prem for resiliency (launchdarkly-docs-13, launchdarkly-docs-32). However there is no first-party SDK doc in this pack explicitly describing the local-evaluation/streaming-store mechanism or microsecond latency claims, and one community comment raises concern about network dependency per request (launchdarkly-comm-6), showing the story is not fully substantiated end-to-end. Missing for 10: dedicated SDK architecture docs describing the in-memory flag store/streaming model, explicit benchmark/latency numbers, and resolution of the community concern about request-time dependency.

   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”
   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “It's a pretty question[able] architecture that outsources feature flags to a third party. You're creating a critical path hard dependency an…”

   proof ↗⚑ flag

   Unleash~partialclaimed3/10

   Evidence shows Unleash SDKs communicate via API keys and that Edge exists as a caching layer to reduce read load from 'thousands of connected SDKs,' implying a poll-and-cache model, but no evidence explicitly describes local, in-process flag evaluation from a cached ruleset or confirms 'no network call per flag check' / microsecond latency. missing for 10: explicit SDK architecture docs describing local evaluation engine, cache refresh intervals, and no-network-per-check guarantee, plus independent benchmarks.

   • [claimed-docs] “functioning as a read replica that can handle thousands of connected SDKs without increasing the read load on your primary Unleash instance”
   • [claimed-docs] “Unleash Enterprise Edge is a lightweight caching layer designed to improve scalability, performance, and resilience.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”

   proof ↗⚑ flag

Sdks

1. developerUse official SDKs across my whole stack — backend, web, and mobile — with consistent flag behavior

   weight 2 · round to LaunchDarkly
   LaunchDarkly✓fullcommunity8/10

   LaunchDarkly documents '30 idiomatic SDKs' across languages/platforms, OpenFeature provider support, edge/Cloudflare SDKs, and a Relay Proxy for consistent flag delivery, and community evidence independently confirms a working mobile client SDK and consistent streaming/flag-download behavior across SDKs. Missing for 10: an explicit enumerated list of backend/web/mobile SDK names in the pack and independent hands-on cross-platform consistency testing (community notes mobile SDK's MAU-based pricing as a practical caveat, not a functional gap).

   • [claimed-docs] “30 idiomatic SDKs”
   • [claimed-docs] “OpenFeature providers”
   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [claimed-docs] “Cloudflare SDK reference”
   • [community] “LaunchDarkly has a mobile client SDK, but they charge by MAU, which would be untenable. So folks tend to write a proxy for the mobile apps t…”
   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”

   proof ↗⚑ flag

   Unleash~partialclaimed5/10

   Docs confirm Unleash's SDK model — distinguishing backend/server SDKs (secret tokens) from client-side SDKs for web/mobile (safe-to-expose frontend tokens) and instruct developers to 'use one of the client or backend SDKs to connect Unleash with your application.' However, the pack never lists concrete SDK names/languages (e.g., specific mobile or web SDKs) or documents consistent flag-evaluation behavior across them. Missing for 10: explicit enumeration of officially supported backend/web/mobile SDKs, evidence of consistent evaluation semantics across SDKs, and independent developer corroboration of cross-stack consistency.

   • [claimed-docs] “use one of the client or backend SDKs to connect Unleash with your application”
   • [claimed-docs] “Frontend tokens are not considered secret and are safe to expose client-side.”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [claimed-docs] “Backend tokens are scoped to one or more projects and a single environment.”

   proof ↗⚑ flag

Standards

1. platform engineerUse the vendor through OpenFeature providers so my flag code isn't locked to one vendor's SDK API

   weight 1 · round to LaunchDarkly
   LaunchDarkly✓fullclaimed8/10

   LaunchDarkly documents official OpenFeature providers (launchdarkly-docs-33) alongside its 30 idiomatic SDKs, letting platform engineers write against the vendor-neutral OpenFeature API instead of a proprietary SDK surface. missing for 10: independent hands-on confirmation of OpenFeature provider behavior/parity across languages and any community discussion validating the OpenFeature integration in practice.

   • [claimed-docs] “OpenFeature providers”
   • [claimed-docs] “30 idiomatic SDKs”

   proof ↗⚑ flag

   Unleash—none0/10

   The evidence pack discusses Unleash's own SDKs, Admin API, Edge, and MCP integration but never mentions OpenFeature or any OpenFeature provider, so there is no evidence supporting vendor-neutral SDK usage via OpenFeature.

   • [claimed-docs] “Create your first feature flag** using the Unleash Admin UI. **Connect Unleash to your application** by integrating an SDK into your codebas…”
   • [claimed-docs] “use one of the client or backend SDKs to connect Unleash with your application”
   • [claimed-docs] “functioning as a read replica that can handle thousands of connected SDKs without increasing the read load on your primary Unleash instance”
   • [claimed-docs] “The Admin API provides comprehensive programmatic access to all Unleash resources.”

   proof ↗⚑ flag

Streaming

1. developerFlag changes propagate to connected SDKs in seconds via streaming or fast polling — a kill switch actually kills

   weight 2 · round to LaunchDarkly
   LaunchDarkly✓fullcommunity7/10

   LaunchDarkly's SDK architecture is documented and independently corroborated as a streaming (SSE) model where clients download all flags then receive real-time updates, with an optional self-hosted Relay Proxy for resiliency — this is the mechanism that lets a flag toggle (kill switch) propagate quickly to connected SDKs. Community commentary explicitly calls out 'centralized feature flag service via SSE with minimal latency' as a key benefit, though some users note occasional API/SDK timeout issues that are latency-adjacent concerns rather than a contradiction of the streaming design. Missing for 10: first-party documentation with explicit propagation-time benchmarks (e.g. 'seconds'), explicit 'kill switch' terminology/case study, and hands-on confirmation of polling fallback speed.

   • [community] “LaunchDarkly clients download all flags in the project on connection, then stream changes. ... LaunchDarkly has an open source 'Relay' you c…”
   • [community] “Key benefits of LaunchDarkly: rules-based targeting so flags can be set at group level, custom rollout by % of users or attributes, centrali…”
   • [claimed-docs] “The LaunchDarkly Relay Proxy is a small Go application that runs on your own infrastructure.”
   • [claimed-docs] “The Relay Proxy”
   • [community] “My logs show frequent timeouts when looking up setting through their API. Their SDK default timeout is 3s. Wouldn't want to wait longer.”

   proof ↗⚑ flag

   Unleash~partialclaimed4/10

   Docs confirm the core mechanic — flags can be enabled/disabled without redeploy (unleash-docs-18) and SDKs/Edge communicate via API keys with Edge scaling to thousands of connected SDKs (unleash-docs-5, unleash-docs-23, unleash-docs-28) — but there is no explicit documentation of streaming vs. polling propagation times, no stated 'seconds' latency figure, and no hands-on/independent test confirming a kill switch instantly disables a live SDK. missing for 10: explicit streaming/polling interval docs, measured propagation latency, independent or hands-on confirmation of kill-switch behavior in production SDKs.

   • [claimed-docs] “They allow you to enable and disable features for certain users without having to redeploy your application.”
   • [claimed-docs] “functioning as a read replica that can handle thousands of connected SDKs without increasing the read load on your primary Unleash instance”
   • [claimed-docs] “Unleash uses API keys to facilitate communication between consuming clients such as SDKs, Unleash Edge, or other tools and automation.”
   • [claimed-docs] “Unleash Enterprise Edge is a lightweight caching layer designed to improve scalability, performance, and resilience.”

   proof ↗⚑ flag