Source Ambiguity Flagging Prompt

This prompt is designed for review queue designers and data quality engineers operating in the middle of an extraction pipeline. After a claim has been extracted from a corpus and candidate source spans have been retrieved, this prompt determines whether the claim's provenance is clear or ambiguous. The core job-to-be-done is preventing incorrect or misleading attributions from being written into a system of record by flagging cases where multiple sources could reasonably support the same claim. The ideal user is someone building an audit-grade extraction system who needs a reliable gating mechanism before final attribution decisions are made.

Use this prompt when you have a structured claim object and a set of candidate source spans, each with their own text content and metadata. The prompt expects inputs like [CLAIM_TEXT], [CANDIDATE_SOURCES] (an array of objects with source_id, span_text, and optional metadata), and [AMBIGUITY_THRESHOLD] to calibrate sensitivity. It is not suitable for initial claim extraction, source retrieval, or final attribution decisions. Do not use this prompt when you have only one candidate source, when the claim is a direct quote with an unambiguous origin, or when you need a simple binary match/no-match decision. The output is a structured ambiguity assessment, not a resolved attribution.

In production, this prompt should sit between your retrieval step and your system-of-record write step. The output flags ambiguous spans, scores the severity of ambiguity on a defined scale, and suggests resolution paths such as 'human review required,' 'merge sources with annotation,' or 'escalate for domain expert.' Before deploying, validate the prompt against a golden set of claims with known ambiguity labels to calibrate the threshold. Common failure modes include the model treating stylistic variation as semantic ambiguity, missing subtle contradictions between sources, or over-flagging when sources are paraphrases of each other. Always log the ambiguity score and resolution path for auditability, and ensure that any claim flagged for human review is held in a quarantine queue until resolved.

The following prompt template is designed to be pasted directly into your prompt layer. It identifies spans in the provided text where a claim could reasonably be attributed to multiple sources, assigns an ambiguity score, and suggests a resolution path. Replace every square-bracket placeholder with the values specific to your document, schema, and operational context before sending the request to the model.

textCopy
You are an audit-grade source attribution analyst. Your task is to examine the provided document and flag every span where a factual claim could reasonably be attributed to more than one source.

## INPUT
Document text:
[INPUT_TEXT]

Known source list (if available):
[SOURCE_LIST]

## OUTPUT SCHEMA
Return a JSON object with the key "ambiguous_spans" containing an array of objects. Each object must have the following fields:
- "span_text": The exact text of the ambiguous span.
- "span_offset": Character start and end offsets of the span in the original text, as [start, end].
- "claim": A concise statement of the claim made in the span.
- "candidate_sources": An array of source identifiers that could reasonably support this claim.
- "ambiguity_score": A float between 0.0 and 1.0, where 1.0 means completely ambiguous (multiple equally valid sources) and 0.0 means clearly attributable to a single source.
- "ambiguity_rationale": A brief explanation of why the span is ambiguous.
- "suggested_resolution": One of "human_review", "majority_vote", "most_recent_source", or "most_authoritative_source".
- "reviewer_notes": A placeholder string for a human reviewer to fill, initially set to an empty string.

## CONSTRAINTS
- Do not flag spans that are clearly attributable to a single source.
- Do not flag opinion, interpretation, or speculative language as ambiguous unless the underlying factual claim is ambiguous.
- If no ambiguous spans are found, return an empty array.
- Preserve the exact text of the span; do not paraphrase or truncate.
- If the document contains no sources at all, flag every factual claim with an ambiguity_score of 1.0 and set suggested_resolution to "human_review".

## EXAMPLES
Example input: "The CEO announced record profits in Q3 (Source A). Industry analysts also reported strong performance for the company in the same period (Source B)."
Example output:
{
  "ambiguous_spans": [
    {
      "span_text": "strong performance for the company in the same period",
      "span_offset": [98, 150],
      "claim": "The company had strong performance in Q3.",
      "candidate_sources": ["Source A", "Source B"],
      "ambiguity_score": 0.8,
      "ambiguity_rationale": "Source A implies strong performance via record profits; Source B explicitly states strong performance. Both support the claim.",
      "suggested_resolution": "human_review",
      "reviewer_notes": ""
    }
  ]
}

## RISK_LEVEL
[RISK_LEVEL] 
// Set to "high" if the output feeds compliance or legal workflows; "medium" for internal review queues; "low" for exploratory analysis.

To adapt this template, start by replacing [INPUT_TEXT] with the full document content and [SOURCE_LIST] with a structured list of known sources referenced in the document. If your application does not maintain a pre-parsed source list, you can omit that section or instruct the model to infer sources from inline citations. The [RISK_LEVEL] placeholder controls downstream behavior: in high-risk contexts, every flagged span should be routed to a human review queue with the reviewer_notes field populated before any automated action is taken. For production deployments, validate the output JSON against the schema before ingestion, and log any spans where ambiguity_score exceeds your operational threshold for automated escalation.

The Source Ambiguity Flagging Prompt is designed to sit between extraction and human review. It should be called after a claim has been extracted and its candidate source spans identified, but before the claim is committed to a downstream system of record. The prompt expects a structured input containing the claim text and a list of candidate source spans with their full context. It returns an ambiguity score, a primary source recommendation, and a structured resolution path. This output feeds directly into a review queue UI where human analysts can accept, override, or escalate the recommendation.

Wire this prompt into an application as a post-extraction processing step. After your extraction pipeline produces a claim and its candidate sources, construct the input payload with the claim in [CLAIM_TEXT] and each candidate source as an object with source_id, span_text, and surrounding_context fields. Call the model with a low temperature setting (0.0–0.2) to maximize consistency in ambiguity scoring. Validate the response against a strict JSON schema that requires ambiguity_score (0.0–1.0), primary_source_id (nullable), flagged_for_review (boolean), ambiguity_type (enum: multiple_viable_sources, insufficient_context, conflicting_evidence, none), and resolution_path (enum: auto_accept_primary, human_review_required, escalate_for_investigation). If the response fails schema validation, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, route the claim directly to the human review queue with a validation_failure flag.

Log every invocation with the input claim, candidate sources, model response, validation result, and final routing decision. This audit trail is critical for compliance workflows where source attribution decisions must be defensible. For high-stakes domains such as legal or clinical review, configure the system to route all claims with ambiguity_score > 0.3 to human review regardless of the model's resolution_path recommendation. Use a review queue UI that displays the claim, all candidate source spans rendered side-by-side, the model's ambiguity score and rationale, and one-click actions for the reviewer to confirm, reassign, or escalate. Track reviewer decisions over time to measure alignment between model recommendations and human judgments, which serves as a continuous evaluation signal for prompt drift and model performance.

Avoid using this prompt as a real-time blocking step in latency-sensitive pipelines. The model call adds latency, and the human review step adds unpredictable delay. Instead, design your system to accept claims into a staging area, process ambiguity flags asynchronously, and only promote claims to the system of record after review is complete or the auto-accept threshold is met. For claims that are auto-accepted, still log the decision and retain the full ambiguity analysis for audit. Never silently drop ambiguous claims—every claim that enters this workflow must either be resolved or explicitly deferred with a tracked reason.