Logical Inference Prompt across Multiple Documents

This prompt is for AI architects and RAG system builders who need to derive a new, non-trivial conclusion by combining premises found in separate retrieved documents. It is not for simple fact lookup, single-document Q&A, or summarization. Use this when the answer requires deductive or inductive reasoning across at least two distinct sources, and the logical rule connecting them must be made explicit. The output is an inferred conclusion, the logical rule applied, and the source premises with citations. This playbook assumes you already have a retrieval pipeline that can surface relevant documents. If your retrieval is noisy or incomplete, pair this with an evidence gap detection prompt before attempting inference.

The ideal user is an engineer or product builder deploying a RAG system where users ask questions like 'Given policy A and incident report B, what is the likely compliance risk?' or 'Based on the Q3 financials and the new vendor contract, what is the projected margin impact?' These questions cannot be answered by extracting a single span of text. They require the model to locate premises in separate chunks, identify the logical relationship between them, and apply a rule—transitive, conditional, causal, or syllogistic—to produce a conclusion that is not explicitly stated in any single document. The prompt template is designed to force this reasoning into a structured, auditable output that includes the inferred conclusion, the logical rule used, and the source premises with citations, making it suitable for high-stakes domains where traceability matters.

Do not use this prompt when the answer is directly stated in a single document, when the task is pure summarization, or when the retrieved documents are topically related but do not contain premises that can be logically combined. In those cases, a standard grounded Q&A or synthesis prompt is more appropriate and less likely to produce hallucinated inferences. Also avoid this prompt when the retrieval step is unreliable—if the necessary premises are missing from the context window, the model will either fabricate a logical bridge or refuse to answer. Before deploying, ensure your retrieval pipeline achieves high recall for the premise-bearing documents, and consider adding a pre-inference step that checks whether all required premises are present. For production systems, pair this prompt with an evaluation harness that checks both the logical validity of the inference and the grounding of each premise in the cited source.

This template is designed for a single-turn inference task where the model must combine premises from separate documents to derive a non-trivial conclusion. It forces the model to state the logical rule applied, cite each source premise, and produce a conclusion that is strictly entailed by the evidence. Use this when you need deductive or inductive reasoning over a knowledge base, not when you need a simple extractive answer or a creative synthesis. The template expects pre-retrieved documents as input; it does not perform retrieval itself.

textCopy
You are a precise logical reasoning engine. Your task is to derive a conclusion from premises found across multiple provided documents. You must apply explicit deductive or inductive rules. Do not introduce external knowledge, assumptions, or facts not present in the provided documents.

## INPUT

### Question or Hypothesis
[QUESTION]

### Retrieved Documents
Each document is identified by a unique ID and contains text that may include relevant premises.

[DOCUMENTS]

### Logical Rule to Apply (if known)
[LOGICAL_RULE or "Infer the most applicable rule from the premises."]

## OUTPUT SCHEMA

Return a valid JSON object with the following structure:

```json
{
  "conclusion": "The derived conclusion stated as a single, clear sentence.",
  "logical_rule_applied": "The name of the rule (e.g., modus ponens, transitivity, inductive generalization, causal inference) and a one-sentence statement of how it was applied.",
  "premises": [
    {
      "premise": "The exact premise statement.",
      "source_document_id": "The ID of the document containing this premise.",
      "source_text_excerpt": "The verbatim sentence or passage from the document that supports this premise."
    }
  ],
  "confidence": "high | medium | low",
  "confidence_rationale": "A brief explanation of why this confidence level was chosen, referencing premise completeness, source agreement, and rule strength."
}

CONSTRAINTS

1. Every premise in the premises array must be directly supported by a verbatim excerpt from a provided document. If a premise cannot be grounded, do not include it.
2. The conclusion must be strictly entailed by the premises and the stated logical rule. Do not over-extrapolate.
3. If the provided documents contain contradictory premises, set confidence to low and explain the contradiction in confidence_rationale.
4. If insufficient premises exist to reach any conclusion, return null for conclusion and logical_rule_applied, set premises to an empty array, confidence to low, and explain the gap in confidence_rationale.
5. Do not fabricate document IDs or source excerpts. Use only the IDs and text provided in [DOCUMENTS].
6. If multiple logical rules could apply, choose the one that requires the fewest additional assumptions.

EXAMPLES

[EXAMPLES]

RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific data. [QUESTION] should contain the hypothesis or question requiring inference. [DOCUMENTS] must be a structured list of pre-retrieved documents, each with a unique ID and text field. If you know the specific logical rule to apply (e.g., transitivity for temporal ordering, modus ponens for conditional reasoning), provide it in [LOGICAL_RULE]; otherwise, use the fallback instruction. [EXAMPLES] should contain 1-3 few-shot demonstrations of valid inferences with the exact output schema. [RISK_LEVEL] should be high, medium, or low and will influence downstream validation behavior. For high-risk domains, always route the output through a human review step before accepting the conclusion. Validate the JSON output programmatically: check that every source_document_id exists in the input, that every source_text_excerpt is a substring of the referenced document, and that the conclusion is not a verbatim restatement of any single premise. For production systems, log every inference with the full input, output, and validation result for auditability.

The logical inference prompt is not a standalone chat widget. It is a component inside a multi-step RAG pipeline that must retrieve candidate premises, validate them, run inference, and then verify the output before it reaches a user or downstream system. The harness is responsible for feeding the prompt the right inputs, catching invalid outputs, and deciding what to do when inference fails. Treat this prompt as a reasoning microservice: it receives a set of premises and a target conclusion type, and it returns a structured inference object that must pass validation before it is accepted.

Wire the prompt into an application by building a thin orchestration layer that performs the following steps in order. 1. Premise retrieval and filtering: Use a retrieval step (vector search, keyword search, or hybrid) to pull candidate passages from your knowledge base. Deduplicate and rank them by relevance. Pass only the top k passages that contain factual claims, not narrative filler. 2. Input assembly: Populate the [PREMISES] placeholder with a JSON array of objects, each containing id, text, and source_document. Populate [INFERENCE_TYPE] with one of deductive, inductive, or abductive. Populate [OUTPUT_SCHEMA] with the exact JSON schema you expect, including fields for conclusion, logical_rule_applied, premise_ids_used, and confidence. 3. Model selection: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Smaller or faster models often skip logical steps or fabricate rules. 4. Structured output enforcement: Set response_format to json_schema (OpenAI) or use tool calling with a strict output schema to prevent free-text drift. 5. Post-generation validation: Run a programmatic validator that checks: every premise_id in the output exists in the input; the logical_rule_applied is a non-empty string; the conclusion is not a verbatim restatement of a single premise; and the confidence is within 0.0–1.0. If validation fails, retry once with the error message injected into the prompt as a [CORRECTION_HINT].

For high-stakes domains such as legal, clinical, or compliance workflows, add a human review gate after validation. The harness should log every inference attempt—inputs, raw output, validation result, retries, and final accepted output—to an audit table. This traceability is essential for debugging hallucinated inferences and for demonstrating due diligence to reviewers. Do not cache inference results across different premise sets without checking for staleness. If the knowledge base updates, invalidate cached inferences that depend on changed documents. Finally, monitor production inference quality with an LLM-as-judge eval that periodically samples outputs and scores them against a rubric checking logical validity, premise grounding, and rule correctness. Escalate if the pass rate drops below your threshold.