Conflict of Interest and Funding Bias Detection Prompt

This prompt is designed for verification engineers and pipeline operators who need to assess a source's independence before using its claims as evidence in a fact-checking or RAG system. The ideal user is someone integrating automated source assessment into a production pipeline where evidence weighting depends on source credibility. You should use this prompt after a source has been identified and its basic metadata extracted, but before its factual claims are accepted into your evidence store or used to support or contradict a target claim. The required context includes a source description, available metadata (publication, author affiliations, funding acknowledgments), and the specific claim or domain the source is being evaluated for. Without this context, the model cannot reliably detect conflicts.

This is a detection and assessment step, not a final verdict on truthfulness. The prompt instructs the model to act as an impartial auditor, analyzing provided information to identify financial, organizational, or personal conflicts of interest. It produces structured output with flagged conflicts, disclosed and undisclosed funding sources, and a bias risk score. This output should feed into your evidence weighting logic—sources with high bias risk scores might be deprioritized, flagged for human review, or excluded entirely depending on your risk tolerance. The prompt includes adversarial test cases where conflicts are deliberately obscured, making it suitable for pipelines that expect sophisticated attempts to hide funding bias.

Do not use this prompt when you lack sufficient source metadata to make a meaningful assessment—the model will hallucinate conflicts rather than report insufficient information if you don't constrain it properly. Do not use it as a standalone truthfulness check; a source can be biased but factually correct, or independent but wrong. This prompt should be paired with human review for high-risk domains like legal, financial, and medical verification, where automated bias assessment errors can have serious consequences. If you need to compare multiple sources or explain why one source was preferred over another, use the Source Selection Justification Prompt instead. For domain-specific authority assessment without the funding bias lens, see the Domain Authority Assessment Prompt for Evidence Weighting.

This prompt template is designed to be dropped directly into a verification pipeline. It instructs the model to act as an impartial auditor, strictly analyzing the provided source description for financial, organizational, or personal relationships that could compromise independence. The prompt distinguishes between disclosed and undisclosed conflicts, producing a structured JSON output that your application can parse, log, and act upon. Use this when you need to programmatically assess source bias before using that source as evidence in a fact-checking workflow.

Below is the copy-ready template. Replace [SOURCE_DESCRIPTION] with the text describing the source, its author, its publisher, and any known funding or affiliation details. The model is constrained to analyze only the provided text and must not hallucinate external information. The output schema enforces a strict float for the bias_risk_score and requires an explicit limitations_of_analysis array, ensuring uncertainty is surfaced rather than hidden.

textCopy
Act as an impartial source-auditor AI. Your task is to analyze the provided source information for potential conflicts of interest and funding biases. Identify any financial, organizational, or personal relationships that could compromise the source's independence. Distinguish between disclosed and undisclosed conflicts. Produce a structured JSON output with your findings. Do not evaluate the truth of the source's claims, only its potential biases.

### SOURCE INFORMATION
[SOURCE_DESCRIPTION]

### OUTPUT INSTRUCTIONS
Return a single JSON object with the following structure:
{
  "source_identifier": "string",
  "flagged_conflicts": [
    {
      "conflict_type": "financial_sponsorship|organizational_affiliation|personal_interest|ownership_stake|other",
      "description": "string",
      "interested_parties": ["string"],
      "disclosure_status": "disclosed|undisclosed|unclear",
      "evidence": "string"
    }
  ],
  "funding_sources": [
    {
      "funder_name": "string",
      "funder_type": "corporation|government|foundation|individual|advocacy_group|unknown",
      "relationship_to_source": "string",
      "disclosure_status": "disclosed|undisclosed|unclear"
    }
  ],
  "bias_risk_score": {
    "score": 0.0,
    "rationale": "string",
    "key_drivers": ["string"]
  },
  "overall_assessment": "string",
  "limitations_of_analysis": ["string"]
}

### RULES
- The bias_risk_score must be a float between 0.0 (no detectable bias risk) and 1.0 (extreme, certain bias risk).
- If no conflicts are found, return an empty array for flagged_conflicts.
- If funding information is completely absent, state this clearly in limitations_of_analysis and set the bias_risk_score to 0.5 with a rationale explaining the uncertainty.
- Base your analysis strictly on the provided text. Do not hallucinate funding sources.

To adapt this for your pipeline, start by replacing [SOURCE_DESCRIPTION] with a structured summary of the source you're evaluating. This summary should include the author's name, their stated affiliations, the publisher, any funding acknowledgments, and the content domain. For high-stakes domains like healthcare or finance, consider adding a [CONSTRAINTS] section that specifies additional conflict categories relevant to your industry, such as regulatory capture or patent holdings. Always validate the output JSON against the schema before ingesting it into downstream systems. If the bias_risk_score exceeds a threshold you define (e.g., 0.7), route the source for human review before using it as evidence.

To wire this prompt into a production pipeline, wrap it in a function that first attempts to enrich the [SOURCE_DESCRIPTION] via a web search or a structured knowledge base lookup. This enrichment step is critical because the prompt's accuracy depends on having sufficient context about the source's ownership, funding disclosures, and known affiliations. Without enrichment, the model may miss conflicts that are publicly documented but not present in the initial input. The enrichment function should return structured metadata—funding sources, parent organizations, board memberships, and known advocacy positions—that gets appended to the prompt's [CONTEXT] section before the model call.

The model call should be made with a low temperature (e.g., 0.1) for deterministic outputs, since this is a classifier and auditor, not a conversational agent. Validate the response against the JSON schema immediately after the call. On validation failure, retry once with the error message appended to the prompt as additional instruction. This single-retry pattern catches most format drift without introducing excessive latency. Log the bias_risk_score as a metric in your observability stack so you can track score distributions over time and detect calibration drift. For high-risk scores (>= 0.7), route the source to a human review queue before any downstream evidence matching occurs—do not allow automated systems to use flagged sources without review. For scores between 0.4 and 0.7, attach the full conflict report to the evidence payload so downstream systems can apply a weighting penalty rather than blocking the source entirely.

This prompt should be called via an API, not a chat interface. It is designed for programmatic consumption in a verification pipeline, not for interactive use. When deploying, ensure your API wrapper handles timeouts gracefully and returns a structured error if the model fails to produce valid JSON after the retry. Avoid using this prompt on sources where no enrichment data is available—the model will produce low-confidence guesses that should not be trusted. Instead, flag unenrichable sources for manual review. For high-throughput pipelines, consider batching enrichment lookups and caching source assessments to avoid redundant model calls for frequently cited sources.