The certificate of conformance is the one document that leaves the shop. Everything else — the schedule, the pyrometry file, the recipe library — stays inside. The cert is what the customer files, what their auditor pulls, and what your name is on. So the question of what belongs on it is not a formatting question. It is a question about where each line came from.

There are two ways to produce a cert that looks identical on paper. One assembles it from records: every field is read from the load, the recipe, the pyrometry in force, the test results. The other assembles it from memory and a template: somebody retypes the numbers into a document. The first is a claim you can defend line by line. The second is a document that agrees with itself and with nothing else, and you find out which one you shipped eighteen months later, in front of an auditor.

Here is what has to be on the cert, and — more to the point — what each line has to be connected to underneath.

Identity: what this was, to which revision

Part number, the customer’s order and line, the lot and its quantity, and the specification the work was performed to including its revision. The revision is the field most often dropped and the one most likely to matter: a customer who moved from revision C to revision D of a spec is asking a different question of the same part, and a cert that names the spec without the revision has not actually said what it certifies against.

None of this should be typed at cert time. It is already on the order line the load was built from. If it is being retyped, it can drift, and a cert whose part number disagrees with the order it belongs to is worth less than no cert.

What actually ran — not what was asked for

A recipe has setpoints. A furnace has actuals. The cert has to carry what the furnace did, read from the cycle record, not what the recipe specified. These are usually close and occasionally not, and the whole point of recording actuals is the occasion when they are not.

This is where a load-centric model earns the cert almost for free. Because the load is a real object carrying its recipe and its cycle actuals, the cert reads the run that happened. An order-centric system knows the line was “at heat treat” and has to reconstruct the rest — which is where retyping creeps in.

The pyrometry that was valid then

The cert asserts, implicitly, that the furnace was qualified to run this work on the day it ran. That means the SAT, the calibration, and the temperature uniformity survey in force at run time — not the ones current when the cert is printed, which may be newer.

If your system stores only the latest pyrometry record per instrument, the cert cannot make this claim honestly, because the evidence it would cite has been overwritten. The two designs that survive are append-only dated records and a snapshot frozen onto the load at build time; doing both is best, for the reasons laid out in what AMS 2750 requires of your software. A cert built on either can name the SAT that was current then. A cert built on a spreadsheet names whatever is in the cell today.

Results, computed and not typed

Where the cert reports a test — hardness, a pass against a uniformity tolerance, a corrected instrument reading — that result should be computed from the readings and the applicable corrections, then printed. A cert with a “Pass” that a technician selected from a dropdown records an opinion. A cert with a “Pass” the system derived from the numbers records a measurement. On paper they are the same word. Under audit they are not.

Signature and the chain behind it

The cert names who released it and when. Behind that signature sits the chain an auditor actually walks — lot to load to cycle actuals to pyrometry to result — and the signature means the person stands behind the chain, not the document. The Nadcap walk-through follows exactly this path, backwards, and the cert is where it starts.

The tell: regenerate last year’s cert

There is one test that separates a cert assembled from records from a cert assembled from a template:

Reprint a certificate you issued a year ago. Does it come back byte-for-byte identical, from the records — or does it come back looking slightly different, because it was a document somebody composed once and the composition is gone?

A cert that regenerates identically is a cert whose every line was a link. A cert that has to be re-composed was never linked to anything; it was a snapshot of somebody’s typing. The first is evidence. The second is a photograph of evidence, and photographs are not admissible when the auditor asks to see the negative.

We built the certificate as the readable face of the trace chain, not a separate document to maintain — which is the whole argument for making the load a first-class object in the first place.

This post names no fields specific to one customer’s flow-down or one prime’s format, because those differ and yours is the one that governs. The structure described here — identity, actuals, as-of-date pyrometry, computed results, a signed chain — survives every format a cert gets poured into.

What actually belongs on a heat-treat certificate of conformance