Quality Decision Records: When Your Organization Stops Repeating the Same Mistakes Because It Forgot Why It Made the Right Choice the First Time
The Decision That Vanished
A few years ago, I walked into a plant that was in the middle of a full-blown quality crisis. A critical dimension on their flagship product had drifted out of specification — again. Scrap was piling up, a key customer was threatening a controlled shipment, and the quality team was working 16-hour shifts trying to contain the damage.
During the root cause investigation, we discovered something fascinating and painful. The same dimension had drifted three years earlier. The team at the time had identified the root cause, implemented a corrective action, validated it thoroughly, and closed the case. The fix worked. It worked beautifully — for about two years.
Then a new process engineer joined the team. He didn’t know about the previous incident. He didn’t know why the process parameters were set the way they were. He saw what he thought was an opportunity to optimize cycle time, changed a key parameter, and inadvertently dismantled the exact control that had been preventing the problem.
The original team had documented their findings in a corrective action report. That report lived in a quality management system that the new engineer had access to but had never been told to look at. The tribal knowledge walked out the door with the previous engineer, and the institutional knowledge was buried in a PDF that nobody read.
Three years of perfect quality. Gone. Not because the fix was wrong, but because the organization forgot why the fix existed.
That day, I started building something I now consider one of the most underappreciated tools in quality management: Quality Decision Records.
What Is a Quality Decision Record?
A Quality Decision Record (QDR) is a structured document that captures not just what decision was made, but why it was made, what alternatives were considered, what data supported it, and — most critically — what would happen if the decision were reversed.
It’s not a new concept. Software engineers have been using Architecture Decision Records for years. The idea is simple: every significant decision your quality system makes should be documented in a way that survives personnel changes, organizational restructuring, and the inevitable erosion of institutional memory.
But in quality management, the stakes are higher than in software. When a software team reverts a decision, the worst case is a bug. When a manufacturing team reverts a quality decision, the worst case is a customer gets a nonconforming product. Or worse — someone gets hurt.
The QDR is your immune system against organizational amnesia.
The Anatomy of a Good QDR
Not every decision needs a record. Choosing which color safety glasses to order doesn’t qualify. But decisions that affect process parameters, inspection criteria, supplier selection, control plan elements, measurement methods, tolerance specifications, or any other quality-critical characteristic? Those absolutely do.
Here’s the structure I’ve refined over dozens of implementations:
1. Decision Statement
A single, clear sentence describing what was decided. Not the background, not the analysis — just the decision itself. “The heat treatment temperature for Part XYZ was set to 845°C with a ±5°C tolerance window.”
2. Context and Trigger
What was happening that required this decision? Was it a customer complaint? A design change? A new process capability study? An audit finding? This section tells the reader why anyone was thinking about this in the first place.
3. Alternatives Considered
This is where most organizations fall short. They document what they did but not what they almost did. The alternatives are crucial because they represent the paths not taken — and those paths are exactly what a future engineer might consider again.
In the heat treatment example: “Alternative A: 830°C (rejected due to insufficient hardness in corner samples). Alternative B: 860°C (rejected due to grain growth concerns in long runs). Alternative C: 845°C with ±3°C tolerance (rejected due to furnace capability — Cpk of 0.89).”
4. Data and Analysis
The evidence. SPC data, capability studies, customer specifications, material certifications, test results, simulation outputs. Not all of it — just the data that actually influenced the decision. Reference the full studies; don’t paste them.
5. Decision Rationale
The “why” in plain language. This is the most important section of the entire document, and it’s the one most likely to be skipped. Write it like you’re explaining it to a new hire who will start three years from now and has never seen this process before.
“We selected 845°C ±5°C because it provides the target hardness (58-62 HRC) with a process Cpk of 1.47, which meets our internal requirement of Cpk ≥ 1.33. The ±5°C window is the maximum tolerance that achieves this Cpk given the current furnace uniformity of ±3.2°C. Narrowing to ±3°C would require furnace modifications estimated at $45,000. Widening to ±8°C would drop Cpk below 1.0.”
6. Consequences and Constraints
What happens if this decision is changed? What downstream systems, products, or processes depend on it? What are the non-obvious linkages?
“WARNING: Changing this temperature or tolerance without re-validating the full PPAP package for Customer A will trigger a resubmission requirement per their CS-1 specification. Additionally, the furnace program is linked to the quench delay timer; modifying one without the other creates a risk of incomplete phase transformation.”
7. Review Date
When should this decision be revisited? Not all decisions are permanent. Some are interim solutions. Some depend on technology that will evolve. A review date forces the organization to consciously re-evaluate rather than passively forget.
8. Stakeholders and Approval
Who made this decision? Who was consulted? Who needs to know if it changes? Names, titles, dates. This isn’t about blame — it’s about knowing who has the deepest context if questions arise later.
Where Most Organizations Go Wrong
I’ve seen plenty of companies that think they’re already doing this. They point to their corrective action databases, their engineering change orders, their management review minutes. But here’s the difference:
Corrective action reports document problems and solutions. They don’t document deliberate design choices. A QDR covers the decisions you make proactively, not just reactively.
Engineering change orders document changes. But they typically document the change itself, not the full reasoning chain. And they’re often written in a compressed, approval-oriented format that strips out the nuance.
Management review minutes document discussions. But they’re chronological meeting notes, not indexed, searchable decision repositories.
Control plans document what to control. They rarely document why those controls exist, what would happen if they were removed, or what alternatives were rejected.
The QDR fills a gap that none of these tools address. It’s the connective tissue between your quality knowledge and the people who need that knowledge.
The Implementation Story That Convinced Me
A Tier 1 automotive supplier I worked with had 14 production lines serving 9 OEM customers. They had a quality department of 22 people, an electronic QMS, and a document control system that would make an ISO auditor weep with joy.
They also had a recurring problem: every 18-24 months, something would break that had been fixed before. Their corrective action closure rate was above 95%. Their recurrence rate for different root causes was below 3%. But their recurrence rate for the same root cause — often triggered by an unknowing process change — was hovering around 15%.
We implemented QDRs as a pilot on their two most complex lines. We trained the process engineers, set up a simple shared repository (a well-structured folder system with a naming convention, not a fancy database), and made QDR creation part of their change management process.
Within the first month, they created 23 QDRs. Reading through them, the engineering manager had a striking realization: six of those decisions had been made at least twice before in the past five years. Each time, a new engineer had gone through the same analysis, run the same tests, and arrived at the same conclusion — completely unaware that the work had already been done.
After six months, the pilot lines had zero recurrence incidents. Zero. Not because the QDRs prevented defects directly, but because they prevented the process changes that would have caused defects. The engineers started reading the QDRs before proposing changes. The new hires read them during onboarding. The maintenance team checked them before adjusting equipment parameters.
The system paid for itself in avoided rework alone within the first quarter.
Building Your QDR System
You don’t need software. You don’t need a database. You need discipline and a simple framework.
Start Small
Pick one production line or one product family. Identify the top 10 quality-critical decisions that have been made in the past two years. Write the QDRs retroactively. It’ll be harder — you’ll have to reconstruct some of the reasoning — but it will teach you the format faster than any training session.
Make It Part of the Process
Embed QDR creation into your change management workflow. Any change to a quality-critical process parameter, inspection method, or control plan element should trigger a QDR. Not as an add-on, but as a gate: the change doesn’t go live until the QDR is complete.
Make It Searchable
A QDR that can’t be found is a QDR that doesn’t exist. Use a consistent naming convention. Tag them by process, product, parameter, and customer. Make the repository accessible to everyone who touches the process — engineers, operators, maintenance technicians, quality inspectors.
Make It Living
Set review dates. When a process is modified, update the QDR rather than creating a new one. Keep the history — show what changed and why — but maintain a current version that always reflects the latest state of knowledge.
Make It Part of Onboarding
This is the highest-ROI application of QDRs. When a new engineer joins the team, have them read the QDRs for their area during their first week. They’ll absorb years of institutional knowledge in days. They’ll understand not just what the process does, but why it does it that way.
The Cultural Barrier
Here’s the hard truth: most organizations don’t fail at QDRs because of technology or process. They fail because of culture.
Writing a good QDR takes time. It takes thought. It requires you to articulate reasoning that often feels obvious in the moment but won’t be obvious to someone reading it three years later. It requires you to admit what alternatives you considered and why you rejected them — which means acknowledging that there were other valid options.
In organizations where documentation is seen as bureaucracy, QDRs will be resisted. In organizations where knowledge is power and sharing it feels like giving away leverage, QDRs will be undermined. In organizations where speed is valued over thoroughness, QDRs will be skipped.
The fix isn’t to mandate compliance. The fix is to make the value visible. When the first engineer avoids a $200,000 scrap event because they read a QDR and didn’t make a change that would have broken the process — celebrate that. Make it a story the whole plant knows.
The cultural shift happens when people experience the benefit directly. Once an engineer has been saved by a QDR someone else wrote, they’ll write their own QDRs with a different level of care. They understand that they’re not filling out a form — they’re leaving a message in a bottle for a future colleague they’ll never meet.
The Connection to Advanced Quality Planning
If you’re doing APQP properly, you’re already generating most of the content that goes into a QDR. The Process Flow Diagram identifies the critical parameters. The PFMEA identifies the risks and controls. The Control Plan specifies what to monitor. The PPAP validates the whole package.
What APQP doesn’t capture is the decision journey. It shows you the destination but not the path. A QDR fills in that gap.
When you set up a new process and select a specific injection molding parameter, APQP tells you to document it in the control plan. The QDR tells you that you considered three alternatives, rejected two of them based on a DOE that showed sink marks at higher pressures and short shots at lower pressures, and that the selected parameter produces a Cpk of 1.67 on the critical dimension but drops to 1.12 if the mold temperature varies by more than 8°C.
That’s the difference between documentation and knowledge.
The Digital Horizon
There’s a future where QDRs are integrated into digital twin environments, where an engineer proposing a process change automatically sees all the decisions that would be affected, the data behind them, and the predicted consequences of the change.
Some organizations are already building this. They’re linking QDRs to their MES, their SPC systems, their change management platforms. They’re using natural language processing to make the QDR repository searchable by question, not just keyword.
But you don’t need to wait for that future. A well-organized folder of Word documents or a shared spreadsheet will capture 80% of the value at 5% of the cost. The technology is not the constraint. The discipline is.
The Real Cost of Forgetting
Let me leave you with a calculation. Take your average cost of a quality incident — scrap, rework, containment, customer notification, potential recall. For a typical automotive Tier 1, that’s somewhere between $50,000 and $500,000 per significant event, depending on whether it reaches the customer.
Now estimate how many of those incidents in the past five years were caused by someone unknowingly changing a process parameter that had been deliberately set to prevent exactly that problem. Not malicious changes. Not negligent changes. Just uninformed changes by competent people who didn’t have the information they needed.
Most organizations I’ve worked with estimate that 10-20% of their quality incidents fall into this category. Preventable not by better inspection or tighter tolerances, but by better knowledge management.
A QDR system costs almost nothing to implement. A few hours per significant decision. A shared folder. A review habit. The ROI isn’t just positive — it’s embarrassing that more organizations don’t do it.
Your quality system knows things. It knows why that temperature is set to exactly 845°C. It knows why that inspection point exists. It knows why that supplier was chosen over the cheaper alternative. It knows why that tolerance is ±0.05 and not ±0.03.
The question is: does the person who will make the next decision about that process know those things too?
If the answer isn’t a confident yes, you have work to do.
Peter Stasko is a Quality Architect with over 25 years of experience in automotive and manufacturing quality systems. He specializes in transforming theoretical frameworks into practical, shop-floor-ready tools that drive measurable improvement. Peter has helped organizations across Europe and North America build quality systems that don’t just comply with standards — they create lasting competitive advantage. His approach combines deep technical expertise with a pragmatic understanding of how real factories and real people actually work.
