Why this Matters
As a client operating in a regulated environment, we understand the importance of knowing whether a system update requires revalidation. This one-pager outlines how our versioning works, what types of changes are deployed, and when (if ever) your internal validation processes should be re-engaged.
Our Approach to Versioning
We follow a risk-based validation strategy and use semantic versioning (SemVer) to help categorize the type and impact of each release.
*Minor releases are assessed case-by-case. If a minor update affects validated workflows, you will be notified in advance.
How We Validate Internally
All releases undergo regression testing using a standardized test case library
Changes are documented and reviewed by our QA and Compliance teams
Impact assessments are conducted for all functional updates
Validation summaries and test results are available on request
How You’ll Be Notified
You will be:
Informed via release notes or email if a change affects validated workflows
Provided with sufficient notice and documentation when revalidation is needed
Given access to our change log and technical summaries for review
⚠️Disclaimer
This document reflects our internal quality assurance practices and recommendations. Decisions regarding the need for client-side validation or revalidation should be made by the client in accordance with their internal quality management procedures and applicable regulatory requirements.
We are happy to support your assessment by providing validation evidence and release documentation upon request.
✅ Bottom Line
Most updates—especially those marked as patch versions—are routine and do not require client-side revalidation. We will always communicate clearly when an exception arises.
Need More Info?
If you'd like to review the latest release notes, validation logs, or impact summaries, please contact: