From an 'Ask the Record' Question to a Cited Fact

The question seems simple enough: "When did the defendant first learn of the defect?" A junior associate types it into a review platform, hits enter, and receives an answer in seconds. But what the platform returns - and how it returns it - is the difference between a tool that accelerates discovery and one that creates a new category of professional risk.

I have spent years building systems that connect questions to documents, and in that time I have learned to distrust any answer that does not show its work. The retrieve-cite-verify loop exists because litigation, unlike most information work, carries a formal obligation to the record. An attorney cannot tell a court that the AI said so. The attorney must be able to point to the page, the paragraph, the exhibit number - and that chain of traceability, from the plain-language question to the source document, is what this guide is designed to walk you through, step by step, with a concrete example at every stage.

What Does "Ask the Record" Actually Mean?

When I say "ask the record," I mean a specific and bounded workflow: you pose a natural-language question to a system that has already indexed every document in your case corpus, and the system returns a synthesized answer drawn exclusively from those documents - not from its training data, not from the open web, not from any source outside the defined collection. The record is the ceiling and the floor. Whatever the system finds inside it, and only that, becomes the basis of its response.

This is the operating principle behind retrieval-augmented generation, commonly abbreviated RAG. In a RAG-based system, the language model does not rely on memorized facts baked into training weights. It retrieves relevant passages from a controlled document set, uses those passages as grounding context, and generates an answer that is, in theory, entirely attributable to what was retrieved. The theory holds - when the citation architecture is built correctly and the verification step is not skipped, as of July 2026.

In legal discovery, "the record" is not an abstraction. It is a defined, bounded collection of documents: production sets, deposition transcripts, internal communications, expert reports, contracts, privilege logs. Every document has provenance. Most documents have Bates numbers - sequential identifiers that function as coordinates in a litigation file, the way GPS coordinates function in physical space. When a system returns a cited answer, it is not enough that the answer be accurate in some general sense; it must be traceable to a specific Bates range or exhibit designation that an opposing party, a judge, or a paralegal can locate and verify in the original.

The legal AI market has converged on this architecture. Logikcull's ASK engine, for instance, is described by the company as returning "a synthesized, cited answer drawn directly from the documents in the matter" - attorneys type plain-language questions like "Who knew about the policy change and when?" and receive evidence-backed responses rather than keyword-search result lists. Similarly, Relativity's aiR Assist is built so that "every meaningful statement ties back to specific documents and excerpts" for verification and defensibility. The principle is shared: every answer needs a return address in the record.

The distinction between an ask-the-record system and a general chatbot is precisely this: the chatbot's answer lives in the model's training weights, invisible and unverifiable. The ask-the-record answer lives in the documents you produced and can be confirmed by anyone with access to the production set. That difference is not a luxury in professional practice. In litigation, it is the line between a response you can rely on and one you cannot afford to use.

In summary, "asking the record" is a closed-loop process in which a natural-language question is answered with sourced, Bates-stamped passages from a defined case corpus - and the loop is not complete until an attorney has verified each source in its full document context.

Step 1: Retrieve - How the System Surfaces Relevant Passages

Retrieval is the first and most consequential step in the loop. If the wrong passages surface - or too few, or too many unfocused ones - no amount of sophisticated generation will produce a trustworthy answer. The retrieve step determines the quality ceiling for everything that follows.

In practice, most production-grade legal AI systems use hybrid retrieval: a combination of BM25 keyword matching and dense vector search. BM25 (Best Match 25) is a classical information retrieval algorithm that scores documents based on term frequency and inverse document frequency - it rewards passages that contain the exact words from your query and penalizes terms that appear so frequently across the corpus that they carry no discriminating signal. Vector search, by contrast, converts both the query and the documents into numerical representations called embeddings, and retrieves passages whose semantic meaning is closest to the query's meaning, even when the exact words differ.

Neither approach alone is sufficient for legal work. BM25 catches precise statutory citations, defined contract terms, and proper nouns - the kinds of specificity that litigation depends on. Vector search catches paraphrases, synonyms, and conceptual proximity. As Logikcull's documentation observes of its semantic expansion approach: "If a custodian wrote 'the numbers look off' instead of 'financial fraud,' a keyword search misses it." Hybrid retrieval runs both approaches in parallel and merges the ranked results, typically using a reciprocal rank fusion algorithm, to produce a final passage set ordered by combined relevance.

In my experience building retrieve pipelines for litigation document sets, the most useful retrieve results surface between eight and fourteen high-ranking passages for a well-formed question. Too few and the answer lacks coverage, missing corroborating evidence that could strengthen a finding. Too many and the generation model begins to blend lower-relevance passages into its synthesis, which is how subtle inaccuracies enter a response that looks authoritative on its surface.

The retrieve step also applies pre-retrieval filters before any passage reaches the ranking stage: date ranges, document type, custodian, and - critically - privilege status. A document coded as privileged must not appear in any retrieve result, regardless of how semantically relevant it is to the query. The filter layer is not optional in a legal RAG system; it is a gating mechanism that enforces the same rules that would apply to a document produced in manual review. Without it, the system is not a legal tool. It is a liability.

Relativity's aiR Assist operates on hundreds of thousands of documents per index and allows queries to span multiple indexes within a single workspace - a signal that production-quality legal retrieval is measured in document scale, not query cleverness. The question is never whether the documents are there. The question is whether the retrieve layer can find the right ones, filtered and ranked, before the generation model ever sees them.

In summary, the retrieve step is where precision is established: the right passages, filtered for privilege and relevance, ranked by a hybrid of keyword and semantic signals, limited to a count that the generation model can faithfully synthesize.

Step 2: Cite - How Each Passage Gets Tied Back to Its Source Exhibit

Retrieval produces passages. The cite step transforms each passage into a verifiable reference. This is where the difference between a useful legal AI tool and a professionally risky one becomes visible - not in the answer text, but in the metadata that travels with each passage from retrieval through synthesis.

A citation in this context is not a footnote appended as an afterthought. It is structured metadata assembled at the moment of retrieval: the source document's file identifier, its Bates number or exhibit designation, the page and paragraph from which the passage was extracted, the custodian who held the document, and the production batch it came from. When the generation model synthesizes the answer, it does not simply weave passages together into fluent prose; it preserves and propagates that metadata so that every claim in the synthesized answer can be traced to a specific passage, and that passage to a specific location in the record.

The industry standard for what good citation looks like is becoming clear. Logikcull's ASK engine commits to "no black-box output, only evidence-backed answers that attorneys can review, verify, and stand behind in court" - with direct links to originating documents included in every response. Relativity's aiR Assist anchors "every meaningful statement" to "specific documents and excerpts so you can verify and defend the result." The framing is identical because the requirement is identical: the citation chain is the answer's proof of existence.

From what I have seen in systems that implement this well, the output takes a consistent and readable form: a synthesized answer of three to five sentences, followed by a numbered citation list where each entry includes the source document name, the Bates range, and a deep link that opens the document at the exact page - not the first page of a 200-page PDF, but the page where the cited passage appears. The attorney reads the answer, reads the citations, and can follow any link directly to the underlying exhibit without navigating away from the interface.

The critical engineering decision in the cite step is what happens to passages that are retrieved but not ultimately used in the synthesized answer. In a defensible system, those passages are still logged in the retrieve record - their retrieval signals something about the question and the corpus that may be relevant even if the generation model chose not to surface them in the final response. An attorney who wants to see what else the system found should be able to pull that full retrieve log. The log is itself a form of documentation about how the question was answered and what the corpus contained at the time of query.

TIP: The cite step is only as strong as the document processing that preceded it. Documents that were OCR-processed poorly, split at incorrect boundaries, or loaded without their Bates metadata intact will produce citations that cannot be located in the original - which defeats the purpose of the entire architecture. Ingestion quality is not a secondary concern; it is a prerequisite for every citation that follows.

In summary, the cite step anchors every retrieved passage to its origin in the record, transforming the synthesized answer from a generated opinion into a traceable artifact where every claim has a verifiable address in the case corpus.

Step 3: Verify - How Attorneys Confirm the Answer Against the Original

The verify step is the one that most AI vendors underemphasize, because it reintroduces the human into what many pitch as an automated workflow.

But in litigation, the human is not the bottleneck to be eliminated. The attorney is the professional with a duty of competence and candor to the tribunal, and the verify step is where that duty is discharged - not delegated to a model.

Verification looks like this: the attorney receives the synthesized answer along with its citation list. She reads the answer. She follows the first citation link to the original exhibit - the PDF, the email thread, the deposition transcript - and locates the specific passage the system cited. She reads it in context. She asks: does the passage actually support what the answer says? Is there qualifying language in the surrounding paragraph that changes the meaning? Is the cited passage taken from a section that, read in full, says the opposite?

That last question is not hypothetical. Language models, even those grounded entirely in retrieved text, can over-weight a fragment that, in its full document context, is qualified, conditional, or explicitly contradicted a paragraph later. The verify step exists to catch exactly this. The attorney is not checking whether the AI made a grammatical error. She is checking whether the answer accurately reflects what the record says in context - not what the record says in extraction, which is a different thing entirely.

The efficiency gains from this workflow are real. KPMG's forensic technology team reports getting citation-backed answers in "hours instead of weeks" using Relativity's aiR Assist - an outcome that comes not from eliminating review but from giving attorneys a precise starting point. As Steven Lutkus of KPMG put it: "the early decisions are informed ones, not guesses." In my experience, a well-trained litigation team can verify a four-citation answer in under ten minutes per citation when the source links are direct and the document interface is responsive. That is materially faster than locating the same passages through manual search of a full production set.

The verify step also creates an audit trail. Every citation that an attorney clicks, reads, and either accepts or flags as inaccurate becomes a record of how the answer was validated. That audit trail may matter if the AI-assisted research is later scrutinized - in a deposition, in a Daubert hearing, or in a bar complaint. As Logikcull frames the standard: AI-assisted review is defensible "when the AI is transparent, verifiable, and auditable." The verify step, with its logged review activity, is what makes that claim true rather than aspirational.

In summary, verification is where AI-assisted research becomes defensible attorney work product - and the audit trail it creates is as important to the professional record as the answer itself, because the audit trail is the answer's proof of competent review.

What Makes an AI Answer Defensible in Litigation?

Defensibility is not a property of the answer text. It is a property of the process that produced the answer and the documentation that records that process.

A generated answer can be accurate in every particular and still be professionally indefensible if the attorney cannot demonstrate how it was produced, what it was based on, and who reviewed it before it was used.

From what I have built and observed, a defensible AI answer in litigation requires four elements to be present simultaneously:

Courts have increasingly accepted AI-assisted review - including technology-assisted review (TAR) and predictive coding - as defensible "when the producing party can explain and document the process." That phrase, from Logikcull's analysis of judicial reception, sets the minimum bar: the process must be explainable, and the documentation must exist. The four elements above are what explainability looks like in practice.

There is also a narrower technical boundary to understand. Systems like Relativity's aiR Assist are explicitly built to return "strong, representative evidence - not every instance of something" - and are not appropriate for questions like "give me all emails from X" or "how many documents mention Y." Those are completeness queries, not insight queries, and they require exhaustive review tools rather than grounded-answer tools. Knowing which question type you are asking is part of making defensible use of either approach.

From what I have seen in the market, most AI tools marketed to law firms satisfy one or two of the four defensibility elements. Very few satisfy all four, and the ones that do not tend to discover this gap at the worst possible moment - when a citing attorney is asked in open court to identify the document the AI actually read.

In summary, a defensible AI answer requires source traceability, privilege enforcement, human verification, and strict corpus scope - all of them documented, all of them auditable, and none of them optional when the answer may appear in a brief, a pleading, or any court-filed document.

How Relevant Discovery Powers the Retrieve-Cite-Verify Loop

Relevant Discovery was built around a single conviction: that the retrieve-cite-verify loop is not a workflow to be approximated or aspired to.

It is a technical architecture that must be implemented with precision at every layer, or it fails the moment an attorney follows a citation link and finds something different from what the answer claimed.

The platform indexes every document in the case corpus before a single query is run. Documents are split into passage-level chunks at processing time, with each chunk carrying its source metadata: document name, Bates range, page number, custodian, production batch, and privilege designation. That metadata is stored alongside each chunk's vector embedding, so retrieval and citation happen simultaneously and from the same data structure. There is no post-hoc attribution step. No system trying to infer which document a passage came from after synthesis has already occurred.

When an attorney poses a question, the hybrid retrieval engine surfaces the highest-ranked passages across the full corpus, pre-filtered by any scope parameters the attorney has set - date range, custodian, document type, production set. The generation step uses only those retrieved passages as context; the model has no access to any information outside the scope. The resulting answer is presented with inline citation markers and a citation panel that displays the full source reference for each marker, with a direct link to the document at the cited page.

The verify step is built into the interface as a first-class feature, not an afterthought. Each citation link opens the source document in a side panel, with the cited passage highlighted in context. The attorney does not need to navigate to a separate document management system, reconstruct a Bates range, or search within a PDF. The verification workflow takes seconds per citation rather than minutes - which means attorneys actually use it rather than skipping it under time pressure.

From what I have seen over years of refining this architecture, the single most important design decision is not the choice of language model or embedding dimension. It is whether the citation chain is built at indexing time or assembled after generation. Systems that build the chain at indexing time - where every chunk already knows exactly which document, page, and Bates range it came from - produce citations that hold up under verification. Systems that attempt to attribute answers to sources after the generation step produce citations that drift: the passage the attorney reads is related to, but not identical to, what grounded the answer.

Relevant Discovery also addresses one of the most consistently underserved questions in legal AI: how to reduce the cost of document review in litigation without sacrificing the completeness that discovery obligations require. The answer is not to replace review - it is to compress the discovery phase that precedes review, so attorneys spend targeted hours on documents the record has already identified as relevant, rather than undifferentiated hours on documents that may or may not matter.

In summary, Relevant Discovery implements the full retrieve-cite-verify loop as a first-order architectural requirement - citation chains built at index time, verification built into the interface, and a scope boundary that keeps every answer inside the record and out of the territory where citations drift and defensibility fails.

What a Retrieve-Cite-Verify Response Looks Like

Below is the structured output format that a well-architected ask-the-record system produces. Every field serves a verification purpose: the answer is what the attorney reads first; the citations array is what she verifies; the retrieve_log is what she - or opposing counsel - audits. This mirrors what leading platforms like Logikcull and Relativity describe as the "no black box" standard: evidence-backed answers with direct links to originating documents.

{
  "answer": "The defendant first learned of the thermal regulation defect on March 14, 2019, based on an internal engineering memo circulated to the product safety team.",
  "citations": [
    {
      "citation_id": 1,
      "passage": "Per the attached thermal drift analysis, the product safety team was notified of out-of-spec readings on 14 March 2019.",
      "source_document": "Exhibit 47 - Internal Engineering Memo",
      "bates_range": "DEF-ENG-004521 to DEF-ENG-004522",
      "page": 2,
      "custodian": "R. Hollis (Product Safety)",
      "deep_link": "/documents/DEF-ENG-004521?page=2&highlight=thermal+drift"
    }
  ],
  "retrieve_log": {
    "passages_retrieved": 11,
    "passages_used": 1,
    "query_timestamp": "2026-07-15T14:32:07Z",
    "corpus_scope": "Production Set A - Engineering Documents",
    "privilege_filtered": 2
  }
}

The retrieve_log reveals that 11 passages were retrieved, 2 were privilege-filtered before reaching the model, and the generation step used only 1 of the 11 to ground this particular answer. The remaining 10 are available for attorney review in the full retrieve log - the complete record of what the system found and chose not to use.

What Will Matter Most in the Next 12 - 24 Months?

The retrieve-cite-verify loop is not static. The architecture will evolve in several directions over the next two years, and understanding where it is heading matters as much as understanding where it stands today.

Citation standards will become mandatory, not differentiating. Right now, source-linked answers are a premium feature that separates better legal AI tools from generic ones. In the next 12 to 24 months, citation architecture will become a baseline expectation - required by court rules, bar guidance, or institutional procurement standards. The firms and vendors that have not built citation traceability into their architecture will face adoption barriers they cannot quickly remedy with a software patch.

Privilege filtering will be audited, not assumed. As AI-assisted discovery becomes more common, challenges to privilege filter reliability will follow. Expect courts and opposing counsel to ask not just whether a privilege filter was applied, but how it was configured, when it was last updated, and whether there is a log of what it excluded. Systems that can produce a privilege filter audit trail will be materially more defensible than those that treat privilege as an on/off flag with no documentation.

The verification interface will become the key differentiator. Language models will continue to improve, and retrieval quality will converge toward a competitive floor. The surface on which attorneys actually verify citations - how fast it loads, how accurately it highlights the cited passage, how well it preserves document context - will become the primary variable in tool adoption. In my view, the platforms that invest in the verification interface rather than the generation step will win the next phase of legal AI competition.

Multi-index and cross-matter retrieval will expand. Today, most RAG deployments scope retrieval to a single production set or matter. The next generation will allow attorneys to query across related matters, prior case archives, or deposition repositories - while maintaining per-matter privilege boundaries. This expansion creates new citation complexity: an answer that draws from two different production sets requires a citation format that distinguishes its sources clearly and unambiguously.

In summary, the trajectory is toward deeper verification, more auditable privilege management, and a more sophisticated citation format - all of which raise the floor for what "defensible" means in AI-assisted legal research.

A plain-language question becomes a cited fact through three steps that cannot be shortcut and cannot be reordered: retrieve the passages from the right corpus, with the right filters in place; anchor each passage to its source exhibit at the moment of retrieval, not after synthesis; and give the attorney the direct links she needs to verify the answer against the original before she uses it. Each step is necessary. None is sufficient alone. The retrieve-cite-verify loop is not a feature - it is the minimum architecture for making AI-assisted legal research defensible.

From what I have seen over years of building these systems, the attorneys and firms that get the most out of AI-assisted document review are the ones who understand that the answer is a starting point, not a deliverable. They verify every citation. They follow every link. And in doing so, they transform a generated response into something far more valuable: a researched finding with a traceable chain back to the record - which is, in the end, what every cited fact in a brief has always required.

If you want to see how the retrieve-cite-verify loop works on your own case documents, Relevant Discovery offers RAG-powered evidence search built specifically for litigation - with citation chains anchored at indexing time, not assembled after generation.