From fabrication data to a rigid-flex process plan

A useful rigid-flex manufacturing handoff connects each released file to a defined part revision and explains which information governs the construction. The goal is to remove contradictions before the fabricator prepares a process plan. Sending a larger archive is not a substitute for resolving conflicting drawings.

Ucamco, the developer of the Gerber format, explains that the Gerber Job file carries fabrication information in a machine-readable form alongside Gerber fabrication data. That capability can improve a data handoff, but the receiving supplier still needs to confirm that its workflow interprets the supplied information as intended.

Begin with a release manifest

Create a manifest listing the part number, revision, export date, file names, and the purpose of each file. Include a designated drawing that identifies the region map and stackup references. Ask a reviewer who did not export the files to find the board outline, layer order, drill data, and construction notes using only the package.

Distinguish design requirements from process choices

The design team should specify the required outcome and acceptance conditions. The manufacturing team determines a suitable process within its qualified capabilities. Do not turn an illustrative process sequence from an article into mandatory routing, lamination, or drilling instructions for an actual order without supplier review.

For example, a drawing may require a particular region boundary, approved construction, and defined finished dimensions. The fabricator may need to clarify how those requirements interact with its production method. Record the clarification as a question with a proposed resolution, not as an undocumented alteration to the design files.

Close an engineering query with a traceable decision

Use four fields: the conflicting requirement, the proposed interpretation, the person authorized to decide, and the affected output files. Consider a fictional release in which a coverlay detail is revision B but the main drawing still references revision A. A response of “use the latest” is weak because the package can change again. A stronger resolution names revision B, identifies the replacement drawing, and records the approval date.

After a change, repeat the specific comparison that exposed the conflict. Then reopen the archive from its final saved location and check the manifest against the actual files. This last step catches a corrected local drawing that was never included in the delivered package.

Describe the part before describing the archive

Start the handoff with the identity of the deliverable. State whether the package defines an individual bare board, a customer-defined production panel, or a reference assembly. Include the part number and revision in the governing drawing rather than relying on the archive filename alone. If the drawing and the purchasing description use different identifiers, provide a controlled cross-reference before the supplier begins interpretation.

For a rigid-flex part, the description should identify the rigid regions, flexible spans, and any local reinforcement that affects fabrication. Keep the installed-state model available as context, but explain which flat geometry defines the manufactured outline. An assembly rendering can show intent without supplying the dimensions and tolerances needed to fabricate the flat board.

Separate required production data from optional explanatory files. A screenshot of an older concept can be helpful during discussion but dangerous inside a release archive if it resembles an approved drawing. Label reference material clearly and remove obsolete alternatives from the active package through a controlled revision process. Preserve historical versions in the project archive instead of presenting several competing constructions to the supplier.

Check the package in an independent viewing workflow

Open the manufacturing outputs in an appropriate viewer after export. Inspect the outline, copper layers, holes, protective-layer information, and drawing alignment using the same units and origin. The purpose is to examine the delivered representation, not merely to confirm that the source CAD project looked correct before export. Keep the viewer version and any interpretation settings in the internal review record when they affect the result.

Choose several reference features that appear in more than one output, such as a mounting hole, an island corner, and a flex junction. Confirm that they align across the relevant views. If a coordinate offset appears, determine whether the export origin, units, or a file-specific setting caused it. Do not apply an informal offset in a viewer and assume the supplier will discover the same correction.

For layer order, compare the exported layer identifiers with the approved stack table. For drill information, confirm that the supplied data distinguishes the required hole types and spans using the agreed handoff convention. A hole represented in a picture is not necessarily a complete drilling requirement. Resolve unclear plating intent, finished-size definitions, and regional applicability before the package is treated as manufacturing-ready.

Assign a governing source for each requirement

A governing-source matrix is particularly useful when two files repeat the same information. Repetition is not inherently a problem, but a conflict needs a defined resolution path. Avoid a blanket statement that one file always wins if it could silently override a critical electrical or mechanical requirement. Instead, identify the disagreement, obtain the authorized decision, and issue a consistent corrected package.

Turn a supplier question into a bounded change

Suppose a fictional package defines a reinforced tail in a mechanical detail but omits the reinforcement from the regional construction table. The supplier asks whether reinforcement is required. A useful response identifies the intended tail region, the governing detail revision, the side of application, and the finished interface requirement. It also states which drawing will be revised to remove the inconsistency.

Before approval, check the consequences of the clarification. Does it change a connector fit, a local thickness, an assembly clearance, or a previously reviewed forming zone? Assign those questions to the relevant design owners. The goal is to close one specific ambiguity without accidentally approving unrelated changes that happened to appear in the same marked-up document.

When the supplier returns an annotated proposal, distinguish accepted changes from comments still under review. Use explicit dispositions instead of relying on color alone. A person receiving a printed or grayscale copy should be able to tell whether a note is a question, a proposed solution, or an approved requirement. Include the date and revision so that a later email does not detach the decision from its technical context.

Build a change-impact checklist for repeat orders

A repeat order can still require a fresh review when the design revision, material proposal, delivery arrangement, or acceptance requirements have changed. Compare the new request with the previously accepted package. Record unchanged items as well as differences, because this makes the scope of the new review explicit and prevents reviewers from assuming the whole design has already been reconsidered.

For example, a component-layout change may leave the outline unchanged but alter copper near a flex transition. A mechanical change may move a mounting feature without changing the schematic. A revised impedance requirement may require a different regional geometry even though the board name is identical. The relevant question is which manufacturing and verification assumptions depend on the changed feature.

Keep the supplier’s accepted proposal linked to the exact design release. If a later purchase uses a different revision, obtain confirmation of the applicable construction rather than copying an old approval record. Historical evidence is valuable for comparison, but it does not automatically approve a new combination of files and requirements.

Prepare a concise release summary

The final summary should allow a reviewer to identify the part, revision, approved construction, delivery form, and unresolved exceptions without reading a long conversation. Link it to the manifest and issue log. If no exceptions remain, state that conclusion with the responsible approval record; if an exception remains, name it precisely and explain its disposition.

Include the verification expectations agreed for the order, such as the reports or inspection records required at delivery. Avoid adding tests that the supplier has not agreed to perform, and do not imply that a general manufacturing overview establishes a qualification program. A clear handoff defines the required evidence before fabrication rather than discovering at shipment that the parties expected different documentation.

Apply three release gates

1. Completeness: Every item required by the agreed supplier handoff checklist is present and readable.
2. Consistency: No unresolved disagreement remains between the released files on construction, geometry, connectivity, or revision.
3. Approval: Changes requiring design acceptance have a recorded decision and are incorporated in the final package.

Archive the accepted package and the issue log together. For repeat orders, compare the requested revision with that archive before assuming a previous process plan remains applicable. A familiar product name does not establish that the construction is unchanged.

Read our manufacturing overview and design documentation guidance. Submit your fabrication package for review with a short list of open questions so the inquiry starts with the decisions that matter.