Semantic search across the data room

Why filename and keyword search fail in a diligence room

Files arrive in a data room 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. Different people at the client, at the accountants, and at the law firm all name files differently, and none of them are naming for the person who will later need to find the document.

Keyword search does not fix this. It moves the guessing from the filename to the body text, but it still requires the searcher to type words that actually appear in the file. Diligence questions do not arrive in contract language. Someone asks whether a customer can exit if the company is acquired. The contract says "assignment", or "Change in Control of the Company", or defines the concept in one clause and then only refers to "Section 14.3" for the next forty pages. A keyword search for "change of control" misses all of it.

The problem is worse for the buy side, which has no knowledge of the seller's naming conventions, folder logic, or internal shorthand. Buyer-side teams and their advisers are searching a filing system they did not build, under time pressure, for concepts rather than words.

What searching by meaning actually does

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

In practice this means a search for "can a customer walk away if we are acquired" can return the agreement whose relevant clause is titled "Assignment", even though the query and the document share almost no words. It also means results are ranked, not filtered. The system returns a small set of the closest matches that clear a similarity floor. 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 exact filename or a defined term that appears verbatim, meaning-based ranking is not obviously better than an exact match would be. It is designed for the case where you know what you are looking for but not what it is called.

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 straight away. Indexing then runs in a detached background job, so a slow or failing model can never stall an upload or lose a file.

That background job does three things. It extracts text locally where it can: Office formats through their internal XML, 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 the summary plus the transcription and stores the resulting vector against the document.

If any of that fails, the document still exists, still opens, and still carries a title derived from its filename. The consequence is that the file is present but not searchable, which is covered below.

How permissions apply to search results

Search does not have its own access rules. It uses the same per-folder access resolution as the rest of the data room, and the check is applied before a document is admitted to the result set, not after ranking. A document in a folder you cannot read never appears, and the count of returned results counts only documents you are permitted to see.

Two structural points matter here. Each deal is a separate database, so a query on one deal cannot reach another deal's material by construction rather than by rule. And read access is separate from export rights: a document in a view-only or watermarked folder can appear in your results and open in the viewer while still being blocked from download and from bulk export. More detail on the access model is on the security page.

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

There are three limits worth stating.

Scanned documents are the hardest case. Indexing depends on getting readable text out of the file. A PDF that is a photograph of paper, with no text layer, can end up indexed on little more than its filename and whatever the extraction step could infer. There is no OCR step in the pipeline. If a room is full of scanned signature pages, board minutes, or old leases, expect search coverage over those files to be thin. The practical mitigation is to load searchable PDFs where you have a choice.

Spreadsheets index unevenly. Cell text, sheet names, and headers extract well. The meaning of a financial model, which lives in structure, formulas, and the relationship between tabs, does not reduce cleanly to a paragraph of text. A workbook that is mostly numbers will have a weak text representation, and search will find it by its labels rather than by what it calculates.

Long documents are represented by a single vector each, and the embedded text is truncated. There is no passage-level chunking. This has two effects. A three hundred page agreement is represented mainly by its summary and its opening, so a specific clause deep inside it may not pull the document to the top of the results. And when a document does match, search points you at the document, not at the paragraph inside it. You still have to open the document and find the passage yourself.

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, which re-runs indexing for every document that has no vector. It is worth running after a large bulk load, and worth knowing about if someone insists a document is in the room and search disagrees.

How search relates to the AI chat and to request matching

The same index serves several features. The data-room chat retrieves documents by the same method before answering, and the automatic scoring of uploaded files against open diligence requests uses the same vectors.

They do not use identical settings. The standalone search endpoint applies a stricter similarity floor than chat retrieval does, so it is possible for chat to answer a question 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. It does not confirm that the list is complete, and it should not be treated as coverage for a full review. For anything 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 through the folder structure to check it. The other features built on this index are described on the features page.