When the Lab Reissues a DCC: Supersede, Don’t Overwrite

"The lab sent a corrected certificate. Which one did we use for the parts we shipped last week?"

That is the question a quality manager asks when a calibration supplier reissues a certificate after it has already been ingested. With PDFs, the usual answer is a shrug and an email search. With Digital Calibration Certificates it should be a single, defensible query. Whether it is depends on one design choice in your system of record: does a revised DCC overwrite the record it corrects, or supersede it?

This article argues for supersession. It sets out what the standards require, walks through a worked example, and answers the obvious objection.

Why reissues are a normal event, not an edge case

Accredited labs make mistakes and correct them, which is exactly what accreditation expects. ISO/IEC 17025:2017 clause 7.8.8 sets the rules. Changes to an issued report must be clearly identified, with the reason where appropriate. An amendment is made only as a further document or data transfer that references the original. If a complete new report is needed, it must be uniquely identified and must reference the original it replaces.

The DCC world has turned this into data. DKD-E 0-2 (Edition 08/2024), the DKD guide to common administrative data for machine-readable certificates, maps clause 7.8.8 onto two optional fields: a revision number and the number of the first certificate issued. Each is 0..1, meaning the field is optional and appears at most once. In a PTB DCC v3.3.0 file these sit in the administrative data, separate from the measurement results. So a correctly built revised DCC says, in machine-readable form: I am revision 1, and I replace certificate K-2026-0412.

That is the useful part. A PDF reissue tells a human the same thing in a footer. A DCC tells the software, and the software can act on it correctly or incorrectly.

A worked example: one gauge block, three weeks

Take a grade 1 gauge block set, calibrated externally and returned with DCC number K-2026-0412. Your ingest validates the signature and the schema, populates the set’s calibration record, and stores the as-found and as-left deviations for each block. It records a pass, and the next due date is calculated from the calibration date on a 24-month interval. Gauge-block DCCs following DKD-E 4-3 carry values for the set and for each individual block, so the record is genuinely granular.

Over the next three weeks the set is checked out four times: to set up a height gauge, to verify two outside micrometers, and once to the goods-in inspection cell.

Then the lab finds an error in the temperature correction applied to one block. It issues K-2026-0412, revision 1. The corrected deviation puts that block outside its grade tolerance. The calibration date is unchanged, because nothing was re-measured. Only the report was corrected.

Now look at what each design does with that file.

If the import overwrites: the block’s values change in place and the set now shows "fail". The record no longer shows that for three weeks you held a valid, signed certificate saying "pass", or that every check-out in that window relied on it. If the importer read the new issue date as a calibration event, the due date has also moved three weeks later than it should be.

If the import supersedes: the original DCC stays exactly as received, signature intact, flagged superseded by revision 1. The revision becomes the current record. Current-status queries return the corrected values. Historical queries return what was known on any given date. The diff is explicit: one block, one deviation, conformity changed from pass to fail.

The objection: "The new one is correct. Why keep the wrong one?"

Because your obligation is not only to know the true value. You also have to show what you knew and what you did about it.

ISO 9001 clause 7.1.5.2 requires you to determine whether the validity of previous measurement results has been adversely affected when equipment is found unfit for purpose, and to act. ISO 10012 frames metrological confirmation the same way. You cannot run that assessment against a record that has been rewritten. The window you need to examine starts on the calibration date and ends on the day the revision arrived. The overwrite erases the evidence that the window existed.

There is also a plain integrity argument. The original DCC is a signed document. Altering its stored values, or deleting it, turns your record into something no signature vouches for. The revision carries its own signature. Keep both, unmodified, and let the link between them carry the meaning.

The opposite failure is just as common: storing the revision as a second, unrelated attachment. Then two certificates give two answers for the same instrument, and the auditor’s first question is which one is authoritative.

Rules for handling a revised DCC on ingest

Whatever system you use, PrüfDesk included, these are the behaviours to test:

• Match on the reference, not the filename. Link the revision to its original using the number of the first certificate issued, the issuer, and the item identity. If a revision arrives without that reference, route it to a person and do not guess.
• Never modify the original. Store the revision as a new, separately signed record and mark the original as superseded.
• Keep the calibration date authoritative. A reissue is not a recalibration, so the due date must not move. If the revision carries a different calibration date, flag it for review.
• Diff the measurement results. Surface the specific changes in as-found and as-left values, uncertainty, and conformity statements, and do not just say the file changed.
• Trigger the impact assessment when conformity flips. Pass to fail opens a review covering the calibration date to today.
• Answer "as of" queries. You should be able to see which certificate was current on the day a given part was inspected.

Where PrüfDesk fits, and where it doesn’t

PrüfDesk is the system of record for the equipment, its calibration status, and the evidence behind that status. It does not perform the calibration, it does not correct the lab’s numbers, and it does not assign traceability to a national metrology institute. All of that stays with the accredited lab that issued the DCC.

What the system of record can do is make the revision’s consequences visible and quick to act on:

• The calibration record with its certificates shows the corrected result next to the one it replaced.
• The auto-calculated due date stays anchored to the calibration date, not to the date the revision was issued.
• The possession audit trail (check-outs, permanent allocations, location history) turns "who used this set in the last three weeks" into a single search, not a reconstruction from memory.
• Configurable overdue and status blocking stops further check-outs once the record shows a fail. Whether that is a hard block or a soft warning is set per tenant.

The result is concrete. When the auditor asks what you did about the corrected certificate, the answer is one record: the original as received, the revision that superseded it, the block that changed, the four check-outs inside the window, and the impact assessment you closed.

Before your next supplier contract

Q4 is when many 2027 calibration-service contracts get renewed. If you are writing DCC delivery into those contracts, add one line: revised certificates must populate the revision number and the number of the first certificate issued, as DKD-E 0-2 provides. It costs the lab nothing, and it lets your software supersede the original record instead of guessing.

If you want to see how a reissued certificate shows up against an instrument’s history in PrüfDesk, we’re happy to walk through it with one of your own instruments.