Before requesting a custom liquid cooling module, separate the outcomes the equipment must achieve from the design choices a supplier can propose. A mounting interface may already be fixed by a released chassis drawing; a hose route may still be open. An unconfirmed coolant inlet temperature is neither of those things: it is an unresolved input that can change the feasibility of the whole proposal.
The useful question is not simply whether a requirement is strict. Ask what must remain true, who can authorize a change, and how compliance will be checked. This turns a collection of drawings, preferences and estimates into a brief that engineering and purchasing can use together.
Classify each input before discussing a solution
A fixed requirement has an identified reason and an approved boundary. It might protect a device temperature limit, preserve interchangeability, or satisfy a customer interface. A negotiable input gives the design team a defined range in which to work. It still needs an owner and acceptance conditions; “flexible” does not mean that any substitute is acceptable.
Keep the status of the requirement separate from the confidence in its supporting data. A temperature limit can be mandatory while the workload used to assess it is still an estimate. Mark both facts. Otherwise a spreadsheet labeled “fixed” can make an unverified operating assumption look confirmed.
Classify inputs before selecting a design
Swipe the table horizontally to compare all columns.
| Input class | What it means | What the supplier needs |
|---|---|---|
| Fixed requirement | An approved result, limit or interface must be maintained | Source document, revision, acceptance rule and change authority |
| Negotiable design input | Alternatives may be proposed within a stated boundary | Allowed range, evaluation criteria and approval owner |
| Working assumption | A provisional value enables a limited study | Rationale, sensitivity, confirmation owner and due date |
| Unknown input | The project has not established a usable value or condition | A named information request and the decision it blocks |
NASA’s general requirements guidance recommends describing the needed outcome, separating it from the implementation, and recording assumptions with a resolution process. Those are useful drafting principles for an OEM brief; they do not make a cooling project NASA qualified. See Appendix C of the Systems Engineering Handbook.
Fix the system boundary and acceptance conditions first
Start by drawing the supplied assembly boundary. Is the request for a machined part, an assembled cooling module, or a broader integration project? Identify the mating equipment, external cooling source, power and control connections, and service access. A supplier cannot resolve a missing system decision merely by choosing a different pump or cold plate.
Replace “keep the processor cool” with a requirement containing these linked fields:
- Object and limit. Device identity, measurement location and the approved temperature limit or source document.
- Operating case. Sustained/peak and concurrent loads, duration, control settings and hardware revision.
- Supplied conditions. Ambient or coolant conditions at the assembly boundary and the party that confirms them.
- Verification. Tested build, mounting, measurement method and the rule for accepting the result.
A mandatory limit can coexist with an estimated workload. Keep the limit mandatory while marking the resulting performance conclusion conditional; “fixed” is not evidence that the input is verified.
For an external coolant loop, the system owner should confirm fluid composition, available inlet temperature range, branch flow and pressure conditions. For a module rejecting heat through a radiator, define the radiator’s air inlet conditions and available airflow path. Room temperature alone does not describe recirculating hot air inside a chassis. The boundary determines which conditions must be supplied by someone else.
Acceptance also has a scope. A module checked on a bench has not automatically passed the customer’s installed-system test. Specify which assembly revision is tested, how it is mounted, which controls are active, what is measured, and the rule for accepting the result. Our testing and reliability overview describes the kinds of checks that can be discussed within an agreed module scope.
Leave design freedom where it can actually help
Write down the reason before declaring a component or dimension mandatory. A particular connector may be essential because it mates with installed equipment and a controlled service procedure. The same connector named in an early concept drawing may only be a preference. The first case needs interface control; the second may allow a documented alternative.
Evaluate alternatives against the original purpose. If hose routing is open, define the endpoints, keep-out zones, installation access and service movement. An alternative route must still be checked against the hose supplier’s bend limits, abrasion risk, connector access and the intended fluid conditions. Moving a port can simplify a route while changing the mating part or assembly sequence. That is a cross-interface change, not a free optimization.
The same distinction applies to material and manufacturing choices. A material grade tied to fluid compatibility or a released drawing cannot be substituted solely to reduce cost. Where material or channel construction is genuinely open, request a proposal explaining thermal, hydraulic, dimensional, joining and inspection implications. Do not assume that the smallest channel or the largest pump is automatically the best design.
A decision sequence for each proposed change
What outcome or mating interface must remain true?
↓ Locate its source, revision and approval owner.
Can this proposal stay within the approved boundary?
↓ If yes, compare it against the same acceptance conditions.
Does it cross a fixed interface or depend on missing data?
↓ Request approval or confirmation before making the affected commitment.
Use this sequence before suppliers invest in detailed work. It keeps useful design freedom available while exposing changes that require another team’s approval. The broader OEM module development guide covers how these decisions move through prototype, validation and production stages.
Work through an incomplete brief without hiding uncertainty
Consider a hypothetical OEM brief for a cooling module in an already released enclosure. The chassis mounting holes and external connector position are controlled. The internal hose route is a supplier proposal. A preliminary thermal study assumes a coolant inlet temperature, but the external-loop owner has not confirmed the available range. These are editorial example conditions, not a ThermalBro customer project.
The team can review packaging against the released interface and compare routing concepts. It cannot turn the assumed inlet condition into an unconditional temperature guarantee. Record the thermal conclusion as conditional, name the external-loop owner responsible for confirming the inlet range, and identify which sizing or test decisions depend on it. If even a provisional range is unavailable, limit the discussion to the work that does not depend on that value.
Suppose the supplier proposes moving the connector to shorten a hose. The mechanical owner checks the mating equipment and service access. If the interface cannot move, the supplier revises the internal route. If a change is permitted, the owner releases a new interface revision and the team checks downstream drawings and tests. A comment in an email is not an adequate substitute for updating the controlled baseline.
This example also separates permission to study from permission to release. A concept may proceed under explicit assumptions while a prototype order remains on hold for a critical fluid condition. Record what work is authorized, which commitment remains conditional, and who decides when the missing information is sufficient. That prevents a feasibility discussion from being mistaken for approval to build the final design.
Give every requirement an owner and a verification route
A compact requirement record needs more than a fixed/flexible column. Assign an ID and include the requirement, its source and revision, status, operating conditions, confirmation owner, approval authority and proposed verification method. Link supporting drawings instead of repeating dimensions in multiple documents that may diverge.
The following example rows show how the record changes with the input. They describe the fields to complete; the actual limits and acceptance values come from the project.
Example requirement records: assign an owner and release consequence
Swipe the table horizontally to compare all columns.
| Requirement or open item | Ownership and evidence | Release consequence |
|---|---|---|
| Mounting pattern follows the released interface | OEM mechanical owner supplies drawing revision and inspection criteria | A proposed change requires interface approval and updated mating checks |
| Device temperature stays within its approved limit | Thermal owner defines measurement node, load cases and test conditions | Thermal acceptance remains conditional until boundary conditions are confirmed |
| Hose route may be proposed within the enclosure | Supplier proposes route; OEM reviews keep-outs and service access | Confirm fit and assembly access before freezing the route |
| Coolant composition remains unconfirmed | System owner provides fluid specification and allowed operating range | Compatibility and relevant performance commitments cannot be closed |
| Required prototype delivery date | Project manager supplies milestone; supplier assesses scope and dependencies | Distinguish the requested date from a confirmed delivery commitment |
Choose verification to match the requirement. A dimensional inspection can address a mounting feature; it does not establish thermal performance. A drawing review may confirm an intended fluid connection but cannot show the assembled path is leak-tight. For a leak or pressure-related requirement, define the assembly, medium, temperature, pressure, duration and acceptance criterion in the agreed test plan. One undefined “pressure test” checkbox cannot stand in for all those conditions.
Compare quotations against the same baseline
Two quotations are comparable only when they respond to the same revision and state their deviations. Ask each supplier to identify accepted requirements, proposed alternatives, assumptions, exclusions and unresolved questions. Keep a proposal’s improved feature separate from a deviation that weakens a mandatory requirement.
Separate nonrecurring engineering or tooling work, prototype quantity, production quantity and any testing or documentation in scope. A lower piece price may exclude joining, cleaning, fixtures or validation that another proposal includes. A faster prototype schedule may depend on an unapproved material or an earlier drawing freeze. Resolve those differences before using price or delivery as the deciding factor.
Accept or reject the deviation
Compare it with the original requirement and its purpose. Record the technical owner’s decision and any revised cost or schedule basis.
Hold pending evidence
State the unresolved question, evidence owner and decision date. A preferred price does not close a compatibility or interface uncertainty.
Keep accepted alternatives, exclusions and outstanding assumptions in the same comparison record. Otherwise a later purchase order can silently lose the conditions under which the quotation was prepared.
Freeze by project stage and control the changes that follow
At feasibility review, enough information is needed to identify plausible options and critical unknowns. Before prototype manufacture, agree the build revision, interfaces and the questions the prototype must answer. Before production release, resolve the requirements that govern the approved product and its inspection, assembly and acceptance records. The maturity of the decision should match the commitment being made.
After a freeze, use a change review tied to the affected evidence:
- Trace the change. Identify the drawing/BOM revision and affected mating parts, operating assumptions, materials and assembly instructions.
- Choose the necessary rechecks. A moved port needs mating and fit review; a new wetted material needs compatibility evidence; a changed load case can invalidate a thermal comparison. Explain why each previous result still applies or needs replacement.
- Approve a new baseline. Record technical approval, cost/schedule consequences and the instructions or acceptance records that must change before the affected build proceeds.
Do not repeat every test automatically, or carry every old result forward automatically. The changed mechanism and interface determine the required evidence.
For a ThermalBro review, send the current drawing revision, heat-source and operating inputs, required supply boundary, quantity stage, acceptance questions and target delivery date. Mark fixed interfaces, proposed alternatives and open assumptions directly in the package. Our project input checklist helps organize the technical inputs; identify which entries apply to your equipment.
Questions that often remain before an RFQ
Can we request a quotation before every input is final?
Yes, a limited feasibility or budgetary discussion can begin with clearly identified assumptions. Ask the supplier to state what the estimate covers and which changes could alter feasibility, price or timing. Do not treat that response as final acceptance of missing operating conditions.
Does calling a requirement fixed prevent all future changes?
No. It means the supplier cannot silently choose a different value or interface. The authorized owner can review a change, update the baseline and define its consequences. The record must show which revision is now approved.
Who decides whether a requirement can become flexible?
The owner of the underlying equipment requirement or interface makes that decision, with affected teams involved. The supplier can explain the tradeoff and propose an alternative. Purchasing should confirm commercial consequences, while the relevant technical owner approves the changed technical basis.
