What AI-assisted data room setup actually creates

The three ways a new room can be started

When you create a deal, you pick one of three starting points.

The first is a written description. You say what the deal is, whether you are acting sell-side or buy-side, and what is being sold. The system returns a draft due diligence request list organised as categories, topics and individual requests, along with a folder tree that matches those categories.

The second starts from a request list template your firm already uses and proposes a folder tree to match it.

The third is a canonical M&A data room structure. That one is not generated. It is a hand-authored tree with access tiers already set on every folder, and it is the closest thing to a default the platform has.

All three produce a draft, not a room. Nothing is written into the deal's database while you are still editing. The folder tree is only materialised when you commit the new deal, which means you can delete half the proposed categories, rename the rest and add your own before anything exists.

What the standard structure contains

The standard structure is a tree of top-level categories with subfolders beneath them, covering the areas a normal diligence checklist covers: corporate and organisational material, financials, tax, commercial and customer material, legal and litigation, intellectual property and technology, people, property and assets, insurance, regulatory matters, and the transaction process itself.

The point of it is not the number of folders. The point is that the tiering is already decided. Every node in the tree is assigned one of three tiers in the wizard, and that tier decides the visibility the folder is created with:

• Shared folders are created with external visibility, 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 setup wizard badges them as clean team material while you are reviewing the tree. The badge is a setup-time label in the wizard, not a property stored on the folder, so note which folders it applied to before you commit.

Because this tree is hand-authored rather than model-generated, it is stable. Two deals set up from it get the same structure, which matters if you want your rooms to be legible to the same people across a portfolio of mandates.

How visibility is set during setup rather than afterwards

This is the part that usually goes wrong when a room is built by hand. Folders get created first and permissions get applied later, in a rush, by whoever happens to be doing the uploading.

In this platform, visibility is a property of the folder record itself, written at creation time. A folder carries one of four labels: internal, external, all buyers, or specific to a single named organisation. Two behaviours follow from that.

First, resolution is inherited and fail-closed. If a folder has no label of its own, the system walks up its ancestors and uses the nearest one that does. If nothing resolves, the answer is internal. At the moment the tree is written, any folder whose visibility was left unspecified is forced to internal rather than being left open. A folder is never accidentally visible to a bidder because someone forgot to set it.

Second, a folder scoped to one specific organisation is readable only by that organisation, and the scoping does not leak downward past a more open ancestor. A folder that sets its own visibility of external, sitting beneath a parent scoped to one buyer, resolves as external for everyone rather than inheriting the parent's private scope, because the walk stops at the nearest folder that sets a visibility of its own. Scoping applies from the folder that carries the label down through folders that set nothing, not past a descendant that sets its own.

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 stays with your own team and your client. Counterparties are blocked from internal folders by default. That is a default rather than a wall: an explicit per-folder grant written by your team still opens a named internal folder to a counterparty, which is how you run a limited disclosure without restructuring the room.

Depth is capped at three levels, enforced on the server, not just suggested in the prompt. That is a deliberate constraint. Permission mistakes are harder to spot in a deep tree than a shallow one.

How the request list and the folder tree stay connected

Generating both from the same input is the reason to do setup this way. The request list's categories become the folder tree's top level, so the place a document belongs is derivable from the request it answers.

Once the room exists, that connection keeps working. A request is embedded the first time it is scored, either by the automatic match that runs after an upload or by a scan the deal team triggers. When a file is uploaded, it is scored against the open requests and the best match is recorded as a pending link, with the interface separating confident matches from ones that need a human look. You can also run the match in bulk, either matching a backlog of unlinked files against a whole list or finding the files that answer one specific request. Bulk actions have a dry-run preview that scores exactly the same way and writes nothing, so you can see what would happen before it happens.

If your checklist already exists in a spreadsheet

Most request lists arrive as somebody's Excel file with an idiosyncratic layout. The import path handles that without letting the model retype your data.

The model is shown the rows and asked to return a reading plan only: which tabs contain requests, where the header row is, and which column or pattern supplies each field. That plan is validated, then executed mechanically against the raw cells. Because the model never transcribes, a request cannot be quietly paraphrased, merged or invented during import. The import reports how many rows it mapped against how many rows exist, warns you when its own coverage looks off, and puts anything it cannot categorise into an explicit uncategorised bucket instead of dropping it.

Rebuilding a room that already exists

If a room was built ad hoc and you later want it to match a request list, there is a reorganisation path. It creates one folder per request list category, then files every existing document into the right one. Documents that already have a confirmed link to a request are placed by that link without being rescored. Everything else is scored, with a boost when a candidate category matches the folder a person already filed the document in, on the theory that a human filing decision is real signal. Anything below the confidence threshold goes to a Needs Review folder rather than being stranded. Preview first, commit second, and old folders left empty are cleaned up afterwards.

One thing to know: 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 are open on the organisation default until you narrow them. The interface returns the new folder list specifically to walk you through setting 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 per topic, so the whole 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 the 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, because scoping a folder to a specific organisation requires that organisation to exist, and at creation time it does not. The wizard's clean team badge tells you which folders need that treatment while you are setting up. Record them before you leave the wizard, because the badge is not stored on the folder. Assigning the actual clean team organisation is a step you take once the party is on the deal.

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, either organisation-wide or per folder, and the per-folder setting takes precedence in both directions. See security for how those tiers behave once set.

Finally, none of this is a substitute for the permission review. The setup path gets the room to a defensible starting state with internal material closed by default and the tree matching the list you are actually working from. Deciding who sees what is still your team's call.