Answer-once question matching

The AI writes the answer, not a list of links

Ask CogniSuite to draft a response to a due-diligence request and what comes back is a written answer, composed in prose and addressed to the counterparty. It states whether the material is available in full, in part, or not at all. It answers in a sentence or two. It names what is still missing, if anything is.

Inside that answer, short spans of text are hyperlinked to the document that supports them, and each link carries the supporting quote, so the reader opens on the passage rather than the top of a file. Underneath sits an index of the documents the answer rests on. The result is a response you could send, rather than a search result you would still have to turn into one.

That is where the time goes on a live process. Your team usually knows where the answer lives. The work is writing the same careful paragraph for the fourth bidder who asked, then tracking which version went to whom.

How a draft is checked before anyone reads it

The model does not write freely into the deal record. It is forced through a structured tool call with a fixed shape: an availability verdict, the answer text, a missing note, and a list of citations. Each citation carries a verbatim quote, the id of the document it came from, and the exact span of the answer that the quote supports.

The application then verifies each citation on the server before a character reaches the screen. The document id has to resolve to a document inside the permitted set for this draft. The quote has to be found in that document's extracted text as a whitespace-normalised substring, with an alphanumeric-only fallback so that extraction artifacts do not throw away a genuine quote. The anchor span has to appear in the answer. A citation failing any of the three is dropped.

The case that matters is when nothing survives. If the model claimed the documents answer the question but no citation passed verification, the answer text is discarded and replaced with a line saying the assistant could not verify an answer and the item is routed for manual review. The verdict is downgraded and the draft carries a flag saying why.

Surviving drafts are then scanned for three failure modes. Language matching reserve price, floor price, walk-away price, competing bid or rival bid raises a flag. So does a money figure stated in the answer but present in none of the verified quotes, and a negation mismatch between a quote and the sentence it supports. These appear as a review banner. They do not block release. The reviewer is told which number to check and decides whether to send.

How grounding is scoped to the side that will read the answer

A counterparty-facing draft is grounded only in documents that counterparty may read, not in what the drafting banker may read. The application resolves the request's parent list, enumerates every counterparty organisation that can see that list, whether by owning it, by an explicit share, or by the list's review status, and admits a folder only if every one of those organisations may read it. That is an intersection, not a union.

If the scope cannot be resolved with confidence, the check denies everything rather than falling back to the drafting user's own access. Organisation-level checks run against the organisation baseline, so one generous per-user grant cannot widen what the model may quote.

All of this runs through the same retrieval path that serves data-room chat, and retrieval only ever touches the database file belonging to that one deal. Semantic search is a separate implementation rather than the same function, and it applies the same folder-read check with a stricter relevance floor of its own. The AI only surfaces documents the asker is already permitted to see, enforced in one shared place, and cross-deal retrieval is structurally impossible rather than policy-enforced.

Approval, editing and release

Nothing is posted automatically. A generated draft is stored on the request and returned only to deal-team roles. From there a reviewer has three moves. Approve and release posts the draft as the advisor response and attaches the verified source documents to the request, so both sides click through to the same evidence. Using the draft loads it into the response composer for rewriting, which is the normal case when the tone needs work. Dismissing it clears the stored draft.

Drafting runs one request at a time. The saving on a long list comes from not writing the same careful paragraph a fourth time, not from generating a batch of answers in a single pass.

How duplicate requests are detected

Every request is embedded from its title, section and description. When your team runs a similarity scan, the target request is compared against every other request in the deal that is not already published or answered, and any pair scoring above the similarity bar becomes a pending link, ordered best first. Pairs that already have a link in either direction are skipped, so rescanning does not stack duplicates of duplicates.

Pending links are hidden from buyers entirely. Nothing about a proposed merge is visible to the side that asked until a person on the deal team has looked at it.

How review turns a match into an inherited answer

Review is deal-team only, with three outcomes. Approved in full means the two requests are the same question. Approved in part requires a written gap description saying what the existing answer does not cover, and the review is rejected if that field is empty. Dismissed means the match was wrong.

Approving in full does the work. It copies every confirmed answer document from the matched request onto the new one and confirms them, so the second bidder's request is answered by the same material the first one received, with no retyping and no risk of a different set of files going out.

Buyers can dispute a decision they can see, with a written reason, and the deal team reviews it again. The objection and the decision that follows it both stay on the request.

Matching files and requests in both directions

When a file is uploaded, it is scored against the open requests in the uploader's scope and the best match is written as a pending link whatever the score. Nothing is dropped for scoring weakly. The interface separates confident matches from ones needing review by comparing the stored score against the threshold, so a weak match is presented as one to check.

Two bulk actions run the other way. Matching a backlog of files to a request list works only on files that have no link at all and that the actor can see, and it never touches an existing link, so a later batch of uploads cannot disturb an earlier decision. Matching one request against the data room uses the same counterparty-scoped retrieval the drafter uses, rather than a fixed score cutoff, so borderline-relevant documents still reach the plan.

Both have a dry run that scores identically and writes nothing, so you see the plan file by file before anything is committed.

Where this stops

The duplicate scan is triggered by your team, per request or across a list. It does not fire when a question arrives, so an unscanned list carries no dedup signal.

On the private question board, duplicate grouping is a much weaker mechanism. It is keyword matching on thread titles, it considers only open threads, and it does not compare a new question against answers already published. Embedding-based reuse exists on the request side only.

Each document is represented by a single embedding built from its summary and transcribed text, truncated. There is no chunking, so a long agreement is represented mainly by its opening and retrieval cannot point at a clause buried inside it.

Enrichment after upload is best-effort and runs in the background. If extraction or embedding fails, the file is stored and viewable but has no vector, which leaves it invisible to matching, dedup and chat until it is reprocessed. Retrieval also scores every vector in the deal on every query, which is comfortable at hundreds of documents and is not a design for tens of thousands.

Intersection scoping is safe but blunt. On a list shared with several counterparties the readable set can be empty, and the draft will then say the material is not available without explaining that the cause was scope rather than absence.

The prompt-level guardrails are mitigation, not enforcement. The real boundaries are the per-deal database, the folder permission check applied before a document can enter retrieval, and the quote verification above. Past that, the design assumes a person reads the draft before it goes out.