Right certificate, right gauge: matching a DCC through its item identifiers

"Four plug gauges went out on Monday. Four certificates came back on Friday. They all say Thread plug gauge M10×1.5-6H. Which one is which?"

Every quality engineer who runs a gauge crib has asked that question. With PDF certificates, a technician answered it by eye: read the serial number on the certificate, read the engraving on the gauge, attach the file. Slow, but a human looked at both.

Digital Calibration Certificates change the mechanics. A DCC built on the PTB schema (v3.3.0) arrives as structured XML that a system can read without anyone re-keying it. That removes transcription. It does not remove the question of identity — it moves it into a rule that runs on every certificate you receive. If the rule is "match on gauge type", you have automated the wrong answer.

What goes wrong when type stands in for identity

Take a concrete crib. Six M10×1.5-6H thread plug gauges, same manufacturer, same model, asset numbers G-0412 to G-0417. Four of them — G-0412, G-0413, G-0415 and G-0416 — go to an accredited lab. Four DCCs come back. Three report both members within limits. The fourth, for G-0415, reports the GO member worn beyond its wear limit as-found.

Now suppose the certificates are linked by name and model, taking the first open record that fits. G-0415’s failing certificate lands on G-0412. The consequences are quiet and they compound:

• G-0412, which is fine, is pulled from use and quarantined.
• G-0415 receives a passing certificate and a freshly calculated due date. It goes back to the line with a worn GO member.
• Overdue blocking cannot help. The record says G-0415 is in date, so nothing blocks it.
• ISO 9001 clause 7.1.5.2 expects you to determine whether earlier results were affected when equipment is found unfit. That evaluation now runs against G-0412’s usage history — the wrong parts, the wrong lots.

Nothing in that chain is a transcription error. Every value was read from the XML exactly as the lab wrote it. The certificate is correct; the attachment is wrong.

Where identity actually lives in the DCC

The v3.3.0 schema separates administrative data from measurement results. Inside the administrative block, the items element lists the calibrated objects, and each item carries several descriptive fields. They are not equally useful for matching.

Type-level fields — describe the kind of gauge, not the gauge:

• name — required, free text, possibly in more than one language.
• manufacturer and model — optional.
• equipmentClass — optional; a classification reference plus class ID.

All six gauges in the crib share every one of these. They confirm a match. They cannot make one.

Instance-level fields — the ones that discriminate:

• identifications — required on every item, holding one or more identification entries.

Each identification has three parts: an issuer, a value and an optional name. The issuer is a fixed list — manufacturer, calibrationLaboratory, customer, owner, other. The value is a non-empty string. The name is a free-text label such as "Serial number" or "Inventory number".

There is no dedicated serial-number element. A serial number is, by convention, an identification whose issuer is manufacturer. Your own asset number appears only if the lab writes it, typically with issuer customer or owner.

Two more administrative fields are easy to confuse with item identity:

• coreData/uniqueIdentifier identifies the certificate, not the instrument. It is useful for tracking deliveries; it says nothing about which gauge was calibrated.
• coreData/identifications typically carries order or reference numbers for the calibration job. Useful as corroboration, not as the item key.

Match on the issuer, not the label

The issuer attribute is the most reliable part of an identification because it is enumerated. The name label is not: one lab writes "Serial No.", another "S/N", a German lab "Seriennummer", and a bilingual certificate may carry both. A rule that searches the label for the word "serial" will work on the first supplier and fail on the third.

A defensible matching rule reads identifications by issuer and compares each one with the field in your register that holds the same kind of fact:

1. Your asset number (issuer customer or owner) against the register’s asset number.
2. Manufacturer and serial together (issuer manufacturer) against the register’s manufacturer and serial fields. Serial numbers are only unique within a manufacturer; compare the pair, never the serial alone.
3. Lab-issued identifiers (issuer calibrationLaboratory) only if you recorded the lab’s intake number when the gauge was dispatched. Otherwise, ignore them for matching.

Then corroborate with context: model and name should be consistent with the register; the calibration dates (beginPerformanceDate, endPerformanceDate) should fall inside the window your records show the gauge was away at the lab; the order number should match the dispatch.

The outcome must be one of three, and only the first links evidence:

• Exactly one register record matches, and nothing contradicts it → link the certificate.
• No record matches → hold for review. The serial may be mistyped in your register, or missing from the certificate.
• Identifiers disagree — the asset number points to G-0413, the serial to G-0415 → stop. Either your register or the lab’s intake is wrong, and an importer should not guess which.

"Best match" is not an outcome. A certificate held for an hour is a nuisance. A certificate on the wrong gauge is a nonconformity.

The objection: "The serial is on the certificate. Why the ceremony?"

Because the schema does not promise what you need. It requires each item to carry at least one identification. It does not require that identification to be your asset number, does not require a serial, and does not enforce uniqueness — the value is simply a non-empty string. A DCC can be fully schema-valid and identify the item only by the lab’s own job number.

With PDFs, a technician compensated for that every time. With DCCs, the match becomes a rule executed hundreds of times a year without anyone looking. Machine readability raises the stakes on the rule rather than lowering them.

The cleanest fix sits upstream. Ask each calibration supplier to include your asset number as an identification with issuer customer, and the manufacturer’s serial with issuer manufacturer, on every item. Put it on the purchase order. If you are taking questions to the FORCE Technology DCC theme day on 2 December, "how do you populate item identifications?" is a good one to put to every lab in the room.

What the register has to hold for this to work

The comparison is only as good as the record it compares against. If the register stores the serial number inside a free-text description, or has no manufacturer field, no rule can do the matching cleanly.

In PrüfDesk, each instrument record carries its asset number, manufacturer, model and serial number as distinct fields, and the possession trail records when a gauge was checked out to an external lab and when it came back. Those are the facts a reviewer — or a matching rule — needs to confirm that a supplier’s certificate belongs to G-0415 and not its five siblings. Once the certificate is linked, the pass/fail result, the certificate itself and the auto-calculated next due date sit on that one unit, and your tenant’s overdue policy, whether hard block or soft warning, acts on the gauge that actually earned it.

The boundary is worth stating plainly. PrüfDesk is the system of record for equipment, calibration status and evidence. It does not perform the calibration, and it does not establish traceability to a national metrology institute — the accredited lab does that, and the DCC is its evidence. PrüfDesk’s job is to make sure that evidence ends up on the right instrument and stays findable at audit.

A short checklist for your next batch of DCCs

• Does every item in the certificate carry an identification with issuer customer or owner that equals your asset number?
• Does it carry a manufacturer serial (issuer manufacturer), and does the manufacturer-plus-serial pair exist exactly once in your register?
• Do model and name agree with the register record?
• Do the performance dates fall within the period the gauge was recorded as away?
• If one DCC lists several items, did you match each item separately rather than the file as a whole?
• Is there a defined place for unmatched or conflicting certificates to wait, with an owner who clears it?

Pick the last five certificates your lab sent and run them through that list. If any of them could only have been matched by someone recognising the job, that is the gap to close before DCC volume grows.

If you would like to see how PrüfDesk structures instrument identifiers and possession history for this check, we are glad to walk through it using one of your own gauges.