Manufacturing
Illustrative workflow data package: a manufacturer's quality decisions
By SourceX Editorial · Updated
Short answer
A workflow data package for manufacturing quality bundles linked records of real decisions, from nonconformance reports and MRB dispositions to supplier corrective actions, CAPAs and effectiveness checks, with a manifest describing every file, field, link and exclusion. The example below is illustrative. The rule: every record traces to a decision and an outcome, and every exclusion is written down.
Key takeaways
- A quality data package is defined by its links: each NCR traces to a disposition, and each CAPA to an effectiveness check.
- The manifest describes files, fields, date coverage, transformations and exclusions, so a buyer does not have to guess.
- Customer drawings, customer names, export-controlled parts and process setpoints are excluded or coded before delivery.
- Code lists for defect, cause and disposition codes travel with the package so the records can be read.
- A buyer reviews the manifest, a sample and the evidence of rights and privacy preparation before delivery is approved.
What is a workflow data package?#
A workflow data package is a set of linked business records showing how one type of work moved from trigger to outcome, delivered with the documentation an outside team needs to use it. For a quality department, the work is a series of decisions: what to do with nonconforming parts, whether the cause is systemic, and whether the fix held.
AI developers want packages like this to train and evaluate agents that reason through operational problems. They need decisions and outcomes, not just defect counts, and they need confidence that the supplier had the right to share the records and removed what should not travel.
Everything that follows describes a fictional package. Its structure is the useful part, because you can hold your own QMS and ERP records up against it.
Illustrative manifest: the files in the package#
The manifest is the package's table of contents: one row per file, naming the record family, the key fields, the links to other files and the preparation applied.
Illustrative: the fictional supplier is a precision components manufacturer that keeps NCRs, MRB decisions and CAPAs in a QMS, supplier corrective action requests in email and a supplier portal, and production records in its ERP. Its manifest lists one file per record family.
| File | Record family | Key fields | Links to | Preparation applied |
|---|---|---|---|---|
| ncr.csv | Nonconformance reports | NCR ID, date, part family, defect code, description, quantity affected, detection point | Job, lot and supplier IDs | Customer names coded; part numbers mapped to families |
| mrb_dispositions.csv | Material review board decisions | Disposition, rationale, approver role, date | NCR ID | Approver names replaced with roles |
| investigations.csv | Root cause analyses | Method, cause category, narrative, contributing factors | NCR and CAPA IDs | Setpoints in narratives replaced with relative terms |
| capa.csv | Corrective and preventive actions | Action type, owner role, due and closed dates, status | NCR and investigation IDs | Employee names pseudonymized |
| effectiveness.csv | Effectiveness checks | Check method, result, recurrence observed | CAPA ID | Coding only |
| scar.csv | Supplier corrective action requests | Issue, supplier response, containment, closure | Supplier and NCR IDs | Supplier names coded; pricing removed |
| jobs.csv | Production context | Operation, work center type, completion dates | Job ID | Customer and drawing references removed |
| code_lists.csv | Lookup tables | Defect, cause, disposition and action codes with meanings | All files | None |
How one NCR travels through the package#
One NCR in the package travels through every file, and following a single record end to end is the fastest way to test whether a package hangs together. It is usually the first thing a buyer's reviewers do.
- Detection: final inspection finds an oversize bore on a lot of housings, and an NCR is opened with a defect code and detection point.
- Containment: the lot is quarantined and in-process stock is checked; the NCR records what was held.
- Disposition: the MRB chooses rework for some parts and scrap for the rest, with a written rationale.
- Investigation: root cause analysis traces the problem to tool wear on one machine type and a missed tool change.
- Action: a CAPA updates the tool life rule and the work instruction, with owner role and dates recorded.
- Effectiveness: a later review of following lots finds no recurrence, and the CAPA closes.
- Context: the job file shows the operation and work center type, and no drawing or customer name appears anywhere.
What the package leaves out, and why#
The package leaves out anything the supplier lacks the right to share or should not share, and the manifest says so explicitly. A written exclusion list matters as much as the file list, because it is how a buyer knows the gaps are deliberate rather than accidental.
| Excluded or transformed | Reason | How it is handled |
|---|---|---|
| Customer drawings, models and specifications | Customer property under NDA and purchase order terms | Removed; references stripped from text fields |
| Customer names and part numbers | Confidential customer relationships | Replaced with consistent codes and part families |
| Export-controlled parts and programs | Controlled technical data | Whole records removed after screening |
| Process setpoints and recipes | The supplier's trade secrets | Exact values removed or expressed as relative changes |
| Employee names and signatures | Personal data | Replaced with role labels or pseudonymous IDs |
| Supplier pricing and contract terms | Supplier confidentiality | Removed; supplier identity coded |
| Complaint contact details | Third-party personal data | Removed; complaint category kept |
Documentation that travels with the files#
Documentation turns a folder of CSV files into a usable package. Without it, a buyer cannot tell what a defect code means, why a field is empty in older records or whether two systems were merged along the way.
- Data dictionary: every field, its meaning, type and allowed values.
- Code lists: defect, cause, disposition and action codes, including retired codes and when they changed.
- Coverage note: date range per file, sites included and known gaps such as a QMS migration.
- Linking guide: which IDs join which files, and where links are missing and why.
- Preparation log: what was removed, coded or transformed, by which method, and who reviewed it.
- Sample walk-throughs: a few complete NCR chains for orientation.
What does a buyer review before approving?#
A buyer reviews the manifest, a prepared sample and the evidence behind the package before approving delivery. An industry metadata standard points the same way: the Data & Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, which the specification describes as necessary for proper dataset selection for AI model training. Its Use group includes elements such as confidentiality classification, privacy-enhancing technologies applied, license to use and intended data use, which map closely to the exclusion table and preparation log above.
In a SourceX transaction that evidence is the SourceX Evidence Packet. The table maps its five parts to this quality package.
| Evidence Packet element | What it shows for this package |
|---|---|
| Provenance | Which QMS, ERP and email sources produced each file, and the date range covered |
| Licensing rights | Why the supplier may license these records, and which customer and supplier terms were checked |
| Permitted use | Training or evaluation use, with no redistribution |
| Privacy record | How names, contacts and signatures were removed or pseudonymized |
| Release authorization | Who at the supplier approved the final scope, and when |
How to build your own version#
Building your own version starts with a single NCR, not the whole QMS. Pick a closed, representative NCR, trace it through every system it touched, and note where the trail breaks. Those breaks tell you what to fix or document before anyone discusses scope.
Then widen to a period when the QMS was stable, export each record family with its IDs, and draft the exclusion list with quality, engineering and counsel. A metadata-only fit check can come before any of this, since it asks about systems, years of history and record families, not files.
Within the SourceX five-step transaction, this work spans Supply and Preparation. Delivery happens only after the supplier signs off, from the supplier's own environment or on encrypted drives, because SourceX does not host large datasets. The records are licensed rather than sold.
Frequently asked questions
Do we need a QMS to build a package like this?
No, but you need consistent IDs. Shops that track NCRs in spreadsheets and CAPAs in email can still assemble a package if each record carries an NCR or job number that ties it to the rest. The linking guide then explains how the sources were joined.
What if older NCRs have no effectiveness checks?
Include them and say so in the coverage note. A buyer would rather see an honest gap than a filled-in field. Records with complete chains can be flagged, so developers can choose which subset to use for training and which for evaluation.
Can supplier corrective action records be included?
Often, with supplier identities coded and pricing removed. Check supplier agreements for confidentiality clauses covering their responses. Where a supplier's reply includes its own proprietary process detail, that detail may need to come out as well.
How are free-text narratives handled?
Narratives are often the most valuable and the riskiest fields. They are scanned and reviewed for names, customer references, part numbers and setpoints, then edited or coded. Automated scanners help, but the open-source Presidio project's documentation warns there is no guarantee it will find all sensitive information, so a person who knows the products reviews a sample.
Is this example based on a real company?
No. The supplier, records and decisions are fictional and shown only to illustrate structure. Real packages vary with the systems a manufacturer uses, the years of history available and the exclusions its contracts require.
Sources
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups: Source, Provenance and Use, and say this metadata is needed to enable proper dataset selection for AI model training. Source
- Presidio's documentation warns that because it uses automated detection mechanisms, there is no guarantee that Presidio will find all sensitive information, and additional systems and protections should be employed. Source
- The Use group of the Data & Trust Alliance Data Provenance Standards includes elements for confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed and excluded processing and storage geographies, license to use, intended data use, and copyright, patent and trademark status. Source
Related resources
- IndustryProperty management data
- InsightCan manufacturers sell their data to AI companies?
- InsightCan energy and utilities sell their data to AI companies?
- InsightCustomer-owned designs vs your process records: what manufacturers can license
- SolutionTurn the data your company already creates into a licensing asset
- SolutionOperational data: the step-by-step record of how work gets done
See if your company qualifies
A short company assessment. No data uploads are needed.