Since the inception of IUID policy back in 2003, the debate over encoding syntax with UID has raged on. Early in the adoption, what I’ll call the “engineering mindset” won the debate, which prompted many to choose construct 2 as their format of choice. Now that almost 8 years have passed, the practicality and direct experience involved in part marking has pushed construct 1 directly into the planning psyche. Both constructs are viable options for encoding the UID however this post will act as a recap of the two approaches to MIL STD 130 and UID encoding.

Construct #1 – Items are serialized within the enterprise and contain the following data:

  • Issuing agency CAGE code
  • Enterprise ID
  • Serial Number

Example: Using a familiar analogy, the license plate number on an automobile is that car’s unique serial number, and the enterprise ID is the state that ha1s issued the plate. The data describing the vehicle, such as the VIN, color and any other information, is then associated with the unique serial number. Note that license plates are created in bulk, prior to assignment to individual vehicles.

The principle advantages of using Construct #1 are the minimization of marking and application errors and the ability to purchase labels in bulk, ready for use on any item.

Construct # 2 – Items are serialized within the part number and contain the following data:

  • Issuing agency CAGE code
  • Enterprise ID
  • Original part number
  • Serial number

Example: Using the same license plate analogy, consider that license plates are made in bulk, and when a car is registered the clerk simply hands one out, after inputting registration data. In Construct #2, however, each plate would have to be made individually, because all detail concerning the automobile, including original part numbers and serial or lot numbers, would need to be properly communicated and then built into the plate number. This creates an opportunity for error as well as a delay in label availability.