What Is a Data Manifest? Examples for AI Data Licensing
What is a data manifest?
A data manifest is an inventory that describes your company's data: what it contains, how much exists, what period it covers, and how the records fit together. The actual collection of material can be called a corpus.
When you apply to work with an AI lab or data partner, you may be asked to provide a company profile and data manifest. This information helps the prospective partner evaluate the data licensing opportunity.
By Jason Varner / DataHasValue
Data manifests and corpora, explained visually
Watch Jason explain the difference between your actual collection of data and the inventory that describes it. Then use the examples below to start outlining your own manifest.
The idea to remember: the corpus is the collection; the manifest describes the collection.
How does a data manifest relate to a corpus?
A corpus is a collection of actual source material, such as emails, reports, support conversations, or other records gathered for a purpose. A data manifest is the inventory that identifies and describes the material in that collection.
Picture boxes of cargo with a packing list beside them. The boxes contain the material. The packing list tells someone what is inside, how much there is, and how it is organized.
CORPUS
The actual data
The files, records, and their contents.
DATA MANIFEST
The inventory
- What? Types of data
- How much? Files or records
- When? Dates covered
- Format? CSV, PDF, Excel...
- Contents? Fields and context
The collection can contain one type of data or several. It can also be a selected subset of your company's records. Calling it a corpus does not mean every file has already been cleaned, checked, or approved for licensing.
What is inside one support ticket?
- ProblemThe customer reports duplicate rows in a report export.
- InvestigationThe agent checks the filters and identifies overlapping date ranges.
- OutcomeThe customer confirms that the corrected export contains the expected rows.
The corpus contains the actual messages, actions, and recorded outcomes. The manifest summarizes how many tickets exist, which fields are included, and whether reliable outcomes are available.
For example, the support collection below contains 18,000 closed tickets, but only 12,000 have customer-confirmed resolutions. A useful manifest makes that distinction visible.
Turn an inventory into a useful description.
“We have accounting records” leaves a reviewer with many questions. A useful manifest explains which records you mean, what work they document, how they can be exported, and what context makes them understandable.
For an initial review, a manifest may be a structured form or spreadsheet summarizing each dataset. At delivery, a more technical manifest may list individual files, sizes, versions, and checksums. Use the format the receiving partner requests.
The goal is to help a reviewer judge relevance, scope, quality, and preparation needs. A manifest is a basis for evaluation; it does not establish a price or guarantee a licensing agreement.
How a manifest supports the licensing process.
An AI lab or data partner may request a manifest during an initial application or a follow-up conversation. This example shows how it can fit into the process; the exact steps depend on the organization.
- STEP 1
Apply and describe your data
A company contact submits an inquiry or application and prepares the company profile and data manifest requested by the prospective partner.
- STEP 2
The partner evaluates the opportunity
The AI lab or data partner reviews the description and may ask about scope, quality, rights, and preparation. If there is interest, both sides discuss terms and next steps.
- STEP 3
Proceed if both sides agree
If both parties agree on terms, they can move to contracting, agreed preparation, data transfer, and acceptance.
Follow the prospective partner's current application and submission instructions. The examples in this article show how to describe a dataset and are not an official submission template.
What should a useful manifest include?
Begin with one entry for each distinct dataset. Describe what you can confirm and label estimates or unanswered questions clearly.
| Name and purpose | A specific dataset name and the business activity it documents, such as completed supplier reconciliations. |
|---|---|
| Contents and connections | The records included, important fields, supporting attachments, and IDs that connect related records. |
| Coverage and volume | Date range, number of cases or records, file count, and storage size when known. State the unit: 5,000 files and 5,000 completed cases describe different things. |
| Formats and source systems | Current systems, available export formats, languages, and whether extraction is straightforward or needs work. |
| Context and quality | Definitions, how outcomes were checked, missing periods or attachments, duplicates, and other known limitations. |
| Rights and sensitive information | Who controls the records, potential client or third-party restrictions, sensitive fields, and questions that need review. |
| Preparation and contact | The responsible team, what is ready, what remains to be checked, and any ongoing updates you could potentially supply. |
Three example data manifests
These are hypothetical summaries. The counts, dates, and filenames are invented to illustrate the level of detail; they are not qualification thresholds or actual company submissions.
Supplier reconciliation cases
“We have accounting files” becomes a description of work that connects a discrepancy to an investigation, an approved correction, and a verified result.
| Dataset | Completed supplier account reconciliations, January 2022 through December 2025. |
|---|---|
| Volume | 1,200 reconciliation cases, with approximately 4,800 supporting documents. Case and document counts are tracked separately. |
| Proposed files | cases.csv, adjustments.csv, and document_index.csv, plus approved PDF statements, workpapers, and invoice evidence. |
| Important fields | Case ID, reporting period, opening discrepancy, investigation notes, adjustment reason, reviewer status, and final reconciliation result. |
| How records connect | The case ID links the starting balances, evidence, proposed adjustment, reviewer decision, and final workpaper. The document index maps each attachment to its case. |
| Quality and limitations | Reviewer sign-off is available for completed cases. Some older cases have scanned documents with limited searchable text; those cases are flagged. |
| Preparation and review | The accounting operations lead can assess the export. Client confidentiality, document ownership, identifiers, and the permitted scope require review before sharing. |
What a reviewer can assess: whether the package contains enough linked evidence to reconstruct the investigation and check the result.
Tickets with troubleshooting and outcomes
A support manifest should make clear whether the dataset includes the conversation, the actions taken, and evidence that the issue was resolved.
| Dataset | English-language technical support cases, January 2023 through December 2025, exported from a ticketing system. |
|---|---|
| Volume | 18,000 closed tickets containing approximately 95,000 messages. Customer confirmation of resolution is available for 12,000 tickets. |
| Proposed files | tickets.csv, messages.jsonl, and outcomes.csv, plus an index of any attachments proposed for inclusion. |
| Important fields | Ticket ID, product version, issue category, timestamps, message role, troubleshooting actions, escalation status, and recorded outcome. |
| How records connect | The ticket ID links messages and outcomes. Message timestamps preserve the sequence of the investigation and any handoffs between agents. |
| Quality and limitations | Customer-confirmed resolutions are identified separately from tickets merely marked closed. Some screenshots are missing, and product-version coverage varies. |
| Preparation and review | The support operations team owns the export process. Customer details, credentials, confidential attachments, and platform or customer restrictions need review. |
What a reviewer can assess: whether the records show the diagnostic reasoning and a reliable outcome, with enough product context to interpret the solution.
Maintenance and verified repair histories
The useful package may combine work orders, technician observations, parts replacements, images, and tests performed after the repair.
| Dataset | Industrial equipment service records for 240 assets, January 2021 through December 2025. |
|---|---|
| Volume | 6,500 work orders, 14,000 inspection images, and 4,800 recorded post-repair test results. Not every work order includes each type of evidence. |
| Proposed files | assets.csv, work_orders.csv, test_results.csv, and image_index.csv, with approved JPG images. |
| Important fields | Asset ID, equipment model, work-order ID, operating hours, symptoms, diagnostic findings, repair action, parts used, and test result. |
| How records connect | Asset IDs connect service histories over time. Work-order IDs link each visit to its images, repair actions, and post-repair tests. |
| Quality and limitations | Units and test pass criteria are documented. Earlier notes use inconsistent fault terminology, and missing test results are identified. |
| Preparation and review | The service manager coordinates the export. Customer-site details, equipment identifiers, image rights, and third-party technical content require review. |
What a reviewer can assess: whether the history connects symptoms and repair decisions to a measurable outcome, and how consistently those links exist.
Can the Business Data Checklist help you create one?
Yes. Start by building your inventory. The DataHasValue checklist helps you identify records you have and add their location, internal contact, history, approximate volume, formats, permission-review status, and preparation notes.
- Identify the candidates. Mark the examples you have and add any records unique to your business.
- Complete the optional details. Ask the responsible team to confirm scope, volume, formats, and known gaps.
- Download your selected inventory. The CSV includes both “We have this” and “Unsure” selections, so resolve or clearly label the uncertain items.
- Prepare the manifest for review. Select the datasets you are proposing, add specific fields and record connections, and enter the information in the prospective partner's requested format.
Move from “we have this” to “here is what it contains.”
Your checklist provides the starting inventory. The manifest adds the detail needed to understand a specific dataset and evaluate the opportunity.
Build your business data inventoryMake the manifest easy to evaluate.
- Use specific names. “Completed equipment repairs with post-repair tests” says more than “operations data.”
- Explain the units. Separate cases, messages, attachments, files, and storage size; label approximate counts.
- Describe the links and gaps. Say how documents connect and identify missing context, duplicate records, or unverified outcomes.
- Be clear about readiness. Explain what exists now, what requires an export, and what still needs permission or privacy review.
A clear manifest helps the next conversation focus on the actual data, its usefulness, and the work needed to assess a possible partnership.
Continue learning
Explore data licensing for your company.
Visit the DataHasValue licensing page to learn about company fit and available referral opportunities. Use your inventory to help prepare any company profile and data manifest requested by a prospective data partner.
Explore data licensing for your company Start with the Business Data ChecklistReferral disclosure: I'm Jason Varner, founder of DataHasValue. I may receive compensation from qualifying company referrals through links on this website.
