HDI PCB RFQ: Turning "For 5G Modules" Into Buildable Requirements

The least useful line on most HDI RFQs is the one labelled "application." Requests saying "for 5G

modules," "for automotive camera," or "for wearables" go out every day. The sender believes the

requirement has been stated. The recipient knows that line will never reach the quoting system and

will never reach the shop floor.

This is not a communication lapse. It is a missing translation between two languages. An application

name belongs to product language: it tells colleagues, management, and investors where the board is

going. Quoting and manufacturing accept only attribute language: a quantity, a location, a method of

determination. If nobody performs that translation, it does not disappear. The supplier completes it

for you, using whichever reading costs least.

1. Why "for 5G" and "for automotive" never reach the floor

Follow one RFQ downstream and the mechanism is visible.

At quoting, an engineer translates files into process steps and risk factors. That requires

knowing which interconnect density band applies, how many lamination sequences the structure implies,

which hole types exist, and how far testing goes. "For 5G modules" constrains none of these. It only

hints at a distribution of possibilities. The estimator must therefore pick a point, and in a

competitive bid, whoever picks the cheapest point wins.

At work order release, the floor receives parameters and programs. No machine has an "application"

field, and no process step behaves differently because a board is destined for a base station. The

application information has fully evaporated by this stage. What remains is coordinates, compensation

values, layer sequence, program numbers.

At incoming acceptance, the problem is starkest. A dispute requires a criterion, and a criterion

must be measurable, reproducible, and capable of yielding the same conclusion for both parties.

"This board is not suitable for 5G" is not a criterion. It has no quantity, no location, no method.

It can neither be demonstrated nor refuted. Such disputes typically resolve by commercial relationship

rather than technical fact.

So the real position of an application name is this: it cannot be executed at any of the three stages,

yet it influences the outcome at all three, silently.

2. The five requirement families an application name packs

An application name is not empty of information. It is compressed too far, and its contents conflict.

Unpacked, it usually contains five families.

Interconnect density. How much routing must pass, how many transitions are needed, how narrow a

space the fan-out must happen in. This family sets the structural ceiling and sits on the steepest

part of the cost curve.

Structure and layer relationships. Which layers must connect directly, which can be built up

sequentially, how many levels of internal interconnect exist. The same density can be achieved through

different structures, and different structures do not involve comparable process counts or prices.

Thermal and current. How much heat must leave, which path carries the main current, whether

cooling relies on the board itself or on external hardware. This family is often entirely implicit:

the thermal expectation hidden inside "automotive" has nothing in common with the one inside

"wearable."

Reliability and environment. Operating temperature range, vibration, humidity, expected life,

severity of failure consequences. This family determines whether additional verification is required,

and verification is the easiest item to quietly remove from a quote.

Assembly and test interface. How the board will be populated and tested, whether test points and

fiducials are needed, whether delivery is single boards or arrays. This family is often treated as

"something for later," yet it constrains every earlier decision in reverse.

The crucial point is that these five are not a parallel checklist. They pull against each other.

Higher density usually implies a thinner structure, which works against thermal and reliability

margin. Added verification buys reliability confidence but consumes cost and lead time. A better

assembly interface may demand extra allowance, which competes directly with density.

**An application name compresses five families into one word and hides the trade-offs between them

along the way.** Those trade-offs are precisely what a quote consists of.

3. The form each family must take

The output of translation is not a longer description. It is a set of entries with identical

structure. Each entry carries four things.

A measurable quantity. What quantity expresses this requirement. It may be a dimension, a ratio,

a band, a class, or a yes/no, but it must be a quantity that does not produce divergent readings

between two parties. Descriptive adjectives such as "high density" or "high reliability" are not

quantities.

A location. Where the quantity must be written to have effect. A requirement stated in the body

of an email carries no binding force. The same requirement placed in the drawing, the specification

sheet, or the designated RFQ field enters quoting and work order release. Identical wording in

different locations has entirely different engineering and contractual weight.

A method of determination. How satisfaction will be confirmed at receipt. Some quantities are

confirmed by measurement, some by test, and some only by supplier declaration plus process records.

These three must be separated at RFQ stage, because anything confirmable only by declaration

becomes permanently untraceable if the declaration was not contractually requested up front.

An owner. Who decides this quantity. Three cases follow below, but the entry must name one.

Otherwise it defaults to the supplier.

An entry missing any of the four fails. With a quantity but no location, it never enters the system.

With a location but no determination method, it cannot be confirmed at receipt. With a determination

method but no owner, there is nobody to ask when it goes wrong. In practice the third and fourth are

the most commonly missing, because most RFQ effort goes into the first.

4. Ownership of the translation: three cases, kept separate

Requiring the buyer to define every attribute is a different failure mode. It turns the RFQ into a

closed-room checklist and excludes the cheaper implementation routes the supplier could have offered.

The workable split has three cases.

Only the buyer can decide. Functional boundaries and consequences: operating environment,

expected life, failure severity, the critical interconnects that must connect directly, the mechanical

interfaces that cannot move. These come from the product itself. A supplier has no way to know them

and no standing to decide them. **Leaving this case blank transfers product risk to the party holding

no product information.**

The supplier must supply options. Implementation routes. Several structure-and-process

combinations can satisfy one functional requirement set, each with a different cost, lead time, and

risk distribution. The buyer's job is not to specify the route but to require that feasible routes

be listed together with their costs. Locking the route in advance usually either raises the price or

keeps the better option out of view.

Both parties must countersign to freeze. Where the two information sets meet: which attributes

take priority in this project, which one yields when they conflict, which items are accepted by

declaration rather than by measurement. These are neither purely product decisions nor purely process

decisions. Written unilaterally they do not hold. They require one explicit mutual confirmation,

after which changes go through a change process.

The practical value of this split is that it turns blanks into owned questions. Every remaining blank

points at a specific party instead of dissolving vaguely into the supplier's quote.

5. Two costs of skipping the translation

Quotes become incomparable. This is the most quantifiable loss and the most frequently ignored.

Three suppliers answer the same "for 5G" RFQ with three prices, and the spread usually reflects

neither efficiency nor margin but three different readings: each assumed a different structure, a

different verification scope, a different delivery format. The buyer sees three numbers and not three

sets of assumptions. Choosing the lowest here means choosing the cheapest reading, which only

reveals itself as insufficient at production transfer or at receipt. Comparison presupposes a common

object, and a common object presupposes this translation.

Receipt becomes undecidable. In a dispute, the two parties cite things on different planes. The

buyer cites intent ("this is not the board I asked for"); the supplier cites the file ("the file does

not say that"), and on this point the file genuinely does not. The dispute cannot converge technically

and gets settled by commercial concession, where the conceding party is determined by who needs the

relationship more rather than by who is correct. Worse, such disputes usually surface after volume

has ramped, when the cost of changing supplier far exceeds the cost of having translated properly.

Both costs share one property: neither appears at RFQ stage. Both erupt later, at a point where

correction costs one to two orders of magnitude more than the original translation would have.

6. Application information still belongs in the RFQ, in a different place

Translation does not mean deleting the application. Application information has irreplaceable value;

its correct location simply is not the specification entries. It belongs in two places.

Background. It lets the supplier understand the use context and therefore propose routes the buyer

had not considered, or flag a requirement that does not match the context. An estimator who knows

where the board is going is more likely to spot a problem than one reading files alone.

Priority. When attributes conflict, the application context is the basis for deciding which one

yields. "Consumer product, cost ahead of extra verification" and "long-life industrial equipment,

verification ahead of cost" lead to entirely different trade-offs, and that judgement must come from

the buyer as one explicit sentence, not be inferred by the supplier from the application name.

The distinction: background and priority are explanatory information that helps the other party

judge better. Specification entries are binding information that enters quoting and acceptance.

Placing explanatory information in a binding slot is the essence of how application names get misused.

7. The minimum action list

No RFQ template rebuild is needed. Adding these lines to an existing request covers most of the

translation.

1. One entry set per requirement family, each entry carrying quantity, location, determination

method, and owner. For anything not yet decidable, write "TBD plus who decides plus when" rather

than leaving it blank.

1. One priority statement: when cost, density, reliability, and lead time conflict, state the

order in which this project yields.

1. One "accepted by declaration" list: name the attributes that cannot be measured at receipt and

depend on process records and declarations, and require suppliers to confirm at quoting whether

they can provide them.

1. One implementation-options requirement: ask suppliers to list feasible structure and process

routes with their respective costs rather than returning a single lump price.

1. One countersignature event: freeze the above once confirmed, with later changes routed through

a change process. Put this event on the schedule, because it will not happen on its own.

1. Relocate application information: move it from the specification area to the background area,

and add one sentence on what it implies for priority.

This list adds no engineering workload. It consolidates the guessing that currently happens separately

at quoting, work order release, and receipt into one action before the RFQ goes out.

Summary

An application name is real information, but it is compressed, internally conflicted, and not

executable. Used as a specification, its cost appears later as incomparable quotes and undecidable

receipts. The translation work itself is small: five families, four fields each, one countersignature.

The hard part is accepting that it must be finished before the RFQ goes out, not when a supplier

finally asks.

For the available range of HDI structures and process routes, see the

HDI PCB product page and the

manufacturing capabilities overview. To submit translated entries for review,

use the quote and production review entry. For the assembly and test interface portions,

see PCB assembly services. Who should decide the build class field

itself is treated separately in

HDI build class specification ownership.

FAQ

**Q1. A supplier asked me where the board will be used. Doesn't that prove the application name is

useful?**

It is useful, but elsewhere. That question is usually asked to judge which of your stated requirements

might be wrong, or whether a cheaper route exists. That is the legitimate use of background

information. It does not replace specification entries. After asking, the supplier still needs the

attributes written into the designated RFQ fields, or the quote still rests on his own inference.

Q2. I have no engineering resource to perform this translation. What then?

Complete the "only the buyer can decide" case. It requires no process knowledge because it comes from

your product: operating environment, expected life, failure consequences, immovable mechanical

interfaces, critical interconnects that must connect directly. For the rest, explicitly require the

supplier to provide options with costs. The worst approach is leaving the whole thing blank, which

does not save work but hands over the decision together with the risk.

Q3. A longer RFQ means a higher quote. Isn't that worse?

Part of the increase is real, but it is usually previously omitted work becoming visible rather than

new cost. The meaningful change is that three quotes become comparable: you can see which one is

expensive because of verification and which is cheap because a structural step is missing. If the

former lowest bid rises after translation, it was never quoting the board you wanted.

Q4. Which attributes typically fall into "accepted by declaration only"?

Any process-level attribute that cannot be measured or reproduced from the finished article: material

lot, process parameters, intermediate-stage records, whether a specific step was performed. These must

be requested as declarations with record retention at RFQ stage. Asking after receipt does not work,

because the records may no longer exist. The key is listing them explicitly rather than assuming the

supplier retains them by default.

Q5. The same board serves two applications, consumer and industrial. How should that be written?

As two attribute sets, not as one union-of-applications description. The two have different priorities,

and a union produces a board that is more expensive for both while still leaving the conflicting items

unresolved. If commercially one part number must be shared, write to the stricter set and state that

this is a deliberate cost choice rather than letting the supplier pick between two readings.

Q6. After translation, is a countersignature really necessary? Isn't email confirmation enough?

The value of countersigning is not formality but the creation of an explicit freeze point. Email

confirmation typically confirms fragments, and each subsequent fragment shifts the baseline slightly

until nobody can say which version was agreed. Countersigning produces a versioned document that

later changes must reference, which is the precondition for a change process to function at all.