Everyone knows the agreement exists and search will not return it

A known agreement that will not surface is not one problem. It is 4, and they need 4 different fixes: the record was never filed at all, the document is there but holds no extractable text, the document is there and indexed but the words you typed never appear in it, or the document is there and access control removed it from your results before the page rendered.

Guessing between them is the expensive part. Teams re-index an entire estate to repair a permissions bug, or buy semantic search to repair a missing OCR step. Four probes, run in order on the one document you are actually looking for, cost about 10 minutes and settle it.

Four probes, run on the one document you want

1. Open the record by its identifier, not by searching. Ask whoever filed it for the record link or the contract number. If there is no record, stop here: this is a filing gap rather than a search defect, and the trail starts where the signed envelope never lands back in the file.
2. Try to select a sentence of body text in the stored file. Open the PDF and drag the cursor across a paragraph on any page. If nothing highlights, the page is a picture of a contract and there is no text for any index to hold.
3. Search 2 exact phrases in quotes, one from the first page and one from deep in the document. Take a phrase from the recitals, then a phrase from page 14 or from a schedule at the back. If the first matches and the second does not, the index holds the record's fields, not the agreement.
4. Have a colleague with wider access run the identical query. If it returns for them and not for you, retrieval is working and visibility is not. Nothing about the index needs touching.
5. Only if all 4 probes come back clean is this a query-language problem — and on a well-run repository, that is the one you should expect.

Run these against the specific document, never as a general audit. A sample of 30 contracts tells you what proportion of the estate is broken; it will not tell you why this one refuses to appear, and the person asking wants this one.

A scanned signature page has no words in it to match

The documents most likely to be image-only are exactly the documents people search for. A born-digital draft carries a text layer for free. An executed copy was printed, signed in ink, scanned on an office multifunction device and emailed back — and what lands in the repository is a sequence of images. The same is true of hand-signed amendments and of anything that arrived by fax at some point in its life.

The check is mechanical: count extractable characters per page. A page that visibly carries 3 paragraphs and yields under 100 characters has no usable text layer. Do that across the estate and you get the population of documents that were never OCR'd, which is usually concentrated in a date range rather than spread evenly — the years before someone wired OCR into the ingest path.

Two details decide whether OCR actually repairs it. Source resolution matters more than the engine: 300 dpi is the ordinary working minimum for body text at 10 to 12 point, and a 200 dpi scan produces a text layer that indexes cleanly and matches badly. And a searchable PDF stores the OCR output invisibly behind the image, so what the index holds is what the engine read, not what your eye reads. Store a per-document OCR confidence and the engine version alongside the file, so you can find the pages that indexed badly and re-run them later rather than trusting a green tick.

The index holds the cover sheet and not the agreement

Plenty of document systems index the record — title, counterparty, agreement type, dates, matter — and store the file itself as an attachment. Search then answers questions about the filing card and never about the paper. The symptom signature is unmistakable once you know it: everything printed on the cover sheet is findable and nothing inside the document is.

• Full text switched on after the estate was loaded. Extraction usually applies to documents ingested from that point on. Without an explicit backfill you get a half-state: contracts signed this year are findable, the archive is not, and nobody notices because recent work goes fine.
• Extraction caps by size or page count. Some pipelines stop extracting after a set number of pages or megabytes. The front of the agreement is indexed and the exhibits are not — which is precisely where the pricing schedule, the service levels and the data-processing terms live.
• Attachments inside the file. Emails filed with the contract, or a PDF portfolio holding the agreement plus its annexes, are frequently indexed at the wrapper level only. The text you want is one container deeper than the extractor went.

You searched for the deal; the paper says 'the Supplier'

A contract names its parties once and then stops. After the preamble the counterparty is the Supplier, the work is the Services, the money is the Charges. So a trading name may occur 3 times in a 60-page agreement — preamble, notices clause, signature block — and a search for the warehouse pricing deal with that company finds nothing, because those words never co-occur anywhere in the document.

Two adjacent traps compound it. The contracting party is a legal entity rather than a brand, so the paper says Acme Logistics Private Limited where the business says Acme. And the internal name for a deal is almost never its title: people search for the renewal we did last spring against a document headed Master Services Agreement. The same mismatch between business vocabulary and drafted vocabulary is what makes a review playbook flag every clause as a deviation, and it is worth recognising as one problem with two symptoms.

The fixes are unglamorous and durable: extract party names and store them as fields on the record rather than relying on the body text; keep an alias list per counterparty so trading names, legal names and abbreviations all resolve; and index the internal deal name as a searchable field, because that is what people will type. This is where semantic retrieval genuinely earns its place — and only here. Buying it to repair a missing OCR step is buying the wrong thing, which is the first question worth asking any supplier when choosing an AI development partner.

A permission filter and an empty index render identically

Matter-level and workspace-level access control is generally applied as a filter over the result set. The engine finds 3 hits, the filter removes all 3, and what reaches the screen is the same blank panel you get when nothing matched. The searcher concludes the agreement was never filed, and then does one of two costly things: files a duplicate, or emails the counterparty asking for a copy of a contract you already hold.

Making those 2 states distinguishable costs almost nothing. Return a suppressed count — 3 results you do not have access to, with a route to request it — and the searcher stops guessing. The permission model behind that decision is usually derived from the same authority matrix used for signing, which is why encoding who may sign what into routing rules tends to be the work that makes access rules coherent in the first place.

One caveat before you ship it. On a small number of matters the existence of the document is itself the confidential fact, and a count leaks it. Make the suppressed-count behaviour a per-workspace setting, default it on, and for the restricted set replace silence with a named person to ask. Silence is the failure mode; a hard wall with a contact on it is not.

Search is not one system. It is a filing step, an extraction step, an index and a permission filter, and any one of the 4 returns the same empty page.

Which fix to run first, and what a working search still will not do

Three things stay broken after all 4 are fixed, and it is worth saying so before anyone declares search solved. A repository cannot return a document that was never filed. It cannot tell you which of 6 near-identical PDFs is the authoritative executed version unless something recorded that at filing. And it cannot fill fields that arrived empty — if half the estate has no counterparty or no term dates, the problem is upstream, where migrated contracts arrive with empty metadata and no re-index will conjure the values back.

Wiring OCR, extraction and alias resolution into the ingest path rather than running them as periodic clean-ups is ordinary AI agents and automation work, and it is what stops the same 4 causes reappearing next year. This page sits in the contract lifecycle from request to renewal, part of legal technology software.

• contract repository
• search
• document management
• OCR