Home services and trades
Illustrative dataset manifest for an HVAC job history
By SourceX Editorial · Updated
Short answer
A dataset manifest for an HVAC job history is a short document listing every table, its key fields, the years covered, record counts and the privacy treatment applied to each field. The illustrative manifest below uses placeholders for counts. Write it before export, so the owner approves the exact scope and a buyer sees what it would receive.
Key takeaways
- A manifest is a control as well as a description: nothing outside it is exported, and every scope change means a new version.
- Exclusions such as call audio, photos and payment data belong in the manifest, not in a side conversation.
- Each table row states a privacy treatment, and the Evidence Packet must show how that treatment was checked.
- Dataset keys are generated fresh, and the table that maps them back to real customers never leaves the company.
- Quality notes about gaps and coding changes build trust and prevent disputes at delivery.
What is a dataset manifest for?#
A dataset manifest records exactly what a licensed dataset contains, written so the supplier, the buyer and any reviewer read the same description. It names tables and fields, gives date ranges and counts, and states how each field was treated for privacy.
Manifests draw on published documentation practice. The Datasheets for Datasets paper, published in Communications of the ACM in December 2021, argued for documenting how a dataset was made and what it should be used for, and the Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use.
For a COO, the manifest is also a control. Nothing outside it gets exported, and any change to scope produces a new, approved version rather than a quiet addition.
Illustrative: the company behind this manifest#
Illustrative: the manifest on this page describes a fictional residential HVAC and plumbing company that has run the same field service platform for several years and keeps its books in a separate accounting system. The job history covers calls, estimates, jobs, equipment, invoices, maintenance agreements and callbacks.
Every count, year and share appears as a placeholder in square brackets. The owner chose to exclude call recordings, photos, signed documents and payment data from this version, and those exclusions are written into the header rather than left to memory.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Manifest header#
The manifest header answers the Source, Provenance and Use questions at a glance: where the records came from, how they were produced and changed, and what they may be used for. A reviewer should understand the dataset from the header alone before reading any table.
| Item | Illustrative entry |
|---|---|
| Dataset name | Residential HVAC and plumbing job history, version [n] |
| Supplier entity | [Legal name of the operating company] |
| Source systems | Field service platform; accounting system used only to reconcile invoice totals |
| Coverage | [first year] to [last year] |
| Record families | Customers, locations, equipment, calls, estimates and options, jobs, job notes, invoices, agreements, callbacks |
| Excluded | Call audio, photos, signed documents, payment details, employee HR records |
| Language | English |
| Delivery | Open file formats delivered from the supplier's own storage |
| Permitted use | As stated in the license agreement, version [n] |
| Prepared | [date], by [preparer], approved by [authorized signer] |
Tables, fields and privacy treatment#
The table section lists each table with its key fields, a row count placeholder and the privacy treatment applied. Field names here are plain descriptions; a real manifest would also reference the data dictionary for exact field definitions.
Each row is a promise. If the job notes row says names and entry codes are removed, the preparation record must show how that was checked, including any sampled human review.
| Table | Key fields | Rows | Privacy treatment |
|---|---|---|---|
| Customers | Customer key, customer type, first job date | [count] | Names, phones and emails removed; key is a pseudonym |
| Locations | Location key, region, home type band | [count] | Street address removed; region only |
| Equipment | Equipment key, type, brand, model, install date, decoded age | [count] | Serial replaced with a hash; data plate photos excluded |
| Calls | Call key, date, reason code, booked flag | [count] | No audio or transcript; caller details removed |
| Estimates | Estimate key, options presented, tier, choice, decline reason | [count] | Prices banded; financing reduced to a flag |
| Jobs | Job key, job type, dates, technician role, status, duration | [count] | Technician names replaced with role and pseudonymous ID |
| Job notes | Job key, note text | [count] | Redacted for names, addresses, phone numbers and entry codes |
| Invoices | Invoice key, job key, line item categories, total band | [count] | No card or bank data; totals banded |
| Agreements | Agreement key, plan type, start and end dates, visits | [count] | Linked to customers by pseudonymous key only |
| Callbacks | Callback key, original job key, root cause, fix | [count] | Same treatment as jobs |
How linkage keys are generated and protected#
Linkage keys let a buyer follow a job from call to estimate to invoice to callback without learning who the customer was. The keys are generated for the dataset, and the table mapping them back to real customer and location IDs stays inside the company.
- Generate new keys for the dataset; never reuse platform IDs, invoice numbers or agreement numbers.
- Keep the mapping table inside the company, with access limited to the preparation owner.
- Use one key per location across all tables so each home's history stays connected.
- Shift or band dates only where the license requires it, and record the method in the manifest.
- Test that no combination of fields in the dataset can be matched back to a street address.
Quality notes and known gaps#
Quality notes tell the buyer where the data is weak, which builds trust and avoids disputes later. A manifest claiming perfect coverage invites hard questions at delivery, while one that names its gaps lets the buyer plan around them.
Write the notes from the completeness checks run during preparation, not from memory. Placeholders below show the form; a real manifest fills them from those checks.
| Note type | Illustrative entry |
|---|---|
| Field fill | Equipment model blank for [share] of units installed before [year] |
| Coding change | Callback root cause list introduced in [year]; earlier callbacks uncoded |
| Price book change | Tiers restructured in [year]; mapped to a common good, better, best scale |
| Duplicates | Duplicate customers merged before keys were assigned |
| Text review | Note redaction checked by sampled human review of [count] notes |
Version and approval record#
The version and approval record shows who approved each version of the manifest and what changed, so the supplier can prove exactly what it released. Each entry names the version, the date, the approver and a one-line summary of the change, such as a table added at a buyer's request or a year range narrowed after a rights finding.
Keep superseded versions rather than overwriting them. If a question arises after delivery about whether a field was included, the record answers it without anyone relying on memory, and it shows the buyer that the supplier ran a controlled process.
How SourceX uses the manifest#
SourceX drafts the manifest with the supplier during Preparation, the third step of the SourceX five-step transaction, after Supply confirms the records exist and Rights confirms they can be licensed. The supplier approves the manifest at the Approval step before anything moves to Delivery.
The approved manifest then sits in the SourceX Evidence Packet alongside provenance, licensing rights, permitted use, the privacy record and release authorization. A job history too large to transfer stays in the supplier's own storage or ships on encrypted drives, because SourceX never hosts multi-TB datasets.
Frequently asked questions
Who writes the manifest, the supplier or the buyer?
The supplier owns the manifest, because it describes the supplier's records and what the supplier approved. A buyer may ask for specific fields, years or formats, and those requests become a new version that the supplier reviews and approves before preparation changes.
Do we need real counts before talking to a buyer?
Approximate counts and year ranges are enough early on, and they can come from standard reports without exporting anything. Exact counts are filled in after preparation, because removals, exclusions and deduplication change them.
Can the manifest itself reveal sensitive information?
It can if it includes real customer names in examples, internal prices or contract terms. Keep the manifest to structure, coverage and treatment, and use invented sample values whenever an example helps a reader.
How is a manifest different from a data dictionary?
A data dictionary explains what each field means in your system. A manifest describes one specific dataset: which tables and fields were included, for which years, how they were treated and what was left out. Most manifests reference a dictionary for definitions.
Do we need a new manifest for each license?
Usually each license gets its own version, since scope, permitted use and preparation can differ. Reusing the structure saves effort, and the version number and approval record keep each one distinct.
What file format should the manifest use?
A spreadsheet or a short document works, as long as the structure is consistent and the version is clear. Some teams also keep a machine-readable copy beside the dataset files so a buyer's tools can read table names, fields and coverage directly. The content matters more than the format.
Sources
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups: Source, Provenance and Use. The specification says this metadata is needed "to enable proper dataset selection for AI Model Training." Source
- "Datasheets for Datasets" by Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daume III and Kate Crawford was published in Communications of the ACM, vol. 64, no. 12, pp. 86-92 (December 2021). Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.