Store DCC uncertainty as data, not a spreadsheet string
"± 0.3" is not the uncertainty. See what a PTB DCC really carries — k, coverage probability, distribution — and why to store it, not re-key it.
Store DCC uncertainty as data, not a spreadsheet string
A calibration certificate lands in the shared inbox as a PDF. The lab manager opens it, finds the results table, and copies the as-found value into column D of the equipment register. In column E goes the uncertainty, typed exactly as it reads on the page: ± 0.3. Next instrument, next PDF, next ± 0.3. By Friday there are forty rows like it, and every one of them has quietly thrown away most of what the calibration laboratory actually reported.
That ± 0.3 is not the uncertainty. It is a fragment of a sentence someone deleted the rest of.

What an uncertainty statement really contains
A defensible measurement uncertainty is not a single number. Following the GUM and the way accredited laboratories report under ISO/IEC 17025, a complete statement is a small structured object:
- the measurand and its measured value, with its unit;
- the expanded uncertainty U;
- the coverage factor k used to expand it;
- the coverage probability (typically ~95 %);
- the distribution assumed (usually normal).
Write U = 0.3 µm, k = 2, 95 %, normal and a metrologist can do real work with it: recover the standard uncertainty, re-expand it to a different probability, combine it with their own contributions, or apply a decision rule against a tolerance. Write ± 0.3 and none of that is possible. Is 0.3 the expanded or the standard uncertainty? At k = 1 or k = 2? At 95 % or 99 %? The string cannot answer, so the next person guesses — and a guessed coverage factor is a factor-of-two error in the very quantity your conformance decision depends on.
This is exactly the information a Digital Calibration Certificate is built to preserve.
How a DCC keeps the whole statement
A DCC is the same calibration certificate expressed as validated, signed XML against the PTB/EURAMET schema — the current release is v3.3.0. The schema deliberately splits the document into two parts: an administrative-data block (the item, its identifiers, the laboratory, dates, traceability to a national metrology institute) and a measurement-results block. The results are where the uncertainty lives, and it lives there as typed data, not prose.
That typing comes from the D-SI framework — the digital representation of the SI. Instead of a cell reading 0.3 µm, a D-SI quantity carries the numeric value, the unit as a machine-resolvable SI expression, and, alongside it, an explicit expanded-uncertainty element holding the coverage factor, the coverage probability and the distribution as separate, named fields. The value and its uncertainty travel together, each addressable on its own.
Because the file is XML, a receiving system reads those fields directly. Because it is digitally signed, the recipient can verify that the results have not changed since the laboratory issued them — the integrity your paper PDF never actually had. The distinction the industry keeps returning to at events like the 6th DCC Conference in February 2026 is not "is it digital" but "is the meaning preserved" — and structured uncertainty is one of the hardest, most valuable parts of that.

A worked example
Suppose a supplier calibrates a gauge block. As-found deviation: +0.2 µm. Expanded uncertainty: U = 0.3 µm at k = 2, 95 %, normal distribution. The block’s tolerance is ±0.5 µm.
Re-keyed as +0.2 (± 0.3), the record looks fine and is quietly useless for a conformance decision. To apply a decision rule under ISO/IEC 17025:2017 — say a guard band that protects a 95 % probability of conformity — you need U at its stated probability. With only ± 0.3 you cannot tell whether the result sits safely inside tolerance or in the guard band, because you do not know what 0.3 is the uncertainty of. In the DCC, the measured value, U, k, probability and distribution arrive as five distinct data points. The decision rule runs on data, not on a technician’s assumption about what the supplier meant.
The same holds for as-found/as-left. When both states are stored with their full uncertainty, drift between calibrations is a calculation. When they are strings in adjacent cells, drift is a story you retell each audit.
Where PrüfDesk fits — and where it does not
PrüfDesk is the system-of-record for your equipment, its calibration status, and the evidence behind it. It does not perform the physical calibration and it does not assign traceability — that remains the accredited laboratory’s and the NMI’s role. What it does is stop the information loss between their certificate and your register.
- Ingest without transcription. A supplier’s DCC populates the instrument’s calibration record directly — as-found and as-left values, and the full uncertainty statement (U, k, coverage probability, distribution) stored as fields, not a truncated string. Zero re-keying, zero
± 0.3. - Queryable, not buried. Every stored uncertainty is a field you can search, filter and report on. An auditor’s "show me the expanded uncertainty and coverage factor for this gauge at its last calibration" is one search, not a PDF hunt.
- Due dates stay yours. The DCC carries the calibration date and traceability; PrüfDesk auto-calculates the next due date under your interval policy and enforces overdue rules — hard block or soft warning per tenant.
- Structured evidence downstream. When your own customer wants machine-readable proof, the record exports as structured certificate data, not a flattened PDF.
This is the substance behind ISO 9001 clause 7.1.5 on measurement traceability and the measurement-management intent of ISO 10012: not just that an instrument was calibrated, but a complete, verifiable measurement result you can act on.

A short check before you accept the next certificate
- Does your record store U, k, coverage probability and distribution as separate fields?
- Can you recover the standard uncertainty without opening the original PDF?
- Can a decision rule read the uncertainty at its stated probability?
- Are as-found and as-left both stored with their uncertainty, so drift is a query?
- If a customer asked today, could you export the result as structured, verifiable data?
If any answer is "we’d have to check the PDF," the string in column E has already cost you the information.
The honest boundary
A DCC does not calibrate anything and neither does PrüfDesk. What changes is that the metrologist’s carefully expanded uncertainty survives the trip from the laboratory into your system intact — as data you can query, compare and defend — instead of collapsing into ± 0.3 the moment it reaches a spreadsheet.
If you want to see how a received DCC lands as a populated calibration record with its uncertainty stored field-by-field, that is worth a quiet look before your next audit.