1.1 The GDP Standard: Formats, Directory & Integrity
Production issues often begin with data ambiguity. When the engineering input data is fluid, subjective, or incomplete, the manufacturing output will be unpredictable.
The Golden Data Pack (GDP) is a deliberately controlled configuration item, not a casual collection of email attachments or a link to a live SharePoint folder. It represents a single, immutable snapshot of the product definition at one specific moment in time. When the GDP does not compile to a deterministic, repeatable state, the physical build should not start.
The Frozen Artifact Principle
Section titled “The Frozen Artifact Principle”You must treat the GDP like a compiled binary for the factory. It should be delivered as a single, version-controlled archive (ZIP or TAR) carrying a unique hash.
The Rule of Immutability
Section titled “The Rule of Immutability”Once a GDP revision (e.g., REV_A01) is formally released to the EMS, no file inside it may change.
- When an engineering change is required (even altering a single resistor value), a completely new GDP Revision (REV_A02) must be generated and released.
- When files are replaced “on the fly” via email or Slack, configuration integrity is broken, and warranty liability shifts back to the design engineer.
Directory Structure Standard
Section titled “Directory Structure Standard”A standardized directory structure eliminates wasteful “treasure hunting” by CAM engineers. The GDP root directory should adhere to the following schema.
The Required Directory Layout:
Section titled “The Required Directory Layout:”/PROJECT_NAME_REV_XX/
├── 00_MANIFEST/ (Traceability & Meta-data)
├── 01_BOM/ (The Bill of Materials)
├── 02_FABRICATION/ (Gerbers, ODB++, Drill files, Stackup Definitions)
├── 03_ASSEMBLY/ (Pick & Place, Assembly Drawings, Stencil Data)
├── 04_SCHEMATICS/ (PDF format strictly for debug reference only)
└── 05_TEST_FIRMWARE/ (Binaries, Flashing instructions, Test specifications)
Engineering Rule: Avoid burying files in deep sub-folders like .../Outputs/Job1/Gerbers/Final/For_Production. Flatten the hierarchy to the core folders listed above.
Allowed Formats & Rejection Criteria
Section titled “Allowed Formats & Rejection Criteria”The EMS intake process is a clear logic gate. Data must be machine-readable and unambiguous.
Fabrication Data (The PCB)
Section titled “Fabrication Data (The PCB)”- Preferred: ODB++ (.tgz) or IPC-2581 (.xml). These intelligent formats contain clear layer data and explicitly defined materials, significantly preventing stackup interpretation errors.
- Accepted: Gerber X2 / RS-274X. Must explicitly include NC Drill files (Excellon format) and a Netlist (IPC-D-356) for bare-board electrical test validation.
- Rejected: Native CAD files only (e.g., .PcbDoc, .brd) without generated fabrication outputs. Native files introduce version-dependency and font-translation risks.
Assembly Data (The PCBA)
Section titled “Assembly Data (The PCBA)”- Required: Centroid / Pick-and-Place file (ASCII/CSV) containing the exact matrix: RefDes, X-Loc, Y-Loc, Rotation, Side (Top/Bottom).
- Required: BOM in a structured, machine-parsable CSV or Excel format.
- Rejected: PDF-only BOMs or scanned images.
Intake Logic: When to Reject the Pack
Section titled “Intake Logic: When to Reject the Pack”- When the archive contains “mystery files” (e.g.,
Old_Files_Ignore.zip), the pack is rejected. - When file names contain conflicting revision tags (e.g., The root folder says REV_B but the Gerber package says REV_A), the pack is rejected.
- When critical hardware layers (Paste, Silkscreen, Drill) are missing, the pack is rejected.
The Manifest: Proof of Origin
Section titled “The Manifest: Proof of Origin”Every single GDP must contain a 00_MANIFEST/README.txt or manifest.json. This file acts as the birth certificate of the build configuration. Without it, production cannot reliably prove what was built 12 months from now.
Mandatory Manifest Data Fields:
Section titled “Mandatory Manifest Data Fields:”- Package Revision: Must exactly match the archive filename.
- Generation Date: ISO 8601 format (YYYY-MM-DD).
- Author/Owner: The accountable Engineering point of contact.
- EDA Tool Version: (e.g., Altium 23.1, KiCad 7.0). This is critical for debugging obscure polygon translation errors.
- Master Checksum (SHA-256): (Highly Recommended) Cryptographically validates file integrity during cross-network transfer.
Final Baseline Checklist
Section titled “Final Baseline Checklist”| The Control Point | The Operational Requirement | The Go/No-Go Metric |
|---|---|---|
| Archive Format | Single contiguous ZIP/TAR file. | Zero loose files or split email attachments. |
| Naming Convention | Project_Revision_Date.zip | Perfectly matches the internal PLM record. |
| Directory Structure | Standard 00-05 root folder layout. | Files are exactly located in correct sub-directories. |
| Fab Data | ODB++ OR Gerber + Drill + Netlist. | CAM software loads the entire stack with zero errors. |
| BOM Format | CSV/XLSX (Purely Machine Readable). | Zero PDF BOMs accepted. |
| Revision Sync | All files sync to one master Revision ID. | No mixed-revision packs (Rev A PCB + Rev B BOM). |
| The Manifest | README or Manifest file is present. | Contains Author, Date, and specific Tool Version. |