How to label records as licensable, restricted or excluded

What the three labels mean#

The three labels sort every record by what must happen before it could be licensed. A licensable record needs only standard preparation, a restricted record needs a specific condition met first, and an excluded record stays inside the company whatever preparation is done.

The labels describe licensing status, not value. A restricted record can be among the most useful in an archive; it simply carries a condition that someone must satisfy and record before it moves.

Rules that keep labels consistent#

Labeling rules matter more than the labels, because two people reading the same ticket will otherwise label it differently. Write the rules down and agree them with counsel before anyone starts tagging.

Reason codes are worth the extra column. When a buyer asks why a customer segment is missing, or an auditor asks why a channel was included, the reason code answers in one line instead of a meeting.

• 1The strictest label wins: a thread with one excluded attachment is excluded until the attachment is removed.
• 2Unknown means restricted: a record whose rights are unclear never defaults to licensable.
• 3Every restricted or excluded label carries a reason code, such as customer contract, privilege, personal data or legal hold.
• 4Every restricted label names its release condition and who can confirm it was met.
• 5Labels change only through a named reviewer, and each change is logged.
• 6Labels apply to a defined version of the data, and new records are labeled as they are added.

Label record families first, then exceptions#

Labeling works fastest from the top down: assign a default label to each record family, then search for the records that break the default. Labeling millions of tickets or messages one at a time is neither practical nor necessary.

Exceptions are found mostly with filters rather than reading. A list of customer accounts with restrictive contracts, legal matter tags, HR channel names, outside counsel email domains and project codes for client-owned work will catch most of them. Sampling then checks what the filters missed, and each miss becomes a new filter.

Keep the family defaults and exception filters in one inventory sheet, so the rights review, the preparation team and the approver work from the same list instead of separate notes.

Examples by system#

Each system has its own typical exceptions, so the same three labels play out differently across a company's stack. Treat the examples below as starting defaults to test, not conclusions.

Code repositories need one extra pass before any label is final. Run a secret scanner over the history, not just the current branch, because credentials committed years ago can sit in old commits that a code-review package would otherwise include.

Where to store labels and reason codes#

Labels belong in a separate register keyed to each record's system ID, not in the source system. Editing tags inside Zendesk or Salesforce changes live records, can trigger automations and leaves no clean history of who decided what.

A workable register needs only a few fields: record or family ID, label, reason code, release condition, reviewer and date. It helps to align field names with metadata that buyers already recognize. The Data & Trust Alliance's Data Provenance Standards, for example, include in their Use group elements for confidentiality classification, consent documentation location, license to use and intended data use.

Once the register exists, preparation becomes a filter. Licensable records go forward, restricted records go forward only when their condition is marked as met, and excluded records never enter an export at all.

Illustrative: a mechanical contractor labels its job history#

Illustrative: a fictional commercial mechanical contractor wants to license service and maintenance history from ServiceTitan, plus project files from SharePoint. The COO and IT manager set family defaults: service jobs and technician notes licensable, SharePoint project folders restricted, and HR and legal folders excluded.

Filters then catch the exceptions. Jobs for a data center client whose contract bars reuse are excluded. Jobs with photos showing building occupants are restricted until the photos are removed. Project folders holding stamped drawings that belong to the client are excluded. The register lets the owner approve a final scope in one review instead of debating individual folders.

Mistakes that undo a labeling effort#

Labeling efforts tend to fail through a few predictable shortcuts. Each one produces a register that looks complete but cannot be trusted at approval.

• 1Labeling by system instead of by record family, so one Slack workspace gets a single label despite holding both HR and engineering channels.
• 2Treating a missing contract as permission rather than as an unknown.
• 3Letting an export script apply labels with no register behind it, so nobody can later show why a record was included.
• 4Forgetting attachments, images and embedded files, which often carry the excluded content.
• 5Relabeling under deadline pressure without a named reviewer.

How SourceX uses the labels#

Labels feed directly into the SourceX five-step transaction. The Rights step reviews family defaults and reason codes, Preparation applies the release conditions for restricted records, and at Approval the supplier signs off on the final labeled scope. The SourceX Evidence Packet then records the licensing rights, permitted use and privacy record behind each included record family.

Because the register is metadata, it can be discussed before any record leaves the company, which keeps early conversations about scope concrete without moving a single file.