Observability Vendor Lock-In Risk Analysis Prompt

This playbook is for architects and platform engineers who need a structured, evidence-based analysis of the risks associated with a specific observability vendor. Use it before signing a multi-year contract, during a build-vs-buy decision, or as part of a regular architecture review. The prompt forces the model to act as a skeptical architect, evaluating the vendor across multiple lock-in vectors and producing a scored risk report. It is designed to be used with vendor documentation, current architecture diagrams, and your organization's specific portability requirements as input context.

The prompt is most effective when you can provide concrete, source-grounded context. This includes the vendor's official documentation on data export APIs, the query language specification, agent installation and configuration methods, and your own organization's architectural standards or multi-cloud strategy. Without this context, the model will generate a generic analysis that lacks the specificity needed for a real procurement or architectural decision. The output is a scored risk report, not a binary yes/no answer, which means you must be prepared to interpret the scores and trade-offs within your own risk tolerance.

Do not use this prompt when you lack access to vendor documentation or when the decision is purely about pricing. This prompt analyzes technical lock-in, not total cost of ownership. It is also not a substitute for a legal review of contract terms, data processing agreements, or SLA commitments. If your organization has no intention of ever migrating away from a vendor, the lock-in analysis is still valuable for understanding operational risk, but the migration cost vector will carry less weight. After running this analysis, the next step is to feed the scored report into a broader architecture decision record that weighs the lock-in risk against the vendor's functional benefits and your team's operational capacity.

This prompt template is designed to produce a structured risk analysis for an observability vendor dependency. It forces the model to evaluate lock-in across multiple dimensions—data export, proprietary query languages, agent coupling, and migration cost—rather than producing a generic summary. The template uses square-bracket placeholders that you must replace with your specific vendor, architecture, and constraints before execution. The output is a risk register with severity ratings, likelihood assessments, and mitigation recommendations, suitable for an architecture decision record or vendor review packet.

textCopy
You are an observability architect evaluating vendor lock-in risk for [VENDOR_NAME] within [ORGANIZATION_CONTEXT].

## INPUT
- Current observability stack: [CURRENT_STACK_DESCRIPTION]
- Services instrumented: [SERVICE_LIST_AND_COUNT]
- Data types collected: [LOGS_METRICS_TRACES_PROFILES_EVENTS]
- Contract terms: [CONTRACT_DURATION_AND_EXIT_CLAUSES]
- Compliance requirements: [REGULATORY_FRAMEWORKS]
- Multi-cloud strategy: [MULTI_CLOUD_POSITION]
- Open standards adoption: [OPENTELEMETRY_PROMQL_OTHER_STANDARDS]

## ANALYSIS DIMENSIONS
For each dimension below, assess lock-in severity (Low/Medium/High/Critical), likelihood of causing migration pain (1-5), and provide evidence from the input.

1. **Data Export Difficulty**: Can raw telemetry data be exported in standard formats? Are there rate limits, format restrictions, or egress fees?
2. **Proprietary Query Language Coupling**: How much of the query, dashboard, and alert logic depends on vendor-specific languages (e.g., proprietary query syntax, non-standard functions)?
3. **Agent and Collector Coupling**: Are agents or collectors tightly coupled to the vendor's backend? Can they be swapped for OpenTelemetry collectors without rewriting instrumentation?
4. **API and Integration Lock-In**: Do critical integrations (incident management, CI/CD, chatops) depend on vendor-specific APIs or webhook formats?
5. **Migration Cost Estimate**: Rough order-of-magnitude estimate for migrating to [ALTERNATIVE_SOLUTION] in engineering-weeks, including retooling dashboards, alerts, and runbooks.
6. **Vendor Stability and Roadmap Risk**: Assess the vendor's financial stability, recent leadership changes, acquisition history, and product deprecation patterns.
7. **Skills and Team Dependency**: How specialized is the operational knowledge required for this vendor? What is the market availability of engineers with this expertise?

## CONSTRAINTS
- Base all assessments on evidence provided in the input. If evidence is missing for a dimension, flag it as "Insufficient Data" and state what information would be needed.
- Do not speculate about the vendor's future beyond what can be reasonably inferred from documented patterns.
- For migration cost estimates, provide a range (best-case to worst-case) and list the key assumptions.
- If [REGULATORY_FRAMEWORKS] includes GDPR, SOC2, or HIPAA, add a dedicated section on data residency and audit evidence portability.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "vendor_assessment": {
    "vendor_name": "string",
    "assessment_date": "string",
    "overall_lock_in_rating": "Low|Medium|High|Critical",
    "summary": "string (2-3 sentence executive summary)"
  },
  "dimensions": [
    {
      "name": "string",
      "severity": "Low|Medium|High|Critical",
      "likelihood": 1-5,
      "evidence": "string (specific facts from input)",
      "data_gaps": ["string (missing information needed for full assessment)"],
      "mitigation": "string (actionable recommendation)"
    }
  ],
  "migration_cost_estimate": {
    "target_alternative": "string",
    "best_case_weeks": number,
    "worst_case_weeks": number,
    "key_assumptions": ["string"],
    "largest_cost_driver": "string"
  },
  "regulatory_considerations": {
    "applicable_frameworks": ["string"],
    "data_residency_risk": "string",
    "audit_evidence_portability": "string"
  },
  "recommended_actions": [
    {
      "action": "string",
      "priority": "P0|P1|P2",
      "effort_weeks": number,
      "reduces_lock_in_dimension": "string"
    }
  ],
  "decision_readiness": "Ready for decision|Needs more data|Escalate for legal review"
}

## RISK_LEVEL
[HIGH] - This analysis may influence significant procurement decisions. Flag any dimension rated Critical with a recommendation for human review before the output is used in a decision memo.

To adapt this template, replace each square-bracket placeholder with concrete data from your environment. The [ORGANIZATION_CONTEXT] should include your company size, industry, and any recent vendor consolidation initiatives. The [CURRENT_STACK_DESCRIPTION] should name specific products and versions. If you lack data for a placeholder, replace it with "Unknown—requires discovery" rather than guessing; the model will flag those gaps in the output. After generation, validate the JSON output against the schema before feeding it into your decision workflow. For high-stakes vendor evaluations, route the output to a human architect for review before it reaches procurement or leadership.

This prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The application layer should collect the required inputs—vendor name, current stack details, contract terms, and integration surface—from a structured form, a configuration repository, or an internal architecture catalog. Before calling the model, validate that all required placeholders are populated and that the [CONTRACT_TERMS] field includes actual data export clauses, not just a summary. Missing inputs should block execution and return a clear error to the user rather than allowing the model to hallucinate contract details.

Wrap the prompt call in a retry harness with at most three attempts. The primary failure mode is a malformed JSON output that fails schema validation. Define a strict JSON schema for the expected output—including required fields like lock_in_score, migration_cost_estimate, data_export_assessment, and portability_recommendations—and validate the model response against it before presenting results. On validation failure, append the schema errors to the retry prompt as [VALIDATION_ERRORS] and request a corrected output. If the third attempt still fails, log the raw response and escalate for human review rather than silently accepting a partial analysis. This is a high-stakes architectural decision prompt; incorrect or incomplete output can lead to costly vendor entrenchment.

Model choice matters here. Use a model with strong structured output capabilities and a context window large enough to hold the full prompt plus any vendor documentation excerpts you include in [VENDOR_DOCUMENTATION]. If you are embedding this in a CI/CD pipeline or an architecture review board workflow, store every prompt version, input hash, and validated output in an audit log. This creates an evidence trail for future vendor migration decisions. For regulated environments, add a mandatory human approval step after successful validation: the analysis should be reviewed by an architect or engineering lead before it becomes part of an official architecture decision record. Do not treat this prompt's output as a final decision—it is a structured risk assessment that informs, but does not replace, engineering judgment.