Open-Source vs Proprietary Decision Prompt Template

This prompt template is designed for engineering leaders, CTOs, and technical architects who need a structured, evidence-based comparison between an open-source solution and a proprietary alternative. The core job-to-be-done is generating a decision-support artifact that moves beyond subjective preference and into a rigorous analysis of licensing, total cost of ownership, community health, and vendor lock-in risk. It is not a generic 'pros and cons' list generator; it forces the model to produce a schema-compliant JSON matrix with explicit evidence citations for each dimension, making it suitable for architecture decision records (ADRs) or formal build-vs-buy evaluations.

Use this prompt when you have already identified a specific open-source candidate and a specific proprietary competitor, and you possess sufficient context about your organization's non-functional requirements (e.g., compliance needs, support SLAs, internal skill sets). The template requires you to supply [OPEN_SOURCE_OPTION], [PROPRIETARY_OPTION], and [ORGANIZATIONAL_CONTEXT] as inputs. The output is a structured JSON object containing a trade-off matrix, a weighted scoring section, and a risk register. This format is designed for direct ingestion into downstream tools or dashboards, not just for human reading. The prompt includes built-in instructions for the model to flag missing evidence and abstain from scoring dimensions where data is insufficient.

Do not use this prompt for comparing more than two options simultaneously, for evaluating internal tools against each other, or for decisions where the primary factor is purely personal preference or aesthetic. It is also inappropriate for early-stage exploration where the options are not yet concretely defined. If your decision hinges on real-time performance benchmarks that you cannot provide as [CONTEXT], a prompt alone will be insufficient; you will need to integrate a retrieval-augmented generation (RAG) step to supply current benchmark data. After running this prompt, your next step should be to validate the generated JSON against the provided schema, manually review the 'evidence_quality' scores, and use the output as a draft for a human-led final decision, not as the final decision itself.

This section provides the core prompt template you will adapt and integrate into your application. The template is designed to produce a structured JSON output that compares an open-source option against a proprietary alternative across consistent dimensions: licensing, total cost of ownership, support, community health, vendor lock-in risk, and security posture. Use this template as the foundation for your decision-support workflow, replacing the square-bracket placeholders with concrete inputs before each run. The prompt enforces a strict output schema, requires evidence grounding for claims, and includes explicit checks for balanced coverage—preventing the model from defaulting to either an open-source or proprietary bias without justification.

textCopy
You are a technical decision-support analyst. Your task is to generate a structured trade-off analysis comparing an open-source solution against a proprietary alternative.

## Input
- Open-Source Option: [OPEN_SOURCE_NAME]
- Proprietary Option: [PROPRIETARY_NAME]
- Evaluation Context: [CONTEXT] (e.g., 'early-stage startup with 5 engineers', 'regulated enterprise with 2000 employees')
- Constraints: [CONSTRAINTS] (e.g., 'must be SOC2 compliant', 'budget under $50k/year')
- Risk Level: [RISK_LEVEL] (choose: low, medium, high, critical)

## Output Schema
Return ONLY a valid JSON object with the following structure. Do not include any text outside the JSON object.

{
  "analysis_id": "string",
  "timestamp": "ISO8601",
  "context": "string (repeated from input)",
  "dimensions": [
    {
      "name": "string (e.g., Licensing, Total Cost, Support, Community Health, Vendor Lock-in, Security)",
      "open_source_assessment": {
        "rating": "string (enum: Strong Advantage, Slight Advantage, Neutral, Slight Disadvantage, Strong Disadvantage)",
        "summary": "string (2-3 sentence evidence-backed assessment)",
        "evidence": ["string (specific fact, link, or metric)"],
        "confidence": "string (enum: high, medium, low)"
      },
      "proprietary_assessment": {
        "rating": "string (enum: Strong Advantage, Slight Advantage, Neutral, Slight Disadvantage, Strong Disadvantage)",
        "summary": "string (2-3 sentence evidence-backed assessment)",
        "evidence": ["string (specific fact, link, or metric)"],
        "confidence": "string (enum: high, medium, low)"
      },
      "trade_off_note": "string (explain the key tension or synergy in this dimension)"
    }
  ],
  "recommendation": {
    "preferred_option": "string (enum: open_source, proprietary, conditional, insufficient_data)",
    "rationale": "string (synthesize the trade-offs, referencing the evaluation context)",
    "deal_breakers": ["string (any dimension where one option is unacceptable given constraints)"],
    "risk_mitigation": ["string (actions to reduce risk for the preferred option)"]
  },
  "limitations": ["string (what this analysis could not determine, missing data, or assumptions made)"]
}

## Instructions
1. Evaluate each dimension from both perspectives with equal rigor. Do not assume open-source is inherently better or worse.
2. Every rating must be supported by at least one piece of specific evidence. If evidence is unavailable, set confidence to "low" and note the gap in "limitations".
3. For community health, check for recent commit activity, contributor diversity, issue resolution time, and bus-factor risk. Do not rely on star count alone.
4. For vendor lock-in, assess data portability, API standardization, and migration cost. Flag proprietary data formats or closed protocols.
5. If the risk level is "high" or "critical", include a dedicated security dimension covering CVE history, audit reports, and supply chain posture.
6. If any constraint (e.g., budget, compliance) makes one option non-viable, list it as a deal-breaker and explain why.
7. Do not fabricate evidence. If you are uncertain, state it explicitly rather than inventing plausible-sounding claims.

To adapt this template for your specific use case, replace the square-bracket placeholders with concrete values before each invocation. The [CONTEXT] field is critical—it grounds the analysis in the reader's actual situation rather than producing a generic comparison. For high-stakes decisions where the output will inform budget allocation or architectural commitments, always route the generated JSON through a validation step that checks for missing evidence, low-confidence ratings, and unbalanced coverage before presenting it to decision-makers. If the model returns "confidence": "low" on multiple dimensions, treat that as a signal to escalate for human research rather than accepting the output at face value.

This prompt is designed to be called from an application layer that first assembles the required context. Before invoking the model, your system must gather the [PRODUCT_NAME], [USE_CASE], [REQUIREMENTS], [CONSTRAINTS], and [BUDGET] variables. The [OPEN_SOURCE_OPTIONS] and [PROPRIETARY_OPTIONS] arrays should be populated from a trusted internal catalog or a prior research step, not from the model's training data. This ensures the comparison is grounded in your organization's approved vendor list and actual evaluation candidates rather than the model's potentially outdated knowledge. The prompt expects these inputs as structured JSON, so your application code should validate that all required fields are present and that array fields contain at least one entry before sending the request.

Wire the prompt into a service that enforces a strict JSON output contract. After receiving the model response, validate it against a JSON Schema that checks for the required top-level keys: executive_summary, comparison_matrix, dimension_scores, risk_assessment, and recommendation. Each object inside comparison_matrix must contain the required fields dimension, weight, open_source_score, proprietary_score, and evidence. Implement a retry loop with a maximum of 3 attempts: if validation fails, append the validation error to the next request as a [PREVIOUS_ERROR] field and re-invoke the prompt. Log every attempt, the raw output, and the validation result to your observability platform for debugging. For high-stakes decisions, route the final validated output to a human review queue (e.g., a Slack channel or internal tool) before it is accepted as a decision artifact. Choose a model with strong JSON mode and reasoning capabilities (such as gpt-4o or claude-3-opus) and set response_format to json_object to minimize parsing failures.

Avoid wiring this prompt directly into an autonomous approval pipeline. The output is a structured recommendation, not an executable decision. Your application should present the matrix and risk assessment to a human decision-maker, not automatically trigger a procurement or integration workflow. If the risk_assessment.vendor_lockin_risk is high or recommendation.confidence is below 0.7, escalate for mandatory human review. Do not cache responses for identical inputs without a TTL, as licensing terms and community health metrics change over time. For repeated evaluations, store the validated JSON in a decisions log with a timestamp and model version to maintain an audit trail for future architecture review.