Technical Specification Claim Audit Prompt Template

This prompt is built for engineering teams, QA leads, and product validation engineers who need to audit product claims—such as performance benchmarks, compatibility guarantees, or capability assertions—against the ground truth of a technical specification document. The core job-to-be-done is automated discrepancy detection: you provide a structured claim and the relevant spec text, and the prompt returns a structured verdict on whether the claim is supported, contradicted, or unverifiable, including a precise citation to the spec section and a tolerance-aware analysis for numerical values. This is not a general-purpose fact-checker; it is a precision tool for aligning marketing collateral, datasheets, and customer-facing documentation with engineering reality before a claim reaches a customer or a regulator.

The ideal user has access to both the claim and the authoritative specification revision. The prompt is version-aware, meaning it expects a spec version identifier and will flag when a claim references an outdated or superseded document. It also distinguishes between a legitimate variance within stated engineering tolerances and a genuine discrepancy that requires investigation. For example, a claim of 'latency under 10ms' against a spec that states 'latency ≤ 10ms ±1ms at p99' would pass if the measured value falls within the tolerance band, but a claim of 'supports 64 concurrent streams' against a spec that explicitly limits concurrency to 32 would fail with a clear contradiction flag. This tolerance handling is critical for avoiding noisy false positives in production pipelines where measured performance naturally varies.

Do not use this prompt for legal compliance verification, regulatory filing review, or clinical claims where domain-specific evidence rules, liability frameworks, or human-in-the-loop mandates apply. This prompt is an engineering audit tool, not a substitute for legal review or certified compliance checks. If your workflow involves SEC filings, medical device claims, or contractual obligations, use the domain-specific verification prompts designed for those evidence standards. After running this audit, the next step is typically routing contradictions to the product team for investigation and updating the claim or the spec, not publishing the raw output as a final determination.

This section provides the core prompt template for the Technical Specification Claim Audit workflow. The template is designed to be copied directly into your prompt library, IDE, or orchestration layer. It uses square-bracket placeholders for all dynamic inputs, ensuring you can wire it into a retrieval system, a manual review queue, or an automated CI/CD pipeline without modifying the instruction structure. The prompt enforces a strict output schema, requires explicit evidence pairing, and separates measured values from stated claims—making it suitable for engineering teams who need audit-ready verification outputs, not just a yes/no answer.

textCopy
You are an engineering specification auditor. Your task is to verify product claims against provided technical specification documents. You must perform version-aware comparison, handle measurement tolerances, and separate confirmed facts from unsupported assertions.

## INPUTS
- **Claim Set:** [CLAIMS]
- **Specification Documents:** [SPEC_DOCUMENTS]
- **Specification Version:** [SPEC_VERSION]
- **Product Version Under Test:** [PRODUCT_VERSION]
- **Measurement Data (optional):** [MEASUREMENT_DATA]
- **Tolerance Configuration:** [TOLERANCE_CONFIG]

## OUTPUT SCHEMA
Return a valid JSON object with this structure:
{
  "audit_id": "string",
  "spec_version": "string",
  "product_version": "string",
  "findings": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "confirmed|contradicted|partially_supported|unsupported|not_applicable",
      "evidence": [
        {
          "source_section": "string",
          "source_text": "string",
          "relationship": "supports|contradicts|partially_supports",
          "tolerance_check": {
            "stated_value": "string",
            "measured_value": "string or null",
            "tolerance_range": "string",
            "within_tolerance": "boolean or null"
          }
        }
      ],
      "confidence": "high|medium|low",
      "requires_human_review": "boolean",
      "review_reason": "string or null"
    }
  ],
  "summary": {
    "total_claims": "number",
    "confirmed": "number",
    "contradicted": "number",
    "partially_supported": "number",
    "unsupported": "number",
    "not_applicable": "number",
    "human_review_required": "number"
  }
}

## CONSTRAINTS
1. For every claim, you MUST cite at least one specific section from [SPEC_DOCUMENTS] as evidence.
2. If a claim references a measurable value (performance, capacity, latency, throughput), compare it against [MEASUREMENT_DATA] using the tolerance windows defined in [TOLERANCE_CONFIG].
3. If [SPEC_DOCUMENTS] contains version-specific requirements, verify the claim against the correct version for [PRODUCT_VERSION]. Flag claims that reference deprecated or superseded spec sections.
4. Set "requires_human_review": true when:
   - The claim involves safety-critical assertions.
   - Evidence is ambiguous or contradictory across spec sections.
   - Measurement data is missing for a quantitative claim.
   - The spec version does not match the product version under test.
5. Do NOT invent evidence. If no spec section addresses a claim, set verification_status to "unsupported" and leave the evidence array empty.
6. For "partially_supported" claims, explain in review_reason what part is supported and what is not.

## TOLERANCE HANDLING
- Use [TOLERANCE_CONFIG] to determine acceptable deviation ranges.
- If a stated value falls within the tolerance window of the measured value, mark within_tolerance as true.
- If no measurement data is available for a quantitative claim, set within_tolerance to null and flag for human review.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adaptation guidance: Replace each square-bracket placeholder with your application's dynamic inputs. [CLAIMS] should be a structured list of extracted claims, ideally with unique claim_id values. [SPEC_DOCUMENTS] should contain the full text or relevant excerpts from your specification documents, with section identifiers preserved for citation. [TOLERANCE_CONFIG] can be a simple JSON object mapping metric names to acceptable deviation ranges (e.g., {"throughput_mbps": "±5%", "latency_ms": "±2ms"}). If your workflow does not include measurement data, remove the tolerance_check block from the output schema and adjust constraint 2 accordingly. The [EXAMPLES] placeholder should contain 2-3 few-shot examples showing correct claim-to-evidence pairing, including at least one partially_supported and one unsupported outcome. Set [RISK_LEVEL] to "high" for safety-critical systems, which will enforce stricter human-review routing.

What to do next: After copying this template, wire it into your verification pipeline with a JSON schema validator that rejects malformed outputs before they reach downstream systems. Implement a retry layer that re-submits the prompt with the validation error message if the output fails schema checks. For high-risk domains, route all findings with requires_human_review: true to a review queue before accepting any automated verification result. Test the prompt against a golden dataset of known claims with expected verification_status values before deploying to production.

This prompt is designed to be a single step in a larger verification pipeline, not a standalone chat interface. The primary integration pattern is a batch audit job triggered by a product requirements document (PRD) update, a spec version change, or a pre-release checklist. The application layer is responsible for chunking the input specification and the target claims document, managing version context, and enforcing the output schema before any result reaches a human reviewer or a downstream compliance system.

To wire this into an application, start by building a pre-processing stage that extracts the specification version, release date, and relevant sections based on the claims being audited. The prompt's [SPEC_DOCUMENT] placeholder should receive a focused excerpt, not the entire 200-page system spec. For each claim in [CLAIMS_LIST], the application should construct a separate prompt call or a structured batch where the model returns a JSON array of audit results. After the model responds, a validation layer must enforce the [OUTPUT_SCHEMA] by checking that every claim has a verdict (Supported, Partially Supported, Contradicted, or Unverifiable), a spec_reference with a section number, and a tolerance_applied field for any numerical comparisons. Failed validations should trigger a retry with the specific schema violation injected into the [CONSTRAINTS] field before any human ever sees the output.

For production deployment, use a model with strong JSON mode and a context window large enough to hold both the spec excerpt and the claims batch—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate starting points. Log every prompt version, spec version, and model response for auditability. When the [RISK_LEVEL] is set to high (e.g., safety-critical systems, medical device specs, or regulatory compliance), the harness must route all Partially Supported and Contradicted verdicts to a human review queue with the original claim, the spec excerpt, and the model's reasoning pre-populated. Do not auto-close these items. For numerical tolerance handling, the application should parse the model's tolerance_applied field and re-verify the math in application code to guard against hallucinated calculations. The next step after a successful audit run is to aggregate the results into a compliance report and flag any spec sections that received zero claims for potential coverage gaps.