3D Printing Master Data Governance and One-Item-One-Code Traceability: From Coding Rules and Version Indexing to Data Dictionary Implementation

Why Multiple Codes for One Item Cause Continuous Rework in 3D Printing Workshops

In high-mix, low-volume 3D printing workshops, the most common issue is not equipment downtime but a more hidden source of loss: the same part is called A in the quotation system, B on the process card, C in the MES work order, and D again on the inspection report. On the surface, all four numbering systems are functioning; in reality, they cannot be reconciled. In reviews of multiple on-demand manufacturing operations, the author found that whenever a part lacks a unique identity code, subsequent material batches, print parameters, inspection records, and delivery traceability can only be pieced together from human memory. Once personnel change or orders run concurrently, use of the wrong revision, incorrect material issuance, and assembly errors become almost inevitable.

The problem is compounded by the fact that 3D printing naturally encourages rapid iteration. A bracket may have its wall thickness changed today, build orientation adjusted tomorrow, and powder batch replaced the day after. If every change creates a new file without being incorporated into unified coding and revision rules, a dozen similar yet incompatible models can accumulate within weeks. This is why digital-factory development cannot focus only on equipment connectivity; it must first address master data and one-item-one-code identification.

1. What Master Data Really Is: Turning a “Part” from a File into a Controlled Object

Master data refers to core business entities that are reused across systems and departments and do not change frequently. For 3D printing companies, key master data should include at least four categories: material/part master data (including material grade, process route, and default post-processing); equipment master data (machine model, build-cylinder dimensions, laser power, and coordinate system); supplier and batch master data (powder lot number, number of sieving cycles, and oxygen content); and process-parameter master data (layer thickness, laser power, scan speed, hatch spacing, and preheat temperature).

The value of this data lies in semantic consistency. For example, the lot number P-2026-10-041 for 316L powder must point to the same code across purchasing receipt, material issue, sieving and reuse, and printing consumption. Otherwise, the question “Which powder batch was used?” will never have a reliable answer. Likewise, the identifier E-LPBF-03 for an LPBF machine must be linked to its maintenance records, geometric-accuracy calibration reports, and build-cylinder number; only then do equipment availability and failure statistics become meaningful.

The distinction between master data and transactional data must also be clear: work orders, delivery notes, and inspection reports are transactional data generated every day; part numbers, equipment numbers, and material grades are master data referenced repeatedly. The former can grow in volume without limit, while the latter must be tightly controlled and changes must be traceable.

2. One-Item-One-Code Rules: Readable, Scalable, and Verifiable

The core of one-item-one-code identification is not simply “assigning every part a number,” but ensuring that the code itself has a parseable structure. In practice, the most robust approach is a segmented format: category code-feature code-sequence number-revision index. For example, BR-Ti64-LPBF-0147-R03 represents a bracket-type part, Ti6Al4V material, LPBF process, sequence number 0147, and Revision 3, respectively. This coding structure provides three direct benefits: first, it is human-readable, allowing warehouse and quality personnel to identify basic attributes without querying a database; second, systems can search by segment to quickly filter “all titanium-alloy LPBF parts”; third, the revision index embeds design iterations in the code and prevents obsolete drawing numbers from being misused.

Several common pitfalls should be avoided in code design. Do not include variable information in the code—customer names, order numbers, and quantities can change, and including them makes the code unstable. Do not use sequential numbers to convey meaning, as this can create duplicates and does not scale. Do not rely on non-ASCII or full-width characters, which can easily result in inconsistent codes across system interfaces. Use uppercase letters, numbers, and hyphens only, and keep codes within 16 to 24 characters to balance readability and barcode capacity.

For serialized parts—where every physical item requires individual traceability, such as aerospace components or medical implant prototypes—add a serial-number segment on top of the one-item-one-code structure, creating a two-level “part code + serial number” structure. The part code manages the design identity, while the serial number manages the physical-item identity; the two should be linked in a parent-child relationship in the MES.

3. Revisions and Drawing Numbers: Making Every Change Traceable

The pace of 3D printing iteration places higher demands on revision management. A recommended rule is that a revision must be raised whenever geometry, material, or any critical process parameter changes. Changes only to notes, packaging instructions, or other information that does not affect physical attributes do not require a revision increase, but must be documented in the revision notes. Revision numbers should use R followed by two digits (R01, R02, and so on) and correspond exactly to the revision index in the code.

Every revision must retain four items: the version's 3D model files, with one STEP file and one native-format file; the associated drawing number and technical requirements; the process card and parameter set for that revision; and first-article inspection or validation records. If any of these is missing, the revision should not be released to production. Many teams retain only the model files while overlooking that “the parameter set is also part of the revision.” Parts printed from the same model using two parameter sets may have dramatically different properties; without parameter revision control, performance variation cannot be explained.

Obsolete revisions must not be deleted; they may only be marked as “obsolete/historical reference only.” Deleting historical revisions destroys the traceability chain. If a customer complaint or failure analysis occurs, the design and process state at that time can no longer be reconstructed.

4. Implementation Path: From Coding Rules to End-to-End System Integration

Implementation is best advanced in four steps, each of which can be independently accepted. The first step is code cleanup: inventory all current work-in-process and historical parts, identify cases of multiple codes for one item and one code for multiple items, and create a cross-reference table. This is the most tedious step, but it is also the only step that cannot be skipped. The second step is rule establishment: publish coding rules, revision rules, and a data dictionary, clearly defining the responsible person and allowed value range for each field. The third step is system entry: embed the rules in PLM or ERP, prohibit manual offline numbering, and require the system to generate codes for new parts according to the rules. The fourth step is integration: ensure that reference fields in quotation, process planning, production scheduling, inspection, and shipping all point to the same part code. Any missing code at any stage should be treated as non-compliant and must not be allowed to proceed to the next stage.

Three quantitative metrics are recommended for acceptance: the multiple-codes-for-one-item rate, with a target below 1%; master-data required-field completeness, with a target above 98%; and revision traceability, measured by sampling 100 work-in-process parts and determining the percentage for which the model, parameters, and inspection records can be fully reconstructed, with a target of 100%. Reviewing these three metrics monthly provides a far more accurate reflection of actual progress than any slogan-driven “digital transformation” initiative.

5. Common Failure Modes and How to Avoid Them

The most common failure is treating master data as a one-time project. Master data requires continuous governance; otherwise, new parts will again be assigned manual codes within six months and the rules will become meaningless. Designate a single owner, and require all coding-rule changes to be reviewed and recorded by that owner. A second failure is overdesigning fields—defining hundreds of fields at once, only to find that no one can complete them and they are ultimately left blank. A better approach is to start with 15 to 25 core fields, establish a working process, and expand gradually as business needs require. A third failure is overlooking outsourced and incoming-material scenarios: outsourced parts and customer-supplied drawings often enter production without internal coding. Codes must be assigned at order intake; otherwise, the traceability chain is broken at the very beginning.

Another frequently overlooked point is that coding rules should allow for expansion across plants and systems. A code used in only one workshop today may need to connect to a customer's PLM or an industry platform tomorrow. Reserving a plant segment or prefix segment in the code can eliminate the need for a painful, full-scale future restructuring.

Conclusion

The true foundation of digitalization in a 3D printing workshop is neither equipment connectivity nor dashboards. It is ensuring that every part has a unique, stable, and parseable identity code, supported by corresponding revision controls and a data dictionary. Master data governance may appear tedious, but it directly determines whether material batches can be traced, process parameters can be reproduced, and delivery evidence can be accepted by customers. From auditing existing codes and publishing rules to system enforcement and end-to-end integration, this path requires several months of sustained investment. In return, it makes all subsequent digital capabilities—scheduling, quality inspection, costing, and traceability—genuinely achievable.