In short
I spent fourteen years in industrial quality before writing a single line of software. What I learned there has nothing to do with a material or a process: it has to do with what happens when a part is rejected, when an instrument hasn't been calibrated, when the customer asks for a documentation package and nobody knows where it is.
Those situations are the same in a machine shop, a sawmill, a welding shop or a window plant. Here are the seven principles that follow from them, and on which everything we build rests.
Why state principles rather than features
A feature list says nothing. Every quality software package handles non-conformities, documents and calibrations — the same way every word processor handles bold and italic. What separates two tools is not what they do, it's what their authors believe.
Believing that a shop should adapt to the software, or the reverse. Believing that a system can declare conformity on its own, or that a human must always sign. Believing that quality is a department, or that it's a daily practice carried by people who already have another job. Those convictions don't show up on a comparison page. They show up in the thousand small trade-offs that make a tool save you time or cost you time.
So they may as well be written down.
1. We start from a shop-floor irritant, not a technology
The first software we built didn't come from watching technology trends. It came from an ordinary observation: in a small manufacturing company, the person inspecting parts spends a considerable share of the day retyping. Retyping the characteristics to be checked from a drawing or a specification. Retyping measured values into a table. Retyping all of it into a document presentable to the customer.
Nobody pays for retyping. The customer pays for a conforming part and for the proof that it conforms. Every minute spent in between is absorbed by the company.
That starting point has a practical consequence: we never begin by asking which features someone would like. We ask what kept them late last week. The answer is almost always an administrative task born of a legitimate requirement — and that's where there is something to do.
Software that doesn't remove a task you hate isn't an investment. It's one more task.
2. Quality means producing the proof
There are two ways to read a quality management standard. The first: an obstacle to clear every three years, dealt with six weeks before the audit. The second: a system that requires, every day, that you be able to demonstrate what you claim.
The first reading produces binders. The second produces companies that know where they stand.
In practice the difference comes down to one question asked cold, on a Tuesday morning: can you demonstrate that this part, this lot, this structure was inspected, by whom, with which instrument, and that the instrument was valid that day? If the answer takes half a day of digging, the system exists on paper but not in fact.
That's why everything we build produces proof alongside the work, never afterwards. An inspection entered generates its own record. An instrument used is tied to its calibration certificate. A non-conformity closes with a verification of effectiveness. Not because an auditor will ask, but because reconstructing after the fact costs ten times more than recording in the moment — and yields a less reliable result.
3. Automation proposes, the human decides
We use automated recognition to read technical documents, and we measure what it delivers: across more than four hundred real files, the vast majority of characteristics is extracted correctly. That's a considerable gain. It is not a reason to hand it the decision.
The rule we impose on ourselves is absolute and admits no exception: a system may propose, only a human declares conformity. Extraction proposes a list of points to check; the inspector validates it. Analysis flags a drift; the manager decides. The signature at the bottom of a file commits a person, and that person must have seen what they are signing.
This position isn't commercial caution, it's a matter of accountability. When a non-conforming part reaches a customer, the software doesn't answer the phone. A tool that suggests otherwise is selling a peace of mind it cannot guarantee.
It carries a less obvious corollary: verification must be fast. A system producing a result that takes a human twenty minutes to check has automated nothing, it has moved the work. The right measure isn't the machine's success rate — it's how long it takes to supervise it.
4. One ecosystem, not silos
In most small manufacturers, the same information is entered three or four times. The order number lives in the management system, gets retyped onto the inspection sheet, then into the package sent to the customer, then into the non-conformity log. Every re-entry is a chance to make a mistake, and every discrepancy between two versions eventually becomes a problem.
The usual reflex is to add one more specialised tool that fixes a symptom and creates another silo. We chose the opposite: several distinct applications, each good at one thing, sharing a single source of truth. The work order is entered once. The instrument used for an inspection is the same object as the one in the calibration register. The non-conformity raised on a part is tied to the process that produced it.
Data that exists in three copies doesn't exist. It's waiting for you.
This is the most expensive principle for us to hold, and the most invisible to you. It appears nowhere in a demonstration. It shows up six months later, the day you look for a piece of information and it's simply there, consistent, without anyone having had to maintain it.
5. A quality system moves from reactive to in control
No company goes from disorder to control by installing a tool. What exists is a trajectory, and it has recognisable stages.
At the start, you absorb: problems are discovered at the customer's, and each is treated as an isolated case. Then you record: deviations are logged, you can count them. Then you analyse: each deviation is tied to a cause and a process, recurrences become visible. Finally you anticipate: you act on risks before they materialise.
The most profitable step of all is the first — moving from absorbing to recording. It requires neither a hire nor a sophisticated tool. It requires that deviations be logged as they occur, and that someone look at them every week.
We design accordingly: a tool must be useful at the stage you're actually at, not only at the end. A company that is learning to log its deviations doesn't need advanced risk analysis, it needs raising a deviation from the floor to take thirty seconds. The rest will come, and the tool must be there when it does — but it must never be a condition of entry.
6. Built for the small manufacturer, not merely scaled down
Large quality management systems are designed for organisations with a full quality department: a manager, engineers, internal auditors, someone whose job is to keep the system running. Sold to a thirty-person company, they are technically functional and humanly unusable.
In a company of thirty, quality rests on two or three individuals who already have another job. The quality manager is often also the shop supervisor, sometimes the owner. Nobody has half a day a week to spend feeding a system.
That constraint shapes everything, and we treat it as a choice rather than a limitation. It rules out configuration that requires a consultant. It rules out modules you must fill in before the rest will work. It requires every screen to answer the question "what does this save me from doing?". A feature that can't answer doesn't deserve to exist, however elegant.
It also requires something rarer: accepting that a company may use a quarter of what we offer, and that this is perfectly fine.
7. Your data stays in Canada
A manufacturer's drawings, specifications and quality records are among its most sensitive assets. They describe what it produces, for whom, to what tolerances. In some sectors they are covered by confidentiality commitments that the holder passes straight down to suppliers — and software is a supplier.
We host everything in Canada, in the Montreal region: databases, files, processing. This isn't a regulatory checkbox, even though Quebec's privacy legislation makes the question unavoidable. It is first a business decision: knowing where your documents are, and under which jurisdiction they fall, is part of what you must be able to answer to your own customer.
It is the only one of the seven principles that rests on an infrastructure choice rather than a conviction about the trade. We include it anyway, because it is expensive to hold and would have quietly unravelled long ago if it weren't on the list.
What these principles don't claim
Two clarifications, for honesty's sake.
We come from mechanical work. My field experience was in machining and dimensional inspection, and our first customers come from there. I won't claim to know sawmilling, food processing or construction sites from the inside — it would be false, and anyone from those trades would see it in three lines. What I do claim is narrower and sturdier: the non-conformity, the uncalibrated instrument, the proof to be produced and the customer waiting for their package behave the same way anywhere something is made for someone else. That's the level at which these principles hold, and no further.
Software doesn't create a culture. No tool will make an employee comfortable reporting their own mistake. That is settled the day someone does it for the first time, and everyone watches how management reacts. What a tool can do is make the phenomenon measurable: how many different people raised a deviation this year, how many non-conformities are tied to a process rather than to a name, how many corrective actions were verified afterwards. Those are culture indicators disguised as quality indicators. When they rise, it isn't the software improving.
In closing
If I had to reduce these seven principles to one, it would be this: quality isn't a department, it's a practice — and a practice is judged by the time it takes.
A legitimate requirement that costs someone two hours a day will eventually be worked around. Not out of bad faith: out of arithmetic. That's how you end up with files completed the night before the audit, calibration registers updated once a year, and non-conformities that never surface because reporting them takes longer than quietly fixing the part.
Making proof cheaper to produce is the only durable way to get it produced at all. Everything else — automation, dashboards, indicators — is useful only to that extent.
These seven principles guide the development of Asterion Solutions, a suite of trade-specific software built for small manufacturers who want to structure their quality without multiplying administrative work. The other articles on this blog take them one at a time: the hidden cost of inspection reports, metrology beyond the spreadsheet, the management review without a consultant, the maturity of a quality system.