Organisations lose critical process knowledge not through poor documentation, but through the wrong type of documentation. Corrective action reports capture failure modes and containment actions. Control plans specify what to monitor. Engineering change orders authorise modifications. None of these records capture the deliberate engineering logic behind why a process parameter was set to a specific value, what alternatives were rejected, and what happens if an unknowing engineer reverses that decision.
I have audited plants where a critical dimension drifted out of specification because a new process engineer optimised cycle time by adjusting a parameter they did not understand. The parameter had been deliberately set three years earlier during an 8D investigation. The original team documented their findings in a corrective action report. That report lived in the QMS, but nobody told the new engineer to read it before changing the process. The tribal knowledge walked out the door with the previous engineer, and the institutional knowledge was buried in a PDF.
Quality Decision Records (QDRs) solve this exact failure mode. Borrowed from the Architecture Decision Records used in software engineering, a QDR is a structured document that captures the context, alternatives, data, and rationale behind a quality-critical choice. It does not replace your APQP documentation or your 8D database. It fills the gap between them, ensuring that the reasoning behind your process parameters survives personnel turnover and organisational restructuring.
What Distinguishes a QDR from Existing Quality Documentation
Most manufacturing leaders assume their existing document control system already captures this information. They point to their corrective action databases, engineering change orders, and management review minutes as proof. But these tools serve different purposes and leave a specific knowledge gap. They document what happened and what changed, but rarely document the deliberate reasoning chain behind proactive engineering decisions.
Corrective action reports document reactive problem-solving. They prove you fixed a failure, but they do not explain why you chose a specific prevention method over the alternatives. Engineering change orders capture modifications, but their compressed, approval-oriented format strips out the analytical nuance. Control plans specify inspection frequencies and reaction plans, but they do not explain what failure mode would emerge if a specific control was removed.
A QDR covers the decisions you make proactively to engineer quality into a process. It is the connective tissue between your quality knowledge and the people who need that knowledge. Without it, organisations rely on memory and hope.
Standard Quality Records vs. Quality Decision Records
What standard records capture
- 8D reports document the reactive problem-solving path after a failure occurs.
- Control plans specify inspection frequencies without explaining the engineering risk.
- Change orders authorise modifications but omit the rejected design alternatives.
- PFMEA scores risk but rarely preserves the exact data behind a parameter selection.
What QDRs add
- Deliberate design choices made proactively during process engineering.
- Explicit warning of what breaks if the parameter is changed without validation.
- The exact data and capability studies that drove the final selection.
- Plain-language rationale written for an engineer who starts three years from now.
The Anatomy of a High-Impact Decision Record
Not every choice requires a QDR. Ordering a different colour of safety glasses does not qualify. Decisions that affect process parameters, inspection criteria, supplier selection, control plan elements, measurement methods, or tolerance specifications absolutely do. The threshold is simple: if reversing this decision could cause a nonconformance, it needs a QDR.
A functional QDR requires specific structural elements to survive organisational turnover. The most critical sections are the alternatives considered, the decision rationale, and the consequences of reversal. The alternatives matter because they represent the paths not taken, which are exactly what a future engineer will consider again. The rationale must be written in plain language for a new hire who has never seen the process.
The consequences section must explicitly state what downstream systems depend on this decision. If changing a heat treatment temperature invalidates a PPAP package and requires customer notification per their specific requirements, that warning belongs at the top of the document. If modifying one machine parameter automatically impacts a linked timer or sensor, that linkage must be documented as a hard constraint.
I refined this structure across multiple ISO 9001 and IATF 16949 implementations. The discipline of forcing engineers to articulate their rationale in writing exposes gaps in their own analysis, making the QDR a quality assurance tool in its own right, not just an administrative record.
Structuring the Document for Practical Use
A QDR must be searchable, accessible, and integrated into the daily workflow. A document that cannot be found is functionally identical to a document that does not exist. Use a consistent naming convention and tag each record by process, product, parameter, and customer. Make the repository accessible to everyone who touches the process, including operators, maintenance technicians, and quality inspectors.
The decision statement should be a single, clear sentence. For instance, the heat treatment temperature for a specific part was set to 845 degrees Celsius with a tolerance window of plus or minus five degrees. The context section explains the trigger, whether it was a customer complaint, a design change, or a new process capability study.
The alternatives section is where most organisations fall short. Documenting what you did is easy. Documenting what you almost did requires discipline. Record that alternative temperatures were rejected due to insufficient hardness in corner samples or grain growth concerns in long runs. State that tightening the tolerance was rejected because furnace capability only achieved a Cpk of 0.89.
Write the rationale so it explains the mathematical and physical reasoning behind the choice. A well-written rationale states that the selected parameter provides the target hardness with a process Cpk of 1.47, meeting the internal requirement of 1.33. It clarifies that narrowing the window would require a furnace modification, while widening it would drop the Cpk below 1.0.
Integrating QDRs into Change Management Workflows
Implementation fails when QDR creation is treated as an optional add-on. It must function as a hard gate within your change management process. Any proposed change to a quality-critical process parameter, inspection method, or control plan element must trigger a QDR review. The change does not go live until the engineer confirms they have read the relevant QDRs and the new QDR is complete.
Embedding the QDR into the Change Management Gate
- 01Identify Change TriggerA proposed modification to a parameter, method, or control plan element.
- 02QDR Repository CheckEngineer searches the database for existing decisions linked to the target process.
- 03Review ConstraintsRead the consequences and rejected alternatives from the original QDR.
- 04Approve or HaltProceed with the change, reject it, or update the QDR based on new validation data.
Start with a focused pilot rather than a plant-wide rollout. Pick one production line or product family. Identify the top ten quality-critical decisions made over the past two years and write the QDRs retroactively. Reconstructing the reasoning is harder than documenting it in real time, but the exercise teaches the format faster than any formal training session.
At a Tier 1 automotive supplier, this pilot approach yielded immediate results. During the first month of creating QDRs for their most complex lines, the engineering manager discovered that six of those decisions had been made at least twice before in the past five years. Each time, a new engineer had repeated the same analysis and tests, completely unaware that the work had already been done.
The Cultural and Organisational Barriers
Technology is not the constraint. Discipline is. A well-organised folder of structured documents captures the vast majority of the value at a fraction of the cost of a custom database. The real barrier is cultural. Writing a comprehensive QDR requires an engineer to articulate reasoning that feels obvious in the moment but will not be obvious in three years.
In organisations where documentation is viewed as bureaucracy, engineers will resist the additional workload. In environments where knowledge is treated as leverage, sharing detailed rationale feels like giving away power. Mandating compliance will not fix this. The solution is to make the value visible through direct experience.
A QDR system succeeds when an engineer avoids a major scrap event because they read a record before changing a parameter.
When the first engineer avoids a significant scrap event because they read a QDR and stopped a change that would have broken the process, celebrate that event publicly. Make it a story the entire plant knows. Once an engineer has been saved by a QDR someone else wrote, they will write their own records with a fundamentally different level of care.
The highest return on investment comes from integrating QDRs into your onboarding process. When a new engineer joins the team, have them read the QDRs for their area during their first week. They will absorb years of institutional knowledge in days, understanding not just what the process does, but why it does it that way.
Connecting Decision Records to APQP Requirements
If you are executing Advanced Product Quality Planning properly, you are already generating the raw material for a QDR. The Process Flow Diagram identifies critical parameters. The PFMEA identifies risks and controls. The Control Plan specifies monitoring requirements. The PPAP validates the package. What APQP fails to capture is the decision journey.
APQP tells you the destination. A QDR maps the path. When you set up a new process and select a specific injection moulding parameter, the control plan tells you to document it. The QDR tells you that you considered three alternatives, rejected two 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.
This distinction between documentation and knowledge is the core value proposition. For a typical automotive Tier 1, a significant quality incident costs between $50,000 and $500,000 depending on whether it reaches the customer. Most organisations estimate that 10 to 20 percent of these incidents stem from someone unknowingly changing a parameter that was deliberately set to prevent exactly that problem.
Preventing these losses does not require better inspection or tighter tolerances. It requires better knowledge management. A QDR system costs almost nothing to implement. It requires a few hours per significant decision, a shared repository, and a review habit. Your quality system already knows why that temperature is exactly 845 degrees. The question is whether the person who makes the next decision knows it too.