RAG Answer Readiness Gate Prompt

This prompt is a final quality gate for production RAG pipelines where the cost of a wrong answer is unacceptable. Its job is not to generate an answer, but to make a single, auditable go/no-go decision on whether an already-generated candidate answer is safe to surface to a user. It ingests the original user query, the full set of retrieved evidence, and the candidate answer from an upstream model. It then applies a structured policy to verify grounding, assess evidence sufficiency, and check for safety violations. The output is a binary gate decision with a detailed audit trail, enabling programmatic routing to the user, a human review queue, or a refusal message.

Use this prompt when you already have a working retrieval pipeline and an answer generation step, but need a reliable, policy-driven guardrail before the response reaches the user. This is essential in regulated industries (healthcare, finance, legal), customer-facing support where brand trust is on the line, clinical decision support, or any financial analysis workflow. The prompt assumes you are operating in a high-stakes environment where a confident hallucination is far worse than a refusal. It is designed to be wired into an application harness that can act on the gate decision—blocking, routing, or escalating the response based on the structured output. You should not use this prompt as a general answer quality scorer or for casual chatbot interactions where the business risk of an incorrect answer is low.

Do not use this prompt to generate answers, to rewrite the candidate answer, or to perform the initial retrieval. It is strictly a verification and decision step. If your application requires iterative evidence gathering, use the Evidence Sufficiency Agent Prompt instead. If you need a dimensional quality score rather than a binary gate, use the Evidence Sufficiency Scorecard Prompt. Before deploying this gate, you must calibrate its decisions against human-annotated ground truth for your specific domain. A gate that is too strict will frustrate users with unnecessary refusals; a gate that is too permissive will fail to catch hallucinations. Start by running this prompt against a golden dataset of known good and bad answers to establish your threshold for the decision field.

This prompt template implements a final answer readiness gate for production RAG systems. It is designed to sit between answer generation and the user, making a binary decision on whether a candidate answer is safe and grounded enough to surface. The gate does not generate content—it only evaluates. Copy the template below and replace the square-bracket placeholders with your runtime values before sending it to the model.

textCopy
You are a final answer readiness gate for a production RAG system. Your sole responsibility is to decide whether a candidate answer is safe and grounded enough to show to a user. You do not generate answers. You only evaluate them.

Evaluate the candidate answer against the provided evidence and safety policies. Make a binary decision: APPROVE or REJECT.

Follow these rules strictly:
1. Every factual claim in the candidate answer must be directly supported by at least one evidence passage. If a claim cannot be traced to a specific passage, flag it as ungrounded.
2. The answer must not contradict any evidence passage. If multiple passages conflict, the answer must acknowledge the conflict or abstain.
3. The answer must not introduce information not present in the evidence.
4. The answer must comply with all provided safety policies. Reject any answer that violates a policy even if grounded.
5. If the evidence is insufficient to answer the query, the candidate answer should state that clearly. An answer that speculates without evidence must be rejected.
6. Partial answers are acceptable only if they explicitly mark what is unknown and do not fabricate to fill gaps.

[SAFETY_POLICIES]
[EVIDENCE_PASSAGES]
[USER_QUERY]
[CANDIDATE_ANSWER]

Return a JSON object with the following structure:
{
  "gate_decision": "APPROVE" | "REJECT",
  "decision_rationale": "Brief explanation of the primary reason for the decision.",
  "grounding_score": 0.0-1.0,
  "ungrounded_claims": ["List of claims in the answer not supported by evidence"],
  "safety_violations": ["List of safety policies violated, if any"],
  "evidence_sufficiency_flag": "SUFFICIENT" | "PARTIAL" | "INSUFFICIENT",
  "audit_trail": [
    {
      "claim": "A specific claim from the answer",
      "supporting_passage_id": "Source ID or null",
      "grounding_status": "GROUNDED" | "UNGROUNDED" | "CONTRADICTED"
    }
  ]
}

To adapt this template for your system, replace [SAFETY_POLICIES] with your organization's specific content safety rules, such as prohibitions on medical advice, financial recommendations, or personally identifiable information disclosure. Replace [EVIDENCE_PASSAGES] with the retrieved chunks your RAG pipeline returned, each tagged with a unique source ID for traceability. The [USER_QUERY] and [CANDIDATE_ANSWER] fields should be populated at runtime from your generation step. The output JSON schema is designed to be machine-readable for downstream routing logic—use the gate_decision field to control whether the answer is shown, queued for human review, or discarded.

For high-stakes applications, do not rely on this gate alone. Pair it with a structured output validator that confirms the JSON schema is well-formed and that required fields like audit_trail contain entries for every factual claim in the candidate answer. If the gate model returns malformed JSON or an empty audit trail, treat that as a REJECT and escalate. Log every gate decision with the full audit trail for post-hoc review and eval pipeline integration. When tuning the gate, run it against a golden dataset of known grounded and ungrounded answer pairs to calibrate your grounding score thresholds before deployment.

Wire this prompt as a post-generation step in your RAG pipeline. The candidate answer generator runs first, then this gate prompt evaluates the output before it reaches the user. On REJECT, route to a fallback: log the rejection, surface a canned 'I cannot answer that' message, or escalate to a human queue. On APPROVE, log the full audit trail alongside the response for downstream compliance and debugging.

Use structured output mode (JSON mode) in your model API to enforce the schema. Set a timeout of 10 seconds; if the gate call fails or times out, default to REJECT to avoid surfacing unvalidated answers. Store gate decisions, grounding scores, and audit trails in your observability platform. Monitor APPROVE/REJECT ratios, grounding score distributions, and safety violation rates as core production metrics.

For high-stakes domains, add a human-in-the-loop override: when the gate returns APPROVE but the grounding score falls below a configurable threshold, route to a review queue before publishing the response. Log every gate invocation with the full prompt, model response, latency, and decision for debugging and audit. Avoid using this gate as a substitute for proper retrieval quality monitoring; it is a safety net, not a primary quality control.