Built for validated environments

Release management for regulated labs

Regulated clients don't mind you shipping — they mind being surprised. This page explains exactly how Aliquora manages releases, what paperwork we hand you, and what to expect at every step.

Release cadences

Two cadences, one predictable rhythm

Non-GxP changes ship continuously and silently. GxP-impacting changes ship on a scheduled validated release — announced in advance, with a full release packet.

Continuous releases

Non-GxP changes — no action required

UI improvements, performance work, and new non-critical features ship whenever they're ready. No advance notice required — these changes have no impact on your validated functionality.

  • UI / UX improvements and layout changes
  • Performance optimisations and page-load improvements
  • New non-critical views (dashboards, analytics, reporting tools)
  • Blog posts, marketing site content
  • Documentation and in-app help text
  • Behind-the-scenes infrastructure changes with no user-visible effect

Validated releases

GxP-impacting — scheduled, with release packet

Changes that touch validated functions ship monthly or quarterly on an announced schedule. Each release comes with a full release packet: VIA, test evidence, and 2–4 weeks' advance notice.

  • Audit-trail capture logic (new events, changed event format)
  • Electronic-signature workflow or re-authentication behaviour
  • Result release gates (QC pass/fail logic, approval chain enforcement)
  • Calculation engine or out-of-spec detection rules
  • COA / report content or PDF output format
  • Role permissions and access-control rules
  • Data-export format (EDD, CSV schema changes)
Release packet

What we hand you for every validated release

Your QA manager should be able to file our packet into their change-control record and sign off in under an hour — not re-test us for two weeks.

What changed

Plain-language summary of every change in the release. No code diffs — the level of detail a QA manager needs to understand scope.

GxP impact classification

Every change categorised as None, Low, or High GxP impact. None = no action. Low = review and file. High = customer UAT and written acknowledgment required before the release applies.

Validation Impact Assessment (VIA)

A completed VIA covering which validated functions are affected, what testing was performed, and what action (if any) you need to take.

Test evidence

Passing test results for the version being released — covering all GxP-impacting functions flagged in the VIA.

Advance notice timeline

2–4 weeks' written notice before any validated release ships. High-impact changes require explicit acknowledgment before they apply to your production environment.

Sandbox access

A staging tenant preloaded with the next release so your team can run your own UAT before the change reaches production.

VIA template

Sample Validation Impact Assessment

This is the format we use for every validated release. Print it to PDF, file it in your change-control record, and you're done.

Aliquora LIMS

Validation Impact Assessment

Form: VIA-001

Version: 1.0

Release version

e.g. v2.14.0

Release date

YYYY-MM-DD

Prepared by

Aliquora team

Review date

YYYY-MM-DD

1. Change summary

Plain-language description of what changed in this release — what problem it solves and what behaviour is different.

2. GxP-impacting functions — does this release affect any of the following?

Check all that apply. If none are checked, this release is classified as Non-GxP — no further action required.

3. Impact classification

None

No GxP functions affected. No customer action required.

Low

Minor change to a GxP function with negligible risk. Review the release notes; re-test at your discretion.

High

Material change to a validated function. Customer UAT recommended; written acknowledgment required before release applies.

Selected classification for this release

[ None / Low / High ]

4. Testing performed by Aliquora

Description of tests run against the GxP-impacting functions. Passing test evidence attached as Appendix A.

5. Customer action required

None — release applies automatically (Non-GxP or Low-impact changes).
Review release notes and file this VIA in your change-control record.
Run customer UAT in the staging tenant before accepting production release (High-impact changes).
Provide written acknowledgment to Aliquora before release applies to your production environment (High-impact changes).

6. Signatures

Prepared by (Aliquora)

Name

Date

Reviewed by (Customer QA)

Name

Date

Print this page to PDF (Ctrl/Cmd + P) to file in your change-control record.

Emergency patches

Security and data-integrity fixes can't wait

Security vulnerabilities and data-integrity issues are deployed immediately. This isn't an improvisation — it's a defined policy that every regulated client accepts up front.

Every client accepts the emergency patch path before going live. Because it's agreed policy — not a surprise — no client has ever objected. The alternative (waiting for the quarterly train while a vulnerability is open) is not acceptable.

  • Deploy immediately

    Security and data-integrity fixes are deployed to production as soon as they pass internal review — no waiting for the next scheduled release window.

  • Notify within 24 hours

    All clients receive written notification within 24 hours of deployment: what was patched, why it couldn't wait, and a preliminary impact assessment.

  • Retroactive impact assessment

    A full VIA is completed and sent within 5 business days of deployment — the same format as a standard validated-release VIA, clearly marked 'Emergency Patch'.

  • Agreed policy, not improvisation

    The emergency path is documented in your service agreement before you go live. Every regulated client knows exactly what to expect if it's ever triggered.

Version support

Clear version support policy

Version pinning sells. Unbounded version pinning destroys margins and splits your validation story into fragments. Here's where we draw the line — stated before you're a customer.

At most 2 releases back

We support your current version and the two previous validated releases. Clients on older versions are supported during transition to the latest.

Maximum 6-month lag

No client may fall more than 6 months behind the current validated release. This keeps the support surface manageable and your validation current.

Security patches always applied

Security and data-integrity patches are applied immediately regardless of version. There is no opt-out — this is a condition of service, not a choice.

A note on bespoke client requests

Per-client code forks create divergent validation stories and wreck margins. Any request that can't be met through configuration is placed on the product roadmap — never written as a one-off. This is how Aliquora stays maintainable and keeps your validation intact across the full user base.

Request a release packet

Get the VIA for your release

Evaluating a specific version? Fill in this form and we'll send you the full release packet — VIA, test evidence, and impact classification — directly to your inbox.

Ready to discuss your validation requirements?

Tell us about your regulatory environment and your existing computer-system validation process. We'll walk you through how Aliquora fits in.