A run at rate (R@R) is a supervised production trial that proves a supplier can build parts at the customer's contracted rate, using production tooling, gauges, operators, and cycle times, while holding quality. It answers one question a first-article build cannot: not just "can you make a good part?" but "can you make good parts fast enough, all day?"
Approving a part that measures perfectly in a lab tells you nothing about whether the line can hold that quality at 300 parts an hour on a Tuesday. The run at rate closes that gap. It is where capacity claims stop being a number on a quote and become a demonstrated fact.
What does a run at rate actually prove?
A run at rate proves that the production process, exactly as it will run in serial production, can hit the required output rate while producing conforming parts. It validates three things at once, and all three have to pass.
- Rate. The line achieves the customer's required parts-per-hour or daily quantity within a defined window, usually a full shift or a set run length.
- Quality at rate. Parts made during the run meet specification. Speed that produces scrap is not capacity.
- Process readiness. The tooling, fixtures, gauges, operators, standard work, and cycle time are the production versions, not a hand-built prototype cell.
The critical phrase is "as it will run in serial production." Skilled engineers babysitting a single cavity does not count. The run at rate deliberately uses the real, everyday process because that is what will build the customer's parts for years.
How is a run at rate different from a significant production run?
These two terms get used interchangeably and they are not the same thing. The distinction is what each one measures.
The AIAG Production Part Approval Process uses the term significant production run: a run, commonly a minimum of 300 consecutive parts, made from the final production tooling and process to produce the sample parts and data submitted for PPAP approval. Its job is to demonstrate the process can consistently make conforming parts. It does not, by itself, verify the required rate of production.
A run at rate layers the rate requirement on top. It confirms the line can sustain the contracted output over a defined time, often a full shift, and is frequently witnessed by a customer representative. Some OEMs treat their run at rate as effectively their version of the significant production run; others require a separate, later run at rate after PPAP approval to confirm the quoted capacity is real. The terminology varies by customer, so read the specific customer requirement rather than assuming.
| Significant production run | Run at rate (R@R) | |
|---|---|---|
| Primary question | Can the process make good parts consistently? | Can it make good parts fast enough, all shift? |
| Typical size | Often a minimum of 300 consecutive parts | A defined window: often a full shift or set quantity |
| Rate verified? | Not directly | Yes, that is the point |
| Who watches | Supplier, data submitted with PPAP | Often witnessed by the customer |
| Timing | Produces the PPAP sample parts and data | Around or after PPAP, per customer requirement |
When is a run at rate required?
A run at rate is triggered by anything that could change whether the production process can hold rate and quality. The usual triggers are the same events that require a new or updated PPAP submission:
- A new part launching into serial production.
- A new or transferred production line, plant, or piece of tooling.
- A significant process change: new equipment, a new method, a relocated operation.
- A capacity increase, where the customer wants proof the higher rate is real.
- Restarting a part after a long production pause.
The common thread is risk to demonstrated capacity. When the process that will build the parts is new or materially different, the customer wants it proven under real conditions before they depend on it, which is a concrete piece of risk-based thinking in action.
How do you run a run at rate?
A clean run at rate is planned like a small launch. Improvising it on the day is how suppliers fail a run they could have passed.
- Confirm the target with the customer. Nail down the required rate (parts per hour or per shift), the run duration, the acceptance criteria, and whether a customer representative will witness. Get it in writing; assumptions here cause disputes later.
- Freeze the production process. Use production tooling, production gauges, the trained production operators, and the documented standard work. If anything is a stand-in, the result is not valid.
- Warm the line to steady state. Start the run from a normal production start, not from a pre-warmed, hand-tuned condition. The customer is buying a Tuesday, not a demo.
- Run the full window and record everything. Log actual output, cycle time, every stoppage, changeovers, downtime, scrap, and rework as they happen. Downtime and scrap during the run count against the demonstrated rate.
- Measure quality on the parts made. Pull samples across the run and verify they conform. Where the customer requires it, compute capability indices so the run doubles as capability evidence.
- Calculate the demonstrated rate. Compute effective output over the window, accounting for real losses, and compare it to the requirement. This is the number that passes or fails the run.
- Document and submit. Package the results into the PPAP file or the customer's run-at-rate report, with the raw data behind the summary.
How does a run at rate fit into PPAP and APQP?
The run at rate is a late-stage checkpoint inside the launch framework. In Advanced Product Quality Planning (APQP) product and process validation is the phase where the process gets proven under production conditions; the significant production run and the run at rate live here. The results then become part of the PPAP submission package the customer reviews before granting production part approval.
For suppliers working to IATF 16949 this chain, APQP planning, run at rate demonstration, PPAP approval, is the backbone of a controlled launch. The run at rate is the moment the paper plan meets the physical line and either holds up or reveals where the process still cannot keep pace. Passing it is the difference between a launch that ramps smoothly and one that starves the customer's assembly line in week two.
Timing varies by customer, and it is worth pinning down early. Some OEMs fold the rate demonstration into the run that produces the PPAP samples, so one event covers both consistency and rate. Others require the run at rate as a distinct trial after PPAP approval, once the process is stable, specifically to verify the quoted capacity before ramping volume. A capacity increase later in the program can trigger a fresh run at rate on its own. When in doubt, treat the customer-specific requirement as the authority and confirm which model applies before you schedule the line.
What makes a run at rate fail?
Most failed runs share a small set of causes, and nearly all are avoidable with honest preparation.
- Prototype conditions. Running on soft tooling, a single tuned cavity, or engineers instead of operators. The result does not represent production, so it is not a valid pass even if the numbers look good.
- Ignoring real losses. Quoting a theoretical cycle time and then discovering that changeovers, minor stops, and scrap eat 20% of the shift. The demonstrated rate must survive real losses.
- Unproven measurement. If the gauge cannot be trusted, the quality data cannot either. Sort out gauge R&R before the run, not after.
- No agreed acceptance criteria. When the supplier and customer never fixed the target rate, window, and pass rule in writing, the run ends in an argument instead of a decision.
- A fragile process. A line that only makes rate with the A-team present and the stars aligned will fail the first bad shift. The run is supposed to expose exactly that fragility.
The uncomfortable value of a run at rate is that it surfaces problems before they become the customer's problem. A run that fails on your floor is a bad day; the same failure discovered after launch is a line-down charge and a supplier scorecard hit. Treat a failed run at rate as the cheapest bad news you will get all program.
| Fact | Detail | Primary source |
|---|---|---|
| Significant production run | Often a minimum of 300 consecutive parts on the final production tooling and process | AIAG, PPAP |
| Automotive core tools | PPAP is one of the five core tools: APQP, PPAP, FMEA, MSA, and SPC | AIAG, PPAP |
| Where the run at rate sits | Product and process validation, producing the data that feeds the PPAP submission | AIAG, PPAP |
Proving rate is a data problem
The hard part of a run at rate is rarely the trial itself; it is capturing honest, complete data during it. Counting good parts, logging every stoppage to the second, tagging scrap to a cause, and tying it all to the quality measurements is a lot to do by hand while the line runs. Runs get "passed" on optimistic manual tallies that quietly omit the minor stops, and the shortfall shows up as a capacity miss after launch.
That capture problem is what Harmony is built for: recording output, downtime, and quality checks as structured, timestamped data as the run happens, so the demonstrated rate is a fact you can defend rather than a number reconstructed from memory. See how a connected floor keeps that record in our customer story. Run the trial like a launch, capture the truth, and let the numbers, not optimism, decide whether the line is ready. For related supplier checkpoints, see source inspection and first article inspection.