Establish the reporting requirements first
NATA’s test-report guidance explains that reporting requirements depend on the relevant standard and program. Its guidance addresses identification of amendments and the relationship between a new report and the original. It also distinguishes activities within an organisation’s accredited scope from those outside it.
Check the requirements applicable to your laboratory and report type. A document labelled “certificate of analysis” does not, by that label alone, establish the correct amendment procedure or imply accreditation.
The workflow below is an original evaluation proposal. It is not a complete statement of NATA, ISO or sector-specific requirements.
Start with the issued record
Ask the demonstrator to open a synthetic document that has already been issued. Record the identifier and the exact version involved. Then introduce a correction request with a reason.
The useful question is not merely whether the text can be changed. It is whether the evaluator can still identify what was originally issued and how the proposed correction is being considered.
Separate the change from the decision to issue it
A proposed change may affect a transcription, a description, an interpretation or another part of the record. The significance must be assessed by the appropriate laboratory role under its procedure.
For the software evaluation, identify who may propose the change, who may review it and who may authorise the resulting issue. Ask what happens when the reviewer rejects the proposal or requests more information. Do not assume an application’s default role names map directly to the laboratory’s authority structure.
Test the relationship between versions
Use a fictional example, CERT-DEMO-031. Version A is the previously issued document. A correction is proposed, reviewed and either declined or accepted. If a new document is issued, ask a second evaluator to find its relationship to the earlier one.
Useful questions include:
- Can the evaluator distinguish the current issued document from an earlier version?
- Is the reason for the change retrievable alongside the decision?
- Can the earlier issued content be located by an appropriately authorised person?
- Does a link or client view make the document’s status clear?
These questions should be answered with demonstrated behaviour. A future roadmap item should be recorded as a gap, not as a passed control.
Include the recipient step
A correct internal record does not necessarily establish that the intended recipient has been informed. Ask how the workflow represents the communication step, what evidence is retained and how an undelivered notification would be handled.
Avoid assuming that an email was read simply because it was sent. Decide what communication and follow-up your procedure requires, and whether the product can support that arrangement. Use synthetic recipients in authorised testing, not a real client mailing list.
Try the awkward cases
Test a correction that is rejected, a second correction after the first revision and an attempt by a role that should not issue the document. Check how download names, displayed identifiers and links distinguish versions. A clear screen label is helpful, but the underlying record relationship matters more.
Record any limitations explicitly. The goal is a traceable and understandable process, not a promise that a revision button makes every reporting obligation disappear.
For current product boundaries, review AureqoLab. A Request a product walkthrough using demonstration data can be structured around one issued document and one correction question, with any wider pilot agreed separately.