A thermocouple has two clocks, and most software watches only one
Ask most shops how they know a thermocouple is good to use, and the answer is the calibration date. It is the obvious clock: calibrated on this date, valid for that interval, check the calendar. It is also only one of the two clocks a thermocouple runs on, and the second is the one that quietly invalidates work.
A thermocouple — depending on its type and how it is used — has a permitted number of uses as well as a calibration interval. Both have to hold. A thermocouple three months inside its calibration date and past its use count is not usable, and a load run on it is a load run on an uncalibrated sensor. A system that checks only the date will wave it through, print a clean record, and the shop will not learn otherwise until an auditor counts.
Uses are consumed by events, not by time
The calibration clock ticks on the calendar and needs nothing from the system but the date. The use clock is harder, because a use is an event the system has to witness: this thermocouple went into that load, that survey, that test. If uses are tracked in a separate log that somebody increments by hand, the count and reality diverge the first time a load is run in a hurry.
The count only stays honest if it is a consequence of recording the work, not a second chore attached to it. When a load is built and a thermocouple is assigned to it, that assignment is the use. Nobody decrements a counter; the counter is the number of assignments, derived. This is the same principle as validity being a calculation rather than a stored flag: a number the system computes cannot be forgotten, and a number a person maintains eventually is.
Type decides which rules apply
Not every thermocouple runs both clocks the same way. Type governs it — an expendable thermocouple, a non-expendable one, a control sensor, a test sensor in a survey all live under different rules for how long calibration holds and how many uses are permitted, and some are single-use by definition. A system that stores “thermocouple” as one undifferentiated thing, with a single date field, cannot apply the right rule because it has thrown away the fact that decides which rule applies.
So type is not a label for a report. It is the input that selects the calibration interval and the use limit. If it lives as free text on the equipment record, nothing downstream can enforce anything from it — the same way a furnace class or instrumentation type stored as free text cannot gate a recipe that demands a minimum.
The same object, three lifespans
The reason this is worth modelling properly, rather than as a checklist, is that the same physical kind of sensor lives very different lives depending on its job:
- A control thermocouple built into the furnace runs a long calibration interval and a high or effectively open use count — it is in every cycle.
- A load thermocouple riding with the parts is handled, bent and reseated, and burns its uses fast.
- A test thermocouple in a survey or system accuracy test carries its own known error that has to be applied to the reading before the comparison means anything — a use clock and a correction the arithmetic depends on.
One record shape has to hold all three without pretending they are the same, and it has to know, at the moment of assignment, which one it is looking at.
Where the check belongs: before the load exists
The place a thermocouple’s eligibility matters is not a monthly report. It is the instant someone tries to assign it to a load. That is early enough to stop the mistake instead of documenting it, and it is where the compliance gate does its work — an out-of-date or out-of-uses thermocouple is refused for the same reason and at the same moment as an overdue furnace, before any work is committed to it.
A report that surfaces the expired thermocouple next Tuesday is a report about a load you already shipped.
The one-line test
There is a single question that tells you whether the model is real or decorative:
Take a thermocouple that is comfortably in date and out of uses. Try to run a load with it.
A system that models thermocouples properly refuses and names the reason — out of uses, not out of date. A system that watches one clock passes it, and every record downstream of that load inherits the flaw silently. It is the same shape of test as running a load on a furnace whose SAT is overdue: the honest system stops you at the point of use, and everything else is downstream of whether it does.
Intervals, use limits and how they vary by type differ between revisions of the standard and by sensor, and your copy governs — not this post. What does not change is the shape: two clocks, type selects the rule, and the check belongs at assignment.