Answer with cited public sources — procedure

Procedure for answering factual public-world questions with cited authoritative sources, stable locators, and fail-closed behavior when evidence is missing.

Purpose

This guide shows how to run a cited-source factual-answer workflow. It separates public-world claims from local-state claims, defines admissible source types, sets the runtime prompt contract, and verifies that the final answer is source-supported rather than completed from memory or inference.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

  • Use case
    The answer makes factual public-world claims
    Use this when the response states facts about technologies, standards, official documentation, research findings, public policies, vendors, tools, or other externally verifiable subjects.
  • Use case
    The answer requires authoritative evidence
    Use this when generic web pages are not enough and material claims must be supported by standards, official documentation, peer-reviewed papers, textbooks, or recognized institutions.
  • Use case
    The answer needs stable source locators
    Use this when citations should include locators such as standard identifier and section, DOI, ISBN with edition and section, official documentation version or date, or an equivalent stable locator.
  • Use case
    Missing evidence must stop the answer
    Use this when the workflow must return a fail-closed result instead of guessing, approximating, or softening unsupported claims.

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Step 1 · Separate public-world claims from local-state claims

    Classify the request before answering.
    Use public sources only for public-world facts. Use user-provided files, repository content, logs, screenshots, or tool output for local-state claims.
    Check: No public source is used as proof of what exists in the current repo, uploaded file, screenshot, log, private system, or chat state.

  2. Step 2 · Define the factual-answer contract

    State the question, source standard, source locator requirement, and stopping condition.
    Specify the required source classes, date or version boundary, jurisdiction if relevant, and the exact fail-closed behavior for missing evidence.
    Check: The prompt includes goal, evidence boundary, output format, and stop condition.

  3. Step 3 · Apply the cited-source component

    Add the reusable cited-source rule before generating the answer.
    Use the cited authoritative sources component as the instruction-layer rule for the run.
    Check: The run explicitly requires authoritative sources for material public-world factual claims.

  4. Step 4 · Use an admissible source hierarchy

    Prefer sources that are authoritative for the exact claim.
    Prioritize standards, official documentation, peer-reviewed papers, textbooks, laws or regulations where relevant, and recognized institutions. Use secondary sources only for context unless they are the best available admissible source for the claim.
    Check: Each material source is authoritative for the specific claim it supports.

  5. Step 5 · Retrieve sources only when needed

    Use web search or retrieval when the answer depends on current, changing, specialized, or missing public evidence.
    Add a web-search prompt only when the required sources are not already provided or when freshness matters.
    Check: The workflow does not claim that search or retrieval occurred unless it actually occurred.

  6. Step 6 · Map claims to sources

    Check the answer before publishing or using it.
    For every material public-world claim, verify that the cited source directly supports the exact statement. Remove unsupported claims or return the fail-closed result.
    Check: No material public-world claim remains without direct source support.

  7. Step 7 · Return fail-closed when evidence is insufficient

    Stop instead of guessing when the required evidence is missing.
    Use the fail-closed result when the core claim cannot be supported by admissible sources.
    Check: Unsupported core claims are not completed from memory, inference, plausibility, or weak sources.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

  • Boundary check
    The answer separates public-world facts from local-state facts
    Public sources support public-world claims only. Local files, logs, screenshots, repositories, and chat-specific state require direct local evidence.
  • Source-quality check
    Each material source is admissible
    Core claims use standards, official documentation, peer-reviewed papers, textbooks, laws or regulations where relevant, or recognized institutions.
  • Locator check
    Citations include stable locators
    Use DOI, standard identifier and section, ISBN with edition and section, official documentation version or date, legal locator, or an equivalent stable locator when applicable.
  • Claim-source alignment check
    Each citation supports the exact claim
    No citation is attached to a claim that the source only indirectly, partially, or generally supports.
  • Freshness check
    Current or version-sensitive claims use current evidence
    Claims about active products, APIs, laws, prices, roles, or current documentation use sources appropriate to the required date or version.
  • Disagreement check
    Material source disagreement is surfaced
    When authoritative sources conflict, the answer states that the evidence is mixed or disputed and cites the relevant sides.
  • Fail-closed check
    Unsupported core claims stop
    If admissible evidence is missing for a core claim, the answer fails closed instead of guessing.

Next steps