Notes

What AMS 2750 actually requires of your software

· 5 min read

AMS 2750 does not mention software. It governs pyrometry: thermocouples, instruments, system accuracy tests, temperature uniformity surveys, and the equipment those apply to. There is no clause a vendor can be measured against, and no such thing as AMS 2750 certified software.

That absence is exactly why the question gets answered badly. A vendor cannot be non-compliant, so every vendor claims compliance, and the claim means nothing. What is true is that the standard imposes a shape on the records a shop has to keep — and a system either fits that shape or forces the shop to keep the real records somewhere else.

Four requirements decide it. None of them is a feature you will find on a comparison grid.

1. Validity is a calculation, not a flag

Every pyrometry record has a date it was performed and an interval after which it is no longer valid. Whether a furnace is currently compliant is therefore not a stored fact. It is derived, at the moment you ask, from dates and intervals.

Systems that store compliance as a status field are storing a cached answer to a question whose answer changes with the calendar. The cache goes stale silently. Nobody notices, because a boolean that says true looks exactly the same the day before it should have flipped and the day after.

What to ask a vendor: if I do nothing at all — no logins, no edits — does a furnace stop being eligible on the day its SAT comes due? If eligibility depends on somebody remembering to change a status, the system is a filing cabinet with a search box.

2. Pass and fail are computed from the readings

A system accuracy test compares an instrument reading against a test thermocouple reading. The test thermocouple has its own known error, which must be applied before the comparison means anything. Only then is the corrected difference compared against the permitted tolerance.

That is arithmetic. It should never be typed. A field where a technician selects “Pass” from a dropdown is a field where a tired technician selects “Pass” from a dropdown, and the record that results is a record of somebody’s opinion at 2am rather than a measurement.

The same applies to a uniformity survey — the deviation across the work zone is computed from the readings — and to instrument calibration, where accuracy is compared against permitted tolerance.

What to ask: can anyone in this system record a passing test that the numbers do not support? If yes, every record it holds is worth slightly less.

3. The evidence must be reproducible as of a past date

This is the one that separates systems that support an audit from systems that merely store data, and it is the one most software gets wrong.

An auditor does not ask whether your furnace is in compliance today. They pick a job that shipped eighteen months ago and ask whether the furnace was in compliance on the day that load ran.

Answering means reconstructing state you have since overwritten: which SAT was in force then, not the one performed since. Which calibration applied, at what accuracy. What temperature range the furnace was qualified for under the survey current at the time. If the system holds only the latest record for each instrument, that history is gone, and the honest answer is a shrug.

Two designs survive this and one does not:

  • Append-only records — each SAT, TUS and calibration is its own dated row, never edited in place, so the set in force on any past date can be selected by date.
  • Snapshots at the point of use — when a load is built, the pyrometry evidence in force is copied onto the load and frozen there.

Doing both is better, because they fail differently. The first survives someone deleting a load; the second survives someone correcting a historical record.

What to ask: show me a load from a year ago, and show me the SAT that was current when it ran — not the current one. Watch whether that takes a query or an apology.

4. Instruments and thermocouples expire in more than one way

A thermocouple has a calibration date. It also, depending on type and use, has a permitted number of uses. Both must be satisfied. A thermocouple three months inside its calibration date and past its use count is not usable, and a system that checks only the date will pass it.

Furnaces carry attributes the standard actually cares about: the class, which reflects the uniformity tolerance the furnace has demonstrated, and the instrumentation type, which reflects what is being controlled and recorded. A recipe may demand a minimum class or a particular instrumentation type. If those live as free text on an equipment record, nothing can enforce them.

What to ask: what happens if I try to use a thermocouple that is in date but out of uses? The answer is a one-line demonstration of whether the model is real or decorative.

The test that covers all four

There is a single question that exercises every requirement above, and it takes a minute to answer:

Take a furnace whose SAT is overdue. Try to run a load on it.

A system that models pyrometry properly refuses, names the reason, and does so before the load exists. A system that does not will let the load through, possibly show a warning somebody can dismiss, and produce a certificate that looks exactly like a good one.

Everything else — the reports, the dashboards, the mobile app — is downstream of that answer.

We built the compliance gate around precisely this, because it is the thing the standard implies and almost nothing implements.


A note on what this post deliberately does not do: it quotes no clause numbers, intervals or tolerance values. Those differ between revisions of the standard, and your copy is the one that governs — not a vendor’s blog. The requirements described here are structural and have survived every revision.

  • ams-2750
  • evaluating-software
  • pyrometry

← All posts