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. If the GDP does not compile to a deterministic, repeatable state, the physical build should not start.

The Frozen Artifact Principle

The GDP must be treated like a compiled binary for the factory. It should be delivered as a single, version-controlled archive (such as a .zip or .tar file) carrying a unique cryptographic hash.

The Rule of Immutability

Once a GDP revision (for example, REV_A01) is formally released to the EMS, no file inside it may be altered.

• If an engineering change is required—even for a single resistor value—a completely new GDP Revision (like REV_A02) must be generated and released.
• Replacing files “on the fly” via email or Slack breaks configuration integrity and can shift warranty liability back to the design engineer.

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:

/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)

Strict Constraint

Burying files in deep sub-folders like ”…/Outputs/Job1/Gerbers/Final/For_Production” is prohibited. The hierarchy must be flattened to the core folders listed above.

Allowed Formats & Rejection Criteria

The EMS intake process is a strict checkpoint. Data must be machine-readable and unambiguous.

Fabrication Data (The PCB)

• Preferred: ODB++ (.tgz) or IPC-2581 (.xml). These intelligent formats contain clear layer data and explicitly defined materials, which helps prevent stackup interpretation errors.
• Accepted: Gerber X2 / RS-274X. These 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)

• Required: A Centroid / Pick-and-Place file (ASCII/CSV) containing the exact matrix: RefDes, X-Loc, Y-Loc, Rotation, and Side (Top/Bottom).
• Required: A BOM in a structured, machine-parsable CSV or Excel format.
• Rejected: PDF-only BOMs or scanned images.

Intake Logic: When to Reject the Pack

• If the archive contains “mystery files” (e.g., “Old_Files_Ignore.zip”), the pack is rejected.
• If file names contain conflicting revision tags (e.g., the root folder indicates REV_B but the Gerber package indicates REV_A), the pack is rejected.
• If critical hardware layers (Paste, Silkscreen, Drill) are missing, the pack is rejected.

The Manifest: Proof of Origin

Every single GDP must contain a “00_MANIFEST/README.txt” or “manifest.json” file. 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:

1. Package Revision: Must exactly match the archive filename.
2. Generation Date: In ISO 8601 format (YYYY-MM-DD).
3. Author/Owner: The accountable Engineering point of contact.
4. EDA Tool Version: (e.g., Altium 23.1, KiCad 7.0). This is critical for debugging obscure polygon translation errors.
5. Master Checksum (SHA-256): (Highly Recommended) Cryptographically validates file integrity during cross-network transfer.

---

Recap: GDP Package Integrity and Structure

Parameter	Requirement	Value/Tolerance	Action on Non-Conformance
Package Integrity	Single, immutable, version-controlled archive.	Unique revision (e.g., REV_A01) with SHA-256 checksum.	Reject pack; require new formal GDP revision.
Directory Structure	Flat, standardized hierarchy.	Root: /PROJECT_NAME_REV_XX/ with mandatory subfolders 00_MANIFEST/ through 05_TEST_FIRMWARE/.	Reject pack for deep nesting (e.g., .../Final/For_Production).
Fabrication Data	Machine-readable, complete layer set.	Preferred: ODB++ (.tgz) or IPC-2581. Accepted: Gerber X2/RS-274X + NC Drill + IPC-D-356 netlist.	Reject pack for native CAD-only files or missing critical layers (Paste, Silkscreen, Drill).
Assembly Data	Structured, machine-parsable files.	BOM: CSV/Excel. Centroid: ASCII/CSV with RefDes, X, Y, Rotation, Side.	Reject pack for PDF/image-only BOMs or missing centroid file.
Manifest & Traceability	Mandatory proof of origin and configuration.	File in 00_MANIFEST/ (README.txt or manifest.json) with Package Rev, ISO 8601 Date, Owner, EDA Tool Version.	Reject pack if manifest is missing or contains conflicting revision tags.