Video-Demo-Claim-to-Documentation Accuracy Prompt

This prompt is designed for a single, high-stakes job: reconciling the procedural steps demonstrated in a video tutorial or product demo against the official written documentation. The ideal user is a technical writer, QA engineer, or developer relations team member responsible for ensuring that a user following a video will not encounter a broken workflow, a missing prerequisite, or a UI state that no longer exists. The required context is a verbatim transcript of the video and the exact, relevant section of the documentation. The output is a step-level reconciliation report that flags every discrepancy, not a summary or a subjective review. Use this when you are shipping a new feature walkthrough, auditing an existing video library for version drift, or responding to a customer report that a demo step no longer works.

This prompt is not a general-purpose video summarizer, a sentiment analyzer, or a QA tool for code functionality. It will not tell you if the video is 'good' or if the documentation is well-written. Its only function is to perform a structured comparison between a demonstrated procedure and a documented procedure. For the prompt to work reliably, you must provide a clean transcript with speaker labels and timestamps removed, and a documentation section that contains the canonical steps. The model will not infer missing context, so if the video references a prerequisite setup that is in a different documentation page, you must include that page in the [DOCUMENTATION] input. The prompt is most effective when the documentation is procedural and step-based; it will struggle with purely conceptual or reference-style documentation that lacks a clear sequence of actions.

Before using this prompt, confirm that a step-level reconciliation is the actual job to be done. If you need to check whether a video's claims about system performance, pricing, or theoretical concepts are accurate, use a claim-extraction and evidence-matching prompt from the Fact Checking pillar instead. If you need to verify that a UI screenshot matches a live API response, use the Screenshot-Claim-to-API-Response Validation Prompt. This prompt should be avoided when the video is a high-level overview without a demonstrated procedure, or when the documentation is a release blog post rather than a usage guide. After running the prompt, always have a subject-matter expert review the discrepancy report before publishing a fix or pulling a video. A flagged 'discrepancy' might be a deliberate simplification for teaching purposes, and only a human can make that judgment call.

The following prompt template is designed to be copied directly into your AI harness. It instructs the model to act as a technical QA auditor, systematically comparing a video transcript against a documentation file. The core job is to identify where the documented procedure and the demonstrated procedure diverge, flagging missing steps, UI state mismatches, and version-drift indicators. Before using this prompt, ensure you have extracted a detailed, timestamped transcript from your video and have a clean text extraction of the relevant documentation section. This prompt is not a replacement for a full RAG pipeline if your documentation is massive; it is designed for a focused, one-to-one comparison of a specific procedure.

textCopy
You are a technical documentation auditor. Your task is to compare a video demonstration transcript against a written documentation snapshot to verify procedural accuracy. You must identify discrepancies, missing steps, and UI state mismatches.

# INPUTS
- VIDEO_TRANSCRIPT: A timestamped transcript of the video demonstration.
  [VIDEO_TRANSCRIPT]
- DOCUMENTATION_SNAPSHOT: The relevant section of the written documentation to verify against.
  [DOCUMENTATION_SNAPSHOT]
- COMPARISON_CONTEXT: Any known version information for the video and documentation.
  [COMPARISON_CONTEXT]

# OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "summary": "A one-sentence executive summary of the overall accuracy.",
  "accuracy_score": "A string, one of 'high', 'medium', 'low', indicating the degree of alignment.",
  "step_checks": [
    {
      "step_description": "A concise description of a single procedural step.",
      "video_evidence": "The exact quote and timestamp from the transcript showing this step.",
      "documentation_evidence": "The exact quote from the documentation describing this step.",
      "match_status": "One of 'exact_match', 'minor_deviation', 'major_deviation', 'missing_in_docs', 'missing_in_video'.",
      "discrepancy_detail": "If not an exact match, explain the specific difference, such as a different UI label, a missing click, or a reordered action."
    }
  ],
  "ui_state_discrepancies": [
    {
      "ui_element": "The button, field, label, or state described.",
      "video_state": "How it appears or is named in the video.",
      "documentation_state": "How it is described in the documentation.",
      "severity": "One of 'critical', 'moderate', 'cosmetic'."
    }
  ],
  "missing_steps": [
    "A list of steps found in the documentation but not demonstrated in the video."
  ],
  "extra_steps": [
    "A list of steps demonstrated in the video but not mentioned in the documentation."
  ],
  "version_drift_indicators": [
    "A list of any clues suggesting the video and documentation are from different software versions, such as different URLs, dated references, or deprecated features."
  ]
}

# CONSTRAINTS
- Be meticulous. A 'minor_deviation' is a difference in wording that does not change the procedural outcome. A 'major_deviation' is a difference that could lead a user to a different result or error.
- If a step is implied but not explicitly stated in one source, flag it as 'missing' in that source.
- Do not hallucinate UI elements. Only report on elements explicitly mentioned in the provided text.
- If the video transcript is too vague to verify a step, set match_status to 'major_deviation' and explain the ambiguity.

To adapt this template, replace the [VIDEO_TRANSCRIPT], [DOCUMENTATION_SNAPSHOT], and [COMPARISON_CONTEXT] placeholders with your actual data. The COMPARISON_CONTEXT is critical for calibrating the model's sensitivity to version drift; include any known version numbers or dates here. The output JSON schema is strict by design to allow for direct parsing in your application. After receiving the output, you should validate the JSON structure and check that all match_status values are from the allowed enum. For high-risk documentation, such as security procedures or compliance steps, a human reviewer must confirm all 'major_deviation' and 'missing_steps' flags before any action is taken.

This prompt is designed to operate as a single step within a larger verification pipeline, not as a standalone chat interaction. The core workflow involves extracting atomic claims from a video transcript and visual description, then comparing each claim against a structured documentation snapshot. The implementation harness must manage version alignment between the video recording timestamp and the documentation revision, as version drift is the most common source of false-positive discrepancy flags. Before invoking the model, the harness should retrieve the documentation version that was current at the time of video recording, not the latest version, unless the task is explicitly a drift audit.

Wire the prompt into an application by first running a pre-processing step that extracts the video transcript (via Whisper or equivalent) and generates frame-level UI state descriptions using a vision-capable model. These become the [VIDEO_TRANSCRIPT] and [VISUAL_STATE_DESCRIPTIONS] inputs. The [DOCUMENTATION_SNAPSHOT] should be a structured extraction of the relevant documentation sections, ideally with step numbers, UI element references, and expected outcomes. The model output should conform to a strict JSON schema with fields for claim_id, claim_text, documentation_match (boolean), matched_doc_section, discrepancy_type (enum: missing_step, ui_state_mismatch, order_difference, extra_step, no_discrepancy), and confidence_score. Implement a post-processing validator that checks schema compliance, rejects hallucinated documentation section references, and flags any confidence_score below a configurable threshold for human review.

For production deployment, use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, with response_format set to json_schema where available. Implement a retry layer with exponential backoff for schema validation failures, but cap retries at three attempts before routing to a human review queue. Log every invocation with the video ID, documentation version, model version, and the full claim array for auditability. For high-stakes documentation (compliance, safety procedures, API contracts), always require human sign-off on any flagged discrepancy before publishing a correction. Avoid using this prompt for real-time or streaming video analysis; it is designed for batch processing of recorded demos against version-pinned documentation snapshots.