Use supplier documentation for your own validation, or agree a broader service for preparation, testing and evidence. Your team stays involved in the requirements, review and approval decisions.
01
Two ways to be supported
Documentation support
Augmenticon: provides the agreed supplier documentation and evidence.
You: organise and carry out your own validation.
Extended validation support
Augmenticon: prepares requirements and tests from your requirements and procedures, runs the agreed tests, and provides evidence for review.
You: set the intended use and procedures, review the requirements and test basis, and approve the results.
Both forms are separate from the user licence and priced according to the agreed commercial scope — see costs.
02
Evidence you can review
Test step
Expected: the release date field accepts only past-or-current dates.
Observed: rejected with a validation message, as expected.
Screenshot attachedVersion 4.3.1 · stage
Project status
RequirementsApproved
Test executionReady for review
Validation reportIn preparation
Tasks are named against Augmenticon or your team throughout.
For QA and IT
The mechanism behind extended validation support, for readers who want it.
03
The principle
A machine drafts. A qualified person approves. A deterministic tool executes. The test management system records. The signature attaches to the review of the evidence, not to the keystrokes.
Never in the assurance path
AI sits in the authoring path only, where its output is reviewed line by line by someone accountable for it.
Static, deterministic, versioned
The executing tool is reviewable, version-controlled code, qualified for its intended use under GAMP 5 (2nd Edition), Appendix M9.
What the signature attests
From “I performed these steps” to “I reviewed this execution record and its evidence, and I attest the result.”
The reviewer reads one format regardless of who executed: numbered step, the action as approved, the expected result, the observed result, a screen capture, a timestamp — the same record a person fills in by hand.
04
Where AI is used, and where it is not
May draft
Functional requirements, from your documents
Test cases and their step tables
The automated script for an approved test case
The per-release impact analysis
The version-specific validation report
Failure triage, as a proposal attached to the run
Must never
Decide or record a pass or fail
Apply or trigger an electronic signature
Approve a requirement, a scope or a release
Transition any GMP artefact beyond draft
Be the sole reader of anything entering the record
Draft EU GMP Annex 22 admits only static, deterministic models in GMP-critical applications and excludes large language models from them, while leaving them available for non-critical tasks under human oversight. AI is kept out of the GMP-critical path, so the design does not depend on the final wording of Annex 22. The boundary is enforced by permissions: the authoring account has no transition or signature rights on GMP records. The use of the tool is declared in the validation plan.
05
What a machine may prove, and what only a person may
A test case may be automated when
The expected result is objectively decidable — a value, a state, a presence or absence — with no judgement about adequacy or legibility.
The behaviour is deterministic from a known starting state.
The evidence a reviewer needs is fully capturable by the harness.
Failure is loud — a silent pass caused by a changed selector must not be possible.
It stays with a person when
The signature ceremony itself is under test — review and approval by two distinct individuals, and the rules that enforce it.
The output is a document a human must be able to read and rely on — the executed record, the audit trail export, a printout's copy marking.
The test is about perception or human factors — shop-floor operation, glove use, whether a change log reads to someone who did not write it.
The assertion requires domain judgement — whether a calculated result is plausible for the process, not merely equal to a number.
Segregation of duties is tested with different user identities.
Anything is new in this release. The first test of a new feature is always carried out by a person; automation is used for regression testing.
The split is a risk decision taken case by case with quality assurance, not a technical one. The FDA's Computer Software Assurance guidance, final since September 2025, endorses risk-based assurance and unscripted methods where process risk permits, and endorses leveraging supplier testing.
06
Every release runs the same gates
Continuous checks
Static analysis, unit tests and build on every change — engineering hygiene, no GMP claim
No person
Scheduled regression
The automated suite against the controlled stage environment, unsigned and marked informational
No person
Impact analysis
The regression scope proposed from the release diff against the traceability graph
Drafted
Scope approval
Quality reviews and edits the proposed scope into an approved test plan set
A person decides
Formal execution
The approved test plans, once, against a frozen build in the qualified environment
A person reviews and signs
Human test points
The cases that stay with a person, plus the exploratory charters for anything novel
A person executes and signs
Release decision
The version-specific validation report, with every finding dispositioned
A person reviews and signs
Unsigned scheduled runs are engineering feedback and are marked as such — never validation evidence. The formal execution is a separate, deliberate run against the frozen build in the controlled stage environment, once per release.
07
How we know the automation still tests something
Negative controls, every run
Deliberately broken fixtures the suite must fail on. If they pass, the run is void.
Periodic manual sampling
A person hand-executes a random sample of the automated cases from the approved script and compares the result. Any difference is raised as a defect against the harness.
Tool qualification
The harness is qualified under GAMP 5 Appendix M9 and must demonstrate that a failure is imported as a failure and an unmapped test as unmapped.
What the reviewer signs over
A step record as PDF is the primary evidence — numbered steps, the approved wording, the observed result, a screen capture per step, timestamps, and a header tying it to the test case version, the release and commit, the environment, the reference dataset and the identity that executed. Recordings and interaction traces are retained as investigation aids; they are not the record, because the record must remain readable for the whole retention period without depending on a particular viewer. Each artefact is hashed at generation and written to storage that is write-once for its retention period.
One run, one build, one environmentNo signature over a red or skipped runReruns additive, never destructiveRaw evidence reachable, and retained
08
What does not transfer
The decisions stay with you. We prepare them so they take little effort.
The decisions
Whether to use new functionality, approving the requirements, approving the executions. Your approvals are the independence control. They are presented as changes against the previous approved version.
Regulatory accountability
You are the manufacturer. Your quality function signs; a contract does not change this. Validation activities are contracted under EU GMP Chapter 7, with the responsibilities of both parties written down.
Your training and periodic review
Of the system as it operates in your process. The people authoring and executing your validation are not the people who wrote the code under test.
09
Evidence for a computer vision model
The agreed use, detection performance under the tested conditions, thresholds, known limits, a versioned model, and the result of a practical test — see how a model is prepared under computer vision. A general software test is not by itself evidence that a specific customer model is fit for its intended use.
10
Ongoing operation and change
Support also covers changes, re-testing and the maintenance of evidence over time. Scope and intervals are agreed with you; this does not by itself add anything to the price of a licence.
Draft. Applies to Augmenticon ONE.
This page states the strategy. The service levels, the stage environment and what each level includes are in the Validation Services document. The regulatory ground is moving — draft Annex 22 is not adopted and Annex 11 is in revision — and the validation plan is reviewed when the final texts land. References to Annex 11/22, the AI Act, FDA guidance or other standards should be checked against current primary sources before public use; this page is background material for that check, not a certification.
11
Microsoft infrastructure. Hosted in Switzerland.
Standard hosting uses a multitenant environment with defined operating parameters. A dedicated instance with a selectable hosting location is available as a separately priced option on Microsoft infrastructure.
Standard operation: multitenant, on Microsoft infrastructure, with a Switzerland default location.
Backup and other operating parameters are fixed as part of the standard offering.
A dedicated instance is priced separately, with the location chosen from the offered range — still on Microsoft infrastructure.
Backup intervals, retention periods, RPO/RTO, availability percentages, encryption commitments and security certifications are not stated here and are not confirmed. Multi-server or load-balancer options are not a topic of the main site; such detail belongs in an agreed technical data sheet. This description of hosting is not a data-residency guarantee for external services — your own connected AI, a training platform, or a video/transcription service — those are answered separately once the specific connections are settled.
Guided setup, customer-managed configuration and automation are designed to reduce implementation and ongoing validation effort. User licenses, implementation, validation services and dedicated hosting are priced separately, so the scope and cost of each part can be agreed clearly.
User licenses
Access according to the user's license type
Implementation
Agreed setup, onboarding and implementation support
Validation and revalidation
The agreed documentation, testing and validation service scope
Dedicated instance
Optional dedicated deployment on Microsoft infrastructure
Custom development
Agreed customer-specific work, such as additional computer vision model development
The license does not include implementation or validation services. A simpler license is planned for operators who execute and document work, with administration in the same category; a more extensive license covers broader use. Exact role scopes and names are still to be confirmed before publication, and a lower license price does not imply an administrator holds no security-relevant permissions.
No prices, currency or billing period are published here. Write to us for the cost of your setup.