How to Build a Torque Test Report Format That Traces a Failure

A torque test report earns its keep on the one day a batch fails, not on the string of days it passes. A torque test report format is the standardized record structure used to log cap or closure torque readings, test conditions, and pass/fail judgment for a batch: the paperwork, digital or otherwise, that sits behind every torque number a lab reports. This piece covers the baseline fields any format already owes you, the fields multi-cavity production can't afford to skip, and a ready-to-use field template you can drop straight into your own report.

What Is a Torque Test Report Format Actually For?

Three sources turn up again and again on this topic, and none of them treat the report as the main event. Checkline's technical document walks through a full eight-part test method — scope, summary, significance, definition, apparatus, specimens, procedure — and reporting shows up last, as section 8, a checklist appended to the real work. Mesa Labs stays at the compliance-framework level without describing report structure; Qualitester covers test procedure and equipment selection without treating the report as a subject of its own.

None of that makes those sources wrong. It just means the report keeps landing in the same spot: paperwork that happens after the test, rather than the reason the test was worth running in the first place.

So who actually reads a torque test report, and when? Almost never the operator who ran the test that day. Almost always someone downstream — a quality manager, an auditor, a customer's technical contact — asking a question nobody expected at the time.

The Baseline: Fields a Recognized Test Method Already Requires

Before adding anything specific to multi-cavity production, a torque test report needs to clear a lower bar: the fields a recognized test method already expects. Checkline's technical documentation spells this out directly in its own reporting section.

The method calls for a specific set of information: which bottles and closures were tested, down to size, style, and material; every individual reading rather than just an average; the number of specimens tested; the conditioning environment the specimens sat in before testing; the test date; the average, range, and standard deviation of the readings; and the time intervals between measurements.

That same method spells out what "conditioning" means, rather than leaving it as a checkbox: a minimum of 24 hours at 23°C ± 2°C (73.4°F ± 3°F) before testing, with a five-second hold on application readings. A field that just says "conditioned: yes" doesn't capture enough to reproduce the test later.

Separately, two ASTM standards show up repeatedly in industry discussion of this same subject, and they are not interchangeable. [ASTM D2063](https://store.astm.org/d2063-91r02.html) covers torque retention testing for continuous-thread closures generally, using manual (non-automated) test equipment. [ASTM D7860](https://store.astm.org/d7860-14.html) covers that same torque-retention testing specifically for child-resistant and non-child-resistant closures, using automated test equipment. A report format has to make clear which standard applied, because a pass under one says nothing about the other.

Pull your current report template next to this list. Anything missing here is a gap against a documented method, not a style choice.

The Fields Multi-Cavity Production Can't Afford to Skip

The baseline list gets a report to "documented." It doesn't get a report to "traceable" once a mould has more than one cavity producing caps at the same time.

A report that doesn't record mould cavity number and operator or equipment ID is incomplete for multi-cavity production. That's a stronger claim than "nice to have." Here's the mechanism: when results from dozens of cavities get folded into one batch average, a single underperforming cavity can sit inside that average without pulling it out of spec. The batch reads as an overall pass while one cavity quietly runs low the entire time.

If your mould runs more than a handful of cavities, you already know you can't test every cap: torque testing is destructive, so testing everything means scrapping everything. The fix isn't testing more; it's tagging what you do test by cavity number and rotating which cavities get sampled, so every cavity gets checked over a defined cycle, and the report records which cavity each result came from, not just the batch it belonged to.

Why does this matter if the batch already passed? "The batch passed" and "every cavity is in spec" are two different claims: only one of them is visible from an average.

Worth being precise here: cavity and operator tracking are recording decisions, not something a [digital cap torque tester](https://torquetester.co/) does automatically. The instrument produces the reading; your sampling plan and report format decide whether that reading traces back to a cavity or an operator at all.

If today's report can't answer "which cavity did this reading come from," that's the first column to add, before anything else on this page.

A Ready-to-Use Cap Torque Test Report Field Template

Here's the torque test report template: the baseline fields from the previous section combined with the two multi-cavity fields, in one table. Every column is a field name plus the reason it belongs on the form: no example readings, no sample dates, nothing filled in. Most of these fields describe one batch test session; the individual-readings field is the exception, since it needs its own row per specimen inside that same batch record. Copy the headers into your own spreadsheet or form and fill it in row by row.

Column order isn't fixed: arrange it to fit your paperwork. What isn't optional is which columns exist. Drop the cavity or operator column because "we've never had a problem," and the report goes back to answering only "did the batch pass" — never the hard question.

Put this table next to your current report template today. Every column here that's missing from yours is a specific, nameable gap, not a vague sense that your documentation could be better.

Design the Format Backward From the Audit Day

A torque test report isn't really written for the day the test happens. It's written for the day, weeks or months later, when someone needs to reconstruct that day from the paper trail alone.

Picture the moments this report actually gets pulled back out: a customer complains a batch opened too hard or sealed too loose; an audit asks to see test records for a given period; a cavity starts drifting and someone needs to know how long. In each moment, the report is being asked a question nobody was thinking about on the day the test ran.

That's the test worth applying to any report format: if a complaint landed on a specific batch today, could this report trace back to the cavity and operator involved, confirm conditions were controlled, and show the pass/fail basis, without anyone's memory filling in the gaps?

If you're the one who has to answer for this report later — quality manager, QC lead, whoever signs off — ask that question before you fill out today's form, not the next time you buy a tester. If the answer is no, the fix is the columns in the previous two sections, not new equipment.