Short answer: how do you actually stop an expired instrument?
A calibration tracking program must not merely show an instrument whose planned recalibration date has passed in red; it must establish a real authorization gate between the instrument's status and its usage operations. The system should re-check the current status when the instrument is selected, assigned to a job, when the measurement record is started and when the result is published; it should block usage according to organizational policy, quarantine the instrument, or allow progress only through an authorized and justified exception workflow.
The phrase “expired” should be used with care. The date on the calendar is the recalibration plan defined by the organization; it does not prove that the instrument started measuring incorrectly at that very second. The converse is also true: an instrument cannot be assumed suitable under all conditions just because the date has not arrived. Events such as a drop, overload, malfunction, a suspicious result, adjustment or a failed intermediate check can take the instrument out of service even before the planned date.
A calibration date is not an expiry date
Assigning a single calibration period valid for everyone to measuring instruments is not correct. ILAC G24:2022 addresses methods that can be used to establish and review calibration intervals for measurement equipment.[1] Usage intensity, transport, environmental conditions, instrument stability, manufacturer information, past results, intermediate checks, the required measurement uncertainty and the impact of an incorrect result can all feed into the assessment. The organization must justify its own program and review it with performance data.
For this reason the “next calibration date” in the program is controlled planning data, not an immutable truth. Moving the cell forward to extend the date makes past delays invisible. The correct approach is to keep the old date and store the justification for the new interval, the approving person, the decision date and the supporting records as a separate revision. A retroactive date change must never be silent.
ISO 10012:2026 defines current requirements for organizations to control their measurement processes and equipment within a system that supports confidence in valid and reliable results.[2] ISO/IEC 17025:2017 is the framework for the competence, impartiality and consistent operation of calibration laboratories.[3] Software does not take over the technical responsibility in these frameworks; it preserves the link between instrument status, decisions and evidence.
First build an explicit device status model
A single "active/passive" field is not enough. At minimum, states such as available, due soon, plan date passed, quarantined, under maintenance, under adjustment, faulty and out of use should carry distinct meanings. Some states arise automatically from the calendar; others start with an authorized user's event record. For example, when the planned date passes at midnight the status may be "overdue"; when the device is dropped, it must be moved to "quarantine" without waiting for the date.
For every status change the source event should be kept: planned date, failed intermediate check, physical damage, customer return, maintenance, adjustment, certificate cancellation or an authorized decision. A user must not be able to remove a block by merely selecting "suitable" from a dropdown. The conditions for returning a device to use must be defined in the organization's procedure; the status must not change before the required calibration, verification, maintenance or technical review is complete.
- Warning: The date is approaching; planning should be done; the device may still be usable under the organization's rule.
- Soft block: The transaction stops, but a person in a specific role may request an exception with justification and duration.
- Hard block: Assignment, measurement or publication cannot be progressed by any user in the standard flow.
- Quarantine: Together with the digital status, the device is physically separated; accidental handover is prevented.
- Out of use: The device is closed to new jobs, but its past records and certificates are not deleted.
At which transaction points should the block operate?
A check made only on the login screen goes stale easily. The user may have opened the page in the morning while the device's date passed during the day, or another authorized person may have quarantined it. The critical condition must be re-evaluated server-side at the moment of the transaction. A greyed-out button in the UI is good guidance; it is not a security control.
1. Device selection and reservation
When planning a new job, the device's status, scope, location and the planned job date are evaluated. If a device that is suitable today will be overdue on the date the job takes place, the system should show this in advance. Reserving the same device for two conflicting jobs is a separate suitability problem.
2. Job start
When the technician starts the job in the field or the laboratory, the status is checked again. If the device was quarantined afterwards, the old reservation does not legitimize its use. In offline work, the time of the last verification must be visible; a risky job must not be silently started with a device status that has not been updated for a long time.
3. Measurement record and device link
The device used must be mandatorily linked to the raw measurement record. The user must not be able to bypass the block by leaving the device field blank or typing another name as free text. If multiple references are used, each one's role and status in the job must be recorded.
4. Technical review
A problem may be noticed later in the certificate of a device that seemed suitable during the job. The technical review must see the device status and certificate link again. A warning must not be just a dismissible window; the outcome of the assessment, its justification and the authorized person must become a record.
5. Report or certificate publication
The last gate is publication. If one of the source devices becomes blocked, the system must not automatically invalidate the results, but it must not open the document to the customer before a technical decision is made. This distinction matters: the program stops the process; the technical expert assesses the impact.
If an exception is required, it should be a controlled decision, not a "back door"
Some organizations may define a limited exception procedure for a device whose planned date has passed under certain low-risk conditions. Others allow no exceptions at all. Software must not impose a universal policy; it should apply the organization's approved procedure. If an exception exists, at minimum the device, job, scope, justification, requester, technical approver, start-end time and additional control evidence must be recorded.
An "admin continue" button is not enough. The administrator role may not mean technical authority. Who may approve the exception should be determined by device type and measurement scope. An indefinite waiver, bulk application to an entire device group, or retroactive approval of past jobs is a serious red flag.
The exception record must not automatically change the next planned date. It should also remain visible on warning and reporting screens; the technical reviewer must know that this job progressed outside the standard. If the organization withdraws the decision, reservations on open jobs must be re-evaluated.
If the overdue period is noticed later, how are affected jobs reviewed?
The first step is to close the device to new use and physically separate it. Then, instead of assuming "wrong since which date?", the evidence interval is determined. The last known acceptable calibration, intermediate check, comparison or functional test; the device's dates of use; the measured quantity and range; the target uncertainty and the impact on the decision are evaluated together.
The program should be able to list quickly the jobs where the device was used. Not just the report number; measurement points, customer, method, user, date, other references used and the result version must be accessible. This list is not a technical decision; it forms the scope of the review. A new calibration result or expert assessment helps determine which jobs may have been affected.
The planned date having passed is not the same as the device being found out of tolerance. An overdue device may later give acceptable results; a device whose date has not passed may also be problematic due to an impact. Therefore the program must not issue automatic customer notifications or bulk document cancellations for every delay. After an authorized decision, the required correction, remeasurement, report revision or notification must be carried out with records.
Watch out for date, time and offline recording errors
Although the block logic looks simple, timezone errors can lead to wrong outcomes. The server may use Europe/Istanbul time while the mobile device is in another timezone. If the date is defined only as "YYYY-MM-DD", the moment of transition must be explained in the organizational policy. A user setting the device clock back must not bypass the block; the critical decision should rely on trusted server time and a signed synchronization record.
The offline app should show when the device status was downloaded. A terminal left disconnected for a long time may carry an old "suitable" status. Depending on organizational risk, a maximum age can be defined for status data; if exceeded, connectivity can be required to start new jobs. If there is a conflict after synchronization, instead of blindly accepting the last writer, a quarantine or review queue should be created.
Certificate files, plan revisions and the device status history must be protected with an immutable record logic. If the wrong file was uploaded, instead of deleting it and putting a new one, a cancelled/superseded-by relation should be established. The log must not just say "user updated"; it must include the old value, new value, source transaction and time.
A warning system and a usage block are different things
Email, panel notifications and an upcoming-jobs report are necessary for planning. But sending a notification does not mean the risk is controlled. The email may go unread, the responsible person may be on leave, or the job may be started by another user. Notification enables proactive preparation; the block prevents the erroneous transaction from happening.
In a good design notifications are tiered: for the approaching deadline the device owner, planner and, if needed, management are informed; on delay, job assignment closes; on quarantine, a physical separation task opens. The system does not have to run heavy queries every minute. A daily planning job, event-based status updates and transaction-time verification together provide reliable control without increasing server load.
Eight acceptance tests for implementation
- Can a device whose date expires tomorrow be assigned to tomorrow's job; does the system consider the planned job date?
- When a device is later quarantined, are open reservations and draft jobs re-flagged?
- Can the user bypass the block by leaving the device field blank or using free text?
- While the mobile device is offline, is the age of status information visible; what happens if the maximum age is exceeded?
- Can an unauthorized user push the planned date forward; are the old value and justification preserved?
- Is the exception limited to a specific job, scope and duration; is technical approval mandatory?
- Can past jobs where the device was used be found with a single query, with measurement context?
- Can return to service be done before the required records are complete?
Run these tests not only with demo data but with anonymized real scenarios. A successful outcome is not "it turned red on screen"; it is the wrong transaction stopping at the right point, the authorized user being able to understand why, and the whole decision chain being auditable afterwards.
How does Vizyon Muayene handle this control?
Vizyon Muayene; it relates controls such as the device inventory, calibration plan, reference device traceability and blocking an expired device in the workflow to calibration laboratory processes.[6] Which point the rule becomes a hard or soft block, the exception authority and the conditions for return to service must be configured according to the organization's procedure.
To validate your own scenario, prepare a reference device, an approaching date, an open work order and a sample exception role. From the contact page when requesting a pilot, test not just the reminder screen but the assignment, offline use, technical review, publication and impact review gates together.
Frequently asked questions
Is a device whose calibration has expired definitely faulty?
No. The passing of the planned date does not prove the device is faulty at that moment; it shows a deviation from the organization's control program. The device must be closed to new use and the technical assessment made by authorized persons.
Is a device whose date has not passed always usable?
No. Events such as damage, overload, malfunction, a suspicious measurement, a failed intermediate check or environmental impact may require quarantining the device before the date.
Is it enough if the system only sends an email warning?
No. Warnings are for planning; they do not technically stop the critical transaction. Server-side status checks are required at device selection, job start, measurement record and publication stages.
Can an authorized user extend the period?
If the organizational procedure allows, a new plan can only be set with a technical justification, supporting record, authorized approval and a change trail. Deleting the old date or changing it retroactively is not correct.
Should all reports made with an expired device be automatically cancelled?
Automatic bulk cancellation is not correct. The device's status, new calibration or intermediate check results, period of use and the impact of the measurements must be assessed through an authorized technical review; the necessary action follows that decision.
Official sources
- [1] ILAC G24:2022, measuring equipment recalibration intervals.
- [2] ISO 10012:2026, measurement management systems.
- [3] ISO/IEC 17025:2017, testing and calibration laboratories.
- [4] ILAC P10:07/2020, metrological traceability of measurement results.
- [5] BIPM/JCGM VIM 3, calibration definition and the adjustment/verification distinction.
- [6] VizyonTech, Vizyon Muayene product page.
Sources were checked on 11 July 2026. Calibration intervals and exception rules must be determined in an authorized manner based on the organization's scope, risk and applicable conditions; this content does not replace a technical or legal compliance decision.