The Manual No One Read And the Calibration Software No One Understood

How metrology inherited a documentation crisis, and what we are doing about it

There is a passage in Robert Pirsig's Zen and the Art of Motorcycle Maintenance that I keep coming back to. It is not the famous parts people quote about Quality or the ghost of rationality. It is a quieter observation, buried early in the book, about technical manuals:

"The typical technical writer... has the peculiar ability to be able to understand everything without actually understanding anything. The manual they write is an accurate reflection of their lack of care."

Pirsig is not criticizing the accuracy of the writing. He is criticizing its absence of soul. The manual may be technically correct in every particular, and still completely fail the person who needs it because it was written from a posture of detachment. It transferred information without transferring understanding. It documented a machine without illuminating the relationship between the machine and the person using it.

When I read that, I think about calibration procedures, SOPs, and calibration software, of course. I think about uncertainty budgets written in a font so small and a format so dense that the technician performing the calibration has effectively stopped reading them, yet is still required to sign that they have.

We have been writing manuals no one reads for a very long time.

How We Got Here

Metrology is a discipline built on rigor. On traceability. On reproducibility. These are not small things. They are the reason a kilogram in Kuala Lumpur is the same kilogram in Kansas City. The precision that metrology demands is genuine and earned.

But somewhere along the way, we confused rigor with impenetrability. We began to write our documentation not for the people who would use it, but for the auditor who would inspect it. The calibration procedure became a compliance artifact rather than a practical guide. The certificate became a legal record rather than a communication of measurement knowledge.

This is not a failure of intent. The people who wrote these documents cared deeply about accuracy. But they were writing for a system, an accreditation body, an ISO standard, a customer audit, and not for a human being standing at a workbench at 7:00 in the

Morning, trying to set up a Fluke 5522A for a calibration they perform three times a week.

Pirsig would recognize the pattern immediately. It is the classical mind, so committed to formal correctness that it has lost the romantic connection to lived experience. The document is valid. The document is useless.

The Calibration Software That Looked Like the Documents

Here is where it gets uncomfortable.

When calibration software came along, and this is true of virtually every legacy system in our industry, its designers did not rethink the model. They digitized it. They took the paper-based mental model of metrology documentation and mapped it directly onto a screen.

The result was software that looked like forms. Software with fields named after the rows of a calibration worksheet. Software that organized the world the way a metrology manager organized a filing cabinet, rather than the way a technician actually thinks through a calibration.

The user interface was not designed around a workflow. It was designed around a database schema. And so the metrologist who used it had to learn two things simultaneously: how to perform the calibration correctly, and how to navigate a system built on logic that was never explained to them.

We gave people software that required its own manual. Then we wrote that manual the same way we wrote everything else for compliance, not comprehension. The person in the middle, the working metrologist, was left to figure it out through training sessions, tribal knowledge, and a great deal of frustrated clicking.

This is not a small industry problem. This is why metrologists with 20 years of experience can be genuinely afraid of adopting new software. Not because they are not technically capable. But because every system they have ever used has treated them as data-entry operators rather than measurement professionals. It has trained them to expect disappointment.

What Breaking the Pattern Actually Requires

At Metquay, we found ourselves confronting this honestly when we began building. The temptation is always to start with what exists to look at how legacy systems work, to mirror their taxonomies, to build something familiar enough that migration feels manageable.

We chose not to do that. Not because familiar is wrong, but because familiar, in this case, means inheriting decades of accumulated workaround and compromise.

On the documentation side, this meant asking a question we did not see being asked elsewhere: What does a metrologist actually need to understand, at the moment they need to understand it? Not what an auditor needs to see. Not what does an ISO standard require us to record. What does the person doing the work need to know and in what form, at what point in the process, do they need to know it?

The answers changed what our user interfaces and documentations looks like. Procedures written in plain language, structured around the sequence of actions a technician actually takes, not the sequence that makes the document easiest to cross-reference. Context delivered at the point of need, not buried in an appendix. Uncertainty guidance is embedded in the workflow, not relegated to a separate calculation sheet opened in another window.

On the software side, the same question took a different form: What is the metrologist actually trying to accomplish, and how do we make the tool disappear? The best tool is the one you stop thinking about. A wrench you grip naturally. A gauge you read without squinting. Software that surfaces the right information at the right moment, asks only for what it genuinely needs, and then gets out of the way.

This is harder to build. It requires understanding not just the technical requirements of calibration, but also the cognitive experience of performing it, the moments of uncertainty, the places where someone is most likely to make a mistake, and the decisions that happen implicitly and need to be made explicit. It requires talking to metrologists not as users of a system, but as domain experts whose knowledge should be encoded into the design itself. It requires, in Pirsig's terms, care.

Metquay's Vision for the Future of Metrology

Metquay is a young company operating in a well-established industry with deep-seated traditions and considerable resistance to change. We acknowledge our own biases. Our design decisions are made to align with our users' needs, and we approach this deliberately.

We have chosen to treat the documentation problem and the software problem as the same problem because they are. Both are expressions of how an industry communicates knowledge. Both have historically prioritized the record over the reader. And both need a fundamental rethink, not a fresh coat of digital paint.

Pirsig's narrator, riding across America on a motorcycle he maintains with genuine care, distinguishes between two kinds of people: those who see a machine as something to be operated, and those who see it as something to be understood. The former follows instructions. The latter develops a relationship.

Calibration software and calibration documentation should help metrologists build a relationship with their instruments, processes, and measurement knowledge. Not just fill out the paperwork.

We think the industry is ready for that shift. We are betting on it.

Metquay is building calibration software designed around metrologists, not around legacy workflows. If that resonates with where your lab wants to go, we'd like to talk.

Connect with us at metquay.com →