Cell C14 vs a signed DCC: tamper-evidence your auditor will accept

Your lab manager opens the master calibration workbook and scrolls to a micrometer that came back from the supplier last month. Row 214. The as-found value in cell C14 reads 25.010 mm. The supplier’s PDF, filed in a folder three clicks away, says 25.001 mm. Someone transposed two digits during re-keying, and there is no way to know when, no way to know who, and no signature anywhere that says the number in the cell is the number the calibration produced. At the next surveillance audit, that spreadsheet is your evidence. It is also completely unverifiable.

This is the quiet weakness in the paper-to-spreadsheet workflow that most quality teams still run. The certificate arrives as a PDF. A technician reads the as-found and as-left values, the tolerance, the measurement uncertainty, and types them into a shared sheet. From that moment the structured measurement result exists in two disconnected places — a document nobody queries and a cell anybody can edit — and neither one can prove it was not altered.

What the spreadsheet cannot do

A spreadsheet cell has no version, no author, no timestamp you can trust, and no integrity check. Turn on change tracking and you record edits made through the UI — but the underlying file is still a document any holder can open, alter, and re-save with the modification date reset. There is nothing cryptographic binding the value 25.001 to the calibration event that produced it.

ISO/IEC 17025 expects calibration results to be traceable and their integrity protected. ISO 9001:2015 clause 7.1.5 requires that monitoring and measuring resources be suitable and that the basis used for calibration be retained as documented information; ISO 10012 frames the wider measurement-management system around the same principle. None of these standards forbid a spreadsheet outright — but they do put the burden on you to demonstrate the record is what it claims to be. With a re-keyed cell, you cannot. The moment an assessor asks "how do you know this value was not changed after entry?", the honest answer is that you do not.

What a signed DCC actually is

A Digital Calibration Certificate is the same information a PDF carries, expressed as validated, machine-readable XML. The current stable schema is the PTB/EURAMET DCC release v3.3.0. Its structure is deliberate: an administrative-data section (who calibrated the item, the instrument identity, dates, the responsible person) is kept separate from the measurement-results section (the actual as-found and as-left values, tolerances and uncertainties). That separation is what lets a system read the results without parsing prose.

Inside the results, values are not free text. The D-SI framework — the digital SI, now at v2.2.1 and grounded in the VIM, the GUM and CODATA constants — represents each quantity as an explicit value, unit and uncertainty that a machine reads unambiguously. "25.001 mm ± 0.002 mm" stops being a string a human retypes and becomes structured data a system ingests.

Then comes the part the spreadsheet can never match: the whole XML is sealed with a digital signature, typically XAdES. Change a single character — one digit in one uncertainty — and the signature no longer verifies. The certificate is tamper-evident by construction. In Germany, DAkkS went further: since 15 July 2025 it replaced handwritten signatures on accredited certificates with digital seals and a digital accreditation symbol, so the accreditation mark you used to eyeball on a scan is now itself cryptographically checkable.

The same micrometer, done the other way

Take that returned micrometer again. The supplier issues a signed DCC. Your system-of-record ingests the file, verifies the signature before it trusts anything, and populates the instrument’s calibration record directly from the XML — the as-found 25.001 mm, the as-left, the tolerance, the uncertainty, the traceability statement, all placed as structured fields. No technician reads a PDF. No one types into C14. The transposed digit that started this article cannot occur, because there is no transcription step in which to make it.

The as-found value is now a queryable field, not a number buried in a document. When an engineer asks "which gauges came back near their tolerance limit last quarter?", that is a query, not an afternoon of opening PDFs. The next calibration due date is calculated from the certificate date the moment the record is created. And the signed XML stays attached as the authoritative evidence, so at audit the certificate behind the value is one search away and provably unaltered.

This is exactly the seam a platform like PrüfDesk sits in. It is the system-of-record that registers the instrument, ingests and verifies the DCC, keeps as-found/as-left and traceability queryable, auto-calculates the due date, and can export structured evidence downstream to a customer who no longer accepts scans. To be precise about the boundary: PrüfDesk does not perform the physical calibration and does not assign traceability to a national metrology institute — that remains the accredited lab’s role. PrüfDesk manages the equipment, the calibration status, and the integrity of the evidence around it.

"But our auditor accepts the spreadsheet today"

They probably do — today. That is an argument about what has been challenged so far, not about what the record can prove. The direction of travel is clear: accreditation bodies are issuing digitally sealed certificates, OEM customers are beginning to ask for machine-readable evidence, and the schema is maturing (v3.3.0 stable, v3.4.0 in release-candidate testing). The realistic near-term state is a mixed inbox — some suppliers still on PDF, some issuing DCCs in different schema versions. You do not have to abandon the spreadsheet on a fixed date. You do need a system-of-record that can accept a signed DCC when one arrives and verify it, so that the strongest evidence you receive is not immediately downgraded to a hand-typed cell.

A short readiness check

• Can you name, right now, who entered the last as-found value in your master sheet and when?
• If a value in that sheet were changed today, would anything flag it?
• When a supplier sends a DCC in v3.3.0, can your system ingest it without a technician re-keying?
• Is the signed certificate stored as the authoritative record, or is the spreadsheet the record and the file just an attachment?
• At audit, is the evidence behind any given calibration value one search away — and provably unaltered?

If those questions are uncomfortable, the gap is not in your metrology. It is in the layer between the certificate and the record. If you would like to see how PrüfDesk ingests a signed DCC and keeps the as-found value queryable and verifiable, that is a short, concrete conversation to have.