Reference architecture
GAMP 5-aligned automation evidence chain
A reference lifecycle connecting intended use and quality risk to proportionate requirements, design, configuration, verification, deviation and release evidence.
Evidence baseline
What is represented
- Representative automation supplier/customer responsibility boundary.
- Tool-neutral lifecycle records scaled to risk and intended use.
- No regulated customer, validation approval or compliance conclusion is claimed.
Constraints
What shaped the engineering model
- The regulated organisation retains validation ownership and quality release authority.
- Document quantity is not a substitute for risk-based content and use.
- Supplier evidence must map into customer procedures and approved plans.
Responsibility boundary
Who owns which decision
Named ownership prevents a technical work package from silently expanding into product, site, safety, quality or release authority.
Responsibility 1
Axiotech: the engineering method, scoped technical artefacts and stated verification evidence.
Responsibility 2
Customer/OEM: intended use, site constraints, acceptance authority and information supplied.
Responsibility 3
Other competent parties: safety, mechanical, process, quality or infrastructure decisions outside the stated scope.
Lifecycle proof
Decision gates used by the evidence model
The case does not equate activity with acceptance. Each gate has authority, inputs, evidence and unresolved-item visibility.
- G0Scope authorityOutcome, boundaries, roles, assumptions and commercial basis agreed.
- G1Baseline acceptedKnown installed/source state, dependencies, constraints and unknowns recorded.
- G2Design approvedRequirements, interfaces, risks and acceptance evidence ready for implementation.
- G3Release candidateBuild reviewed, verified, versioned and accompanied by defect disposition.
- G4Site acceptanceCommissioning evidence, deviations and release decision recorded.
- G5Handover acceptedSource, configuration, records, recovery and residual risks transferred.
Requirement-to-evidence assurance matrix
A compact proof structure
Public result statements remain deliberately bounded. Project-specific values require approved evidence.
| Need / requirement | Design control | Evidence | Public result status |
|---|---|---|---|
| Fitness for intended use | Risk-based requirements | Traceable verification set | Reference lifecycle only |
| Controlled configuration | Baseline/change model | Version/release records | Evidence pattern documented |
| Owned approval | Responsibility matrix | Review/signature states | No validation claimed |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Approved requirements allocated to risk-proportionate verification
- Released source/configuration matches the accepted evidence baseline
- Deviations and residual risks have named disposition authority
Deliverable manifest
What makes the decision reviewable
- Intended-use/boundary/responsibility record
- Risk-based requirements and design
- Configuration/source and trace baseline
- Verification/deviation evidence
- Release input and residual-risk handover
Limitations
What this evidence does not establish
- GAMP 5 alignment is not certification and does not determine all applicable obligations.
- Customer quality-system procedures and intended use are required project inputs.
Residual risk
What still requires ownership
- Operational procedures, training and infrastructure remain part of the complete validated state.
- Later changes require maintained traceability and impact assessment.
Apply the method
Start with a bounded assessment or engineering work package.
Project facts, responsibilities and acceptance measures are confirmed before any outcome is promised.