Quality and Critical Thinking: Preventing “Perfect Conformance” to the Wrong Target
A practical definition of quality for QA, CSV, CSA, and data integrity.
Xevalics Consulting, LLC
Who This Is For
This post is for QA professionals (especially those early in their careers), Computer Systems Validation (CSV) and Computer Software Assurance (CSA) practitioners, and quality leaders who want a practical, audit-defensible definition of quality for computerized systems. It is also for teams modernizing digital workflows who need “fit for use” to mean something specific when data integrity and evidence matter.
Introduction
When people casually talk about “quality” as a “degree of excellence”—as defined in standard dictionaries like Merriam-Webster11—it’s easy to lose sight of how that phrase differs from a quality definition you can measure, demonstrate, and defend in regulated environments. ISO 9000:2015, for example, defines quality in terms of fulfilling requirements, reinforcing why objective framing matters.9
One influential definition of quality comes from Philip Crosby’s 1979 book Quality Is Free, in which he described quality as “conformance to requirements.”8 In regulated environments, this framing makes sense because it grounds quality in objective, verifiable, and defensible standards rather than subjective impressions of “excellence.”
This matters even more as organizations adopt modern software, cloud platforms, and AI-enabled tools. FDA’s draft guidance on the use of artificial intelligence for regulatory decision-making reinforces how much credibility depends on clear intent, sound controls, and defensible evidence—not just outcomes.1
In practical terms, this article brings together the concepts QA teams must align to make quality defensible in computerized systems: intended use, fit-for-use requirements, validation evidence, traceability, audit trail review, and data integrity, including ALCOA+ principles. These elements are how quality is translated from theory into day-to-day practice, particularly in GLP and other regulated record environments..
Key Takeaways
- Quality needs to be definable and testable, not just aspirational.
- “Quality = conformance to requirements” is audit-defensible, but only when the requirements are fit for intended use.8,9,10
- Critical thinking prevents “perfect conformance” to the wrong target.
- CSV is the evidence discipline for demonstrating conformance in computerized systems.
- CSA reinforces right-sized assurance, focusing rigor where risk and impact are highest.12
- Data integrity controls are quality requirements when systems create or influence regulated records (for example, audit trails and validation expectations in 21 CFR 11.10).3,13
Back to Basics: A practical definition of quality
A clear, teachable definition of quality is especially important when training new QA professionals. At Xevalics, we use the following working definition:
Quality is conformance to fit-for-use requirements, demonstrated by objective evidence.
This definition intentionally blends three complementary perspectives:
- Crosby’s operational view: quality is conformance to requirements, not subjective “goodness.”8
- ISO’s measurement language: quality reflects the degree to which requirements are fulfilled.9
- Juran’s practical lens: requirements must ensure fitness for use in real-world conditions.10
Conformance provides discipline. Fit-for-use provides meaning. Objective evidence makes the claim defensible.
The hidden assumption: “assuming good requirements”
The phrase “quality is conformance to requirements” quietly assumes something critical: that the requirements are worth conforming to.
In practice, many quality failures stem not from poor execution, but from requirements that were incomplete, misaligned, or disconnected from real operational use. When this happens, teams can achieve perfect conformance and still deliver a system that fails users, inspectors, or both.
Well-formed requirements share four essential characteristics:
- They are aligned with intended use and real decision-making.
- They ensure the system is fit for use, not just functionally complete.
- They are verifiable through objective evidence.
- They reflect risk, with stronger controls applied where failure would matter most.
From a quality perspective, the true “target” is the requirement set itself. Protect that target, and conformance becomes meaningful.
Fit for use: where “requirements” become real
In computerized and digital systems, teams often focus heavily on functional requirements while under-specifying the controls that make systems dependable over time. Fit-for-use requirements extend beyond what a system does to how reliably and securely it operates.
In regulated environments, these controls are not optional enhancements. They are fundamental quality requirements. For example, 21 CFR 11.10 establishes expectations for validation, record protection, access controls, and audit trail integrity in closed systems. Without these controls, a system may function correctly and still fail to meet regulatory expectations.3
- Role-based access, segregation of duties, and operational checks
- Audit trail expectations and reviewability
- Time synchronization, retention, backup and restore
- Change control and configuration governance
In GLP settings, the Quality Assurance Unit requirement itself is framed around conformance to the regulation and study integrity (for example, 21 CFR 58.35 for FDA GLP and 40 CFR 160.35 for EPA GLP).2,4 These expectations are reinforced by the EPA’s GLP compliance monitoring program and enforcement posture, which operationalizes what “conformance” means in real inspections.5
For global organizations, this “fit-for-use conformance” mindset also aligns with the OECD Principles of GLP, which support harmonized expectations for study conduct, quality assurance, and data integrity across participating countries.6
Critical thinking is QA’s safeguard against validating the wrong thing.
Critical thinking: preventing “perfect conformance” to the wrong target
One of the most common failure modes in modern QA is achieving flawless conformance to requirements that were never fully thought through. When requirements are incomplete or misaligned, quality systems can generate impressive documentation that proves the wrong thing.
This is where critical thinking becomes a quality safeguard rather than a soft skill. It forces teams to challenge assumptions early, before validation, testing, or documentation lock in the wrong outcome.
If requirements are unclear, incomplete, or misaligned with intended use, perfect conformance can still produce a quality failure.
A practical set of questions to teach new QA professionals:
- What decision will this system support, and what is the consequence of being wrong?
- What could go wrong that functional testing would not detect?
- What evidence would convince a skeptical reviewer that the record is trustworthy?
- If the system changes frequently (cloud updates, configuration changes, AI-enabled features), how do we keep requirements current and controlled?
Why CSV depends on this definition of quality
Computer Systems Validation (CSV) exists to make quality claims defensible for computerized systems. If quality is defined as conformance to fit-for-use requirements, CSV becomes the structured mechanism for demonstrating that conformance with objective evidence.
When CSV is grounded in clear intended use and well-formed requirements, traceability tells a coherent story. When the definition of quality is vague, CSV degrades into a documentation exercise rather than a quality control.
In many organizations, the practical artifact that ties this together is the requirements traceability matrix (RTM): it links intended use, requirements, tests, and evidence. When the RTM is coherent, reviewers can follow the logic from “what we need” to “what we proved,” including controls for audit trails, access, record retention, and change control.
When CSV is working well, it creates a coherent evidence story: intended use informs requirements, verification demonstrates conformance, and traceability ties requirements, tests, and outcomes together.
Where CSA fits: right-sized assurance without losing the quality argument
Computer Software Assurance (CSA) is best understood as a risk-based evolution of how confidence is established and maintained in software. Rather than weakening quality expectations, CSA reinforces them by aligning assurance activities with the actual risk posed by the system and its records.12
The practical takeaway for QA teams is that CSA does not weaken the quality argument. It strengthens it by aligning evidence depth to risk, avoiding over-documentation where it adds no value, and increasing rigor where failure would matter most.
In other words, CSA helps teams avoid two common traps: over-testing low-risk functions and under-controlling high-risk records.
When records matter, integrity controls are quality requirements.
Data integrity: quality requirements for records, not optional “controls”
Many digital quality failures are not about whether a feature works. They are about whether the record is trustworthy. If a system creates or influences regulated records, data integrity expectations belong in the requirements set.
This is why Part 11 controls matter to quality discussions. For example, 21 CFR 11.10 includes expectations for validation, accurate copies, record protection and retrieval, access controls, and secure time-stamped audit trails.³
From an audit-readiness perspective, data integrity requirements typically include audit trail generation and review, role-based access and segregation of duties, time synchronization, secure retention and retrieval, and controlled changes to configurations and critical workflows. These are not “nice-to-have” controls; they are fit-for-use requirements because they determine whether the electronic record can be trusted.
FDA’s Data Integrity and Compliance With Drug CGMP: Questions and Answers guidance makes the same point from a different angle: data must be reliable and accurate throughout its lifecycle, and firms should implement meaningful strategies to prevent and detect integrity issues.¹³ Even when you are not operating strictly under drug CGMP, the logic is highly transferable: if your data is not trustworthy, your “quality evidence” collapses.
For organizations designing future-forward digital quality systems, data integrity is not a side topic. It is a core quality requirement for computerized systems that generate, transform, or store scientific and regulated records.³,¹³
Finally, this fits naturally with modern data stewardship expectations such as the FAIR Guiding Principles, which emphasize making scientific data findable, accessible, interoperable, and reusable — principles that strengthen traceability and audit readiness when applied thoughtfully in regulated workflows.⁷
If a system can influence a regulated record, data integrity controls are quality requirements.
Myth vs Reality
MYTH: “Quality means exceeding customer expectations.”
REALITY: “Expectations” drift. In QA, quality must be definable and testable. Requirements can be reviewed, approved, verified, and defended.MYTH: “If we add extra features, quality goes up.”
REALITY: Unapproved extras are often gold plating. They introduce scope, risk, and validation burden without authorization.MYTH: “As long as it works, it’s quality.”
REALITY: In regulated systems, “works” must also mean fit for intended use, with trustworthy records and controlled change.2,3,6SO WHAT: If it matters, it belongs in requirements. If it is not in the requirements, treat it as a change request.
Conclusion
A strong QA definition of quality is not “excellence” and not “exceed expectations.” It is:
Quality is conformance to fit-for-use requirements, demonstrated by objective evidence, scaled to risk, with data integrity treated as part of the requirement set.
That definition makes CSV coherent, makes CSA practical, and gives QA professionals a reliable way to think, speak, and act under scrutiny in modern digital environments.
Keywords for readers and discovery: quality definition, fit-for-use requirements, critical thinking in QA, computer systems validation (CSV), computer software assurance (CSA), data integrity, audit trails, traceability matrix, intended use, and OECD/FDA GLP expectations.
About Xevalics Consulting
Xevalics Consulting, LLC supports regulated organizations in the responsible design, qualification, and governance of agent-enabled technologies within validated and GLP-compliant environments.
Our focus is the qualified, controlled, and auditable deployment of agent-enabled systems to support regulated processes without compromising scientific integrity or regulatory expectations.
Transparency Statement
This article was developed with the assistance of artificial intelligence tools to support research synthesis, drafting, and editorial refinement. Human subject-matter expertise guided all analytical decisions. Xevalics Consulting, LLC retains full responsibility for the content and perspectives expressed.
Regulatory and Compliance Disclaimer
This article is provided for informational and educational purposes only and does not constitute regulatory guidance, legal advice, or an official interpretation of applicable laws, regulations, or guidance documents. Organizations remain solely responsible for determining regulatory applicability and compliance.
Works Cited
1. FDA — Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products (Draft Guidance, Jan 2025).
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological
2. eCFR — 21 CFR Part 58 — Good Laboratory Practice for Nonclinical Laboratory Studies.
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-58
3. eCFR — 21 CFR Part 11 — Electronic Records; Electronic Signatures.
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
4. eCFR — 40 CFR Part 160 — Good Laboratory Practice Standards (EPA).
https://www.ecfr.gov/current/title-40/chapter-I/subchapter-E/part-160
5. EPA — Good Laboratory Practices Standards Compliance Monitoring Program.
https://www.epa.gov/compliance/good-laboratory-practices-standards-compliance-monitoring-program
6. OECD — OECD Principles of Good Laboratory Practice (as revised in 1997) (Publication, 1998).
https://www.oecd.org/en/publications/1998/01/oecd-principles-on-good-laboratory-practice_g1gh32e8.html
7. Wilkinson, M.D., et al. — The FAIR Guiding Principles for scientific data management and stewardship (Scientific Data, 2016).
https://www.nature.com/articles/sdata201618
8. Philip B. Crosby — Quality Is Free
Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. McGraw-Hill, 1979.)
9. ISO — ISO 9000:2015 definition of quality
International Organization for Standardization. ISO 9000:2015: Quality Management Systems—Fundamentals and Vocabulary. 4th ed., International Organization for Standardization, Sept. 2015. ISO, https://www.iso.org/standard/45481.html. Accessed 31 Jan. 2026.
10. Joseph M. Juran — “fitness for use”
Juran, Joseph M., and A. Blanton Godfrey, editors. Juran’s Quality Handbook. McGraw-Hill, 1999.
11. Merriam-Webster — definition of “quality” (includes “degree of excellence”).
https://www.merriam-webster.com/dictionary/quality
12. FDA — Computer Software Assurance for Production and Quality System Software (Final Guidance, Sept. 24, 2025).
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-system-software
13. FDA — Data Integrity and Compliance With Drug CGMP: Questions and Answers (Final Guidance, Dec. 13, 2018).
https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
