Semantic document search

What this gives you on a live deal

You can search the room for the concept instead of the file. Someone asks whether a large customer can walk away if the company is acquired. You type that question in ordinary English. The room returns the agreement whose relevant clause is headed "Assignment", together with the other documents that address the same idea in their own wording. You did not need the filename, the folder, or the vocabulary the drafter happened to use.

That matters most to the side that did not build the room. A buy-side team and its advisers are working through someone else's filing system, on a deadline, looking for concepts rather than words. It also helps the sell-side team answering the questions, because the fastest way to respond to a diligence request is to find the documents that bear on it without walking the folder tree.

Every result is a document you were already allowed to open

Search does not have its own access rules. It resolves your access with the same per-folder permissions that govern the rest of the data room, and the check runs before a document is admitted to the result set, not as a filter applied to an already ranked list. A document in a folder you cannot read does not appear in results, does not influence the ordering, and its existence is not disclosed to you. The set of results you get back counts only documents you are permitted to see.

Two further points are structural rather than configured. Each deal is a separate database served from its own subdomain, so a query on one deal cannot reach another deal's material by construction. And read access is kept separate from export rights: a document in a view-only or watermarked folder can appear in your results and open in the viewer, while the download, the native-file stream and the bulk ZIP path all stay closed. That gate is applied per file inside a bulk export too, not only on single downloads.

One honest note on that boundary. Retrieval admits any folder you can read at all, including the view-only and watermarked grades. A document you may view but not export can still be returned by search, and its text can still be quoted back to you by the AI chat that runs on the same index. If a document is too sensitive to be quoted, close the folder rather than relying on the export restriction. The access model is described on the security page.

Why filename and keyword search fail in a diligence room

Files arrive named by whoever produced them. A master services agreement can be MSA_final_v3_JB.pdf, Contract - Acme (executed).pdf, or Copy of Schedule 4.docx. None of those names describe the document's contents to someone searching for it later.

Keyword search moves the guessing from the filename to the body text, but it still requires you to type words that actually appear in the file. Diligence questions do not arrive in contract language. The contract says "assignment", or "Change in Control of the Company", or defines the concept once and then refers only to "Section 14.3" for the next forty pages. A keyword search for "change of control" misses all of it.

What searching by meaning actually does

When a document is indexed, the platform produces a title, a summary and a transcription of the readable content. That text is converted into a numeric vector that encodes meaning rather than exact wording. A search query is converted the same way and compared against every stored document vector, and results come back ranked by closeness of meaning.

Results are ranked, not filtered. The system returns a small set of the closest matches that clear a similarity floor, and if nothing clears it, it returns nothing rather than padding the list with weak hits.

There is no lexical fallback in the search path. If you already know the filename or a term that appears verbatim, meaning-based ranking is not obviously better than an exact match. Meaning-based ranking helps most when you can describe what you are looking for but do not know how the document is named or worded.

What happens to a file when it is uploaded

Storage and indexing are deliberately separated. On upload the file is stored and appears in the data room immediately. Indexing then runs in a detached background job, so a slow or failing model can never stall an upload or lose a file.

The background job extracts text locally where it can, reading Office formats through their internal XML and taking CSV and plain text directly. It then sends the document for extraction of a title, a summary and a markdown transcription, with images and PDFs routed differently from text-bearing formats. Finally it embeds that text and stores the vector against the document. If any step fails, the document still exists, still opens and still carries a title derived from its filename. It is present but not searchable, which is covered below.

Where semantic search is weaker: scans, spreadsheets and long files

Scanned documents are the hardest case. Indexing depends on getting readable text out of the file, and there is no OCR step in the pipeline. A PDF that is a photograph of paper, with no text layer, can end up indexed on little more than its filename. If a room is full of scanned signature pages, board minutes or old leases, expect thin coverage there. Load searchable PDFs where you have the choice.

Spreadsheets index unevenly. Cell text, sheet names and headers extract well. The substance of a financial model is in its structure, its formulas and the relationships between tabs, and none of that reduces to a paragraph of text. A workbook that is mostly numbers will usually be found through its labels rather than through the calculations it performs.

Long documents get a single vector each, and the embedded text is truncated. There is no passage-level chunking. A very long agreement is represented mainly by its summary and its opening, so a clause deep inside it may not pull the document to the top. When a document does match, search points you at the document and not at the paragraph inside it. You still open it and find the passage yourself.

One more limit worth knowing. Every query is compared against every document vector in the deal, with no approximate vector index. That is a sound trade at the document counts a normal deal room holds, and not the design you would choose for a room of tens of thousands of files.

What to do when a document does not appear in results

If a file was uploaded but never finished indexing, it is stored and viewable but invisible to search, to the AI chat and to the automatic matching of files against diligence requests. There is no badge on the document telling you this, which is a real gap.

The recovery path is a reprocess action, available to the deal team on the advisory side, which re-runs indexing for every document with no vector. Run it after a large bulk load, and consider it when someone is certain a document is in the room but search does not return it.

How search relates to the AI chat and to request matching

One index serves several features. The data-room chat retrieves documents by the same method before answering, and the scoring of uploaded files against open diligence requests uses the same vectors. That is why the room can propose which request a new upload answers instead of waiting for someone to file it.

The settings are not identical. Search applies a stricter similarity floor than chat retrieval does, so chat can sometimes answer from a document that a direct search for the same phrase did not return. If a search comes back empty, asking the same question in chat is a reasonable second attempt.

What this does not replace

Semantic search narrows a large room to a short list of candidate documents, quickly, and without you knowing the filing system. It does not confirm the list is complete, and it is not coverage for a full review. Where completeness is the point, such as confirming that every customer contract with an assignment restriction has been identified, use search to build the working set and then work the folder structure to check it. The other features built on this index are described on the features page.