Evidence Sufficiency Threshold Justification Prompt Template

This prompt is for verification system architects who need to produce a documented, defensible rationale for choosing a specific evidence sufficiency threshold. Use it when you are configuring a claim verification pipeline and must justify to stakeholders, compliance reviewers, or engineering teams why claims scoring above X are auto-verified, claims between Y and Z go to human review, and claims below W are rejected. The prompt assumes you have already defined your claim domain, understand the cost of false positives versus false negatives, and can articulate stakeholder risk tolerance. Do not use this prompt for scoring individual claims; use the Evidence Sufficiency Scoring Prompt Template for that. This prompt produces a threshold justification document, not a score.

The ideal user is a technical lead or architect who has completed initial pipeline testing and needs to lock down operational thresholds before production deployment. You should have access to calibration data from your scoring pipeline, error cost estimates from business stakeholders, and throughput constraints from your operations team. The prompt works best when you can provide concrete numbers for false-positive and false-negative impact, such as 'a false positive costs $X in reviewer time' or 'a false negative risks Y regulatory exposure.' Without these inputs, the prompt will produce a generic rationale that fails audit scrutiny. The output is a structured justification document suitable for change management boards, compliance filings, or engineering design reviews.

Avoid this prompt when you are still prototyping your scoring model or when you lack stakeholder alignment on risk tolerance. If your team cannot agree on the relative cost of errors, the prompt will surface that ambiguity rather than resolve it—which is useful for diagnosis but not for producing a final threshold. Also avoid this prompt for one-off claim evaluations or for generating threshold values without human review of the output. The justification document this prompt produces should be treated as a draft that requires human approval before thresholds are implemented in production routing logic. For ongoing threshold monitoring, pair this prompt with the Triage Threshold Assignment Prompt for Verification Pipelines and the Confidence Decay Over Time Prompt Template to define re-evaluation triggers when conditions change.

This prompt template is designed for verification system architects who need to produce a clear, auditable justification for why a specific evidence sufficiency score (e.g., 0.75) was chosen as the boundary between 'auto-verify' and 'human-review' for a particular claim domain. It forces the model to articulate the trade-offs between risk tolerance, the cost of errors, and stakeholder requirements, creating a document that can be reviewed by compliance, product, and engineering teams. Use this before hard-coding a threshold into your verification pipeline to ensure the decision is defensible and aligned with business priorities.

markdownCopy
You are a senior verification architect documenting the rationale for an evidence sufficiency threshold. Your task is to produce a structured justification that explains why a specific threshold was chosen for a given claim domain, considering risk tolerance, error cost analysis, and stakeholder requirements.

## INPUTS
- **Claim Domain:** [CLAIM_DOMAIN]
- **Proposed Sufficiency Threshold:** [THRESHOLD_VALUE]
- **Risk Tolerance Level:** [RISK_TOLERANCE]
- **Error Cost Analysis:** [ERROR_COST_SUMMARY]
- **Stakeholder Requirements:** [STAKEHOLDER_REQUIREMENTS]
- **Available Evidence Types:** [EVIDENCE_TYPES]

## OUTPUT_SCHEMA
Produce a JSON object with the following structure:
{
  "threshold_justification": {
    "proposed_threshold": number,
    "claim_domain": string,
    "rationale_summary": string,
    "risk_tolerance_assessment": {
      "level": string,
      "justification": string
    },
    "error_cost_analysis": {
      "false_positive_cost": string,
      "false_negative_cost": string,
      "cost_asymmetry": string
    },
    "stakeholder_alignment": [
      {
        "stakeholder": string,
        "requirement": string,
        "how_threshold_meets_it": string
      }
    ],
    "evidence_sufficiency_definition": string,
    "threshold_boundary_examples": [
      {
        "scenario": string,
        "score": number,
        "verdict": "auto_verify" | "human_review",
        "reasoning": string
      }
    ],
    "review_triggers": [
      {
        "trigger_condition": string,
        "action": string
      }
    ]
  }
}

## CONSTRAINTS
- The rationale_summary must be understandable by a non-technical stakeholder.
- The error_cost_analysis must explicitly state whether false positives or false negatives are more costly and why.
- Provide at least three boundary examples showing claims that fall just above and just below the threshold.
- Review triggers must describe real-world conditions (e.g., new regulation, source availability change) that would necessitate re-evaluating the threshold.
- Do not invent fake regulations, benchmarks, or customer data. Base the justification on the provided inputs and general verification best practices.

To adapt this template, replace each square-bracket placeholder with concrete values from your domain. For [ERROR_COST_SUMMARY], provide a brief analysis of the business impact of a false positive (verifying a false claim) versus a false negative (failing to verify a true claim). For [STAKEHOLDER_REQUIREMENTS], list the explicit needs from legal, compliance, product, and customer success teams. The output JSON is designed to be stored as a versioned artifact in your verification system's configuration, serving as an audit trail for threshold decisions. After generating the justification, route it for human review before implementation, especially in regulated domains where threshold choices have compliance implications.

This prompt is not a runtime component of a verification pipeline; it is a design-time tool for system architects documenting why a specific sufficiency threshold was chosen for a claim domain. The output—a structured threshold rationale—should be treated as a decision record that lives alongside your pipeline configuration, not as a prompt you call per claim. Wire it into your workflow by triggering it when a new claim domain is onboarded, when error cost assumptions change, or when stakeholder requirements shift. The prompt expects inputs that are typically gathered from product requirements, risk assessments, and domain expert interviews, not from automated data feeds.

To integrate this into a verification system design workflow, create a documentation pipeline step that runs after domain scoping and before pipeline implementation. The prompt requires [CLAIM_DOMAIN], [RISK_TOLERANCE], [ERROR_COST_ANALYSIS], and [STAKEHOLDER_REQUIREMENTS] as inputs. These should be sourced from structured intake forms or design documents, not left to ad-hoc entry. After the model returns a threshold rationale, validate the output against a schema that checks for required fields: a numeric threshold, a risk tolerance statement, an error cost justification, stakeholder requirement alignment, and a list of threshold review triggers. If any field is missing or the justification is circular, route the output for human review before accepting it as the pipeline's configured threshold. Store the validated rationale in your decision registry with a version number and timestamp.

The most common failure mode is treating this prompt's output as a one-time artifact. Thresholds decay as evidence sources change, error costs shift, and stakeholder risk appetites evolve. Build a review trigger into your pipeline configuration that surfaces the stored rationale when any of the documented review triggers fire—such as a new source type being added, a change in regulatory requirements, or a drift in verification accuracy metrics. Do not auto-apply a new threshold without human approval. The rationale document should be linked from your pipeline's operational dashboards so that operators understand why a claim is being auto-verified versus escalated, and can challenge the threshold when conditions change.