Calibration establishes a measurement relationship
The international vocabulary of metrology describes calibration in terms of establishing relationships between reference values and indications, including the associated measurement uncertainties, and using that information to obtain a measurement result. Calibration is not simply another word for adjustment. See the VIM calibration entry for the full definition and notes.
For a record system, the practical question is what information must remain connected to that event: the item, date, relevant reference information, report and any subsequent decision. The exact content depends on the laboratory’s activity and applicable requirements.
Verification asks about specified requirements
The VIM describes verification as providing objective evidence that specified requirements are fulfilled. It is distinct from calibration and should not be confused with validation. The VIM verification entry provides the formal definition and examples.
In a proposed record model, identify the requirement being checked and the evidence used to reach the outcome. A pass label without the relevant criteria may be difficult for a later reviewer to interpret.
Maintenance records work performed
For this practical discussion, maintenance means work intended to keep equipment functioning or restore its operation. This is a working description for organising records, not a quoted formal definition or a substitute for a manufacturer’s instructions.
A maintenance event might describe an inspection, cleaning, repair or replacement. Whether a separate verification or calibration activity is needed afterwards depends on the equipment, work performed and applicable procedure. Do not let a generic “maintenance complete” state make that decision implicitly.
Keep activity, evidence and decision separate
Consider a fictional instrument, EQ-DEMO-024. A repair event records what was changed. A subsequent check records its own criteria and outcome. A responsible person then records the decision required by the laboratory’s procedure.
The software evaluation should show whether those records can be related without collapsing them into one editable note. Ask whether the original repair remains visible if the later check is repeated. Ask whether an attachment can be replaced and, if so, how the previous evidence and reason for the change are handled.
These are proposed evaluation questions. They do not imply that every product supports those controls or that one particular workflow is universally required.
Avoid a status that answers too many questions
An equipment item may have current scheduled work but a separate restriction. Work may be completed but still awaiting review. Evidence may be attached without a conclusion being accepted.
Use labels that make the question clear: equipment lifecycle, requirement status, work state and review outcome. When evaluating an overall status, ask which underlying facts contribute to it and which decisions remain outside that calculation.
A green state should never be interpreted more broadly than the defined rule supports.
Configure the record around the procedure
Before configuring software, write down the activities your laboratory recognises and who determines their requirements. Decide which records need dates, criteria, supporting documents and authorisation. Identify events triggered by a repair or incident rather than by a calendar alone.
Then test one ordinary history and one exception with synthetic data. A useful system should make the relationships understandable to another authorised person—not just to the person who created the records.
For the wider record model, read the equipment management guide. For schedule behaviour, use the calibration tracking evaluation guide. An Request a product walkthrough should begin with your terminology and questions, not a claim that software can determine the technical requirements for you.