Inside a DCC: the anatomy of the PTB v3.3.0 schema, block by block

Every quarter it comes back. A batch of supplier certificates lands in the shared inbox as PDFs, and someone on the team — often the person who can least spare the afternoon — opens them one at a time and types the numbers into a spreadsheet. Instrument ID here, as-found value there, as-left in the next column, expanded uncertainty if there’s room, the reference standard’s own certificate number in a note nobody will read again. A lab manager running twelve hundred instruments knows exactly how this ends: a transposed digit in a cell, a due date calculated from the wrong date, and an auditor who wants to see the traceability behind a torque wrench you can’t immediately produce.

The Digital Calibration Certificate exists to end that transcription step. But "it’s an XML file" is not an explanation you can act on. If you’re going to trust a DCC as your calibration record — and eventually issue your own — you need to know what is actually inside one. So here is the PTB/EURAMET DCC schema, current release v3.3.0, taken apart block by block.

A DCC is not a PDF with metadata bolted on

First, the boundary that trips people up. A DCC is not a PDF that happens to carry some tags, and it is not a scan. It is a structured XML document defined by an XML schema (XSD) that the Physikalisch-Technische Bundesanstalt (PTB) develops with EURAMET. The schema dictates which elements must appear, in what order, and what kind of value each may hold. A file either validates against the v3.3.0 schema or it does not — there is no "mostly correct" DCC, the way there is a mostly-correct spreadsheet. That strictness is the point: a validating file can be ingested by any conforming system without a human deciding what each field means.

The root element, digitalCalibrationCertificate, carries the schema version so a receiving system knows exactly which rules to apply. Underneath it, the document divides into two halves that mirror how a metrologist already thinks: the administrative data, and the measurement results.

Half one: administrative data — who, what, when, and by whom

The administrativeData block holds everything that isn’t a measured number. Its mandatory child, coreData, is the certificate’s identity: the unique certificate identifier, the country code of the authorising body, the languages used, the date the item was received, and the begin/end dates and location of the calibration. These are the fields that a spreadsheet either omits or scatters across three tabs, and they are exactly the fields a due-date calculation depends on.

Then come the structured blocks:

• items — the calibrated object itself: name, manufacturer, model, and one or more identifications such as the serial number. This is what lets a system match the certificate to the right instrument in your catalog rather than a human eyeballing a serial.
• calibrationLaboratory — the lab that performed the work, with contact data.
• respPersons — the responsible persons who stand behind the result.
• customer — who the calibration was for.
• statements — an optional block for declarations such as a conformity statement against a tolerance, or the decision rule applied.

Note the division of labour. The administrative half tells you whose result this is and which instrument it belongs to. It does not, on its own, tell you whether the instrument passed.

Half two: measurement results — the numbers that used to live in cell C14

The measurementResults block is where the value your spreadsheet reduced to a single cell finally gets room to exist properly. It contains one or more measurementResult elements, and each can declare its usedMethods, usedSoftware, influenceConditions (the temperature and humidity the measurement was made under), and — critically — measuringEquipments: the reference standards used, which is where the calibration’s traceability chain is recorded.

The actual data sits inside results, structured as lists of quantities rather than free text. This is where as-found and as-left values live as machine-readable numbers, each with its unit and its uncertainty attached, not as prose a human has to parse. When we say a DCC keeps the as-found value "queryable," this is the literal reason: it is an addressable element in a defined tree, not text buried in a rendered paragraph.

D-SI: units and uncertainty carried as data

A number without a unit is a rumour, and this is where the DCC leans on the digital SI framework, D-SI. Instead of writing "12.001 mm" as a string that a downstream system has to guess at, D-SI encodes the value, the unit, and the uncertainty as separate, defined elements: a real value, a unit expressed in a formal SI notation (so a micrometre is unambiguous and machine-comparable), and an expanded uncertainty with its coverage factor and coverage probability. A receiving system can therefore compare a result against a tolerance, or convert units, without ever interpreting human text. Uncertainty stops being a footnote and becomes a first-class field — which is the whole reason metrologists cared about DCCs in the first place.

The signature: why you can trust a file you didn’t type

The last piece is integrity. A DCC is meant to be sealed with a digital signature (an XML signature, in practice following the XAdES profile), which binds the content to the issuer and makes any later change detectable. Alter a single digit after signing and validation fails. That is the property a spreadsheet fundamentally cannot offer: a signed DCC is tamper-evident in a way an editable cell never is, which is what lets an auditor accept it as evidence rather than as your team’s retyping of someone else’s evidence.

Mandatory vs optional: a quick validity checklist

A valid v3.3.0 DCC must carry, at minimum:

• a schema version and a unique certificate identifier;
• coreData with dates, languages, and authorising country;
• the calibrated items with identifications;
• the calibrationLaboratory and respPersons;
• measurementResults with the results expressed as D-SI quantities.

Optional but valuable: statements (conformity/decision rule), influenceConditions, usedMethods, and human-readable comment blocks. Treat the optional blocks as the difference between a file that merely validates and one that is genuinely useful downstream.

Where PrüfDesk fits — and where it does not

Here is the honest boundary. PrüfDesk does not perform the physical calibration, and it does not assign traceability to a national metrology institute — that is the accredited lab’s and the NMI’s role, recorded inside the measuringEquipments and respPersons blocks. PrüfDesk is the system-of-record for your equipment, its calibration status, and its evidence.

What that means in practice, mapped to the schema above:

• Ingest without re-keying. When a supplier’s DCC arrives, PrüfDesk reads the items identification to match it to the right instrument in your catalog, and pulls the as-found/as-left values and their uncertainties from measurementResults straight into that instrument’s calibration record — zero transcription errors, because no human retyped anything.
• Auto-calculate the next due date. From the performance dates in coreData, the next calibration due date is computed against that instrument’s interval, so nothing slips overdue because someone read the wrong column.
• Keep traceability one search away. The reference standards from measuringEquipments and the certificate identifier stay attached to the instrument, so at audit the traceability behind any given gauge is a search, not an archaeology dig through PDFs.
• Export structured evidence downstream. When your customer wants machine-readable proof, PrüfDesk can issue the calibration record as structured certificate data rather than a flat PDF they’ll only have to re-key themselves.

"But none of our suppliers issue DCCs yet"

The most common and most reasonable objection. Adoption is uneven, and most certificates still arrive as PDFs. That doesn’t make the schema academic. Knowing the anatomy lets you do two useful things now: recognise which of your suppliers’ processes already produce the structured data a DCC needs, and structure your own records so that when you receive — or issue — a DCC, the fields map cleanly. The point of ISO 9001 clause 7.1.5 and ISO 10012 is that your measurement evidence is controlled and available; ISO/IEC 17025 raises that bar for accredited labs. A file whose every field is defined, validated, and signed is simply the strongest form of that evidence. The teams who understand the blocks today are the ones who won’t be re-keying tomorrow.

Where to start

You don’t need every supplier on DCC to benefit from thinking in DCC. Pick one instrument family — say your torque wrenches — and look at how their certificates map to the blocks above: which fields you’re currently retyping, and where the as-found value disappears into a PDF. If you’d like to see how PrüfDesk ingests a DCC into an instrument record without transcription, and keeps the as-found value and its traceability queryable at audit, that’s a good place to start a conversation.