Retrieval Context and the Search Bridge

Grounded answers depend on retrieval — pulling evidence from the StretchSearch index so StretchGPT can cite real sources. This article explains the retrieval context that powers grounding, how operators can inspect it, and the safety and audit guarantees that surround it.

What retrieval context is

When StretchGPT needs evidence, it queries the StretchSearch index and gets back a bundle of retrieval context: evidence chunks (the actual passages), candidate signals, and the sources those passages came from. Each evidence chunk carries a citation key so it can be cited in an answer as [n]. This bundle is exactly what makes grounded, citable answers possible.

Retrieval is evidence-only from the index. StretchGPT does not fetch pages from the live web or scrape sites — it only reads what StretchSearch has already indexed. That's a deliberate safety boundary.

Inspecting retrieval as an operator

Operators can run a retrieval query directly to see what evidence a question would surface:

1. Open the retrieval inspector in the StretchGPT console (the /retrieval/context capability).
2. Enter your query.
3. Optionally set a limit (how many results, up to 25; the default is 8) and narrow by project, crawl job, or page if you want to scope the evidence.
4. Run it. You'll see the evidence chunks, candidate signals, the source list with URLs, and the citation keys that would be used.

This is invaluable for diagnosing grounding: if a user complains that answers aren't cited, you can run their question here and see whether the index has anything to ground on.

Safety and audit

Retrieval is one of the most carefully governed parts of StretchGPT:

• Dry-run and retrieval-only — the retrieval path reads from the index and never triggers crawling, scraping, or model mutation.
• No network fetch by StretchGPT — evidence comes only from the StretchSearch index, never a live fetch.
• Fully audited — every retrieval creates a job record, writes a completed result summary, and emits an audit event capturing the query, how many evidence chunks and sources were found, and the citation keys. The write scope is limited to job-result and audit metadata — retrieval never writes model or dataset changes.

This means you always have a trail of what was retrieved for which query, without any risk that retrieval reached outside the index or changed anything.

A realistic example

A user reports that questions about a specific product never come back cited. You open the retrieval inspector and run their exact question with a limit of 10. The result shows zero evidence chunks — the index simply has nothing on that product yet. That tells you the fix isn't in StretchGPT at all: the product's content needs to be crawled and indexed in StretchSearch. Once it is, you re-run the query, see evidence chunks with citation keys, and grounded answers start appearing.

Tips

• Use the inspector to triage grounding complaints. Empty results mean an indexing gap, not a StretchGPT bug.
• Scope with project/page filters when you want to check whether a specific source is retrievable.
• Keep limits modest. The default of 8 is usually enough; higher limits return more but rarely change the top evidence.
• Check the audit trail when you need to prove what evidence informed an answer.

FAQ

Does StretchGPT crawl the web to answer me? No. It only reads evidence already in the StretchSearch index. Crawling and scraping are separate, gated functions that StretchGPT's retrieval path never triggers.

Why did an answer have no citations? The index had no matching evidence for that query. Improve coverage in StretchSearch, or expect a general-knowledge answer that says it isn't grounded.

Is every retrieval logged? Yes — each retrieval writes a job record, a result summary, and an audit event with the query and evidence counts.