Use the right term for the activity
The VIM distinguishes calibration from verification. In simplified terms, calibration establishes measurement relationships; verification provides objective evidence about fulfilment of specified requirements. They should not become interchangeable labels merely because both can have a due date.
Ask how the product represents the activities your laboratory actually performs. Do not choose an interval simply because a software template defaults to one year. The appropriate rule must be determined from the applicable technical, procedural and other requirements—not from a generic marketing example.
Separate the requirement from the completed event
A requirement describes what is expected. A completed event records what happened. An uploaded document is evidence associated with the event; it is not automatically the same thing as an accepted result.
In the demonstration, change a future schedule without editing the historical activity. Then ask the evaluator to explain which rule applied when the earlier work was completed. If that explanation is difficult, the software may not match your intended control model.
Ask the due-date questions explicitly
The table below is an original evaluation framework. It does not prescribe your laboratory’s rules.
| Scenario | Question to answer before the test |
|---|---|
| Activity completed early | Is the next date based on the planned date, completion date or another approved rule? |
| Activity completed late | How is the overdue period represented? |
| Work completed but not reviewed | Does the display distinguish completion from acceptance? |
| Date crosses a month or leap-year boundary | What is the agreed calculation and displayed local date? |
| Requirement is changed | Who can change it, what reason is recorded and which records retain the old basis? |
| Required information is missing | Is the result shown as unknown or incomplete rather than assumed satisfactory? |
Choose expected outcomes before clicking through the examples. Otherwise, almost any demonstrated behaviour can be rationalised after the fact.
Test an unsatisfactory result
Record a fictional result that does not meet the specified criteria. Ask how the issue is connected to the equipment and how the next decision is recorded. A new attachment should not, by itself, make a failed outcome disappear.
Follow the example through corrective work and any review your procedure requires. Check whether the original event remains retrievable and whether the reason for the later decision is clear. Do not assume the presence of an audit-history screen proves every relevant change is captured; test the exact change you care about.
Look beyond the reminder
Ask who receives a reminder, how ownership changes are handled and what happens when an activity remains overdue. A useful notification should direct the recipient to the relevant record and action.
Do not put confidential results or unnecessary personal information into notification examples. Start with synthetic data. Also ask what happens when a notification cannot be delivered: is the underlying task still visible, and is there an agreed operational process for dealing with it?
Make a fit decision, not a feature count
At the end of the evaluation, retain a short record of each scenario, expected result, observed result and remaining gap. Separate a missing capability from an untested one. A supplier’s future intention is not the same as a demonstrated feature.
Software can organise schedules and supporting records. It does not perform the calibration, determine the scientific suitability of the method or grant accreditation to the laboratory.
Review the equipment-record guide for the wider lifecycle. For an AureqoEq discussion, bring one requirement, one due-rule question and one failure scenario to a Request a product walkthrough using demonstration data.