Paraphrase Drift Detection Over Document Revisions Prompt

This prompt is for documentation and editorial teams who need to track how a paraphrased statement changes across multiple draft revisions relative to a fixed original source. The core job-to-be-done is detecting semantic drift: identifying when incremental edits to a paraphrase gradually shift the meaning away from the source material, even if each individual revision looks acceptable in isolation. The ideal user is a technical editor, content reviewer, or verification analyst managing document pipelines where paraphrased content passes through multiple contributors or revision cycles before publication.

Use this prompt when you have a known original source text and a sequence of paraphrased versions (drafts) that must stay faithful to that source. It is appropriate for editorial workflows where quote integrity and paraphrase fidelity are auditable requirements, such as newsroom copy desks, technical documentation review, legal document preparation, and compliance content pipelines. The prompt requires three concrete inputs: the original source text, an ordered list of paraphrase revisions with version identifiers, and a drift threshold that defines when cumulative semantic change becomes actionable. Without these inputs, the prompt cannot produce a meaningful drift log.

Do not use this prompt for single-version paraphrase checking (use the Paraphrase Fidelity Scoring Prompt instead), for detecting misquotations in direct quotes (use the Misquotation Detection Prompt), or for real-time editing suggestions. This prompt is designed for retrospective drift analysis across a known revision history, not for inline editing assistance. It is also not a substitute for human editorial judgment when the drift threshold is ambiguous; the output should route to human review when the cumulative drift alert fires. For production deployments, pair this prompt with a structured output validator that checks the drift log schema, version ordering, and threshold compliance before the results enter a CMS or review queue.

This prompt template is designed to compare a paraphrased statement against its original source and track how its meaning shifts across multiple document revisions. It produces a structured drift log with version-to-version semantic distance scores and a cumulative drift alert when meaning crosses a defined threshold. Use this template as the core instruction block in your application, replacing the square-bracket placeholders with actual values before each run.

textCopy
You are a semantic drift detection system. Your task is to compare a paraphrased statement against an original source and track how its meaning changes across document revisions.

## INPUT
- Original source text: [ORIGINAL_SOURCE]
- Paraphrased statement versions (chronological order): [PARAPHRASE_VERSIONS]
- Semantic distance threshold for cumulative drift alert: [DRIFT_THRESHOLD]

## CONSTRAINTS
- Compare each paraphrase version directly to the original source, not to the previous version.
- Treat minor wording changes that preserve core meaning as low drift.
- Flag any version where a key claim, stance, attribution, or factual element differs from the original.
- Distinguish between clarifying rewrites and meaning-altering changes.
- If a version introduces a claim absent from the original, mark it as an addition.
- If a version omits a material claim present in the original, mark it as an omission.

## OUTPUT_SCHEMA
Return a valid JSON object with this structure:
{
  "original_source_summary": "string (one-sentence summary of the original source's key claim)",
  "versions": [
    {
      "version_index": "integer (0-based)",
      "version_text": "string",
      "semantic_distance_score": "float (0.0 to 1.0, where 0.0 is identical meaning and 1.0 is completely unrelated)",
      "drift_category": "string (one of: 'none', 'minor_rewording', 'clarification', 'emphasis_shift', 'omission', 'addition', 'meaning_change')",
      "drift_explanation": "string (specific explanation of what changed and why it matters)",
      "affected_claims": ["string (list of specific claims from the original that were altered, omitted, or contradicted)"]
    }
  ],
  "cumulative_drift_alert": {
    "triggered": "boolean",
    "max_drift_score": "float",
    "drift_trajectory": "string (one of: 'stable', 'gradual_drift', 'sudden_drift', 'oscillating')",
    "summary": "string (explanation of the overall drift pattern across versions)"
  },
  "recommendation": "string (one of: 'accept_latest', 'revert_to_version_X', 'escalate_for_review')"
}

## EXAMPLES
Example 1 - Stable paraphrasing:
Original: "The company reported a 12% revenue increase in Q3, driven primarily by new product launches."
Version 0: "Q3 revenue grew 12% thanks to new products, the company said."
Output: score 0.05, category 'minor_rewording', no alert.

Example 2 - Meaning drift:
Original: "The company reported a 12% revenue increase in Q3, driven primarily by new product launches."
Version 0: "The company's revenue jumped 12% in Q3, entirely due to cost-cutting measures."
Output: score 0.8, category 'meaning_change', affected_claims: ['driver of revenue increase'], alert triggered.

## RISK_LEVEL
[RISK_LEVEL]

If RISK_LEVEL is 'high', include a confidence field for each version and flag any version where confidence is below 0.7 for human review.

To adapt this template, replace the placeholders as follows: [ORIGINAL_SOURCE] with the exact source text being paraphrased; [PARAPHRASE_VERSIONS] with a JSON array of version strings in chronological order; [DRIFT_THRESHOLD] with a float between 0.0 and 1.0 that triggers the cumulative drift alert when exceeded; and [RISK_LEVEL] with either 'standard' or 'high' to control whether confidence scores are required. For high-risk domains such as legal or medical content, always set [RISK_LEVEL] to 'high' and route outputs with triggered alerts or low-confidence scores to human review before any downstream action.

Before deploying this prompt into production, validate the output against the JSON schema using a programmatic validator. Common failure modes include the model returning a drift_category outside the enumerated list or omitting the cumulative_drift_alert object when no drift is detected. Add a retry step that feeds schema validation errors back into the prompt as correction instructions. For batch processing across many document sets, log every run's semantic distance scores and drift categories to build a calibration dataset that helps you tune [DRIFT_THRESHOLD] for your specific content domain.

The paraphrase drift detection prompt is designed to operate as a comparison step within a document revision or content management pipeline. It expects three inputs: the original source text, a previous revision's paraphrased statement, and the current revision's paraphrased statement. The harness should call the prompt for each paraphrased passage that has changed between revisions, not for the entire document at once. This targeted invocation keeps token usage predictable and prevents the model from losing fidelity when comparing long passages. The output is a structured drift log containing a semantic distance score, a cumulative drift alert flag, and a version-to-version diff explanation.

Wire the prompt into your application by first extracting changed paraphrased blocks using a text-diffing preprocessor (such as diff-match-patch or a git-style diff). For each changed block, retrieve the original source passage and the previous revision's paraphrase from your content store. Construct the prompt payload with these three text fields plus your [OUTPUT_SCHEMA] and [CONSTRAINTS]. Validate the model's JSON response against a strict schema that requires: a semantic_distance float between 0.0 and 1.0, a cumulative_drift_alert boolean, a drift_log array of objects with version_from, version_to, change_description, and distance_delta fields, and a recommendation enum of accept, review, or escalate. If validation fails, implement a single retry with the validation error message appended to the prompt as a correction hint. After two consecutive failures, log the failure and route the item to a human review queue with the raw model output attached.

For production deployments, choose a model with strong instruction-following and structured output capabilities. Set temperature to 0 or near-zero to maximize consistency across repeated comparisons of the same text. Implement a drift threshold in your application layer: when cumulative_drift_alert is true or semantic_distance exceeds your configured threshold (start with 0.3 and calibrate against human judgments), automatically flag the revision for editorial review. Log every comparison result with a trace ID that links the original source version, both paraphrase versions, the model response, and the final routing decision. This audit trail is essential for content governance and for tuning your drift thresholds over time. Avoid using this prompt for real-time collaborative editing where latency budgets are under two seconds; the comparison step typically requires one to three seconds depending on passage length and model choice.

The harness should also handle edge cases where the paraphrase has been completely rewritten rather than incrementally revised. In these cases, the previous revision may share little surface text with the current revision. The prompt is designed to compare meaning rather than surface form, but you should add a pre-check: if the Levenshtein distance between the two paraphrase versions exceeds 80% of the shorter text length, prepend a note to the prompt indicating that a major rewrite has occurred and that the comparison should focus exclusively on semantic preservation relative to the original source. Finally, build an evaluation set of 50 to 100 known drift examples with human-annotated distance scores and alert decisions. Run this eval set against any prompt or model changes before deploying to production, and track the false-positive and false-negative rates on drift alerts as your primary quality metric.