Compatibility Matrix Prompt for Technical Specs

This prompt is designed for integration and platform engineering teams who need to extract structured compatibility information from large, unstructured technical documentation. The core job-to-be-done is converting messy spec sheets, SDK docs, and release notes into a machine-readable matrix that maps product versions to supported platforms, runtimes, and known limitations. The ideal user is a developer or technical product manager building a migration guide, an integration hub, or a 'supported platforms' page where presenting stale or incorrect compatibility data directly causes customer outages.

Use this prompt when you have a source document that explicitly states version support, deprecation timelines, or platform-specific caveats. It is most effective when the input context is a single, authoritative document, such as a SUPPORT.md file, a product datasheet, or a compatibility section of an API reference. Do not use this prompt for general Q&A over a broad knowledge base, for generating compatibility data from code alone, or for inferring support status from changelogs without explicit statements. The prompt is not a substitute for a real-time version resolution API; it is a documentation extraction tool that requires human review for any matrix that gates a production deployment or customer-facing compatibility guarantee.

The primary risk is hallucinated version support. The model may confidently state that a library works on a platform it has never been tested on, or it may miss a critical deprecation notice buried in a footnote. To mitigate this, the prompt enforces a strict rule: every cell in the matrix must be backed by an explicit quote from the source text. If the source is silent on a specific combination, the cell must be marked as 'Unknown' rather than assumed. Before integrating this prompt into a CI/CD pipeline or a customer-facing docs site, you must implement a validation layer that flags any 'Supported' or 'Not Supported' claim lacking a direct citation, and you should route matrices with a high percentage of 'Unknown' cells for manual documentation review.

This template is designed to extract compatibility information from technical specifications, API docs, and platform documentation. It produces a structured matrix showing version support, platform coverage, and known limitations. The prompt uses strict output formatting to ensure the matrix is machine-readable and auditable. Before using this template, ensure your retrieved context contains version-specific compatibility statements, platform support tables, or dependency declarations. If the source documents lack explicit version or platform information, the prompt will flag missing data rather than fabricate compatibility claims.

codeCopy
You are a technical compatibility analyst. Your task is to extract compatibility information from the provided technical documentation and produce a structured compatibility matrix.

## INPUT
[CONTEXT]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "product": "[PRODUCT_NAME]",
  "compatibility_matrix": [
    {
      "component": "string (name of the component, dependency, or integration point)",
      "component_type": "string (e.g., operating_system, database, runtime, library, api_version, browser, hardware)",
      "supported_versions": ["string (exact version numbers or ranges)"],
      "unsupported_versions": ["string (explicitly unsupported versions if documented)"],
      "platforms": ["string (platform names where this applies, e.g., linux, windows, macos, cloud)"],
      "compatibility_status": "string (supported | deprecated | experimental | unsupported | unknown)",
      "constraints": ["string (specific limitations, prerequisites, or conditions)"],
      "deprecation_date": "string or null (date when support ends, if documented)",
      "source_reference": "string (exact quote or section reference from the provided context)",
      "confidence": "string (high | medium | low based on evidence quality)"
    }
  ],
  "missing_information": ["string (questions the documentation does not answer about compatibility)"],
  "conflicts_found": ["string (any contradictory statements found in the documentation)"],
  "generation_notes": "string (summary of what was found and any caveats)"
}

## CONSTRAINTS
[CONSTRAINTS]
- Only include information explicitly stated in the provided context.
- If a component is mentioned but version support is unclear, set compatibility_status to "unknown" and add a note to missing_information.
- If two statements in the context contradict each other, document both in conflicts_found and set confidence to "low".
- Do not infer compatibility from general industry knowledge. Only use the provided documentation.
- For any component where no explicit deprecation date is given, set deprecation_date to null.
- If the context contains a support matrix table, extract all rows and columns faithfully.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Read the provided context carefully.
2. Identify every component, dependency, or integration point with version or platform information.
3. For each component, extract the supported versions, platforms, constraints, and deprecation dates.
4. Flag any missing information or contradictions.
5. Output ONLY the JSON object. No markdown fences, no commentary.

To adapt this template, replace the square-bracket placeholders with your specific needs. The [CONTEXT] placeholder should contain the retrieved technical documentation chunks. The [CONSTRAINTS] placeholder can include domain-specific rules such as minimum version requirements, regulatory constraints, or platform exclusions relevant to your use case. The [EXAMPLES] placeholder should contain one or two example matrix entries showing the expected format and level of detail. The [RISK_LEVEL] placeholder should be set to "high" if the matrix will be used for deployment decisions, triggering additional validation requirements. For production use, always validate the output JSON against the schema before presenting it to users, and implement a retry loop with schema error feedback if the model produces malformed JSON. Human review is required when the confidence field contains "low" entries or when conflicts_found is non-empty.

The Compatibility Matrix Prompt is designed to be embedded in a multi-step RAG pipeline, not called in isolation. Before the prompt runs, your application must retrieve relevant technical documentation chunks—version notes, platform support pages, API references, and deprecation notices—and assemble them into the [CONTEXT] block. The prompt expects structured input: a product or component name, a list of target platforms or environments, and the retrieved evidence. The output is a structured matrix with version support, platform coverage, and limitation notes. Because this output often feeds downstream systems (compatibility checkers, sales configurators, integration test planners), the harness must enforce schema compliance and evidence grounding before the result leaves the pipeline.

Wire the prompt into an application function that accepts product_name, target_platforms, and retrieved_documents as inputs. Construct the [CONTEXT] by concatenating document chunks with source identifiers. Populate [INPUT] with the product name and platform list. Set [CONSTRAINTS] to enforce the output schema: a JSON array of objects with fields product_version, platform, support_status (enum: supported, partial, unsupported, unknown), limitations (array of strings), and source_references (array of source IDs). After the model responds, run a validation step that checks: (1) every claimed support status has at least one source reference, (2) no supported status appears without explicit evidence, (3) all target_platforms appear in the output, and (4) unknown entries are flagged for human review. If validation fails, retry once with the validation errors appended to [CONSTRAINTS] as explicit correction instructions. If the retry also fails, route the output to a human review queue rather than silently accepting an incomplete matrix.

For model choice, prefer a model with strong instruction-following and structured output capabilities. If your platform supports tool calling, define the matrix schema as a function parameter to enforce field-level constraints. Implement structured logging that captures the prompt version, retrieved document IDs, raw model output, validation results, and any human review decisions. This audit trail is critical when downstream consumers question a compatibility claim. Avoid common failure modes: stale documentation producing false supported claims (mitigate with document freshness checks in retrieval), the model inventing version numbers not present in evidence (caught by source reference validation), and the model omitting platforms from the input list (caught by completeness checks). For high-stakes deployments where incorrect compatibility data causes production incidents, gate all supported classifications behind human confirmation regardless of validation pass.