Calibration Due-Date Tracking for NDT Instruments, Probes, and Blocks

The register is bigger than your instrument list

Ask a shop for its calibration list and you get flaw detectors and thickness gauges. Ask an auditor what they want to see and the list grows: every probe with its serial number, the cables in the kit, every IIW block, step wedge, and reference block, the MT yokes, the UV-A lamps and the light meter that proves them, and the survey meters the RT crew carries. The register's scope rule is simple to state: if the item can change a recorded reading or a probability of detection, it has an entry.

Blocks deserve the emphasis because they fail silently. A flaw detector out of calibration announces itself at the next linearity check; a calibration block with a worn notch or a dinged radius corrupts every verification performed on it while looking exactly like a block should. So blocks carry their own dimensional-verification due dates, their own certificates, and their own damage-inspection entries. The same logic covers reference blocks cut for specific procedures — sometimes the only physical standard a client's job ever sees.

Each register entry carries the same skeleton: unique asset ID and serial number, description and manufacturer, current status, the applicable check type, the interval, last-done and next-due dates, the certificate or verification evidence, and location or kit assignment. Location matters more than it looks — the audit question is never only "is it calibrated" but "which technician had it on which job," and a register that cannot say where an item was is only half a register.

Due-date logic: three clocks per asset

The first clock is the certificate cycle: a fixed interval from the last accredited calibration, with the interval set in your written procedure — a twelve-month cycle is the common baseline for flaw detectors and thickness gauges. The software's job is to hold whatever your procedure says and count down from the calibration date printed on the certificate, not from the date the unit came back in the door. That distinction quietly shortens the real interval by shipping time when it is gotten wrong.

The second clock runs faster: functional verifications between calibrations. A thickness gauge proved against a reference block each working day; an angle-beam setup verified on the IIW block at the start of the examination; sensitivity re-checked at the points the governing code section requires during the job. These checks are logged, not certificated — a dated entry against the asset's serial number with pass or fail and the technician's identity. Software that captures them from a phone in the field turns a compliance chore into a ten-second habit.

The third clock has no schedule at all. A dropped instrument, a crushed cable connector, a block that came back from a job with a gouge — any of these forces an immediate status change with the printed due date untouched and irrelevant. The register needs a one-tap way for a technician to flag an asset suspect from the field, because the alternative is the instrument riding along to the next job while the office waits for the annual date to catch the problem.

Out-of-cal: quarantine that blocks, not a color that warns

The difference between tracking and control is what happens the day after a due date passes. A spreadsheet turns a cell red; control means the asset's status flips to out-of-cal and the scheduling system refuses to assign it — the dispatcher building tomorrow's UT crew cannot attach that serial number to the job, the same way a certification gate refuses an expired technician. The digital state gets a physical twin: a quarantine tag on the unit and a quarantine shelf away from the ready kits.

Quarantine also covers the in-between states: sent-to-lab, awaiting certificate review, limited-use. The certificate-review state is worth modeling explicitly — a unit back from the lab is not automatically fit for use until someone reads the certificate's as-found data. As-found out-of-tolerance is exactly the trigger for the recall review of prior work, and a workflow that auto-restores status on the unit's physical return will skip the one reading of the certificate that matters most.

The recall review: reverse traceability

When a certificate comes back reading as-found out-of-tolerance, the question stops being about the instrument and starts being about the work: every reading that unit produced since its last good calibration is now suspect. Answering it requires reverse traceability — the register linked to job records, so one query returns every job, report number, and client that serial number touched inside the exposure window. Shops without per-job equipment logging reconstruct this from technicians' memories and truck sheets, in front of a deadline, with a client waiting.

The disposition itself belongs to a Level III: how far out of tolerance, in which direction, against what acceptance margins. A thickness gauge reading a few thousandths heavy is a different conversation from one reading heavy on a corrosion survey where readings sat at minimum wall. The software's role is the evidence package — affected jobs, the readings, the certificate — and the record that the review happened, was signed, and reached the client where notification was owed. That signed record is what closes the finding at the next audit.

Certificates: storage that survives an audit

A calibration certificate answers four questions: who calibrated the item, against what reference standards, what the as-found and as-left conditions were, and when it is due again. Storage that works means one record per calibration event, attached to the asset, with the certificate PDF plus its key fields — lab, certificate number, dates, as-found status — extracted into searchable data. The as-found field earns its keep: filed-and-forgotten out-of-tolerance certificates are how a shop learns about a recall obligation a year late, from an auditor.

The retrieval standard to design for: given a job number, produce the certificates for every asset used on that job, valid as of the job dates, in minutes. That query joins the asset register to per-job usage records, which is why folder trees named by year and instrument cannot answer it no matter how tidy they look. If you are formalizing what a certificate itself should contain, /resources/calibration-certificate-template breaks the required fields down line by line.

ISO/IEC 17025 and what clients actually expect

ISO/IEC 17025 accredits laboratories, not inspection contractors — but it shapes what your clients expect from your equipment program anyway. The working expectations: instruments calibrated by accredited labs, measurement traceability running back to NIST, documented control of equipment found nonconforming, and records that hold the whole chain together. Client auditors apply that frame to NDT contractors whether the formal audit basis is a quality manual, an ASNT-based program, or a corporate supplier standard.

The practical consequences: buy calibrations from accredited labs and keep the accreditation scope with the certificate, because an accredited lab calibrating outside its scope is a finding you inherit. Reference your own written procedure's actual requirements and the code sections your work is performed to, rather than dressing procedures up with clause citations nobody verified. A register organized around traceable certificates, logged verifications, and nonconformance control answers audits from any direction without pretending to an accreditation you do not hold.

The audit questions a client asks — and the report answering each

Audit questions about calibration follow a pattern, and each one maps to a report the software either produces in seconds or does not produce at all. Show me your equipment list with calibration status — the register, filtered live. How do you prevent use of overdue equipment — the quarantine gate, demonstrated on screen. Show me the certificate for this serial number — one click from the asset record. What equipment was used on this job — the per-job usage log.

The harder half: what happened the last time a unit came back out-of-tolerance — the recall review record, signed and dated. How do you verify between calibrations — the field verification log. Who decides your intervals — the written procedure, cited by the register's interval field. An answer that begins with someone opening a spreadsheet and scrolling is scored as a weakness even when the data eventually surfaces; the auditor is grading the system, not the search skills.

Why this is an ERP module, not another spreadsheet

Every capability above is a join between calibration data and something else: quarantine joins the register to scheduling, recall joins it to jobs, audit retrieval joins it to documents, field verification joins it to mobile data capture. Spreadsheets hold the register but cannot make the joins, which is why spreadsheet tracking works right up until the first out-of-tolerance certificate — and then fails all at once, in front of a client.

Atlantis builds this as the equipment module of its Odoo-based ERP for NDT companies — the register, three-clock due dates, quarantine gating on dispatch, per-job usage capture from the field app, and certificate storage with as-found flags — sharing data with the personnel-certification and job-costing modules beside it. Affordable, accessible, fully customizable. A demo against your own equipment list is available on request, and it is the fastest way to see the recall query run.

Request a consultation