S4.10 - Retrieval_query_and_index_ID

S4.10 ? Retrieval query and index ID

flowchart LR
    A[Traditional limitation:
citations visible but retrieval context hidden] --> B[RAIDT:
run-level evidence framework]
    B --> C[[Retrieval query and index ID]]
    H[Practical fields:
query string
rewritten query
collection or snapshot ID
vector index version
retrieval timestamp] --> C
    C --> D[Evidence pack:
retrieval provenance recorded]
    C --> E[RAIDT score profile:
Auditability Traceability Dependability]
    D --> F[Reviewer reconstruction
and contestability]
    E --> G[Governance readiness
organisational learning
policy alignment]

? Star S4 - Evidence Architecture and Artefacts

Star context: Specifies the concrete fields and artefacts that make a run record inspectable, reconstructable, and reviewable within RAIDT's evidence architecture.

Academic picture

Definition / background

Retrieval query and index ID are run-level evidence fields used when a generative AI system relies on retrieval-augmented generation, search, or any other external knowledge lookup. The retrieval query records the actual search request sent to the retrieval component. The index ID records the specific source space that was searched, such as a named document collection, a vector database snapshot, a policy library build, or another stable retrieval target. In combination, they show both what the system asked and where it looked.

Conceptually, this item sits between prompt evidence and source evidence. It is not the same as the user prompt, because the user prompt may be transformed into one or more internal retrieval queries. It is also not the same as final citations, because citations describe what appears in the answer, whereas retrieval provenance describes the source space and search event that informed generation. A system can produce polished citations while still leaving uncertainty about whether the correct corpus, snapshot, or search parameters were used.

In GenAI governance, this distinction matters because retrieval is often treated as a hidden implementation detail. RAIDT makes it explicit. If the run is the unit of governance, then the retrieval event inside that run must also be evidenced. Recording retrieval query and index ID allows a reviewer to inspect grounding conditions, compare runs executed against different knowledge bases, and test whether an answer was produced from the intended informational environment.

Within RAIDT, this item therefore belongs inside the run-level evidence pack. It contributes particularly strongly to Auditability and Traceability, while also supporting Dependability and Responsibility when organisations must show that staff were guided by the right knowledge source at the right time. It also improves interpretive clarity, because reviewers can separate failures caused by prompting, model behaviour, and retrieval configuration instead of collapsing them into one vague explanation.

Why this concept matters

This concept matters because retrieval-based systems can appear trustworthy while remaining evidentially weak. Without the retrieval query and index ID, an organisation may know that a model produced an answer, yet still be unable to show what corpus it searched, whether the corpus was current, or whether the retrieval step was appropriately targeted. That weakens review, challenge, and remediation.

Capturing these fields solves a practical governance problem. It prevents teams from relying on vague claims such as "the model searched the knowledge base" or "the answer was grounded in internal documents" without a reconstructable record of what actually happened. It also reduces confusion between three different layers of evidence: what the user asked, what the system searched, and what sources were finally cited or quoted.

If this information is missing, several risks appear. Reviewers cannot distinguish between a bad answer caused by an outdated index and a bad answer caused by poor prompting. Organisations cannot compare runs fairly across system updates. Incident investigation becomes slower and weaker because there is no stable way to reconstruct the retrieval context. In regulated or high-impact settings, this undermines claims of due care and weakens audit readiness.

RAIDT uses this item to move from principle-level governance to operational governance. Rather than asking whether retrieval is used in some general sense, RAIDT asks whether the specific retrieval event in a specific run can be evidenced, inspected, and contested.

Key idea: retrieval query and index ID matter because they turn hidden retrieval behaviour into run-level evidence that can be reviewed, compared, and governed.

What this item captures

The exact retrieval query text, transformed query, or structured search request used during the run.
The identifier of the searched index, collection, snapshot, corpus build, or vector store version.
The scope of the knowledge space that grounded the run at the time of execution.
The basis for linking retrieval behaviour to retrieved document IDs and hashes in S4.11 ? Retrieved document IDs and hashes.
Evidence needed to compare outcomes across different retrieval environments or index refresh cycles.
A review point for determining whether a failure arose from query formulation, corpus selection, or later generation behaviour.

Practical example / likely audience question

Audience question

If the final answer already includes citations, why does RAIDT also need the retrieval query and index ID?

Answer

The concern behind this question is the assumption that visible citations are enough to demonstrate grounding. They are not. Citations usually show what the answer refers to after generation, but they do not necessarily show what the system searched, which collection it searched, whether the collection was the correct one, or whether the retrieval environment had changed since an earlier run.

The direct answer is that citations are output-level artefacts, whereas retrieval query and index ID are process-level evidence. RAIDT needs both. If a staff-facing assistant answers a question about procurement rules and cites a policy PDF, a reviewer still needs to know whether the system searched the current procurement index or an outdated archive, and whether the query that drove retrieval was narrow, broad, or mis-specified.

A practical example makes the difference clearer. Suppose two runs cite the same document title, but one run queried the current compliance index and the other queried a legacy archive. The answers may look similar, yet the governance significance is different. RAIDT handles this better than a generic AI governance approach because it ties the answer to the exact run configuration and retrieval evidence, allowing reconstruction rather than inference.

Practical example in RAIDT terms

Consider a hospital using a GenAI assistant to help clinical administrators draft discharge summaries that must align with current local guidance. In one run, the operator asks for discharge advice for an adult asthma patient. The system converts that request into a retrieval query such as "adult asthma discharge criteria local protocol follow-up medication safety" and searches index respiratory_policy_index_2026_04_15.

The run-level issue is not simply whether the answer looks plausible. The real governance question is whether the answer was grounded in the correct knowledge environment. If a later review finds that the output omitted an updated follow-up requirement, RAIDT needs evidence showing whether the failure came from the model, the query transformation, or the fact that the run used an index that had not yet incorporated the newest protocol update.

The evidence needed would include the retrieval query, the index ID, the timestamp, the run ID, the model identifier, and the retrieved document IDs and hashes. The most affected RAIDT pillars are Auditability, Dependability, and Traceability, with Responsibility also engaged because the organisation must show reasonable control over the knowledge source used in a clinically consequential workflow. Recording this item improves governance readiness because it lets the hospital reconstruct the retrieval context during supervision, incident review, and policy assurance.

Detailed link to RAIDT

Retrieval query and index ID link to RAIDT in four ways.

First, they support RAIDT's core idea that governance should attach to the run rather than to abstract system claims.
Second, they make one crucial part of the run inspectable by showing what source space was queried and under which retrieval context.
Third, they strengthen the evidence pack and the score profile by giving reviewers concrete retrieval provenance rather than relying on output appearance alone.
Fourth, they support reviewability, contestability, audit readiness, and organisational learning because failures can be traced back to retrieval conditions instead of being treated as unexplained model behaviour.

Retrieval query and index ID ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

In other words, this item operationalises the relationship between external knowledge access and accountable AI use. It gives RAIDT a practical way to examine whether grounding was merely claimed or actually evidenced.

Link to the five RAIDT pillars

Responsibility

This item supports Responsibility by showing whether the organisation directed the system towards an appropriate and governed knowledge source for the task at hand. It helps demonstrate that reliance on retrieval was not careless or undefined.