Uncertainty Detection and Quantification Prompt Template

This prompt is designed for ML engineers and platform developers who need explicit, structured uncertainty signals from model outputs before those outputs reach a downstream system or user. The core job-to-be-done is automated gating: you have a model generating claims, summaries, or extracted data, and you need to programmatically decide whether to accept, flag, escalate, or discard the output based on the model's own confidence. This is not a general-purpose 'how confident are you' wrapper. It is a production-focused template that forces the model to attach uncertainty markers to specific claims, produce an overall confidence interval, and structure its uncertainty report in a machine-readable format suitable for logging, routing, or alerting.

Use this prompt when you are building a pipeline where downstream actions depend on output reliability—such as automated ticket creation from summaries, database insertion from extracted fields, or customer-facing responses that require a confidence floor. It is appropriate when you have access to the model's internal token probabilities (for calibration checks) or a held-out test set with known ground truth. The template expects you to provide [INPUT] (the model's original output plus the source context that generated it), [CONSTRAINTS] (acceptable uncertainty thresholds, required fields), and [OUTPUT_SCHEMA] (the expected JSON structure for the uncertainty report). You should also supply [EXAMPLES] of calibrated uncertainty assessments to improve reliability. The prompt is most effective with models that support structured output or function calling, as the uncertainty report must be parsed and acted upon by application code.

Do not use this prompt when the model's output is purely creative, subjective, or lacks a verifiable ground truth—uncertainty quantification in those domains produces misleading precision. Avoid it when latency is critical and the additional inference call for uncertainty assessment would violate your SLA; in those cases, consider a lightweight self-assessment prompt or a rule-based confidence heuristic instead. This prompt is also insufficient as a standalone safety gate for high-risk domains (clinical, legal, financial compliance). In those contexts, the uncertainty report must feed into a human review queue, and the prompt's [RISK_LEVEL] parameter should be set to 'high' to enforce stricter calibration requirements and mandatory evidence grounding. Finally, do not treat the model's self-reported confidence as a calibrated probability without validating against your own test set—the prompt includes calibration check instructions, but the harness must perform the actual comparison.

This template is designed to extract granular uncertainty signals from a model, not just a single numeric score. It instructs the model to decompose its own output into individual claims, assign a confidence level to each, and explain the source of uncertainty. The output is a structured report that can be parsed by downstream validation logic. Use this when you need to programmatically decide whether to trust, review, or discard a model response before it reaches a user or database.

textCopy
SYSTEM:
You are an uncertainty-aware analyst. For every factual claim you make, you must attach an explicit confidence marker and explain the source of uncertainty. Never state a claim without quantifying your confidence in it.

USER:
Analyze the following input and produce a structured uncertainty report.

INPUT:
[INPUT_TEXT]

CONTEXT (optional, ground truth for calibration):
[CONTEXT]

OUTPUT_SCHEMA:
{
  "overall_confidence": {
    "score": 0.0-1.0,
    "rationale": "string"
  },
  "claims": [
    {
      "claim_text": "string",
      "confidence": 0.0-1.0,
      "uncertainty_source": "insufficient_evidence | conflicting_evidence | model_limitation | domain_ambiguity | temporal_uncertainty | none",
      "evidence_reference": "string | null",
      "needs_human_review": true | false
    }
  ],
  "calibration_notes": "string (only if CONTEXT provided)"
}

CONSTRAINTS:
- Every sentence in your analysis must appear as a claim in the output.
- Confidence scores must reflect genuine uncertainty; do not default to 1.0.
- If CONTEXT is provided, compare your claims against it and note any discrepancies in calibration_notes.
- Mark a claim for human review if confidence < 0.7 or uncertainty_source is not 'none'.
- Do not invent evidence references. Use null if no source supports the claim.

RISK_LEVEL: [HIGH | MEDIUM | LOW]

Adaptation guidance: Replace [INPUT_TEXT] with the document, question, or data the model should analyze. [CONTEXT] is optional but critical for calibration—supply known ground-truth passages to measure the model's self-assessment accuracy. Set [RISK_LEVEL] to control downstream behavior: HIGH risk should trigger mandatory human review for any claim below 0.9 confidence. The OUTPUT_SCHEMA block can be tightened further by adding required enum values for uncertainty_source that match your domain's failure modes. If you are using a model that supports structured output APIs, replace the JSON schema description with the native function-calling or response-format parameter. For streaming applications, buffer the full response before parsing, as the JSON report is not valid until complete.

Next steps: After copying this template, run it against a labeled calibration set where you know the correct answers. Compare the model's self-reported confidence against actual accuracy to measure calibration error. If the model is overconfident (confidence > accuracy), add explicit instructions to lower scores for ambiguous cases. Wire the output into a gating harness that routes needs_human_review: true claims to a review queue. Do not rely on the overall_confidence score alone—individual claim flags are the actionable signal for production filtering.

The uncertainty detection prompt is not a standalone tool; it is a component inside a larger quality-control pipeline. The typical integration point is immediately after a primary model generates an output and before that output reaches a user, database, or downstream system. The harness calls the primary model, extracts its claims, and then invokes this prompt to produce a structured uncertainty report. The report's confidence scores and flagged segments become the input to a routing decision: publish, rewrite, escalate, or discard. This harness must treat the uncertainty prompt as a deterministic evaluation step with strict input/output contracts, not as an optional advisory layer.

Input assembly requires three concrete pieces: the original user query or context, the full model output under evaluation, and a calibration reference set of known-ground-truth examples formatted as claim/truth pairs. The prompt template's [INPUT] placeholder receives the concatenated query and output. [CALIBRATION_EXAMPLES] receives the reference set, which should be drawn from a static, version-controlled dataset that matches the production distribution. The [OUTPUT_SCHEMA] placeholder must be replaced with a strict JSON Schema definition that includes claims (array of objects with claim_text, confidence_score, uncertainty_type, and evidence_fragment), overall_confidence_interval (object with lower_bound, upper_bound, confidence_level), and calibration_notes (string). The [CONSTRAINTS] placeholder should enforce that every confidence score is a float between 0.0 and 1.0, that every claim must cite a specific substring from the original output, and that the model must abstain from scoring claims it cannot locate in the source text.

Validation and retry logic must be implemented in the application layer, not trusted to the model. After receiving the uncertainty report, the harness must validate: (1) the JSON parses without error, (2) every claim's confidence_score is a number in [0.0, 1.0], (3) every evidence_fragment is a substring of the original output, (4) the overall_confidence_interval bounds are logically ordered, and (5) no claims reference hallucinated content not present in the source. If validation fails, the harness should retry once with a repair prompt that includes the validation error message and the malformed output. If the retry also fails, the output should be escalated to a human review queue with the failure context attached. Do not silently accept malformed uncertainty reports; downstream routing decisions depend on their integrity.

Model choice and tool use matter here. This prompt benefits from models with strong instruction-following and structured output capabilities. If the model supports native structured output modes (e.g., JSON mode, function calling with strict schemas), use them instead of relying on text parsing. For high-throughput pipelines, consider using a smaller, faster model for the uncertainty evaluation step while reserving larger models for the primary generation task. The calibration examples should be injected as few-shot demonstrations, not as part of the system prompt, to keep the system prompt stable and cacheable. If the application uses RAG, the uncertainty prompt should receive the retrieved context alongside the output so it can cross-check claims against source material.

Logging and observability are critical because uncertainty signals drive automated decisions. Every invocation must log: the original output, the uncertainty report, validation results, retry counts, and the final routing decision. These logs feed into calibration dashboards that track whether low-confidence outputs correlate with real-world failures. Over time, the calibration reference set should be updated with production outcomes to improve the prompt's accuracy. Human review integration should be triggered when the overall confidence interval's lower bound falls below a configured threshold (e.g., 0.7) or when any individual claim scores below 0.5. The review queue should present the original output, the uncertainty report, and a pre-built form for the reviewer to confirm or override each flagged claim. This closes the loop between automated detection and human judgment without requiring reviewers to start from scratch.