LaunchDarkly vs Statsig

Agent access

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

   weight 2 · round to Statsig
   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

   Statsig✓fullprobed9/10

   Statsig publishes a working llms.txt (probed live, HTTP 200) and offers a dedicated Docs MCP server that lets AI clients read documentation directly, confirmed via a full keyless initialize handshake at /api/mcp. This directly satisfies pointing an agent at agent-oriented docs. Missing for 10: independent third-party confirmation of agents actually using llms.txt in practice beyond the probe.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.statsig.com/llms.txt # Statsig Documentation > Official documentation for Statsig feature flags, e…”
   • [claimed-docs] “Use the Statsig Docs MCP server to let supported AI clients read public Statsig documentation directly from /api/mcp.”
   • [claimed-docs] “Use the Statsig Docs MCP server to let supported AI clients read public Statsig documentation directly from /api/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.statsig.com/api/mcp completed a FULL keyless ini…”

   proof ↗⚑ flag

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

   weight 2 · round to Statsig
   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

   Statsig✓fullprobed8/10

   Statsig ships an official CLI (@statsig/siggy) that runs keylessly and is explicitly documented and probe-verified for CI/CD automation of Feature Gates and Experiments, plus a Console API/HTTP API for headless programmatic control. Runtime probes confirm the CLI executes via npx in a scriptable, non-interactive way suitable for automation pipelines. Missing for 10: no independent third-party CI pipeline case study or deeper docs on CLI command coverage beyond gates/experiments.

   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [probe] “official CLI documented at https://docs.statsig.com/statsigcli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Statsig✓fullprobed9/10

   Statsig ships an official MCP server integrating with agent tools like Codex, Cursor, and Claude Code for querying Statsig data, plus a separate docs MCP server; runtime probes confirm both endpoints are live, with the main MCP server enforcing OAuth and the docs server completing a full handshake. missing for 10: independent third-party (non-vendor) hands-on report of using the MCP server in a real agent workflow beyond docs/probes.

   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup,…”
   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code.”
   • [claimed-docs] “Use the Statsig Docs MCP server to let supported AI clients read public Statsig documentation directly from /api/mcp.”
   • [probe] “official MCP server documented at https://docs.statsig.com/integrations/mcp/overview”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”
   • [probe] “PROBE runtime (recorded 2026-09-05): the documented no-auth docs MCP server at https://docs.statsig.com/api/mcp completed a FULL keyless ini…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   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

   Statsig✓fullprobed9/10

   Statsig ships an official CLI (Statsig CLI / @statsig/siggy) for managing Feature Gates, Experiments, and Dynamic Configs, documented for CI/CD automation, and a runtime probe confirms it executes keylessly via npx and is scriptable. missing for 10: no independent (non-Statsig) hands-on review of the CLI's full feature set beyond the version-check probe.

   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [probe] “official CLI documented at https://docs.statsig.com/statsigcli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”

   proof ↗⚑ flag

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

   weight 3 · round to Statsig
   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

   Statsig✓fullprobed9/10

   Statsig documents multiple public API surfaces (HTTP API for gate/experiment retrieval and event logging, full CRUD Console API, and CLI) that let developers/agents drive the product programmatically, and runtime probes confirm the CLI works keylessly and the MCP servers respond live. missing for 10: a discoverable OpenAPI/Swagger spec (probe found 404s on standard OpenAPI paths), which would give full machine-readable API discoverability.

   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.statsig.com/openapi.json, https://docs.statsig.com/swagger.json, https://docs.statsig.c…”

   proof ↗⚑ flag

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

   weight 2 · round to LaunchDarkly
   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

   Statsig~partialprobed3/10

   Statsig documents general access-management/SSO/SCIM controls and shows its hosted MCP server requires an OAuth bearer token rather than being fully open (statsig-probe-rt-2), implying some authenticated, permissioned access surface an agent could use. However there is no explicit documentation of issuing scoped or least-privilege API keys/tokens specifically for agent use (e.g., read-only or project-scoped Console API keys). Missing for 10: explicit docs on creating scoped/limited-permission API keys, role-based key scoping for agents, and any guidance on least-privilege credential issuance for AI agents.

   • [claimed-docs] “In many enterprise environments, organizations use SSO and SCIM together to improve security and usability.”
   • [claimed-docs] “Basic settings include automatically adding new users with the same email domain to your project. Statsig also supports SSO to simplify invi…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to LaunchDarkly
   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

   Statsig✓fullclaimed7/10

   Statsig's docs explicitly describe SDK architecture (client vs. server evaluation, on-device eval SDKs, deterministic evaluation across platforms) and even offer an HTTP API for cases without an SDK, confirming a first-party SDK ecosystem that AI-native developers can build against. Missing for 10: a concrete list/matrix of supported languages/platforms and independent hands-on confirmation of SDK usage beyond docs.

   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”

   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

   Statsig—none0/10

   The evidence pack contains no mention of webhooks or event subscription mechanisms anywhere in Statsig's docs, community posts, or probes — only feature gates, experiments, CLI, MCP, and access management are covered. Webhooks are a plausible axis for a flagging/analytics platform, so absence of evidence yields none rather than na.

   ⚑ flag

Agentic features

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

   weight 2 · round to Statsig
   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

   Statsig~partialprobed5/10

   Statsig's MCP server explicitly lets AI clients (Claude Code, Cursor, Codex) 'ask questions, explore experiments, and access your Statsig data using AI,' which is a form of AI-generated insight retrieval, and this is confirmed live via a working OAuth-gated MCP endpoint. However this is an external-agent integration rather than a native in-product AI insights/suggestions feature (e.g., no evidence of built-in AI-generated experiment summaries, anomaly explanations, or suggestion widgets inside the Statsig console itself). Missing for 10: native in-app AI-generated insights/copilot UI, evidence of proactive AI suggestions surfaced directly in the console rather than via external MCP client.

   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup,…”
   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”
   • [probe] “official MCP server documented at https://docs.statsig.com/integrations/mcp/overview”

   proof ↗⚑ flag

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

   weight 2 · round to Statsig
   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

   Statsig~partialprobed6/10

   Statsig supports background-running automations like Scheduled Rollouts (gradual gate rollout without manual intervention) and Autotune (autonomously shifts traffic toward winning variants), plus CLI integration into CI/CD pipelines for automated gate/experiment management. These are real autonomous background mechanisms, but they are experimentation/rollout automations rather than general-purpose AI-agent automations, and there's no evidence of scheduling/triggering arbitrary agentic workflows. Missing for 10: evidence of general-purpose scheduled/triggered agent workflows beyond rollout/autotune, and independent verification that these run reliably unattended in production.

   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Unlike a standard A/B test, Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”

   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

   Statsig—none0/10

   Evidence covers Statsig's MCP server, which lets external AI tools (Cursor, Claude Code, Codex) query Statsig data — the opposite direction of an in-product assistant that users delegate tasks to. No evidence of a built-in AI assistant embedded in the Statsig console itself.

   ⚑ flag

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

   weight 2 · round to LaunchDarkly
   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

   Statsig~partialprobed6/10

   Statsig ships a first-party MCP server (verified live via runtime probe) that lets AI clients like Claude Code and Cursor query experiments, gates, and data using natural language, which is the core mechanism for natural-language operation. However, this is an agentic/AI-integration layer bolted onto a console/CLI/API-driven product rather than a native NL command interface across the whole product surface. missing for 10: evidence of natural-language command support within the core Statsig console UI itself (not just via external MCP-connected agents), independent hands-on validation of NL command accuracy/reliability, and coverage of write-actions (creating/modifying gates or experiments) via natural language rather than read-only querying.

   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup,…”
   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code.”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”
   • [probe] “official MCP server documented at https://docs.statsig.com/integrations/mcp/overview”

   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

   Statsig—none0/10

   Statsig documents an HTTP API and Console API but there is no evidence of an interactive API reference with runnable/try-it examples; explicit probes for OpenAPI/Swagger endpoints returned 404s, indicating no such interactive explorer exists.

   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.statsig.com/openapi.json, https://docs.statsig.com/swagger.json, https://docs.statsig.c…”

   proof ↗⚑ 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

   Statsig—none0/10

   Statsig documents a Console API and HTTP API but a direct probe for OpenAPI/swagger specs at common paths (openapi.json, swagger.json, api/openapi.json, .well-known/openapi.json) all returned 404, and no docs reference a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.statsig.com/openapi.json, https://docs.statsig.com/swagger.json, https://docs.statsig.c…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”

   proof ↗⚑ flag

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

   weight 1 · round to LaunchDarkly
   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

   Statsig—none0/10

   The evidence pack documents feature gates, experiments, CLI, and MCP integrations, but nothing describes a distinct sandbox/staging environment or project isolated from production data for testing purposes — only production-oriented tools like emergency disable switches, gate overrides, and scheduled rollouts are mentioned. This is a fair question for a feature-flag/experimentation platform, but no evidence confirms a sandbox capability exists.

   • [claimed-docs] “Feature Gates, commonly known as feature flags, allow you to toggle the behavior of your product in real time without deploying new code.”
   • [claimed-docs] “Have an emergency disable switch that lets you immediately turn off a particular code branch for users in production”
   • [claimed-docs] “After your Feature Gate is live, view Feature Gate exposures in the Statsig console to monitor who encounters your gate.”
   • [claimed-docs] “set up Feature Gate overrides to allow specific users to bypass the gate.”
   • [claimed-docs] “Basic settings include automatically adding new users with the same email domain to your project. Statsig also supports SSO to simplify invi…”

   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

   Statsig—none0/10

   Statsig documents an HTTP API and Console API but the evidence pack contains no mention of API versioning scheme or a documented deprecation policy; a probe for OpenAPI spec files (which would typically reveal version info) returned 404s across all candidate paths.

   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.statsig.com/openapi.json, https://docs.statsig.com/swagger.json, https://docs.statsig.c…”

   proof ↗⚑ flag

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

   weight 2 · round to Statsig
   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

   Statsig~partialprobed6/10

   Statsig's Console API provides a CRUD API for managing gates, experiments, and configs programmatically, and the CLI (confirmed runnable via npx) can be scripted/integrated into CI/CD, enabling automation across many items rather than one-by-one UI clicks. However, no evidence explicitly documents a bulk/batch endpoint or bulk-edit feature, so bulk operations must be assembled by looping API/CLI calls rather than a native bulk primitive; missing for 10: explicit bulk/batch API endpoints, documented multi-item transactional updates, and independent confirmation of large-scale automation use.

   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”

   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

   Statsig~partialclaimed4/10

   Statsig supports rule-based automation such as targeting rules on Feature Gates, Scheduled Rollouts, and Autotune (which automatically shifts traffic toward a winning variant based on live metrics) — these are forms of automatic rule-triggered behavior, but they are evaluation/targeting rules and traffic-shift algorithms rather than a general 'on event X, trigger action Y' automation engine. Missing for 10: documented event-triggered workflow/webhook automation (e.g., alert-to-action pipelines), explicit event-based trigger definitions distinct from targeting/eval rules, and independent hands-on evidence of such automation working end-to-end.

   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Unlike a standard A/B test, Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “Schedule gradual feature rollouts to safely deploy new code”
   • [claimed-docs] “Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “set up Feature Gate overrides to allow specific users to bypass the gate.”
   • [claimed-docs] “Infra Analytics: Monitor and debug service health alongside product outcomes. Ingest metrics and traces with OpenTelemetry, search and group…”

   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

   Statsig—none0/10

   Statsig only documents one-time 'Scheduled Rollouts' for feature gates and CLI/CI-CD scripting of flag management (statsig-docs-3, statsig-docs-25, statsig-docs-31); there is no evidence of a recurring job/workflow scheduler (e.g., cron-like recurring automation) that an AI-native user could set up. missing for 10: any documented recurring/cron-style job scheduling, workflow orchestration, or automated recurring task execution beyond a single scheduled feature rollout.

   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Schedule gradual feature rollouts to safely deploy new code”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”

   proof ↗⚑ flag

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

   weight 1 · round to LaunchDarkly
   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

   Statsig~partialclaimed4/10

   Statsig's feature gates support rollback-like controls (emergency disable switch, scheduled rollouts) and CLI/Console API can be scripted into CI/CD for programmatic management, implying some versioned control over flag state, but the evidence never documents an explicit audit/version history, diffing, or approval-review workflow for these 'automations'. missing for 10: explicit version history/audit log for gate or experiment changes, a review/approval workflow before changes go live, and a documented one-click rollback to a prior version (only an on/off disable switch is shown).

   • [claimed-docs] “Have an emergency disable switch that lets you immediately turn off a particular code branch for users in production”
   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “After your Feature Gate is live, view Feature Gate exposures in the Statsig console to monitor who encounters your gate.”

   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 to LaunchDarkly
   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

   Statsig—none0/10

   No evidence in the pack describes a self-hostable relay/edge proxy for offline or in-network flag serving; documentation covers SDKs, HTTP API, CLI, and MCP but nothing about a proxy component that caches flags locally when Statsig's servers are unreachable.

   ⚑ 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 drawn
   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

   Statsig—none0/10

   No evidence in the pack mentions an open-source self-hosted distribution of the full Statsig platform; all material describes the hosted SaaS console, SDKs, CLI, and MCP integrations that connect to Statsig's cloud API. Absence of evidence for this applicable axis means it is not delivered.

   ⚑ flag

Agent ops

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

   weight 1 · round to Statsig
   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

   Statsig✓fullprobed8/10

   Statsig provides a Console API (CRUD for experiments/gates), an HTTP API for retrieving experiment/gate values, a CLI scriptable in CI, and an official MCP server explicitly documented to let AI tools like Claude Code/Cursor/Codex 'ask questions, explore experiments, and access your Statsig data' — directly enabling an AI agent to programmatically read experiment configs/results. Runtime probes confirm the MCP server and CLI are live and reachable. Missing for 10: explicit documented example of an agent using these APIs to produce a ship/rollback recommendation (only general data-access capability is evidenced, not the recommendation workflow itself).

   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup,…”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”

   proof ↗⚑ flag

Analysis

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

   weight 2 · round drawn
   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

   Statsig~partialcommunity6/10

   Statsig documents a full experimentation suite with variance-reduction techniques (CUPED, stratified sampling, switchback tests) and hypothesis/metric scorecards, and community sentiment praises its 'stat rigor,' but the evidence never names or details whether the underlying engine is Bayesian, frequentist, or a documented hybrid methodology. missing for 10: explicit documentation of the statistical model (Bayesian vs frequentist), confidence-interval/p-value methodology details, and independent validation of statistical correctness beyond anecdotal praise.

   • [claimed-docs] “Statsig offers a full suite of experiment measurement tools, including CUPED, Stratified Sampling, Switchback Tests, and more.”
   • [claimed-docs] “The Scorecard feature makes this easy by letting you enter your hypothesis and select both primary and secondary metrics.”
   • [claimed-docs] “Statsig Warehouse Native is an experimentation platform that runs analysis directly in your data warehouse.”
   • [community] “Hats off to Statsig. They built a stellar product. Superior to many of their industry competitors like Optimizely. Back when I was on an int…”

   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 Statsig
   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

   Statsig✓fullcommunity9/10

   Statsig's docs directly describe running A/B/n and multivariate experiments with primary/secondary metrics via the Scorecard, plus Layers for managing multiple experiments and Autotune for identifying/shifting toward winning variants, and community feedback corroborates its statistical rigor versus competitors. Missing for 10: independent hands-on validation of the results/analysis UI itself (e.g., screenshots or third-party review of the 'winning variation' scorecard output) rather than only docs.

   • [claimed-docs] “Statsig experimentation runs randomized controlled trials (A/B or A/B/n tests) that measure how product changes affect your key metrics.”
   • [claimed-docs] “The Scorecard feature makes this easy by letting you enter your hypothesis and select both primary and secondary metrics.”
   • [claimed-docs] “Unlike a standard A/B test, Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “Autotune shifts traffic toward the winning variant to maximize a target metric.”
   • [claimed-docs] “A Layer allows you to manage multiple experiments and feature flags together.”
   • [community] “Hats off to Statsig. They built a stellar product. Superior to many of their industry competitors like Optimizely. Back when I was on an int…”
   • [community] “Have implemented Statsig in two companies as alternatives to LaunchDarkly and loved it both times. Going to be interesting how their other b…”

   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 to Statsig
   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

   Statsig✓fullclaimed7/10

   Statsig Warehouse Native explicitly runs experiment analysis directly on the customer's own data warehouse rather than a black-box metric store, and Statsig's core event-ingestion pipeline lets PMs define metrics from ingested events with a full analysis toolkit (CUPED, stratified sampling, switchback tests). missing for 10: independent/hands-on corroboration of Warehouse Native in production and detail on the custom-metric-definition UI/workflow itself.

   • [claimed-docs] “Statsig Warehouse Native is an experimentation platform that runs analysis directly in your data warehouse.”
   • [claimed-docs] “Statsig offers a full suite of experiment measurement tools, including CUPED, Stratified Sampling, Switchback Tests, and more.”
   • [claimed-docs] “Statsig experimentation runs randomized controlled trials (A/B or A/B/n tests) that measure how product changes affect your key metrics.”
   • [claimed-docs] “Experiments enable you to run randomized controlled trials (A/B or A/B/n tests) to measure the impact of product changes on key metrics.”

   proof ↗⚑ flag

Environments

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

   weight 2 · round to LaunchDarkly
   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

   Statsig—none0/10

   The evidence pack covers feature gates, experiments, CLI, console API, and access management, but nowhere mentions environment tags (dev/staging/prod) or environment-scoped SDK keys — a core Statsig platform capability that isn't documented here. Missing for 10: explicit environment/project configuration docs, environment-scoped SDK key generation, and any mention of promoting flag state across environments.

   ⚑ flag

Flags

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

   weight 3 · round to Statsig
   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

   Statsig✓fullcommunity8/10

   Docs provide a first-feature tutorial creating a gate, targeting users, and checking it live via SDK within a browser console (statsig-docs-24), plus a free-tier signup with feature flags included (statsig-docs-17), console-based exposure monitoring and overrides (statsig-docs-19, statsig-docs-29), and community praise confirming Statsig ships fast, developer-friendly tooling (statsig-comm-1, statsig-comm-2). Missing for 10: independent hands-on account of actual time-to-first-flag from signup and no third-party benchmark of onboarding speed.

   • [claimed-docs] “This tutorial creates a feature gate, targets mobile platforms and internal testers, then checks it live with the JavaScript SDK in your bro…”
   • [claimed-docs] “You get feature flags and 2 million metered events for free.”
   • [claimed-docs] “After your Feature Gate is live, view Feature Gate exposures in the Statsig console to monitor who encounters your gate.”
   • [claimed-docs] “set up Feature Gate overrides to allow specific users to bypass the gate.”
   • [community] “Hats off to Statsig. They built a stellar product. Superior to many of their industry competitors like Optimizely. Back when I was on an int…”
   • [community] “Have implemented Statsig in two companies as alternatives to LaunchDarkly and loved it both times. Going to be interesting how their other b…”

   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

   Statsig~partialclaimed6/10

   Statsig docs reference Dynamic Configs alongside Feature Gates and Experiments (e.g., statsig-docs-9, statsig-docs-10, statsig-docs-11, statsig-docs-31 mention 'Dynamic Configs' as a managed entity distinct from booleans), and experiments/layers imply multivariate parameter delivery (statsig-docs-4, statsig-docs-26, statsig-docs-30). However, no evidence explicitly confirms support for strings/numbers/JSON value types or shows a dynamic config JSON payload example. missing for 10: explicit documentation or example showing dynamic config value types (string/number/JSON), SDK code sample retrieving a non-boolean config value.

   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [claimed-docs] “A Layer allows you to manage multiple experiments and feature flags together.”
   • [claimed-docs] “Statsig experimentation runs randomized controlled trials (A/B or A/B/n tests) that measure how product changes affect your key metrics.”

   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

   Statsig—none0/10

   The evidence pack covers feature gates, experiments, rollout scheduling, overrides, CLI, and MCP integrations, but nothing documents stale-flag detection, flag usage/code-reference scanning, or cleanup workflows. This is a reasonable axis for a feature-flag platform, but no capability is evidenced.

   ⚑ flag

Targeting

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

   weight 1 · round drawn
   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

   Statsig✓fullclaimed8/10

   Docs explicitly cover overrides for targeting/excluding specific users and a guided tutorial that targets internal testers/mobile platforms, directly matching the allowlist/beta-tester/internal-account use case. missing for 10: no independent hands-on confirmation of override UI behavior beyond first-party docs.

   • [claimed-docs] “set up Feature Gate overrides to allow specific users to bypass the gate.”
   • [claimed-docs] “This tutorial creates a feature gate, targets mobile platforms and internal testers, then checks it live with the JavaScript SDK in your bro…”
   • [claimed-docs] “After your Feature Gate is live, view Feature Gate exposures in the Statsig console to monitor who encounters your gate.”

   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

   Statsig~partialclaimed5/10

   Docs confirm Feature Gates support attribute-based targeting (e.g., targeting mobile platforms and internal testers) and per-user overrides, indicating rule-based flag targeting is supported. However, the evidence pack never mentions a dedicated 'segments' or reusable audience-list feature, so reusable, cross-flag targeting groups are unevidenced. missing for 10: explicit documentation of reusable segment/audience definitions, evidence of segment reuse across multiple flags/experiments, and independent/hands-on confirmation of complex rule builders.

   • [claimed-docs] “This tutorial creates a feature gate, targets mobile platforms and internal testers, then checks it live with the JavaScript SDK in your bro…”
   • [claimed-docs] “set up Feature Gate overrides to allow specific users to bypass the gate.”
   • [claimed-docs] “Feature Gates, commonly known as feature flags, allow you to toggle the behavior of your product in real time without deploying new code.”

   proof ↗⚑ flag

Access

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

   weight 2 · round to LaunchDarkly
   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

   Statsig~partialclaimed4/10

   Statsig docs reference enterprise access management with SSO/SCIM and a Console API for programmatic control, implying some access-control layer exists, but no evidence details role definitions, granular permissions, or scoped/limited API tokens for restricting who can change specific flags. Missing for 10: explicit RBAC documentation, permission granularity for flag edits, and scoped/read-vs-write API token support.

   • [claimed-docs] “In many enterprise environments, organizations use SSO and SCIM together to improve security and usability.”
   • [claimed-docs] “Basic settings include automatically adding new users with the same email domain to your project. Statsig also supports SSO to simplify invi…”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”

   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

   Statsig~partialprobed4/10

   Statsig documents multiple agent-friendly interfaces for creating/toggling flags — a CLI (also usable in CI/CD), a Console CRUD API, and an official MCP server reachable via OAuth — giving strong coverage of the 'documented APIs, CLIs, or MCP' half of the story. However, there is no evidence of an approval/review workflow that intercepts or blocks agent-initiated changes before they hit production; access-management docs mention SSO/SCIM for identity but not change-approval gating. Missing for 10: documented approval-workflow/change-review gating for flag mutations, evidence that CLI/API/MCP writes can be routed through a review step rather than applied directly.

   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “The Statsig MCP (Model Context Protocol) server brings the power of Statsig into tools like Codex, Cursor, and Claude Code. With this setup,…”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”
   • [probe] “PROBE runtime (recorded 2026-09-05): keyless JSON-RPC initialize POST to the hosted MCP server https://api.statsig.com/v1/mcp returned HTTP …”
   • [claimed-docs] “In many enterprise environments, organizations use SSO and SCIM together to improve security and usability.”

   proof ↗⚑ flag

Approvals

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

   weight 3 · round to LaunchDarkly
   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

   Statsig—none0/10

   No evidence describes an approval workflow, change request, or review gate before flag changes go live in production; docs mention scheduled rollouts, overrides, and audit-adjacent features like exposure logging but not a governance approval mechanism.

   ⚑ 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

   Statsig—none0/10

   The evidence pack covers feature gates, experiments, SSO/SCIM, CLI, Console API, and MCP integrations, but nowhere mentions an audit log or change history capturing who changed a flag, when, or to what value. This is a standard governance capability for feature-flag platforms, so its complete absence from the docs pack means the axis applies but is unsupported.

   ⚑ flag

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

   weight 2 · round to Statsig
   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

   Statsig✓fullprobed8/10

   Statsig documents a full Console API that is explicitly the CRUD API for 'performing the actions available on console.statsig.com without using the web UI,' plus a separate HTTP API for gate/experiment evaluation and event logging, and an official CLI wrapping these for CI/CD scripting — together covering feature gates, experiments, dynamic configs, and access management via API/CLI rather than only the UI. MCP servers and CLI were confirmed live/reachable in runtime probes, reinforcing that programmatic parity is real and operational, not just documented aspiration. Missing for 10: no independent third-party audit confirming 1:1 UI/API feature parity (e.g., some newer UI features like Autotune or Warehouse Native scorecards aren't explicitly confirmed as API-exposed), and no public OpenAPI spec was found (404s on standard paths).

   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “Overview of the Statsig HTTP API for retrieving feature gate, experiment, and dynamic config values and logging events directly without an S…”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”
   • [probe] “PROBE runtime (recorded 2026-09-05): the official Statsig CLI (npm @statsig/siggy) ran keylessly via `npx -y @statsig/siggy --version`, prin…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.statsig.com/openapi.json, https://docs.statsig.com/swagger.json, https://docs.statsig.c…”

   proof ↗⚑ flag

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

   weight 3 · round to Statsig
   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

   Statsig~partialclaimed4/10

   Statsig provides a Console API and CLI for programmatic access to configuration data (feature gates, experiments, dynamic configs), which supports exporting configuration/setup data in a scriptable way, but there is no evidence of a bulk data export feature for user-level event/analytics data in open/standard formats, nor documentation of data portability or account deletion/export workflows for users wanting to leave the platform. missing for 10: documented bulk export of analytics/event data in open formats (CSV/JSON/Parquet), explicit data portability or 'leave the platform' export tooling, evidence of exporting experiment results/metrics data, and any community confirmation of successful full data export.

   • [claimed-docs] “The Console API is the CRUD API for performing the actions available on console.statsig.com without using the web UI.”
   • [claimed-docs] “The Statsig CLI is a command-line interface that helps manage Feature Gates, Experiments, and Dynamic Configs within the Statsig platform.”
   • [claimed-docs] “You can integrate the CLI into CI/CD pipelines to automate the management of Feature Gates and Experiments.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Statsig—none0/10

   No evidence in the pack indicates Statsig's core platform or source code is released under an open license; only docs, CLI, MCP servers, and SaaS features are mentioned, none of which speak to open-source licensing of the product's source.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   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

   Statsig—none0/10

   No evidence anywhere in the pack mentions self-hosting or an on-prem/open-source deployment of the core Statsig platform; all documentation describes a hosted SaaS console, hosted MCP/API endpoints, and cloud-based warehouse-native analysis. Self-hosting is a fair ask for this category (competitors offer it), so absence of evidence means 'none' rather than 'na'.

   ⚑ 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

   Statsig~partialclaimed3/10

   Docs mention a free tier tied to 'events' as a metered unit, giving a partial glimpse of cost drivers, but there is no evidence of a full published pricing page detailing seats, MAUs, or request-based costs across paid tiers. missing for 10: published pricing tiers/page, seat-based pricing, MAU-based pricing, request-based pricing, enterprise pricing details.

   • [claimed-docs] “You get feature flags and 2 million metered events for free.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Statsig—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data controls for Statsig's platform; the documentation excerpts cover feature flags, experiments, MCP, CLI, and access management but never address where data is stored or user choice of region.

   ⚑ 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

   Statsig—none0/10

   The evidence pack covers feature flags, experimentation, MCP integrations, and access management (SSO/SCIM), but contains no mention of data retention policies, deletion controls, or GDPR/CCPA-style data lifecycle management. This is a fair axis for a SaaS analytics/experimentation platform handling user event data, so absence of evidence yields 'none' rather than 'na'.

   ⚑ 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

   Statsig—none0/10

   No evidence in the pack addresses whether Statsig's own tools (CLI, SDKs, MCP server, docs site) collect telemetry/usage data or provide an opt-out mechanism; the pack only covers Statsig's core flagging/experimentation features, not its own instrumentation privacy controls.

   ⚑ 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 LaunchDarkly
   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

   Statsig~partialclaimed5/10

   Statsig supports gradual/scheduled rollouts, feature-gate emergency kill switches, and metric-based experimentation with alerting for regressions (Infra Analytics 'set alerts to catch regressions'), giving the pieces needed to guard a rollout with metrics. However, none of the evidence shows an automated rollback action triggered by a detected metric regression — alerts and kill switches appear to require manual intervention rather than an automatic release rollback loop. Missing for 10: documented automatic rollback/kill-switch triggered by metric threshold breach, closed-loop guardrail-to-rollback automation, and independent confirmation this works in production.

   • [claimed-docs] “Have an emergency disable switch that lets you immediately turn off a particular code branch for users in production”
   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Infra Analytics: Monitor and debug service health alongside product outcomes. Ingest metrics and traces with OpenTelemetry, search and group…”
   • [claimed-docs] “Monitor and debug service health alongside product outcomes. Ingest metrics and traces with OpenTelemetry, search and group logs, and set al…”
   • [claimed-docs] “Schedule gradual feature rollouts to safely deploy new code”
   • [claimed-docs] “The Scorecard feature makes this easy by letting you enter your hypothesis and select both primary and secondary metrics.”

   proof ↗⚑ flag

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

   weight 3 · round to LaunchDarkly
   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

   Statsig✓fullclaimed8/10

   Statsig docs explicitly describe scheduled/gradual rollouts to safely deploy new code without redeploying, and deterministic evaluation ensures consistent bucketing across evaluations for the same user given the same gate state. Percentage-based ramping (1%→100%) is a core documented Feature Gate/Scheduled Rollout capability, backed by consistent hashing via deterministic evaluation. missing for 10: explicit mention of percentage granularity/UI slider mechanics and independent hands-on confirmation of ramp behavior.

   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Schedule gradual feature rollouts to safely deploy new code”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Feature Gates, commonly known as feature flags, allow you to toggle the behavior of your product in real time without deploying new code.”

   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

   Statsig~partialclaimed6/10

   Docs confirm Statsig supports 'Scheduled Rollout' for Feature Gates, letting you gradually deploy a feature over time rather than instantly ('Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout', 'Schedule gradual feature rollouts to safely deploy new code'), which implies future-time scheduling of flag state changes. However, the pack lacks detail on setting an exact future timestamp for a release event, calendar/date-picker UI specifics, or independent confirmation of this exact workflow. Missing for 10: explicit documentation of specifying an exact date/time for a rollout step, screenshots or hands-on walkthrough, and third-party confirmation that scheduled changes fire reliably.

   • [claimed-docs] “Gradually deploy a feature over time by setting up a Feature Gate as a Scheduled Rollout.”
   • [claimed-docs] “Schedule gradual feature rollouts to safely deploy new code”

   proof ↗⚑ flag

Edge

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

   weight 2 · round to LaunchDarkly
   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

   Statsig—none0/10

   The evidence pack covers Statsig's feature gates, on-device eval SDKs for client-side, server SDKs, and CLI/API surfaces, but nothing addresses evaluating flags specifically at CDN/edge workers or an edge/relay layer close to users. Missing for 10: any mention of Cloudflare Workers, edge runtime SDKs, or a proxy/relay layer for edge evaluation.

   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”

   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

   Statsig~partialclaimed5/10

   Docs confirm deterministic evaluation 'even across different platforms (client or server)' implying server SDKs replicate rule logic locally, and explicitly describe on-device eval SDKs keeping definitions in memory for fast evaluation — but this on-device architecture is documented only for client SDKs, not explicitly server SDKs. Missing for 10: explicit server-SDK docs on background polling/streaming to a local cache, no-network-call guarantee per check, and microsecond-latency benchmarks specific to server SDKs.

   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”

   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

   Statsig~partialclaimed5/10

   Statsig documents deterministic evaluation guaranteeing identical results 'across different platforms (client or server)' and offers On-Device Eval client SDKs plus a JS SDK tutorial that also targets mobile platforms, implying a consistent cross-stack SDK model. However, the pack never enumerates specific backend/web/mobile SDK names or shows hands-on parity testing across a real multi-platform stack. Missing for 10: an explicit list of officially supported language/platform SDKs, and independent/hands-on evidence confirming identical flag behavior when used together across backend, web, and mobile in a real project.

   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”
   • [claimed-docs] “This tutorial creates a feature gate, targets mobile platforms and internal testers, then checks it live with the JavaScript SDK in your bro…”

   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

   Statsig—none0/10

   No evidence pack item mentions OpenFeature or a provider implementation for it; all SDK references are to Statsig's own proprietary SDKs, CLI, HTTP API, and Console API. This is a fair axis for a feature-flag/experimentation platform, so absence of evidence yields 'none'.

   ⚑ 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

   Statsig~partialclaimed7/10

   Statsig's docs explicitly describe real-time toggling and an 'emergency disable switch' to immediately turn off a code branch in production, plus deterministic evaluation and on-device SDKs for fast client updates — directly supporting the kill-switch and fast-propagation story. However, there is no explicit documentation of streaming vs polling mechanics, propagation latency in seconds, or independent/hands-on verification of SDK update speed. Missing for 10: documented streaming/polling interval specifics, third-party benchmark or hands-on confirmation of sub-second/seconds-level propagation.

   • [claimed-docs] “Feature Gates, commonly known as feature flags, allow you to toggle the behavior of your product in real time without deploying new code.”
   • [claimed-docs] “Have an emergency disable switch that lets you immediately turn off a particular code branch for users in production”
   • [claimed-docs] “Evaluation in Statsig is deterministic. Given the same user object and the same state of the experiment or feature gate, Statsig always retu…”
   • [claimed-docs] “Statsig's client-side On-Device Eval SDKs provide an alternate client-side architecture. The device keeps the definition of each experiment …”

   proof ↗⚑ flag