Flex PCB Gerber Layer Naming: Make the Stack Unambiguous

UPDATED October 23, 2026

Discuss your flex PCB project →

A flex PCB fabrication package can contain every required image and still be ambiguous. The receiver must know which file describes each copper layer, which geometry represents a coverlay opening, where reinforcement applies, and how the files relate to the same physical part. Names such as mechanical1 and bottom_extra leave those decisions unresolved.

A layer manifest connects each delivered file to its physical purpose. This article develops an original manifest for a hypothetical two-copper-layer flex circuit and a review sequence for finding missing or mirrored features. It complements the flex PCB manufacturing guide by concentrating on the handoff from released design data to fabrication review.

Separate file identity from physical function

A filename identifies an item in the delivery package. Its function identifies what that item means in the finished circuit. A useful manifest records both. Do not assume that a familiar extension or an internal CAD layer number communicates the complete physical function to another organization.

For each image, identify the side or copper position, the relevant region and the meaning of the represented geometry. Also identify the associated drawing or note when the file needs additional interpretation. A coverlay opening and a coverlay outer boundary may occupy the same CAD mechanical-layer family while describing different physical boundaries.

Ucamco’s fabrication-data guide recommends using Gerber X2 to communicate layer structure and clear filenames when that information is unavailable. It also emphasizes common coordinates and a top-view convention rather than mirroring individual layers. These are data-transfer principles; they do not define every flex-specific construction note. See PCB Fabrication Data, version 6, sections 5 and 8.

Use a supported exporter to produce the required format information, then check it against the manifest. Renaming a file does not change its geometry or correct conflicting attributes. Resolve disagreement at the source and regenerate the controlled package where possible.

Define the package before writing the names

Start with the released stackup and list the physical features that fabrication must understand. For a simple flex circuit, the list might include two copper layers, two coverlay opening definitions, the circuit profile, holes and a local reinforcement region. The exact set depends on the design; this is not a requirement to invent unused layers.

Distinguish production geometry from explanatory views. A dimensioned drawing can explain a stiffener section without serving as its machine-readable outline. Conversely, a clean outline file can define a boundary without specifying material or finished thickness. The manifest should show how the two pieces of information connect.

Identify whether the package describes a single circuit or a delivery array. If both are present, label their roles and precedence explicitly. A profile for one circuit should not compete with an array outline under two nearly identical names. Keep fabrication proposals separate from the approved release until the responsible parties accept them.

Use an explicit manifest for flex-specific features

The table below is an original human-readable example, not a Gerber syntax specification or a mandatory naming standard. The fictional part is called SENSOR_A and the revision is C. The suffixes describe intent for reviewers; the actual exporter and fabricator must support the selected file formats and semantics.

Add the actual drill files and any other required records to the real manifest. Record an intentional absence where it matters: for example, a construction without a bottom coverlay should not be mistaken for a missing export. Do not include empty placeholders merely to make the file count match an old project.

For each non-copper image, state whether the geometry represents material present, material removed, a region boundary or a reference annotation. The filename helps a human start the review, but the agreed interpretation must survive import into the receiving CAM workflow.

Check orientation with an asymmetric reference

Choose an existing feature that distinguishes left from right and top from bottom in the released design. A connector’s uniquely located pad or an asymmetric outline can provide such a reference. Show its relationship to the relevant drawing view. Do not add unnecessary copper text or geometry solely to create an orientation marker.

As a hypothetical coordinate check, suppose the approved top-view drawing places a reference feature at x = 2 mm relative to a datum, while its asymmetric counterpart is at x = 8 mm. A reflection about x = 5 mm swaps those locations. If one imported layer appears to have made that swap while the others have not, investigate the export and viewing transformations before accepting the overlay.

This example detects a particular inconsistency; it does not establish that every apparently mirrored image is wrong. A viewer can intentionally display a bottom view without modifying the underlying data. Record the view mode when comparing screenshots, and distinguish a display transformation from a transformation embedded in an exported file.

Use the actual circuit landmarks to resolve orientation. A symmetric rectangle alone cannot reveal a reflection. Likewise, a package that happens to overlay at its outside boundary can still contain an incorrectly oriented contact pattern. Review the functional features, not only the silhouette.

Reconcile the manifest with machine-readable information

When the exporter supplies layer-function attributes, check that they agree with the named role and stack position. A file named top copper with conflicting metadata should be treated as a release discrepancy, not an invitation for the receiver to choose whichever description seems plausible.

Ucamco describes the Gerber Job File as a mechanism for transferring fabrication documentation in machine-readable form alongside Gerber fabrication data. See its fabrication documentation announcement. Where supported, include the appropriate job information and validate it with the receiving workflow. A human manifest remains useful for reviewing the delivery and explaining flex-specific relationships.

Do not manually invent attribute values for a feature just because its ordinary name sounds similar to a standard field. Use the applicable specification and supported exporter. If a flex-specific function requires a separate agreed note or drawing, make that dependency explicit and keep the data consistent with it.

Review the exported package as a new artifact

Inspect the delivered files in a viewer capable of interpreting the chosen format. Reviewing the CAD design alone does not demonstrate that the export contains the intended layers. Open the actual release directory and compare its contents with the manifest before checking geometry.

Perform two complementary passes. In the first, inspect each file independently and confirm its role, extent and visible content. In the second, overlay related files to check alignment and physical relationships. An individual coverlay opening image may look reasonable until it is placed over the intended copper contacts.

For the flex-specific pass, compare coverlay windows with required exposed features, reinforcement regions with their drawing boundaries, and cutouts with nearby conductors. Use the flex PCB design rules guide to identify the design questions, while keeping this export review focused on whether the package accurately represents the released design.

Record viewer warnings and resolve their significance. A screenshot proves only what was visible in that view; it does not prove the completeness of the package or the absence of import errors. Keep the checked file set and the review result together so that another reviewer can reproduce the check.

Control revisions at the package level

Build a release in a clean directory containing only the intended delivery. Avoid placing old exports beside new ones and expecting the receiver to identify the latest file from timestamps. A mixed package can combine current copper with an obsolete coverlay window even when each file is individually valid.

If only one feature changes, regenerate and review the package according to the project’s release process. State which revision supersedes the previous delivery. Retain the earlier package in the project’s controlled archive, but do not include competing alternatives in the active fabrication ZIP without explicit instructions.

A checksum list can help confirm that the reviewed files are the files delivered. It cannot prove that their engineering meaning is correct. Use it for identity and transfer verification, alongside the functional manifest and review, rather than as a substitute for either.

Resolve questions before approving fabrication

A useful clarification names the file, feature and conflicting interpretation. For example, ask whether a reinforcement image defines the full material region or only an adhesive region, and identify the drawing section that should govern. This produces a concrete answer that can be incorporated into the release.

After an agreed change, update the affected data and manifest together. Recheck the relevant overlays and record approval. Do not leave a critical interpretation only in an informal message while the delivered package continues to imply something different.

Send the reviewed manifest, released stackup, geometry files and relevant drawing with your flex PCB fabrication review request. The practical outcome is a package in which every file has a defined role, every physical feature has an identified source, and the receiver can reconstruct the intended circuit without guessing.

Explore the flex PCB guide and tools →