Conflict of Interest Detection Prompt for Authors

This prompt is designed for research synthesis and due-diligence AI systems that need to surface potential conflicts of interest (COI) from author-provided metadata and disclosure statements. It extracts structured data on funding sources, employment affiliations, and competing interests, then flags any undisclosed potential conflicts by cross-referencing declared affiliations against the research topic. Use this prompt when building evidence pipelines for grant review, journal submission checks, investment due diligence, or regulatory compliance workflows where author objectivity must be assessed before evidence is weighted.

The ideal user is an AI engineer or technical decision maker integrating COI detection into a production pipeline. The prompt assumes the input text contains disclosure statements or author metadata sections—it is not a general-purpose extraction prompt and will perform poorly on narrative prose, full-text articles, or unstructured author bios without explicit disclosure language. Required context includes the research topic or domain against which to cross-reference declared affiliations, a clear output schema for structured COI data, and a defined risk threshold for flagging undisclosed conflicts. The prompt works best when paired with a validation layer that checks extracted entities against known funding databases, employer records, or patent filings.

Do not use this prompt as a standalone compliance decision engine. It surfaces potential conflicts for human review but does not make final determinations about author bias or research validity. It is not suitable for real-time chat applications, consumer-facing products without human-in-the-loop review, or workflows where the input text lacks explicit disclosure language. In regulated domains such as pharmaceutical research or securities analysis, always route flagged outputs to a qualified reviewer and maintain an audit trail of the prompt version, input metadata, and extracted COI records. The next step after reading this section is to review the prompt template, adapt the placeholders to your domain, and design the validation harness before integrating it into your evidence pipeline.

This template is designed to be dropped directly into your application or evaluation harness. It instructs the model to act as a disclosure analyst, extracting structured conflict-of-interest (COI) data from provided author metadata and disclosure text. The prompt uses strict square-bracket placeholders for all variable inputs, allowing you to swap in your own data, output schema, and risk thresholds without altering the core instruction logic. The template is structured to produce a JSON array of findings, making it suitable for downstream database insertion, API responses, or human-review queues.

textCopy
You are a disclosure analyst. Your task is to extract and flag conflicts of interest from the provided author disclosure statements and metadata.

# INPUT
Author Name: [AUTHOR_NAME]
Author Metadata: [AUTHOR_METADATA]
Disclosure Text: [DISCLOSURE_TEXT]

# OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "author": "string",
  "findings": [
    {
      "type": "funding | employment | competing_interest | undisclosed_potential",
      "description": "string (concise, factual description of the conflict)",
      "source_quote": "string (exact text from the disclosure that supports this finding)",
      "confidence": "high | medium | low",
      "requires_human_review": true | false
    }
  ],
  "no_conflicts_found": true | false,
  "analysis_notes": "string (brief summary of the overall assessment)"
}

# CONSTRAINTS
- Only report conflicts that are explicitly stated or strongly implied by the disclosure text.
- For "undisclosed_potential" types, flag only if the author metadata (e.g., known employer, recent grants) suggests a conflict that is absent from the disclosure. Set confidence to "low" and requires_human_review to true.
- Do not invent or assume conflicts not supported by the provided text.
- If no conflicts are found, set no_conflicts_found to true and return an empty findings array.

# RISK LEVEL
[RISK_LEVEL]

# EXAMPLES
[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your production data. [AUTHOR_NAME] and [AUTHOR_METADATA] should be populated from your author database or submission system. [DISCLOSURE_TEXT] is the raw text of the disclosure statement. The [RISK_LEVEL] placeholder allows you to inject context-specific instructions—for example, in a high-stakes regulatory workflow, you might add: 'This is a HIGH-RISK review. All findings must be flagged for human review. Err on the side of caution.' The [EXAMPLES] placeholder should be filled with one or two few-shot examples demonstrating the desired output format, especially for edge cases like undisclosed potential conflicts. After generating the output, validate the JSON structure and route any finding with requires_human_review: true to a review queue before accepting the result.

This prompt is designed to operate as a structured extraction step inside a larger due-diligence or research synthesis pipeline. It should not be exposed directly to end users as a free-text chat interface. Instead, wire it as a single-turn extraction call that receives pre-processed author metadata and disclosure statements, and returns a typed JSON object that downstream systems can ingest. The prompt expects two primary inputs: an [AUTHOR_PROFILE] containing name, affiliations, and known funding sources, and a [DISCLOSURE_TEXT] containing the verbatim conflict-of-interest statement or acknowledgments section from the publication. If your system retrieves these from PDFs or HTML, run document extraction and normalization before calling this prompt—do not pass raw scanned text or unparsed markup.

Validation and retry logic is critical because the output drives compliance and editorial decisions. After receiving the model response, validate the JSON structure against the expected schema: conflicts_detected (boolean), declared_conflicts (array of objects with entity, relationship_type, disclosure_verbatim), potential_undeclared_conflicts (array of objects with entity, evidence_source, confidence), and assessment_notes (string). If the JSON fails to parse, retry once with a repair prompt that includes the raw output and the schema. If the confidence field for any undeclared conflict falls below a configurable threshold (we recommend 0.7), route that item to a human review queue rather than surfacing it automatically. Log every extraction attempt with the input hash, model version, raw output, validation result, and reviewer decision for auditability.

Model choice and tool use should match the risk profile. For high-stakes applications—journal submissions, regulatory filings, grant reviews—use a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Enable structured output mode if your provider supports it, rather than relying on parse-and-repair loops. This prompt does not require tool calls or retrieval-augmented generation during extraction, but you may chain it with an upstream RAG step that fetches author publication histories, funding databases (e.g., NIH RePORTER, Crossref Funder Registry), or institutional affiliation records to improve undeclared conflict detection. If you add retrieval, pass the retrieved evidence into the [AUTHOR_PROFILE] field as structured context, not as raw search results. Always include a human review gate before any flagged conflict is surfaced to an external audience—this prompt identifies signals, not final determinations.