Source Authority Documentation Prompt

Use this prompt when you need to produce a structured, defensible record explaining why a specific source was trusted or excluded during a fact-checking or evidence-gathering workflow. The primary job-to-be-done is generating a per-source authority document that captures credibility indicators, domain relevance, recency, and potential bias, creating an audit trail for source selection decisions. The ideal user is a verification engineer, compliance analyst, or AI pipeline builder who must justify source choices to auditors, regulators, or downstream reviewers. This prompt is essential when source authority directly impacts claim verdicts and when the rationale for trusting one source over another must be explicit and traceable.

This prompt requires several concrete inputs to function correctly. You must provide the source identifier and content, the claim or domain context for relevance assessment, and any known credibility signals such as author credentials, publication reputation, and peer-review status. The output is a structured authority record, typically in JSON, containing fields for authority level, credibility indicators, domain relevance score, recency assessment, bias flags, and a justification narrative. The prompt is designed to be wired into a verification pipeline where source authority records are stored alongside claim verdicts, enabling downstream audit queries like 'show me the authority justification for every source used in this batch.'

Do not use this prompt for real-time, low-latency applications where source authority is already pre-computed and cached. It is not a replacement for a static source whitelist or blocklist, nor is it designed for consumer-grade content moderation. The prompt is most effective when source authority is contested, when multiple sources conflict, or when an auditor requires a documented rationale. Avoid using it for sources where authority is self-evident and uncontested, as the overhead of generating a full record outweighs the benefit. For high-risk domains like healthcare or legal, always pair the output with human review and ensure the authority justification references specific, verifiable evidence rather than relying solely on model-generated reputation summaries.

This prompt template is designed to be copied directly into your verification pipeline. It instructs the model to produce a structured authority record for a single source, documenting why it was trusted or excluded for a specific claim. The output is a JSON object suitable for ingestion into an audit trail or evidence database. All dynamic inputs are represented as square-bracket placeholders, which your application must resolve before sending the request to the model.

textCopy
You are a source authority documentation specialist. Your task is to evaluate a single source and produce a structured authority record. You must be objective, evidence-based, and conservative in your assessments. Do not invent information. If a field cannot be determined from the provided context, mark it as null or 'UNKNOWN'.

## INPUT
- Source Content: [SOURCE_CONTENT]
- Source Metadata: [SOURCE_METADATA]
- Claim Being Verified: [CLAIM_TEXT]
- Verification Domain: [DOMAIN]
- Current Date: [CURRENT_DATE]

## OUTPUT SCHEMA
Return a single JSON object conforming to this structure:
{
  "source_identifier": "string",
  "authority_assessment": {
    "credibility_rating": "HIGH" | "MEDIUM" | "LOW" | "UNKNOWN",
    "domain_relevance": "DIRECT" | "INDIRECT" | "NONE" | "UNKNOWN",
    "recency_assessment": {
      "publication_date": "string | null",
      "is_current_for_claim": "YES" | "NO" | "UNKNOWN",
      "recency_justification": "string"
    },
    "authority_justification": "string",
    "bias_indicators": ["string"],
    "exclusion_risk": "HIGH" | "MEDIUM" | "LOW"
  },
  "trust_decision": {
    "verdict": "TRUSTED" | "EXCLUDED" | "CONDITIONAL",
    "rationale": "string",
    "conditions_if_conditional": "string | null"
  }
}

## CONSTRAINTS
- Base all assessments strictly on the provided source content and metadata.
- If the source is anonymous, lacks a publication date, or has no identifiable author, reflect this in the credibility rating and justification.
- For bias indicators, list specific, observable signals (e.g., 'funding source conflict', 'one-sided language', 'lacks opposing viewpoints'). Do not speculate.
- A source should be marked EXCLUDED if it is irrelevant, demonstrably false, or so biased that it cannot contribute reliable evidence.
- A source should be marked CONDITIONAL if it can be used with caveats (e.g., 'use only for factual data, ignore editorial opinion').

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each placeholder with data from your application context. [SOURCE_CONTENT] should contain the full text or a representative excerpt of the source. [SOURCE_METADATA] should include any available information like author, publisher, URL, and publication date. [FEW_SHOT_EXAMPLES] is critical for calibration; provide 2-3 examples showing the correct assessment for sources similar to those in your domain. If the [RISK_LEVEL] is HIGH, your implementation harness should route the output for human review before the trust decision is finalized. For production use, validate the output JSON against the schema and log any instances where credibility_rating is UNKNOWN or exclusion_risk is HIGH for operational review.

The Source Authority Documentation prompt is designed to be called once per source that a verification pipeline intends to use as evidence. It should not be called inline during claim matching; instead, it runs as a pre-processing step that builds a structured authority record before evidence is weighted. In a production pipeline, this prompt typically sits between source discovery (where candidate URLs or documents are identified) and evidence matching (where claims are paired with sources). The output is a machine-readable authority record that downstream components can use to decide whether to trust, deprecate, or escalate a source. Wire this prompt as a synchronous API call with a strict timeout, because authority assessment is a blocking dependency for evidence quality scoring.

The application harness should enforce a JSON output schema with required fields: source_id, authority_level (enum: high, medium, low, rejected), credibility_indicators (array of objects with indicator and evidence), domain_relevance (object with relevant_domains and justification), recency_assessment (object with publication_date, cutoff_relevance, and stale_after), bias_detection (object with detected_biases and mitigation_notes), and exclusion_risk (boolean with reason). Validate the output against this schema immediately after model response. If validation fails, retry once with the validation error message appended to the prompt as a correction instruction. If the second attempt also fails, log the failure and route the source to a human-review queue rather than silently accepting a malformed record. For high-stakes domains such as healthcare or legal verification, require human approval on any source where authority_level is low or rejected before the source is excluded from evidence matching. Log every authority assessment with the model version, prompt version, timestamp, and raw output for audit trail completeness.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may collapse the structured schema or skip bias-detection fields. If you are processing a large batch of sources, implement a concurrency cap and cost-tracking per source, because authority assessment is a fixed per-source cost that multiplies quickly. Do not use this prompt inside a tight retrieval loop where latency is critical; instead, pre-compute authority records and store them in a cache keyed by source URL or document hash, with a TTL based on the stale_after field. When a source's authority record expires, re-run the prompt rather than silently using stale credibility data. The next step after implementation is to build eval checks that measure whether the prompt consistently detects known low-authority sources and correctly flags domain mismatch, so that your verification pipeline does not quietly degrade when source quality drops.