Preserving Calibration While Replacing Storage: Prove the Export Belongs to This Unit

Preserve calibration as a unit-bound service artifact, not as an anonymous file copied from the nearest working board. Before storage replacement, establish which physical unit and calibrated assembly produced the data. Before any later import, independently identify the destination and compare that identity with the protected export record.

This guide defines a read-only export and import-preflight contract. It uses Linux 6.12 NVMEM as an access example and RFC 9124 as a firmware-metadata design reference. The proposed service schema is original, not a calibration standard. No target reads, transfers or calibration writes were performed.

1. Separate unit identity from product compatibility

Two devices can share a model, hardware revision and firmware while requiring different calibration. A matching product label therefore answers only part of the transfer question. A filename such as “controller-backup” proves even less.

RFC 9124’s Class ID groups devices by firmware compatibility. That is useful context, but it is not a unique physical-unit identity. This service workflow requires both a supported hardware/format combination and an independently established match to the intended unit.

Record the authoritative identity source before removing storage. It might be an approved manufacturing record linked to a board identifier, provided the product’s service policy establishes that relationship. Do not invent a universally trustworthy serial-number location. If identity exists only in the component being replaced, resolve that limitation before replacement rather than trusting whichever backup is selected afterward.

2. Define an allowlisted export

The NVMEM documentation provides named-cell access as well as a raw device interface. Having raw access does not make the whole region suitable for a service archive. Use a reviewed allowlist of nonsecret calibration fields and approved identity references.

Exclude credentials, private keys and unrelated provisioning data. Do not dump an entire EEPROM or fuse region merely because the calibration shares that provider. Determine the allowed representation of each selected cell, including any layout post-processing, so a later tool does not mistake transformed consumer bytes for raw storage bytes.

Export record field	Required interpretation
Record schema and tool revision.	How to parse the record and reproduce its acquisition.
Source unit identity and evidence reference.	Which physical unit was independently identified.
Calibrated assembly identity and hardware variant.	Which sensor or analog chain the coefficients describe.
Calibration format, generation and approved reader versions.	How the payload is interpreted and whether it is current.
Allowed field inventory and exact byte counts.	What was deliberately collected, with no implicit extra regions.
Payload digests and acquisition status.	Which exact bytes were read successfully.
Controlled service-record reference.	Where authority, provenance and destination scope are established.

Specify how identity strings are encoded and compared. Reject unexpected whitespace, truncation or ambiguous aliases according to the approved identifier format; do not normalize two different identifiers into one because they look similar.

3. Make acquisition completeness explicit

Read only the approved cells using the qualified service interface. Check every result and returned length. A partial or failed acquisition must remain visibly incomplete; do not pad missing bytes, reuse an old buffer, or silently substitute factory defaults.

If multiple cells can change during acquisition, use the product’s supported snapshot or maintenance mechanism. Otherwise prove that the relevant data remains immutable throughout the read. Two separately successful reads do not establish that their values belong to one calibration generation.

Record whether the export contains raw provider bytes or the consumer representation. Keep decoding, unit binding and transfer authorization as separate checks. A payload that decodes to plausible coefficients can still belong to another unit.

4. Protect provenance as well as bytes

A digest detects a change relative to a trusted expected digest. It does not establish which board supplied the data, who approved its use, or whether a newer calibration exists. An attacker or mistaken operator can pair the wrong payload with its perfectly correct hash.

RFC 9124 sections 3.13–3.15 distinguish payload digests, sizes and the signature protecting manifest metadata. Apply the relevant principle through the existing approved service process: bind the identity, format, generation and payload digest together, rather than protecting the payload while leaving its unit label editable.

This article does not define a signing infrastructure or create keys. Where authenticated records are required, use the product’s established trust and verification policy. Otherwise state the controlled process and its assurance limits; a self-written label is not cryptographic proof of origin.

5. Run a read-only destination preflight

1. Identify the destination through the approved independent source, not through the selected export itself.
2. Check the service authorization names that destination and permits the intended calibration operation.
3. Verify the record’s provenance protection and exact payload size/digest.
4. Compare unit identity, hardware variant and calibrated assembly identity.
5. Validate the format, supported reader version and calibration-generation policy.
6. Confirm that the artifact cannot change between preflight and the separately authorized application step.

Return a decision record containing each comparison and its evidence. “Preflight accepted” means the package passed these checks; it does not mean calibration has been applied, verified physically or approved for production operation.

Observation	Decision
Correct digest, different unit.	Reject the transfer.
Same unit, sensor or analog assembly replaced.	Hold for the calibration owner’s applicability decision or recalibration.
Unknown identity, incomplete read or untrusted provenance.	Hold; do not infer a match.
Unsupported format or stale generation.	Require the approved migration or generation policy.
All preflight gates satisfied.	Eligible for the separately authorized service procedure.

6. Qualify the workflow with swapped fixtures

Create synthetic exports for two different units of the same hardware variant, each with internally valid lengths and digests. Deliberately select unit B’s export for unit A and require rejection. Also test a changed assembly, truncated payload, edited identity, unsupported format, stale generation and an artifact modified after preflight.

These are proposed qualification cases, not executed results. After any separately authorized application, the product’s procedure still needs appropriate readback and functional calibration verification. Byte equality alone cannot establish that the physical measurement chain is calibrated.

Hypothetical service mix-up

Two identical controllers arrive together for storage replacement. Both archives pass their digest checks, but the technician selects B’s archive while servicing A. The independent destination identity comparison blocks the operation before any write.

The useful deliverable is the unit-bound record and its explicit rejection evidence. Preserve the original approved export, keep secrets outside the package, and treat uncertainty as a service hold rather than borrowing another unit’s coefficients.