Paper compliance isn’t the same as real-world performance
On paper, everything can look perfect.
The testing plan is written.
The documentation is complete.
The boxes are checked.
The audit trail is clean.
And yet—things still go wrong.
This is one of the most common (and expensive) traps in regulated work: confusing paper compliance with real-world effectiveness.
The problem with fixes that only work on paper
Documentation is important. Testing plans matter. But a fix that only survives in a document has not been proven to work.
Paper answers one question:
“Can we show this was done?”
It does not answer:
“Does this actually work when people use it?”
That gap is where failures live.
A real-world example: the “perfect” testing plan
Imagine this scenario.
A testing plan is updated after a study issue:
Clear objectives
Detailed procedures
Defined acceptance criteria
Multiple review signatures
On paper, it’s flawless.
But in practice:
The plan assumes data will be available earlier than it actually is
The procedure requires tools the team doesn’t consistently have access to
The review step is scheduled during peak workload
Critical decisions are buried in dense text
What happens?
The plan gets followed just enough to say it was followed—but not well enough to prevent the next issue.
The document is compliant.
The outcome is not.
Why this keeps happening
1. Documents are written for auditors, not users
Many fixes are designed to look good during review, not to work smoothly during execution.
If a plan:
Is hard to follow
Is unrealistic under time pressure
Relies on people remembering “important notes”
It will fail—quietly, repeatedly.
2. Assumptions are never tested
Paper fixes often assume:
People will read every word
Steps will happen in the intended order
Conditions will match the ideal scenario
Real work doesn’t behave that way.
If assumptions aren’t tested against reality, the fix is theoretical—not operational.
3. Compliance hides weak design
Once something is documented, teams feel safe:
“We updated the plan, so we’re covered.”
But documentation doesn’t stop errors. Design does.
A weak process with strong documentation is still a weak process.
What real-world fixes look like
Effective fixes:
Are tested under real conditions
Match how work actually happens
Make the right action obvious
Catch errors early, not at the end
Reduce reliance on memory
They don’t just exist on paper—they hold up under pressure.
Where Kandih comes in
Kandih helps teams go beyond documentation and ask the harder question:
“Does this work in real life?”
We help organizations:
Review testing plans and documentation against actual workflows
Identify hidden assumptions that will fail in practice
Stress-test processes before regulators or studies do
Redesign plans so they work on busy, imperfect days—not just ideal ones
Align compliance with outcomes, not appearances
In short, we help teams test their fixes against reality—before reality does it for them.
Bottom line
Paper compliance is necessary.
But it is not sufficient.
If a fix only works in a document, it doesn’t work.
Kandih helps teams turn good-looking plans into systems that perform where it matters most: in real-world use.
References
FDA – Quality System Regulation (21 CFR 820) Preamble
Emphasizes effectiveness of actions, not just documentation or completion.
https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
FDA – Applying Human Factors and Usability Engineering to Medical Devices (2016)
Explicitly warns against relying on documentation and user memory instead of system design.
ICH Q10 – Pharmaceutical Quality System
Stresses continual improvement and evaluation of whether actions actually improve performance.
https://database.ich.org/sites/default/files/Q10_Guideline.pdf
ISO 9001:2015 – Clause 10.2 (Nonconformity and Corrective Action)
Requires organizations to evaluate the effectiveness of corrective actions, not just implement them.
https://www.iso.org/standard/62085.html
Reason, J. (2000). Human Error: Models and Management. BMJ
Foundational paper explaining why strong documentation cannot compensate for weak system design.