Calibration Certificate Release¶
The Release tab on a calibration takes the certificate through a documented process: submit, decide, optionally seal. It replaces the plain "Release" action in the report dialog, which filed the report without a state and without a record.
The process is complete once the decision is made. The seal is an optional module; without it, the release works exactly as described.
The process¶
| Step | What happens |
|---|---|
| Submit for release | The selected report is rendered once, filed in the DMS and frozen. Its checksum (sha256) is shown on the request from then on. |
| Approve | An authorised person decides on that exact file, not on a fresh run against the current data. |
| Reject | Requires a reason. The request stays on record; after the correction a new one is submitted. |
| Withdraw | Takes an approved or sealed certificate out of circulation. Requires a reason. |
| Seal | Binds the approved file cryptographically to a laboratory certificate (PAdES). Optional, see below. |
Frozen means frozen
A record can change between looking at it and approving it. That is why the certificate is produced at submission and only copied afterwards. The Approved file button downloads exactly the file that was decided on.
What can stand in the way of a release¶
Before submission calServer checks the preconditions and lists each missing one separately, with a jump to where it is filled in:
- linked device
- assigned customer (from the calibration or from the device)
- calibration date
- technician
- certificate number
- at least one measurement row
The completion check in the next section adds to this list.
Two of these depend on the calibration's origin (see below): on an outsourced certificate the named performing laboratory takes the place of the technician, and the filed foreign certificate takes the place of a measurement row. In return, three checks apply there that an in-house calibration does not have.
The accreditation scope does not hold up the release. calServer derives it per measuring point from the annex in the quality specifications, and the completion check points out deviations (Accreditation scope); with an accreditation seal the explicit declaration of the deciding person stays (see below). And the outcome of a calibration is never a criterion: a certificate for a failed calibration is a valid certificate.
Origin: who did the measuring¶
Every calibration carries an origin. It decides what the release checks — the same calibration is released under different rules as an outsourced certificate than as an in-house one.
| Origin | When | Yardstick for the uncertainty |
|---|---|---|
| internal | the own laboratory measured | the own annex as a floor: a certificate must not claim more accuracy than the accreditation allows |
| subcontracted | we passed a customer order to an external laboratory | the annex of the subcontractor |
| external | the certificate was produced without us, we only document it | the annex of the performing laboratory |
| own traceability | our own reference standard was calibrated elsewhere | the own annex as a ceiling: a standard must not come back less accurate than what we ourselves claim |
A calibration without an entry is treated as internal. Existing data therefore behaves exactly as before.
For the three outsourced origins the field Performing laboratory (quality provision) takes the external laboratory's annex. It is both its identity and the yardstick for the uncertainty on its certificate — without it nothing is compared. Maintain it under Administration > Requirements > Quality provisions with owner "External laboratory".
What an outsourced certificate additionally requires:
| What is found | subcontracted | external | own traceability |
|---|---|---|---|
| foreign certificate not filed as a document | blocks | blocks | blocks |
| performing laboratory not named | blocks | notice | notice |
| laboratory's accreditation does not cover the calibration date | blocks | notice | notice |
| reference standards used | not required | not required | not required |
Subcontracting is stricter because we hold the customer order there and remain responsible for the subcontractor's competence under ISO/IEC 17025 (clause 6.6). For a certificate we merely file, that oversight is not ours — there it stays a notice.
Reference standards drop out for every outsourced certificate: the performing laboratory keeps them in its own system. The traceability evidence sits in the foreign certificate itself, and that is exactly what the check demands.
Where no validity of the accreditation is maintained, nothing is reported — an empty entry is not a statement.
Completion check¶
Above the submit block sits the completion check with three visibly separate areas. Each carries its state (checked, findings, notices, skipped), and every finding names the place where it is filled in.
| Area | Checks | State |
|---|---|---|
| Completeness | the six points above, plus the pass/fail decision, the reference standards used and half-filled measurement rows | active |
| Plausibility | contradictions between the decision and the rows, unknown SI prefixes, magnitudes, dates, ambient conditions | active |
| Specification coverage | whether the calibration covers the test points of the chosen option and every point has a yardstick | active |
Additions to completeness compared with the list above:
- Pass/fail decision. A statement is required, not a positive result. A certificate for a failed calibration stays valid.
- Reference standards. Only when at least one measurement row carries numbers. A purely visual or functional check needs no standard.
- Conformity statement without measurement uncertainty. A captured point with a verdict for which no standard supplied a measurement uncertainty blocks; the finding names the reason per row (such as “Keine Zeile in … für 50 V”). Under Rules › Measurement uncertainty it becomes a notice. Points computed with the stand-in from an uncertainty model are always listed as a notice (Measurement uncertainty per GUM). Once the specification, the standard or the stand-in is added, Recalculate measurement uncertainty at the finding recomputes these points from the stored readings, without measuring again and only before release (Recalculating without measuring again).
- Decision rule. A verdict by another rule or another guard band than the calibration's blocks; own conformity texts next to a rule other than the non-binary one are a notice (Decision rule).
- Accreditation scope. Notices when the annex says something different today for points than was frozen at capture, or when points carry their statement without origin (Accreditation scope).
The next calibration date is a notice and holds nothing up: not every certificate carries a due date.
The plausibility area looks for contradictions rather than gaps:
| What is flagged | Effect |
|---|---|
| A row with numbers that nobody decided on | blocks |
| Head says "passed" but a row is out of limits (or the other way round) | blocks |
An SI prefix the catalogue does not know (K instead of k) |
blocks |
| Calibration date in the future, due date before the calibration | blocks |
| Deviation beyond ten times the tolerance | notice |
| Due date beyond the interval recommended by the chosen option | notice |
| Temperature, humidity or pressure outside the physically sensible range | notice |
| uncertainty below the performing laboratory's smallest specifiable one | notice |
| uncertainty above the own smallest specifiable one (own traceability only) | notice |
Three things the area deliberately does not flag:
- Missing limits. A measurement without a tolerance is a recorded value, not a contradiction. Whether it is a defect is up to specification coverage.
- The guard-band case. If the head says "passed" while a row sits in the guard band, a human judged it under the laboratory's decision rule. That is a technical decision, not a contradiction.
- A due date on the calibration day. It may be an unfilled default or a deliberate "no interval". Only a due date before the calibration is unambiguously wrong.
On the interval: the yardstick is the recommended interval of the option the calibration chose, and nothing is flagged up to the end of that month — putting due dates on the last day of a month is ordinary planning. Calibrating more often than recommended is never a finding; what applies is the laboratory's call based on how the device is used, hence a notice and not a block.
Specification coverage¶
The third area checks the calibration against the one option it chose (see Specifications). Test points are the point rows of that option; bands only give a tolerance and require no point. Rows of other options are neither required nor a yardstick.
The area shows specification, revision and option, whether it is maintained on the device or on the device type, and coverage as "n of m test points".
| What is flagged | Effect |
|---|---|
| No option of the specification chosen | blocks |
| Choice changed after the plan was loaded, plan not reloaded | blocks |
| Test point of the option not measured | blocks |
| Test point measured but without a verdict (no tolerance) | blocks |
| Points without a tolerance when the certificate states conformity | blocks |
| Points without a tolerance on a measurement-only certificate | notice |
| Points with a tolerance from the test plan instead of the specification | notice |
| Chosen revision withdrawn since | notice |
Matching uses the row that was frozen when the plan was loaded, not values. Only points whose tolerance comes from the plan carry no row; they are found by function, unit and value.
No tolerance, no verdict. A point for which the lookup finds no row or several rows stays without passed or failed, instead of being judged against the nominal value or the first row. Measurement capture shows the reason before the reading.
A tolerance in the plan is a different yardstick. It wins when the plan is loaded, the certificate marks the points, and the completion check reports them as a notice so nobody mistakes them for the specification.
Measuring more than required is not a defect. Rows without a test point only appear as a counter.
If no released specification applies to the device, the plan is the only yardstick; the area then only reports points without a tolerance.
Switching areas off¶
Prüfung einstellen switches any area off for a device. That requires
the "configure completion check" permission (completion_check_edit) and a
reason — without one nothing is saved. Until 09/2026 this hung on "decide
release"; it is a permission of its own since, because switching areas on and
off sets the yardstick every further certificate is judged by, which is a
different decision from approving a single one. The setting applies to every further certificate
of the same device.
What applies is resolved bottom-up: device, else device type, else the factory default (everything on). Levels are not mixed; if the device carries a setting, it applies alone. Where the effective setting comes from is stated above the areas.
Skipped does not mean passed
A switched-off area is not computed. It stays visible, shows its reason, and on submission its state and reason go into the log — so it is later traceable under which rule a certificate came about.
The check runs on submission, not on approval: the decision is about the frozen file, and a second run would work against data that has since changed. The approver therefore reads the report from the log.
Details: concept "Abschlussprüfung des Kalibrierscheins" under Development.
Four-eyes principle¶
By default a different person decides than the one who submitted. The
switch is called enable_release_four_eyes and is on by default — a laboratory
that does not want the separation turns it off deliberately.
The two switches of the release module¶
Two values govern the module as a whole. Both are on out of the box, even when they are set nowhere:
| Switch | Effect when off |
|---|---|
enable_release_four_eyes |
Whoever submits may also approve |
enable_release_completion_check |
The completion check is dropped; all three areas count as skipped |
No screen yet
These two switches have no UI so far — the feature flag admin carries
only grid and report engine values. They are therefore set directly in the
property table, category features, subcategory release_workflow. That
is an open gap, not a decision.
Permissions:
| Permission | Allows |
|---|---|
calibration_view |
View the request and its log |
calibration_edit |
Submit for release, withdraw |
release_request_decide |
Approve and reject |
completion_check_view |
View the completion check and its areas |
completion_check_edit |
Switch check areas on and off |
seal_edit |
Seal |
The log¶
Every step creates an entry with a consecutive number, timestamp, person (the name as of the event), reason and the checksum of the file it refers to. Entries are append-only; there is no way to change or delete them, neither in the UI nor through the API.
What the chain proves — and what it does not
Every entry carries the hash of its predecessor, so a later change to a single entry becomes visible, and a gap in the numbering is reported explicitly. Proof towards third parties only comes with an external timestamp on the topmost hash. Without it the honest statement is: internally consistent and tamper-evident.
Sealing (optional)¶
A seal proves to third parties that the file comes from this laboratory and has not been altered since. For each credential the seal dialog states:
- Level — B-B (who), B-T (also when), B-LT (also verifiable long-term)
- Where the key lives — key file on the server, device (card or HSM), or remote sealing at a trust service provider
- What the seal is worth — self-declared, CA-issued, qualified certificate, or qualified
The word „qualified" is not for casual use
Only a credential whose certificate carries the corresponding statements and whose key is not exportable is called qualified. A company seal is a company seal — in the UI, in the log and in the API.
Failed attempts stay on the list. One case is called out separately: if the trust service provider does not answer, it is not established whether a signature was created. calServer reports this as "sealing outcome unclear" and explicitly advises against repeating until the provider has been checked — a second run would otherwise create, and usually be charged for, a second signature over the same document.
Accreditation scope¶
If a seal rule assigns an accreditation seal, the release additionally requires an explicit declaration by the deciding person that the calibration lies within the laboratory's accreditation scope. Wording and person are recorded in the log.
Why still a declaration
calServer derives per measuring point from the annex in the quality specifications whether it lies within the accreditation scope, and the certificate marks points outside with "*" (Accreditation scope). Whether the calibration may carry the seal still is a decision: if two quantities share unit and range, the annex cannot tell them apart, and not every laboratory maintains its annex. The declaration states what is true: a human decided, and it is traceable who. Its hint text names the comparison with the annex.
Earlier requests¶
Rejected, withdrawn and superseded requests stay visible. As long as a certificate is approved or sealed, no second request can run alongside it — withdraw first, then submit again. Otherwise there would be two requests both claiming to be the valid one.
This is not the handwritten signature
The signature captured in the report dialog is an image stamped into the PDF (see Reports). It is exchangeable and not cryptographically protected. The proof towards third parties is the seal in this process.