XSD-Valid Isn’t Accepted: 3 DCC Validation Gates

The lab manager at a Tier-1 machining supplier put it plainly: "The file came in, the validator went green, and we nearly booked it against the wrong gauge block set." That is the trap of the first months with Digital Calibration Certificates. A green tick from the XSD validator feels like acceptance. It is not. It tells you the file is a well-formed DCC. It does not tell you the file is a trustworthy certificate for your instrument, fit to become your calibration record.

If a DCC is going to replace re-keying, something has to replace the person who used to read the PDF before typing. That something is a set of validation gates on ingest, and schema validation is only the first of them.

What XSD validation actually proves

The PTB DCC schema (v3.3.0 is the release most labs deploy today) defines the structure of a certificate: an administrative-data block with the issuing lab, the customer, the calibrated item and its identifications, and a measurement-results block whose quantities are expressed through the D-SI framework, with value, unit and expanded uncertainty as separate elements. Validating against the XSD confirms that the required elements are present, in the right order, with the right datatypes.

That is genuinely useful. It rejects truncated files, hand-edited XML and exports from tools that only approximate the schema. But consider what it cannot see:

• Who wrote it. An XML file that satisfies the schema can be produced by anyone with a text editor.
• Whether it was changed. Schema validity survives any edit that keeps the structure intact, including a changed deviation value.
• Which instrument it describes. The schema requires an identification element. It has no idea whether that identifier exists in your register.
• Whether the content is fit for purpose. A unit element is present; whether it is the unit you expect for that measurand, and whether every result you rely on carries an uncertainty, is outside the schema’s scope.

Machine-readable is not the same as machine-understood, and a valid structure is not an accepted record.

Gate 1: Structure and version

Validate against the schema version the file declares, not the one you assume. A DCC states its schemaVersion; your ingest should check it against the versions you actually support. Today that means v3.3.0. PTB has published v3.4.0-rc.1 for review, explicitly marked as a release candidate whose features may still change. A file built against a release candidate should not quietly flow into your calibration records. Route it to a person, with the reason stated.

Validate the embedded D-SI quantities as well. A result block that parses but carries a malformed unit expression is a structural failure, not a content question.

Gate 2: Integrity and origin

The point of a DCC over a PDF is that it can be verified. So verify it:

1. The signature is valid over the certificate content — any change after signing breaks it.
2. The signing certificate chains to a trust anchor you accept. A self-signed key proves only that someone owns a key.
3. The signer is the lab you contracted. A valid signature from an unexpected issuer is a finding, not a pass.
4. The verification result is recorded, with the time it was checked. Seal certificates expire long before a 10-year record retention period ends; the evidence that the signature was valid at receipt is what an auditor will ask for later.

A certificate that fails gate 2 has no business in your system of record, however clean its XML.

Gate 3: Fit for this record

This is the gate that replaces the engineer’s eye, and the one most often skipped. Gates 1 and 2 establish that the file is a genuine DCC. Gate 3 asks whether it is a usable certificate for this instrument, under your measurement-management system.

• Identity match. The item identifiers in the administrative data (serial number, your inventory number, typically carried with refTypes such as basic_serialNumber and basic_identificationNumber) must resolve to exactly one instrument in your register. Zero matches or two matches both stop the ingest.
• Structure match for sets. For gauge-block sets, DKD-E 4-3 notes that users usually label only the set, yet each block must remain uniquely assignable, and the set’s accuracy class is governed by its worst block. The DCC’s sub-items must reconcile with the blocks you hold.
• Expected measurands and units. A calibration procedure defines what should be measured. Results for an unexpected quantity, or a missing one, are a discrepancy.
• Uncertainty present for every result you will use in a conformity decision.
• As-found and as-left present where your procedure requires both. If the instrument was adjusted, the as-found value drives your impact assessment on product measured since the last calibration.
• Plausible dates. Calibration date on or before the issue date, and not earlier than the certificate already on file. A revision number signals a reissue, which must supersede, not overwrite.

A worked example

A 32-block steel gauge-block set returns from its external lab. The DCC arrives on time.

Gate 1: the file declares v3.3.0 and validates. Gate 2: the seal verifies, chains to the lab’s accredited signing certificate, and the issuer matches the purchase order. Under a "green tick" process, this certificate is now the record.

Gate 3 finds the problem. The set’s serial number matches. But one sub-item carries a block identifier that is not in the register: last spring a damaged 1.005 mm block was replaced, and the lab’s customer master data still lists the original. The certificate is authentic, intact and schema-valid. It is also, for one block, a certificate for a piece of steel you no longer own, while the block actually in the set has no calibration result at all.

Nobody would have caught that by looking at a green tick. A person reading a PDF might have. The gate must, because no person is reading anymore.

"The lab is accredited. Isn’t this their job?"

Partly. Under ISO/IEC 17025 the lab is responsible for the technical validity of what it reports. But accepting a certificate into your records is your decision. ISO 9001 clause 7.1.5 and ISO 10012 put metrological confirmation on the user: establishing that the instrument meets the requirements of its intended use, against your maximum permissible error, not the lab’s general statement. An accredited lab can issue a perfectly correct certificate for the wrong serial number your purchasing team sent it.

The second objection is that a manual review step defeats the purpose. It does not, if it is designed correctly. The gates clear the routine certificates without transcription; people see only the exceptions, with the failing check named.

Where the system of record fits

PrüfDesk is the system-of-record for your equipment, its calibration status and its evidence. It does not perform the calibration and it does not assign traceability to a national metrology institute; that comes from the lab and its accreditation. What it controls is what happens after the certificate arrives.

That is where the gates pay off. A DCC that clears all three becomes the instrument’s calibration record: pass/fail, as-found and as-left values queryable rather than buried in a file, certificate attached, next due date calculated from the interval. A DCC that fails stays in quarantine with its reason, and the instrument’s status does not change. If it is overdue, your tenant’s overdue setting, hard block or soft warning, stays in force until a valid record exists. The possession audit trail and the compliance report then show an auditor not only the certificate, but that it was checked before it was trusted.

Ingest checklist

• Declared schema version is one you support (v3.3.0 today; release candidates routed to review)
• XSD and D-SI validation pass
• Signature valid, chain trusted, issuer equals contracted lab
• Verification result and timestamp stored with the record
• Identifiers resolve to exactly one instrument; set sub-items reconcile
• Expected measurands, units and uncertainties present
• As-found / as-left present where the procedure requires them
• Dates plausible; revisions supersede, never overwrite
• Every failure quarantined with a named reason, instrument status unchanged

If you are writing DCC delivery into your 2027 calibration-service contracts this quarter, this list is also a useful acceptance test for your suppliers’ files. We are happy to walk through it against a sample DCC from your own lab.