Exclusions: keeping clients, channels and folders out of scope

Licensing your company's data does not mean licensing all of it. Before anything moves, you decide what stays out: a particular client, a set of Slack channels, a shared drive folder, a repository, a date range. Those exclusions are written into the contract, and they are often the part of the process that makes a founder or liquidator comfortable saying yes.

This post covers what can be excluded, what is excluded by default and how to choose exclusions that protect what matters without hollowing out the dataset. It is general information, not legal advice, and counsel should review your scope before signing.

In our process, the seller sets scope and exclusions right after the intro call, and those terms are annexed to the contract before any data is touched. That ordering is deliberate. The seller is never in the position of hoping that something sensitive will be filtered out later; the boundary is fixed before anyone looks.

It also keeps the evaluation honest. The read-only evaluation, which takes under an hour of the seller's time, measures only what is in scope. The value estimate is then based on data the buyer will actually receive, not on material that will be removed afterward.

Exclusions can be drawn along almost any line that the underlying tools let us filter on. Common ones include:

• Clients or customers, such as a single account whose contract has strict confidentiality terms, or a whole category like government work
• Channels and spaces, such as a leadership channel, a board channel or a channel used for a sensitive negotiation
• Folders and drives, such as a legal folder, an M&A data room or a fundraising folder
• Repositories, such as a repo containing a client's proprietary code or a security tooling project
• Projects or boards in Jira, Linear or Asana that relate to an excluded client
• Date ranges, such as everything before a particular reorganization or after a wind-down decision
• Whole systems, such as leaving the finance tool out entirely

The more precisely an exclusion is described, the easier it is to apply and to verify. "The Acme account" is less useful than "the Acme Slack channels, the Acme folder in Drive, the ACME Jira project and email threads with the acme domain."

Some material is out unless there is a specific reason to include it. HR, payroll, medical and legally privileged folders are excluded by default. Direct messages are excluded unless the company chooses to include them and has the right to do so.

Separately, some content is removed from whatever is in scope, whether or not you ask. Credentials, API keys, card numbers and government IDs are stripped outright, and faces, logos and signatures are blacked out in images and PDFs. Our post on secrets in the archive explains how that removal works.

The difference is worth keeping straight. Default exclusions remove whole areas of the data. Anonymization changes what remains, replacing every person, company, email and account with a consistent token.

Every exclusion has a cost, and it is not always the obvious one. What makes company data valuable to AI labs is connection depth: the same project traceable from a Slack thread, to a Jira ticket, to a pull request, to an email to the customer. Our post on how company data is valued goes into this in detail.

A narrow exclusion, such as a single leadership channel, usually costs very little. A broad one can cost a lot more than its size suggests. Imagine a 70-person agency that excludes its two largest clients across every tool. If those clients account for most of the cross-tool project history, the remaining data may be thinner and less connected than a simple message count would suggest.

That does not mean you should keep a client in scope that you are uncomfortable including. It means it helps to understand the effect before deciding, and to look for narrower alternatives. Sometimes excluding a client's shared folder and named channels is enough, and the rest of the work, already tokenized, can stay.

A short working session usually covers it. The questions we suggest asking are:

• Do any customer contracts contain confidentiality terms that cover this kind of use? If so, those clients may need to be excluded or reviewed with counsel.
• Are there channels or folders where the content itself, not just the names, is sensitive, such as legal disputes or board discussions?
• Is there a period of company history you would rather not include?
• Is there any system where you are unsure you have the right to license the contents?

Someone who knew the day-to-day work, such as a former head of operations or engineering lead, is often the best person to point at the channels and folders that matter. The signatory still makes the decision.

Exclusions are only useful if you can confirm they were applied. Before delivery, you review an anonymized sample. That is the moment to check that an excluded client's projects are absent, that a leadership channel does not appear and that nothing from a default-excluded folder slipped in.

After sign-off, the raw archive is deleted within 30 days, as a contract obligation, with a deletion certificate. Excluded material never reaches the buyer, and the raw copy it was filtered from does not linger.

If you have a client, a channel or a folder you are not sure about, bring it to the first conversation. We can show how a narrow exclusion compares with a broad one before you commit to either. Book a 15-minute call to start with your scope.