Request lists that are indexed, so the same question is not answered twice

What a request list actually contains

A request list is the structured spine of a diligence process. It has three levels. Categories sit at the top (financial, legal, commercial, HR, tax, and so on). Topics sit inside categories. Individual requests sit inside topics, and a request is the unit that actually gets answered.

Each request carries a title, the section it belongs to, a description of what is being asked for, an owner, a status, and a set of links to the documents that answer it. Those links have their own state: proposed, or confirmed by a person. The list itself carries metadata that matters more than it looks like it should, including which organisation owns it, its review status as it moves from drafting to the seller and on to approved, and which other parties it has been shared with. That metadata is what later decides who is allowed to see a request, and what a machine is allowed to read when it drafts against one.

Lists get built three ways. You can describe the deal in prose and get a generated draft list plus a matching folder tree. You can start from a saved template. Or you can import a spreadsheet, which is what most teams actually have.

How a client's spreadsheet becomes a structured list without being retyped

The spreadsheet path is worth explaining because it is where transcription errors normally enter. Real diligence checklists are messy. Categories appear as sparse header rows in some files, as a repeated value in a column in others, and as one tab per category in others again. There are index tabs and summary tabs that must be ignored.

The model is not asked to read the requests out. It is shown every row of every tab, with cells truncated, and asked to return a reading plan: which sheets hold requests, where the header row and the first data row are on each, and where each field comes from. The source of a field is restricted to a small fixed vocabulary (a column, a repeated cell value, a category row, the sheet name, or nothing). That plan is then validated. An unknown source type, a negative column index, or a category-only source used for a per-row field all cause the import to fail loudly instead of producing a short, plausible, wrong list. A title column pointed at the description column is corrected rather than rejected: the title source is dropped and the description text is used.

Once the plan passes validation, the application executes it mechanically against the raw cells. Because the model never transcribes the content, a request cannot be paraphrased, silently merged with its neighbour, or invented. The import reports how many rows it mapped against how many rows exist, and flags a material gap against the model's own expectation of what it should have found. Rows it cannot place go into an explicit uncategorised bucket rather than disappearing.

What it means for a request to be indexed alongside documents

A request's title, section and description are embedded the first time it is scored against something, and that vector is cached in the same index as document vectors. Documents are embedded from their generated summary and extracted text after upload.

The practical effect is that requests and documents sit in one comparable space. A file can be scored against every open request. A request can be scored against every file. And a request can be scored against every other request, which is the part that makes answer reuse possible at all.

There are two constraints on that index worth stating. A document is represented by a single vector built from a truncated version of its text, so a long agreement is represented mainly by its opening and the index cannot point at a specific clause deep inside it. And enrichment runs in the background after upload, so a file whose extraction failed is stored and viewable but carries no vector, which makes it invisible to matching until it is reprocessed. Scanned PDFs with no extractable text layer are the common case here.

How a new request gets matched to an answer the team already produced

The similarity scan is run by the deal team, either against one request or across every request in the deal that is not already answered or published. It embeds the target request and compares it against other requests in the deal that are not already published or answered. Where a pair scores above the bar, the system records a proposed link between them. Existing links in either direction are skipped, so re-running a scan does not pile up duplicates.

Proposed links are hidden from buyer-side users until they have been reviewed. The deal team reviews each one and takes one of three actions.

Approve in full. The confirmed answer documents attached to the earlier request are copied onto the new one and marked confirmed. The same item is answered once, with the same files, and the counterparty who asked second gets the answer without anyone re-assembling it.

Approve in part. This requires a written description of the gap. The earlier answer covers most of the new request but not all of it, and the delta is recorded rather than left as an assumption.

Dismiss the link. The two requests scored as similar but are not asking for the same thing.

The other side has a route back. A buyer-side user can dispute a merge with a stated reason, which puts the question in front of the deal team again rather than leaving the requester stuck with an answer they believe does not respond to what they asked.

Why the confirmation step is deliberate

The obvious question is why the match does not just apply itself. The answer is that the confirmation is doing several jobs that automation would do badly.

Two requests can score as similar without asking for the same thing. "Audited financials for the last three fiscal years" and "audited financials for the last five fiscal years" are close in any embedding space and different in a way that matters. So are two requests that differ only by entity, subsidiary, or jurisdiction. A person reading both takes seconds to see the difference.

The bar is set to be permissive on purpose. A strict threshold would miss genuine duplicates written in different house styles, which is the whole point of the feature. A permissive threshold surfaces the borderline pairs, and accepts that some of them will be wrong. That trade only works if a person is the one deciding.

Audience matters as much as content. A request approved for one counterparty may be scoped differently for another, and the documents attached to the earlier answer may not be readable by the party now asking. Where the platform drafts material that will go to the other side, the documents it may quote are scoped to what that side is permitted to read, using the intersection when several parties can see the list. Inheriting an answer across parties is a disclosure decision, and disclosure decisions belong to the deal team.

Finally, there is the record. What was disclosed, to whom, and when it was decided is the part of a data room that gets read back later. A confirmed link with a named approver, and a written gap description on partial approvals, is a defensible record. An automatic merge is not.

The cost of the step is low. Reviewing a proposed pair is much faster than answering the request again, and the scan is what removes the harder work of noticing the duplicate in the first place.

How the same index handles files rather than requests

The reverse direction works the same way and follows the same rule about human confirmation. When a file is uploaded, it is scored against the open requests and the best match is recorded as a proposed answer, always, regardless of score, so nothing gets silently dropped. The interface then splits confident matches from ones that need review.

Bulk operations exist for the backlog. You can match a set of unlinked files against a whole list, or find the files that answer one request. Both have a preview that scores exactly as the real run does and writes nothing, so you can see what would happen before it happens. Bulk matching is additive and never overwrites a link a person already confirmed. There is also a reorganisation action that rebuilds the room's folders around a list's categories and files documents into them, sending anything below the confidence bar to a review folder rather than guessing. Folders created that way carry none of the old structure's per-folder grants, and in the external room they are created visible to buyer organisations, so access has to be narrowed deliberately straight after the run. More detail on the access model is on our security page.

What this does not do

Answer reuse of this kind exists on the request side. On the Q&A board, duplicate detection is lexical rather than semantic. It groups open threads that share keywords in their titles, it looks only at titles and not at the body, it is shown only to the deal team, and it does not compare a new question against answers already published on the shared board. Someone asking a question that has already been answered publicly gets no signal.

Scans are triggered rather than continuous, so a list that has not been scanned since the last batch of requests arrived will not have proposed links waiting.

Matching and retrieval compare against every stored vector on each query. That is fine for rooms with hundreds of documents and is not the right design for a room with tens of thousands.

And there is no engine that reconciles figures across documents. The chat surface is instructed to state disagreements and cite each figure with its source, but nothing extracts numbers, normalises units, and flags a contradiction as a tracked finding. Treat conflicting figures as something your team still has to catch.