Product spotlight

AI-assisted data room setup

Describe the deal and you get a due diligence request list and a folder tree built from it, with a visibility decision already recorded on every folder. Any folder whose visibility is left unspecified is written as internal by the server, so nothing is exposed to a bidder because someone forgot. This is what each setup path creates, and where each one stops.

By the CogniSuite team

What you have before the first document is uploaded

Setup ends with three things: a due diligence request list, a folder tree whose top level is that list's categories, and a visibility decision recorded on every folder in the tree. Internal material is closed to the counterparty before anyone uploads anything, and the place a document belongs is derivable from the request it answers.

The ordering is what matters. Building a room by hand means creating folders first and setting permissions later, under time pressure, usually by whoever happens to be doing the uploading. Here the permission decision is made while the tree is still a draft, and it is written into the folder record at creation.

You start from one of three places.

  • A written description of the deal, including what is being sold and whether you are acting sell-side or buy-side. You get back a draft request list organised as categories, topics and requests, plus a folder tree that matches those categories.
  • A request list template your firm already uses, with a proposed folder tree built to match it.
  • A canonical M&A data room structure. That one is not generated. It is hand-authored, with an access tier already set on every folder.

All three produce a draft, not a room. Nothing is written into the deal's database while you edit, so you can delete half the proposed categories, rename the rest and add your own before anything exists.

Why a folder is never visible to a bidder by accident

Visibility is not applied to a folder afterwards. It is a property of the folder record, written when the record is written. Each folder carries one of four labels: internal, external, all buyers, or specific to a single named organisation.

Resolution is inherited and fail-closed. If a folder carries no label of its own, the system walks up its ancestors and uses the nearest one that does, and if nothing resolves the answer is internal. When the tree is committed, any folder whose visibility was left unspecified is forced to internal by the server, not by the prompt and not by a checklist step someone can skip. Tree depth is capped server-side, because permission mistakes are harder to see in a deep tree than a shallow one.

A folder scoped to one named organisation is readable by that organisation alone, not by every buyer. The folder listing and the file access check run the same resolution code rather than separate copies of the rules, so the tree cannot show a folder the access check would deny.

Setup also knows which side you are on. The room reads the deal type and works out who the counterparty is. On a sell-side mandate the buyers are external. On a buy-side mandate the seller is external instead, and the internal room holds your own team and your client. Counterparties are blocked from internal folders by default, and that default can be overridden deliberately. An explicit per-folder grant from your team opens one named internal folder to a counterparty, which is how you run a limited disclosure without restructuring the room.

If your checklist already exists in a spreadsheet

Most request lists arrive as somebody's Excel file with an idiosyncratic layout: categories as sparse rows, or repeated in every cell, or one tab per category, with summary tabs to ignore. That file goes in as it is, and no request in it gets reworded.

That holds because of how the import works. The model is shown the rows and asked to return a reading plan only: which tabs contain requests, where the header row sits, and which column or pattern supplies each field. The plan is checked against a closed list of allowed field types, and a malformed plan fails the import with an error rather than returning an empty list. A valid plan is executed mechanically against the raw cells. Because the model never transcribes, a request cannot be paraphrased, merged or invented on the way in.

The import also reports on itself: rows mapped against rows present, a warning when coverage looks off against the count the model predicted, and an explicit uncategorised bucket for anything it cannot place.

What the standard structure contains

The standard structure is a hand-authored tree of top-level categories and subfolders that covers the ground a normal diligence checklist covers: corporate, financials, tax, commercial, legal, intellectual property and technology, people, property, insurance, regulatory, and the transaction process itself.

The tiering matters more than the folder count. Every node is assigned one of three tiers in the wizard, and that tier decides the visibility the folder is created with.

  • Shared folders are created external, so counterparty organisations can see them once they are granted access to the deal.
  • Internal folders are created internal-only.
  • Restricted folders are created internal-only, and the wizard badges them as clean team material while you review the tree. The badge is a setup-time label, not stored on the folder, so note which folders carried it before you commit.

Because the tree is hand-authored rather than generated, two deals started from it get the same structure, which matters across a portfolio of mandates.

How the list and the tree stay connected after setup

The connection keeps working once documents arrive. An uploaded file is scored against the open requests and its best match is recorded as a pending link, so nothing disappears silently, and the interface separates confident matches from ones needing a human look. The same matching runs in bulk in both directions, and every bulk action has a dry run that scores identically and writes nothing. Use it, because bulk matching confirms links automatically at or above its threshold, and that threshold is set to catch borderline documents rather than to be strict.

Rebuilding a room that already exists

If a room was built ad hoc and you want it to match a request list, there is a reorganisation path. It creates one folder per request list category and files every existing document into the right one. A document that already carries a link to a request is placed by that link without rescoring, preferring a confirmed link where a document has more than one. Be aware that an unreviewed AI-proposed link counts here: a top match is written for every scored file whatever its score, so placement by an existing link is not always placement by a human decision. Everything else is scored, with a boost when a candidate category matches the folder a person already filed the document in, because a human filing decision is real signal. Anything below the threshold goes to a Needs Review folder rather than being stranded, and empty folders left behind are cleaned up after you commit.

Folders created by a reorganisation carry none of the old structure's per-folder grants. In the external room they are created visible to buyer organisations, and buyers are notified, so they sit on the organisation default until you narrow them. The interface returns the new folder list so you can set access on each one. Rebuilding the tree does not rebuild the permission model.

What setup does not do

The generated path is size-capped. The model is instructed to return a small number of categories, topics and requests so the list fits inside one response. That is noticeably smaller than the hundred-plus item lists real diligence uses, and smaller than the standard structure. Treat a generated list as a skeleton to expand, and use the spreadsheet import or the standard tree when you need full coverage.

Restricted folders in the standard tree are seeded as internal rather than as clean-team-only. Scoping a folder to a named organisation requires that organisation to exist, and at creation time it does not. Assigning the real clean team organisation is a step you take once the party is on the deal, which is why the wizard badge is worth writing down.

Watermarking and view-only access are configuration, not a default posture. The default organisation-level permission allows clean downloads. If you want watermarking or view-only tiers you set them, organisation-wide or per folder, and the per-folder setting takes precedence in both directions. See security for how those tiers behave once set.

None of this replaces the permission review. What setup gives you is a defensible starting state: internal material closed by default, nothing open because a field was left blank, and a tree that matches the list you are working from. Deciding who sees what is still your team's call.

General information, not legal, tax or financial advice. For how CogniSuite handles security and access, see Security. To see it on a live deal, book a walkthrough.

← All articles