The protocol’s audience is not only the client. It is also the third party who reviews the results years later, the insurer who asks what was verified, and the engineer who has to compare a future result against this one. Writing for that audience is what makes the document durable.

What an acceptance protocol must contain

The document should identify the asset or system being tested, the scope of the test, the method to be applied with its standard reference, the acceptance criteria and their source, the conditions under which the measurements will be taken, and the sign-off arrangement.

It should also state what happens if the result falls outside the criteria, who authorises a deviation, and what constitutes a valid re-test. Those items are the ones that are most often left to be settled informally, and they are the ones that determine whether the handover is straightforward.

The scope matters as much as the criteria. A protocol that defines the test but not what it covers leaves the coverage question open, and the coverage question is what a reviewer asks first: what has this test actually verified, and what has it not?

Agreed limits before testing starts

The acceptance criteria should be traceable to a document. Where the limit comes from a standard, the protocol should cite the designation, the part and the edition. Where it comes from the client’s own specification, the protocol should cite the specification, and where the client’s specification and a standard differ, the protocol should state which governs.

Where the standard or specification leaves a value to be agreed, the agreed value belongs in the protocol with a note that it was agreed rather than derived. That distinction matters if the value is later questioned, because an agreed value can be revisited by agreement while a derived value has to be checked against the document.

The criteria should be expressed in the form the measurement produces. A limit stated as a resistance, a loss factor or a charge value has to match the quantity the instrument reports, including its units. Criteria stated in a different quantity from the measurement invite conversion errors that appear as marginal results.

Recording conditions alongside results

Every result in the protocol should be accompanied by the conditions under which it was obtained. The specific conditions depend on the test, but the categories are consistent: the applied quantity, the duration, the temperature, the humidity where it affects the measurement, the connection or coupling arrangement, and the instrument with its calibration status.

The categories are not bureaucratic. Each one corresponds to a variable that changes the measured value, and a protocol that omits them is one that can only be accepted on trust rather than on evidence.

Sign-off structure and who witnesses

The protocol should state who performs each test, who witnesses it, and what each signature confirms. Ambiguity about the scope of a signature is the commonest cause of dispute during handover.

The most workable arrangement is a single record signed by both the tester and the witness, with the procedure document referenced so that both parties are confirming the same thing. Where the witness is the client’s representative, the record should make clear whether the signature confirms the result, the method, or both.

Where a third party will review the results after handover, the protocol should identify the reviewer’s role. A document written with that review in mind tends to be more complete in the fields that a reviewer checks: conditions, raw data and deviations.

Deviation handling and re-test rules

A deviation is any departure from the agreed method or criteria. The rule should be that deviations are recorded when they occur, with the reason and the authorising person, and that the effect on the result is stated.

The re-test rule should state when a repeat measurement is permitted and what it means. A repeat after a corrected connection error is a valid measurement; a repeat performed because the first result was inconvenient is not, unless the deviation is recorded and the reason stated.

The distinction is easier to maintain when the protocol states the expected repeat rule in advance. A rule such as allowing a single repeat where the measurement conditions were demonstrably wrong, with the deviation recorded, is workable and defensible.

Formatting results so a third party can follow

The results section should be organised by asset or by test, with each entry showing the measured value, the criterion, the verdict and the conditions. A reader should be able to trace any verdict back to the measurement and forward to the standard that supplied the criterion.

Where a result is marginal, the protocol should state the margin rather than only the verdict. A value that passed with one percent of margin and one that passed with fifty percent are different statements about the asset, and a reader who sees only the verdict cannot tell them apart.

Summaries are useful and should not replace the detail. A summary table with the overall verdict for each asset, cross-referenced to the detail, gives a reader the overview without forcing them to work through every entry.

Attaching raw data without bloating the report

Raw data belongs in an appendix, referenced from the results table. Traces, timed readings and instrument exports are the evidence behind the derived values, and a reviewer who wants to check a calculation needs them.

The format matters. A proprietary file that requires software the client does not have is not an attachment in any practical sense. Exporting to a format the client can open, or including a printed representation alongside the data file, is what makes the appendix usable.

Where the raw data is large, the appendix should be structured so that the relevant portion for each result is identifiable. An undifferentiated mass of files is technically complete and practically unusable.

Closing out the protocol at handover

Closing out means confirming that every item in the scope has a result, that every deviation is recorded and authorised, and that the sign-off is complete. A protocol with open items should be identified as such rather than presented as complete.

The close-out should also record the state in which the equipment was left, including the settings applied, the connections restored and any temporary arrangements removed. Those items determine whether a tested asset is an asset ready for service, and they are the items that a later inspection cannot reconstruct.

Where the client requires a certificate of test or a conformity statement, the protocol should state what it covers and what it does not. The scope statement is what prevents a certificate from being taken as evidence of something that was never tested.

Client-supplied criteria versus your own standard

Where the client supplies the criteria, the protocol should use them and cite them, even where the contractor’s own standard would be more demanding. The client’s specification governs the acceptance decision, and a contractor who applies a different criterion without agreement creates a discrepancy that has to be resolved later.

Where the client’s criteria are less demanding than the contractor’s own engineering judgement would suggest, the protocol may note the difference and record the client’s instruction. That note protects both parties: the contractor has recorded the advice, and the client has recorded the decision.

Where the client supplies no criteria at all, the protocol should propose them and reference the standard they came from. A protocol that leaves the criteria blank until the results are known is not a protocol, and it is the document that most often produces a disputed handover. The laboratory competence framework that a testing organisation is measured against is described by the accreditation bodies, such as the material published by ILAC and IAF; independent acceptance practice is set out by NETA; the traceability framework for the measurements is described in the NIST handbooks, and legal metrology requirements are published by OIML.

Digital records and retention period

The retention period should be set by what the record may be needed for. A test record may be required for a warranty claim, for a failure investigation, for comparison against a future measurement, or for a regulatory review. The longest of those determines the period, which in practice means the life of the asset.

A digital record has to remain readable over that period, which is a format question rather than a storage question. Storing the report as a document and the data in an open format, and keeping a copy outside the software that produced it, is the practical approach.

The record should also be searchable by asset. A retention policy that stores files by project rather than by asset makes the future comparison harder, which is the main reason the records were kept. Comparable certification and product documentation practice is shown on the certifications page, and the service arrangements that support a test programme are described under testing services and OEM/ODM solutions.