AI-drafted request answers

What you get back when a diligence request lands

You get a written answer rather than a shortlist of files. It is prose, with the supporting language quoted and each quote linked to the exact place in the document. The draft also says whether the request is answered in full, in part, or not at all by what is in the room, and lists what is missing.

The difference matters because document matching hands your team a folder and leaves the writing to be done. On a list of several hundred items the writing is most of the work, and drafting removes that first pass.

Drafts are not sent anywhere automatically. They go to the deal team and nobody else, and a person approves, edits, or deletes and writes their own before anything goes back. The same path runs on the private Q&A board, where a buyer question produces a draft your team reviews before it is answered.

How a draft is checked before your team even reads it

The strongest part of this feature is what happens between the model finishing and the text appearing on screen. The model cannot write free text into the answer field. It returns a structured object: the availability verdict, the answer, the gaps, and citations, each carrying a verbatim quote, the document it came from, and the phrase in the answer that quote supports. The application verifies every citation on the server before anything is rendered.

Each citation passes three checks. The named document must resolve to one inside the permitted set for that draft. The quote must actually occur in that document's extracted text, compared with whitespace normalised and with a fallback for the spacing artefacts of PDF and spreadsheet extraction. And the phrase it supports must appear in the answer, so a citation cannot be attached to a claim the answer never made.

Failed citations are dropped. If a draft claims the request is answered in full and no citation survives, the answer is discarded and replaced with a note routing the item for manual review. A confident answer with no surviving support is withheld rather than shown to a reviewer as finished work.

What survives is scanned and flagged: language resembling material non public information such as a reserve or walk away figure, money figures present in the answer but in none of the verified quotes, and negation flips where the answer states the opposite of the text it cites. Flags do not block. They mark where a reviewer should look closely.

Which documents a draft may quote when the answer goes to the other side

When a draft will be shown to a counterparty, the documents it may quote are scoped to what that side is permitted to read, not to what the person drafting can see. The application works out every counterparty organisation that can see the request's list, and admits a folder only if every one of them may read it. That is an intersection, not a union. Where the list's ownership cannot be resolved as your own side, it denies rather than falling back to the wider view.

This has two consequences worth stating plainly. A broadly shared list narrows the admissible documents for every draft written against it, and can leave the model with nothing to work from. Read access and export rights are also separate tiers, so a verified quote can come from a document that party can open but not download.

What a request list contains, and how one gets built

A request list has three levels: categories, topics inside them, and requests inside topics. The request is the unit that gets answered. It carries a title, section, description, owner, status, and links to answering documents, each either proposed or confirmed by a person. The list itself records its owning organisation, its review status, and which parties it has been shared with. That metadata decides who may see a request and what a draft may quote.

Lists get built three ways: describe the deal in prose and get a draft list plus a matching folder tree, start from a saved template, or import a spreadsheet. The generated path is size capped, so it produces a starting structure rather than a finished list.

Import is where transcription errors normally enter. Real checklists are messy: categories appear as sparse header rows in one file, a repeated column value in the next, one tab per category in the one after. The model is never asked to read the requests out. It is shown every row of every tab and asked for a reading plan: which sheets hold requests, and where each field comes from, drawn from a small fixed vocabulary. An invalid plan fails the import loudly. A valid one is executed mechanically against the raw cells, so a request cannot be paraphrased or invented.

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

A request's title, section and description are embedded into the same index as document vectors, and documents are embedded after upload. Requests and documents sit in one comparable space, so a request can be scored against every file and against every other request.

The similarity scan is triggered by your team, against one request or the whole deal. Where a pair scores above the bar the system records a proposed link, hidden from buyer side users until it is reviewed. Your team then approves in full, which copies the confirmed answer documents from the earlier request onto the new one so the item is answered once with the same files; approves in part, which requires a written description of the gap; or dismisses it. A buyer side user can dispute a merge with a stated reason.

The index runs the other direction too. An uploaded file is scored against open requests and the best match is recorded as a proposed answer whatever the score, so nothing is silently dropped. Bulk actions match a backlog of unlinked files to a list or find the files answering one request, with a preview that scores exactly as the real run does and writes nothing.

Why a person still confirms the match

Two requests can score as similar without asking for the same thing. Audited financials for three years and audited financials for five years sit close together in any embedding space and differ in a way that matters, as do two requests separated only by entity.

The bar is deliberately permissive, because a strict one would miss duplicates written in different house styles. A permissive bar surfaces borderline pairs and accepts that some will be wrong, which only works when a person decides. The documents attached to an earlier answer may also not be readable by the party now asking, so inheriting an answer is a disclosure decision. A confirmed link records who approved it, which an automatic merge would not. Reviewing a proposed pair is still much faster than answering the request again.

Where this stops

The guardrails on model behaviour are prompt level. Document text is marked as data rather than instructions, but the real boundaries are the per deal database, the permission check applied before retrieval, and the quote verification. There is no output classifier and no second model reviewing the first.

A document is represented by one 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 clause inside it. Enrichment also runs in the background, so a file whose text extraction failed carries no vector and stays invisible to matching and drafting until it is reprocessed. Scanned PDFs with no text layer are the common case.

Semantic answer reuse exists on the request side. On the Q&A board, duplicate detection is lexical, grouping open threads that share title keywords, and it never compares a new question against answers published on the shared board. Scans are triggered rather than continuous. Matching compares against every stored vector per query, which suits rooms holding hundreds of documents, not tens of thousands.

And no engine reconciles figures across documents. Drafts are checked against their own quotes, but nothing extracts numbers, normalises units, and records a contradiction as a tracked finding. Conflicting figures are still something your team has to catch. More on the access model behind this is on our security page.