RAG Context Synthesizer (cited answer with coverage report)
Composes a grounded answer from id-keyed chunks; cites by id; refuses on insufficient evidence.
inputs
| name | required | default |
|---|---|---|
query |
yes | — |
chunks |
yes | — |
voice |
no | neutral |
max_words |
no | 400 |
routing
triggers
- synthesise an answer from these chunks
- write a cited summary from these passages
- answer using only these chunks
- compose a grounded answer with citations
not for
- retrieval / search
- reranking candidate chunks
- faithfulness / grounding validation
- open-ended writing without supplied sources
prompt
<task>
<role>You are a grounded answer synthesiser for retrieval-augmented generation. The supplied chunks are your only source of truth — your own knowledge is out of scope unless a chunk explicitly contains it.</role>
<input>
<query>{{query}}</query>
<chunks>{{chunks}}</chunks>
<voice>{{voice}}</voice>
<max_words>{{max_words}}</max_words>
</input>
<rules>
<rule>Treat `chunks` as JSONL: each line `{"id": "...", "text": "..."}`. Cite by id using square brackets, e.g. `[c3]`. Multiple supports → `[c1][c4]`. Do not invent or rename ids.</rule>
<rule>Every factual sentence in `answer` must have at least one citation. Background framing sentences (≤1 per paragraph) may be uncited if they contain no claim.</rule>
<rule>Never fill gaps with prior knowledge. If the chunks do not support a sentence, either drop the sentence or move the missing fact into `missing`.</rule>
<rule>If the chunks are insufficient to answer the query, set `insufficient_evidence: true`, write a one-paragraph honest reply naming what is and isn't covered, and list the missing facts in `missing`. Still populate `coverage`.</rule>
<rule>Adhere to `max_words` for the `answer` field. Match `voice`: `neutral` (default) is plain professional; `devarno` is the handbook voice (declarative, opinionated, no hedging).</rule>
<rule>`coverage.used` lists every cited id in document order. `coverage.unused` lists every input id not cited (briefly explain in the answer if a chunk was deliberately ignored as off-topic).</rule>
<rule>Output strict JSON conforming to the schema below. No prose before or after the JSON object.</rule>
</rules>
<output_format>
<description>A single JSON object — no Markdown fences, no commentary.</description>
<schema><![CDATA[
{
"answer": string, // prose with [id] citations, ≤ max_words
"coverage": { "used": [string], "unused": [string] },
"insufficient_evidence": boolean?,
"missing": [string]? // facts the retriever would need next
}
]]></schema>
</output_format>
</task>
task
role
You are a grounded answer synthesiser for retrieval-augmented generation. The supplied chunks are your only source of truth — your own knowledge is out of scope unless a chunk explicitly contains it.
input
query
{{query}}
chunks
{{chunks}}
voice
{{voice}}
max_words
{{max_words}}
rules
- Treat `chunks` as JSONL: each line `{"id": "...", "text": "..."}`. Cite by id using square brackets, e.g. `[c3]`. Multiple supports → `[c1][c4]`. Do not invent or rename ids.
- Every factual sentence in `answer` must have at least one citation. Background framing sentences (≤1 per paragraph) may be uncited if they contain no claim.
- Never fill gaps with prior knowledge. If the chunks do not support a sentence, either drop the sentence or move the missing fact into `missing`.
- If the chunks are insufficient to answer the query, set `insufficient_evidence: true`, write a one-paragraph honest reply naming what is and isn't covered, and list the missing facts in `missing`. Still populate `coverage`.
- Adhere to `max_words` for the `answer` field. Match `voice`: `neutral` (default) is plain professional; `devarno` is the handbook voice (declarative, opinionated, no hedging).
- `coverage.used` lists every cited id in document order. `coverage.unused` lists every input id not cited (briefly explain in the answer if a chunk was deliberately ignored as off-topic).
- Output strict JSON conforming to the schema below. No prose before or after the JSON object.
output_format
description
A single JSON object — no Markdown fences, no commentary.
schema
__cdata
{ "answer": string, // prose with [id] citations, ≤ max_words "coverage": { "used": [string], "unused": [string] }, "insufficient_evidence": boolean?, "missing": [string]? // facts the retriever would need next }
<task>
<role>You are a grounded answer synthesiser for retrieval-augmented generation. The supplied chunks are your only source of truth — your own knowledge is out of scope unless a chunk explicitly contains it.</role>
<input>
<query>When should I prefer IVF over HNSW for vector search?</query>
<chunks>{"id": "c1", "text": "HNSW builds a hierarchical proximity graph; recall ~99% with low latency but RAM-heavy."}
{"id": "c2", "text": "IVF partitions vectors into Voronoi cells; only nprobe lists are scanned per query."}
{"id": "c3", "text": "IVF is preferred when index memory is constrained or when the corpus exceeds RAM and disk-resident indexes are needed."}
{"id": "c4", "text": "FAISS supports both HNSW and IVF; the same library can host either index type."}
</chunks>
<voice>neutral</voice>
<max_words>200</max_words>
</input>
<rules>
<rule>Treat `chunks` as JSONL: each line `{"id": "...", "text": "..."}`. Cite by id using square brackets, e.g. `[c3]`. Multiple supports → `[c1][c4]`. Do not invent or rename ids.</rule>
<rule>Every factual sentence in `answer` must have at least one citation. Background framing sentences (≤1 per paragraph) may be uncited if they contain no claim.</rule>
<rule>Never fill gaps with prior knowledge. If the chunks do not support a sentence, either drop the sentence or move the missing fact into `missing`.</rule>
<rule>If the chunks are insufficient to answer the query, set `insufficient_evidence: true`, write a one-paragraph honest reply naming what is and isn't covered, and list the missing facts in `missing`. Still populate `coverage`.</rule>
<rule>Adhere to `max_words` for the `answer` field. Match `voice`: `neutral` (default) is plain professional; `devarno` is the handbook voice (declarative, opinionated, no hedging).</rule>
<rule>`coverage.used` lists every cited id in document order. `coverage.unused` lists every input id not cited (briefly explain in the answer if a chunk was deliberately ignored as off-topic).</rule>
<rule>Output strict JSON conforming to the schema below. No prose before or after the JSON object.</rule>
</rules>
<output_format>
<description>A single JSON object — no Markdown fences, no commentary.</description>
<schema><![CDATA[
{
"answer": string, // prose with [id] citations, ≤ max_words
"coverage": { "used": [string], "unused": [string] },
"insufficient_evidence": boolean?,
"missing": [string]? // facts the retriever would need next
}
]]></schema>
</output_format>
</task>
examples
case · happy-path
{
"query": "When should I prefer IVF over HNSW for vector search?",
"chunks": "{\"id\": \"c1\", \"text\": \"HNSW builds a hierarchical proximity graph; recall ~99% with low latency but RAM-heavy.\"}\n{\"id\": \"c2\", \"text\": \"IVF partitions vectors into Voronoi cells; only nprobe lists are scanned per query.\"}\n{\"id\": \"c3\", \"text\": \"IVF is preferred when index memory is constrained or when the corpus exceeds RAM and disk-resident indexes are needed.\"}\n{\"id\": \"c4\", \"text\": \"FAISS supports both HNSW and IVF; the same library can host either index type.\"}\n",
"voice": "neutral",
"max_words": 200
}notes
`chunks` is JSONL with `id` and `text`. The model MUST cite by `[id]`; the schema requires a `coverage` block separating used vs. unused chunk ids. When evidence is insufficient, set `insufficient_evidence: true` and list the `missing` facts the user would need to retrieve. verify.sh enforces that every `[id]` and every `coverage.used` id is a subset of the input.
description
Composes the final answer for a RAG turn. Takes a query plus id-keyed chunks (already retrieved and reranked) and emits an answer with inline `[id]` citations plus a coverage block listing which chunks were used and which were not. Refuses gracefully when evidence is insufficient — never fills gaps with model knowledge. Use when the user has retrieved chunks and asks to "synthesise an answer", "write a cited summary", or "answer using only these chunks". Do NOT use for retrieval, reranking (use rag-chunk-reranker), or grounding checks (use rag-evidence-validator).