Feature Flag Platform Comparison Prompt Template

This prompt is for product engineering teams that need to move from a spreadsheet of opinions to a structured, evidence-based comparison of feature flag platforms like LaunchDarkly, Flagsmith, Unleash, and Split. The primary job-to-be-done is generating a decision matrix that normalizes vendor claims into comparable fields—targeting rules, SDK coverage, experimentation support, latency impact, and kill-switch reliability—so that an engineering lead can make a confident recommendation without manually reconciling every vendor's documentation.

The ideal user is a technical decision-maker or staff engineer who has already gathered raw documentation, pricing pages, and architectural notes for each platform. They must provide a detailed [CONTEXT] block containing these source materials, along with a [CONSTRAINTS] block specifying non-negotiable requirements like self-hosting, a specific cloud region, or a latency budget. Do not use this prompt when you lack primary source material; asking the model to generate a comparison from its own training data will produce a confident-looking but unverifiable matrix that should not be used for procurement decisions.

This prompt is also inappropriate for evaluating a single platform in isolation—use a vendor due diligence prompt for that. It is not designed for real-time feature flag evaluation during an incident, nor for comparing platforms on purely financial dimensions without technical trade-offs. The output is a structured JSON matrix meant for human review and architectural decision records, not for automated gating of a CI/CD pipeline. Before using the output, you must validate that every claim in the matrix is grounded in the provided [CONTEXT] and flag any gaps where a vendor's documentation was silent on a critical dimension.

This template is designed to produce a consistent, structured decision matrix comparing feature flag platforms. It forces the model to evaluate each platform across a fixed set of dimensions critical to product engineering teams, such as targeting rules, SDK coverage, and experimentation support. The output is a JSON object containing a comparison_matrix array and an evaluation_notes object, making it directly ingestible by downstream tooling or a human review dashboard. Use this template as the core instruction set for a single model call, or as the system prompt for a comparison agent.

textCopy
You are a technical analyst evaluating feature flag platforms for a product engineering team.
Your task is to compare the following platforms: [PLATFORM_LIST].

For each platform, evaluate the following dimensions using only the provided context. If information for a dimension is not available in the context, mark the field as null and set the `evidence_quality` for that field to 'unavailable'.

Dimensions to evaluate:
- targeting_rules: Describe the flexibility and granularity of user targeting (e.g., percentage rollouts, user attributes, rule-based targeting).
- sdk_coverage: List the officially supported server-side and client-side SDKs.
- experimentation_support: Describe A/B testing and experimentation capabilities, including statistical analysis and metrics integration.
- latency_impact: Describe the architecture's impact on application latency (e.g., local evaluation, streaming updates, polling).
- kill_switch_reliability: Describe the mechanism and guarantees for instantly disabling a feature.
- integration_depth: Note integrations with common tools like Slack, Datadog, Jira, and CI/CD pipelines.

[CONTEXT]

You must output a single valid JSON object conforming to the following schema:
{
  "comparison_matrix": [
    {
      "platform_name": "string",
      "targeting_rules": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      },
      "sdk_coverage": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      },
      "experimentation_support": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      },
      "latency_impact": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      },
      "kill_switch_reliability": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      },
      "integration_depth": {
        "summary": "string | null",
        "evidence_quality": "high | medium | low | unavailable"
      }
    }
  ],
  "evaluation_notes": {
    "overall_confidence": "high | medium | low",
    "missing_information_risks": ["string"],
    "recommended_next_steps": ["string"]
  }
}

[CONSTRAINTS]
- Do not invent features or capabilities not present in the provided context.
- If the context contains conflicting information, note the conflict in the `summary` and set `evidence_quality` to 'low'.
- The `evidence_quality` field must reflect the specificity and source reliability of the context, not your general knowledge.

To adapt this template, replace the [PLATFORM_LIST] placeholder with a comma-separated list of the platforms you are evaluating, such as LaunchDarkly, Flagsmith, Unleash, Split. The [CONTEXT] placeholder should be populated with the raw text from documentation, vendor pages, or internal research notes. For a production implementation, consider injecting this context via a RAG pipeline. The [CONSTRAINTS] section is critical for high-stakes decisions; it forces the model to ground its output in evidence and flag uncertainty, which is essential for a human reviewer to trust the matrix. Before deploying, test the prompt with a golden dataset where you know the expected evidence_quality scores to ensure the model correctly identifies missing or conflicting information.

This prompt is designed to be called from an application layer that manages the full lifecycle: input assembly, model invocation, output validation, and result presentation. The prompt itself is a template, but the harness around it determines whether the output is trustworthy enough to drive a platform selection decision. The application should treat the prompt as one step in a pipeline, not a standalone oracle. Before calling the model, assemble the [PLATFORM_LIST], [EVALUATION_CRITERIA], and [CONTEXT] variables from a structured source of truth—such as internal requirements documents, vendor documentation, or a feature flag evaluation rubric—to prevent hallucinated platform names or criteria.

After receiving the model response, run a strict JSON Schema validator against the expected output structure. The schema should enforce that every platform object contains all required fields (platform_name, targeting_rules, sdk_coverage, experimentation_support, latency_impact, kill_switch_reliability), that sdk_coverage is an array of strings, and that latency_impact is an object with estimated_ms (number) and confidence (enum of low, medium, high). If validation fails, implement a retry loop with a maximum of two additional attempts, appending the specific validation errors to the [CONSTRAINTS] field in the retry prompt. Log every validation failure and retry attempt to your observability platform for later analysis of prompt brittleness. For high-stakes decisions where the comparison will influence a purchasing or architectural commitment, route the final validated output to a human review queue. The reviewer should confirm that each platform's capabilities are accurately represented against the provided [CONTEXT] and flag any unsupported claims before the matrix is used in a decision document.

Model choice matters for this workflow. Use a model with strong JSON mode or structured output support (such as GPT-4o with response_format or Claude 3.5 Sonnet with tool use configured for structured output) to minimize format drift. Avoid models that struggle with consistent enum adherence, as fields like kill_switch_reliability require exact values. If you are comparing more than five platforms, consider splitting the prompt into multiple calls—one per platform—and merging the results in the application layer to avoid context-window truncation that drops fields from later platforms. Finally, store every successful output with a hash of the input variables and a timestamp. This creates an audit trail that lets you trace any future decision back to the exact prompt, context, and model version that produced it.