At a receiving table outside a Midwest 3PL, an OEM buyer lays out three documents: a supplier spec sheet for a custom rooftop tent, the owner's manual for the pickup it will sit on, and a parts list for bars, feet, and fit kit. The spec sheet leads with sleeper count and shell fabric. The manual states a roof limit nobody quoted on the tent order. The parts list prices four pieces with no capacity figure against any of them. The order in which this buyer settles those three documents is the acceptance checklist, and most files I see settle them backwards.
Fix the sequence first: vehicle roof dynamic weight capacity, then the lowest-rated component in the rack system, then the rail interface and whether it is supported. Tent sleep capacity sits outside that chain. What follows is drawn from a published Thule vehicle and rack compatibility reference, a manufacturer application guide for its own tent and rack combinations; it is not a custom OEM certification and does not substitute for a model-specific file from your supplier.
Start With the Vehicle Roof Limit
The first line on the checklist is a number the tent supplier cannot give you: the roof limit of the specific vehicle. The instruction manual, or the local dealer when the manual is thin, states the roof weight limitations, and those limitations are the dynamic weight capacity — the maximum weight permitted on the vehicle's roof while driving. Record it at the top of the acceptance sheet with the vehicle year, cab and bed configuration, and whether the roof is rated for a load at all.
Opening with tent data instead — sleeper count, shell, ladder, mattress — is the mistake, because that is what the supplier leads with and what a buyer can actually see on the sample. The consequence is quiet: the file looks complete, every tent line is signed off, and the one figure that decides whether the package can leave the lot never got recorded.
The manual figure belongs to the vehicle, not the tent maker, and it is stated for driving, not for parked occupancy with the engine off and stabilizer legs down. When a supplier quote blends those two conditions into a single number, challenge the blend before anyone argues about anything else on the sheet.
The Weakest Rack Component Sets the Limit
Rack systems are not rated as one object. Bars, feet, and fit kits may each carry a different weight capacity, and the component with the lowest capacity determines the rack system's maximum. On a live order three or four figures reach the table and the buyer has to choose one: choose the minimum. A bar rated well above the foot that clamps it does not raise the system; the foot is the ceiling.
Averaging the ratings feels diligent and is wrong. So is taking the highest figure because it sits in the header of the parts list. Both produce an over-accepted system, and over-acceptance is invisible at the dock: the box arrives, the parts fit, nothing fails. The failure lives later, at speed, where the lowest-rated part does the work regardless of what the header promised.
Build one row per candidate — bars, feet, fit kit, and the tent's own mounting rails — and take the minimum as the system limit. Compare that minimum with the roof figure already at the top of the sheet. Whichever is lower is the number the acceptance file carries; the other is recorded as context, not as permission.
Unsupported Rails Are a Rejection Flag
Unsupported rails are usually too flexible to handle the static load of a tent with people inside. The statement is about parked load and it still disqualifies them, because a rail that cannot carry the parked load is not a mounting point you can sign off.
Treating every rail on the vehicle as an anchor is the error. A buyer counts four rails, the supplier ships four brackets, the paperwork matches, and nobody asked whether the rail is a load-bearing structure or a trim channel with a bolt hole in it.
Exclude unsupported rail claims from the list until the supplier produces a documented supported interface for that exact tent-and-vehicle combination — a drawing or a written statement tying the rail to structural support. That rejects a specific claim, not rails as a category; what you want to see held up at the table is a supported interface with combination-specific paperwork.
Do Not Convert Tent Capacity Into Driving Load
Static capacity and driving rating answer different questions. Static capacity asks what the shell, frame, and platform hold at camp, stationary, occupants inside. Driving rating asks what the roof and rack may carry in motion, with braking and crosswinds in play. A tent that holds several sleepers at camp answers the first and says nothing about the second.
The obvious objection is that a tent built for several adults must be stronger than the roof beneath it, so the roof number is the conservative one and the tent cannot be the limiting part. Strength at rest and a permitted driving load are not the same quantity: one is a structural observation made at camp, the other a limit the vehicle manufacturer publishes for motion. A tent that out-holds the roof does not license the roof to carry more.
Suppose a buyer, facing a gap in the custom supplier's documentation, invents a multiplier — static rating times three, say — to manufacture a driving figure. That multiplier is not a Thule rule, not a vehicle-manufacturer rule, and it cannot enter the acceptance arithmetic, because it replaces a missing number with a fabricated one. When the driving figure is absent, leave the field blank and escalate it as an open item.
What If the Tent Is Custom?
Custom changes what you can lean on. The Thule guide covers tents and racks sold for defined vehicle combinations; a custom tent from an OEM supplier falls outside that set unless the supplier's own combination is documented. A skeptic would say that makes the reference irrelevant to a custom program — if the guide does not cover my tent, why is it in the acceptance file at all. It stays because it tells you what a custom file has to prove, and that is a different job from certifying it.
Stated as a preference: I would rather demote the published guide to a question list than let it stand in for a custom certification. A guide that names the roof limit, the component minimum, and the rail support requirement hands a buyer the exact list to demand in writing from a custom supplier. Demoting it costs nothing at receiving and keeps the file honest about what it does and does not contain.
A skeptic would push again: questions are not evidence, and a file built on questions does not clear a shipment. Agreed, which is why each question carries an owner and a date, and why the file stays open until the supplier answers in writing. Treating the guide as proof instead closes that file early, and early closure is the expensive failure.
RFQ Questions to Close the Evidence Gap
The RFQ does the work the acceptance file cannot. Ask for the declared dynamic capacity of the exact roof-and-rack combination with its source named — vehicle manual, engineering statement, or a report the supplier will release — and for component-level ratings for bars, feet, and fit kit instead of a single system number. Ask for the supported rail interface drawing, the model-specific installation manual, and the warranty conditions attached to roof-mounted use.
Accepting one load rating on a quote is the mistake at this stage. A single number is easy to compare and impossible to audit: it hides which component is lowest and whether the rail interface is supported, so the two items most likely to fail are the two the quote never mentions. A component table with a named source per figure can be checked against the vehicle manual and shows its own weakest link.
None of this is a promise about what a given factory will answer. The purpose is to get answers in writing before the PO, so the checklist has figures to receive against rather than blank fields and a verbal assurance.
The one thing to confirm before the order goes out is a component-level dynamic rating table from the supplier, with the lowest-rated part called out and tied explicitly to the roof limit of the vehicle you are actually fitting. One table, two comparisons, and the checklist has a floor to stand on. Without it, the acceptance file is a stack of confident documents with the system limit and its weakest link both still open, and no receiving inspection repairs a number nobody wrote down.