What metadata can you share in a fit check without sharing records?

What counts as metadata in a fit check#

Metadata in a fit check is information about your records rather than the records themselves: which systems hold them, how far back they go, roughly how many there are, which fields they contain and what restrictions apply. You can share metadata, not data, and still give a reviewer enough to judge whether a licensing conversation is worth having.

The test for any item is simple. If it could tell a reader something about a specific customer, employee, deal or incident, it is content rather than metadata, and it stays inside the company at this stage.

Share, share with care, or hold back#

Most fit check items fall into three groups. The table sorts the common ones; the middle group is where judgment is needed, because neutral-looking descriptions can carry client names or commercial signals.

When a field list reveals more than you expect#

A field list reveals more than expected when it includes custom fields, custom objects or picklist values named after customers, projects or internal initiatives. A CRM field named after a key account, or a help desk tag named for a product recall, tells an outsider something real about the business.

Before sharing a schema, export the field list, then rename or group custom items into generic descriptions such as custom account health field or customer-specific tag set. Standard system fields can stay as they are, since the vendor's own documentation already describes them.

Treat volumes the same way. Exact ticket or order counts by year can act as a proxy for revenue or headcount, so bands and orders of magnitude are usually enough at this stage.

Common ways companies overshare early#

Oversharing in a fit check usually happens through convenience rather than intent: someone attaches a file to explain structure faster than they could describe it. Each of the habits below moves real content out of the company before anyone has decided to proceed.

The fix in every case is the same: describe instead of attach, and route anything that would require a file through a later, approved step.

• 1Sending a small export just to show the column layout, which carries real rows with it.
• 2Pasting one representative ticket, email or work order into a message as an example.
• 3Sharing a project or Jira key list where keys are named after clients.
• 4Attaching admin console screenshots that show user names, email addresses or recent activity.
• 5Forwarding an org chart to explain who owns each system, instead of naming roles.
• 6Filling the example column of a field list with real values copied from the system.

A data profile summary you can fill in#

A data profile summary is a short description per system that a privacy lead can approve quickly. The entries below cover what a fit check typically needs and nothing more.

• 1System and edition, with the years it was in use and any system it replaced.
• 2Record families held, described in plain words, such as support conversations, change orders or quality holds.
• 3Accessible date range and any known gaps from migrations or retention settings.
• 4Approximate volume band per record family.
• 5Linkage: which identifiers connect records to other systems, such as ticket to issue or order to exception.
• 6Field groups present, described generically, with custom fields renamed.
• 7Predominant languages.
• 8Known restrictions: client-owned content, contractual limits and notices that limit reuse.
• 9Who owns the system and who can approve exports.

Illustrative: a 3PL describes its order and exception history#

Illustrative: a fictional third-party logistics company runs NetSuite for finance, a warehouse management system for fulfillment and McLeod for transportation, with EDI feeds from its retail customers. Its general counsel wants to take part in a fit check without letting any customer name leave the building.

The COO prepares one profile per system: years of history, volume bands for orders and exceptions, the field groups in the exception log, and the fact that exception records carry free-text resolution notes linked to orders. Customer-specific EDI partner codes are described only as customer identifiers, and warehouse names that reveal client locations are grouped as facility codes.

The fit check points to the exception and resolution history as the strongest record family. No file has moved; a fuller inventory happens only if the company decides to proceed.

Borrowing from dataset documentation standards#

Dataset documentation standards offer a useful vocabulary for metadata, even though a fit check needs only a fraction of what they cover. The Data and Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, and the Use group includes items such as confidentiality classification and where consent documentation is kept.

Datasheets for Datasets proposes that every dataset come with a datasheet covering its motivation, composition, collection process and recommended uses, and MLCommons' Croissant format offers machine-readable metadata for machine learning datasets. Items from these standards that describe composition and collection fit a fit check well; items that require sample content wait until later.

How SourceX runs a metadata-only fit check#

The SourceX fit check is the opening part of the Supply step in the SourceX five-step transaction, and it collects metadata, not files. Nothing is shared during the initial assessment: no exports, samples or screenshots are requested.

The fit check looks at the drivers in the SourceX Enterprise Data Value Framework that metadata can speak to, such as domain expertise, scale, recency and rights, and flags likely preparation cost and privacy burden. Content is reviewed only later, with the supplier's approval, during the Rights and Preparation steps.