Who Is ‘JS’? Mapping Calibration Initials to Real Users

Martina is three weeks into cleaning up her plant’s Access calibration database for migration. The equipment table is in reasonable shape. The due dates reconcile. Then she runs a distinct-values query on the PerformedBy column of tblCalHistory and gets 41 values for a lab that has never employed more than nine people.

JS, J.S., js, JSc, Jan, JS/MK, ext, Cal Lab, ?, and a blank on 212 rows.

There are two JS candidates: Jan Schreiber, who retired in 2021, and Julia Sommer, who joined in 2019 and still works there. Between 2019 and 2021 both of them were calibrating height gauges on the same surface plate. And in October an IATF 16949 surveillance auditor may pick any record from that period and ask who did the work, and whether that person was qualified to do it.

This article is about that column. It is usually the least-examined field in a legacy calibration database, and it is the one migration most often carries across unchanged.

Why the initials made sense at the time

The database was built for a small team, for a practical reason. Everyone knew everyone. Typing two letters into a text box was faster than keeping a users table, and nobody was going to fund user management for a tool IT didn’t officially support. When the lab was three people, JS was unambiguous.

The real problem is that a free-text field records what someone typed. It does not record who someone is. Nothing stopped a technician from typing a colleague’s initials, leaving the field blank, or writing ext for an outside lab without naming it. Nothing stopped anyone from editing the field later. Access has no built-in, tamper-evident record of who changed a row, so the value you see today may not be the value entered on the day of calibration.

Why auditors care about the name, not the initials

Several requirements depend on knowing who performed a calibration:

• ISO/IEC 17025 (clause 6.2) requires the lab to authorise personnel for specific activities and keep records of that authorisation and competence. A calibration record that can’t be tied to a person can’t be tied to an authorisation.
• IATF 16949 (7.1.5.2.1) requires calibration/verification records, and internal laboratories must have personnel competent for the scope. AS9100 has similar competence and record-retention expectations.
• ISO 9001 (7.1.5.2) needs measurement traceability to be maintained. If an as-found result was out of tolerance, you have to decide whether earlier product results are still valid, and that assessment often starts with who measured, with what, and how.
• Data-integrity principles (ALCOA+), which are increasingly used outside pharma, make "Attributable" the first letter: every entry traces to one identified individual. Shared or ambiguous identities are among the most frequently cited data-integrity findings in regulatory inspections.

An auditor seldom asks to see the PerformedBy column. They pick one torque wrench calibration from 2020 and ask to see the technician’s training record for torque calibration as of that date. If the record says JS and you have two candidates, you have a finding. You may also have a longer conversation about your other records.

The trap: migrating the ambiguity

The easy path is to import PerformedBy as text into a notes field and move on. It looks harmless, but it has a cost. The new system now shows the same ambiguous strings, only in cleaner formatting, and a modern interface makes old data look more trustworthy than it is.

The opposite mistake is just as serious. Someone does a bulk find-and-replace from JS to Julia Sommer because she’s the JS who still works there. You have now attributed Jan’s calibrations to someone who may not have been authorised for that instrument type at the time. That is worse than an ambiguous record, because it is a confidently wrong one.

The correct approach sits between those two: resolve what can be evidenced, preserve the original, and label what cannot be resolved.

A worked method: the attribution map

Treat the mapping as a controlled document, not a cleanup chore. Here is how it went in Martina’s case.

1. Extract every distinct value with its context

For each distinct PerformedBy string, pull the row count, the earliest and latest calibration date, and the equipment categories involved. JS split cleanly once dates were attached. Every JS row before March 2019 has to be Jan, because Julia hadn’t started. The overlap period, from March 2019 to Jan’s retirement in June 2021, is the only part that needs real investigation.

2. Resolve with evidence, not memory

For the overlap rows, look for corroborating sources: signed paper calibration sheets, certificate PDFs with a signature, shift rosters, training records showing who was authorised for which category. In Martina’s case, Julia wasn’t signed off on torque calibration until 2022. That settled every torque row in the overlap. The dimensional rows were resolved against the scanned calibration sheets.

Write down the evidence for each mapping decision: "JS 2019-03 to 2021-06, torque category → J. Schreiber; basis: training matrix rev. 7, J. Sommer torque authorisation dated 2022-02."

3. Classify what remains

Every legacy value ends in exactly one of these states:

• Resolved to a named person, with the evidence reference.
• Resolved to an external provider. ext and Cal Lab become the named accredited lab, confirmed against the certificate on file.
• Unresolved. The original string is kept verbatim and explicitly marked as not attributable from available evidence.

Martina finished with 11 unresolved rows out of roughly 6,800. Eight were for instruments already retired. That is an honest result. An auditor will accept a small, documented residue with a clear explanation much more readily than a suspiciously perfect dataset.

4. Keep the original value alongside the mapped one

Never overwrite the legacy string. Import it into a remarks or legacy-reference field next to the resolved person, and file the attribution map with your migration validation records. If someone asks in three years why a 2020 record names Jan, the answer is on file and doesn’t depend on anyone’s memory.

What changes after cutover

The mapping deals with the past. The bigger gain is that the problem stops recurring.

In PrüfDesk, the technician on a calibration record is a user account in your tenant, not a text box. By default, the person logging the calibration is recorded as the technician. Only a quality engineer or admin can log a calibration on someone else’s behalf, and that action is captured in the audit log. The technician has to be an active user with a technician-capable role. If you enable training prerequisites, the system checks the performing technician’s training for that equipment category before the record is accepted. The technician who performed a calibration cannot approve it, so each record carries two accountable names.

In practice, "who is JS?" becomes impossible to ask about any record created after go-live, because every record carries a unique identity rather than two typed letters. Together with auto-calculated due dates, certificates attached to the record, and audit-ready PDF compliance reports, the answer to the auditor’s question is one click away instead of an afternoon in the archive.

The objection: "It’s historical data, just import it as-is"

This is a reasonable position, and for some fields it’s the right one. You shouldn’t rewrite history to make it look tidier. But attribution isn’t cosmetic. It links a calibration record to a competence record, and so to your ability to defend a product-impact assessment. Importing it as-is is fine if you import it knowingly: original string preserved, resolution documented where evidence exists, gaps labelled. What isn’t fine is importing it silently and letting the new system present JS as if it meant something.

The effort is also bounded. Distinct values in a PerformedBy column usually number in the dozens, not thousands. Most resolve by date range alone. The investigation is concentrated in the overlap periods, which you can identify on day one.

Pre-migration checklist for the PerformedBy column

• [ ] Run a distinct-values query on every "who" field (PerformedBy, CheckedBy, ApprovedBy), with counts and date ranges.
• [ ] Build a staff timeline: start dates, leave dates, and authorisation dates per equipment category.
• [ ] Identify overlap periods where one string could mean two people.
• [ ] Map external-lab values to named providers and confirm against certificates.
• [ ] Document the evidence for every mapping decision.
• [ ] Keep the original legacy string verbatim alongside the resolved identity.
• [ ] Label unresolved rows explicitly, and count them.
• [ ] File the attribution map with your migration validation records.
• [ ] Before go-live, create every current technician as a named user with the correct role and training records.

Where to start

You don’t need to have chosen a system to start on this. The distinct-values query takes five minutes, and it will tell you whether you’re looking at nine names or forty-one. If it turns out to be forty-one, it’s better to find that out in a quiet week than in the opening meeting of your next audit.

When you’re ready to see how named technicians, training checks and approval separation look on your own equipment list, PrüfDesk’s team is happy to walk through it with your data.