Define
Requirements & acceptance
Intended outcome, boundary, constraints, risks and testable acceptance.
Explore this routeAxiotech delivery method
Requirements become evidence through named engineering gates.
The method scales to a review, a software change or a complete machine-controls package. Each gate makes authority, baseline, evidence and unresolved risk visible before commitment increases.
G0–G5
Six decisions, not six document piles
Artefacts scale with intended use and risk; the decision chain remains.
- 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.
Assurance matrix
Connect every important need to its proof
A live project adds identifiers, versions, owners and approval states to this structure.
| Controlled item | Question | Typical evidence | Authority |
|---|---|---|---|
| Requirement | What must be true and why? | Approved criterion and source | Customer/OEM requirement owner |
| Design | How will responsibility and behaviour be realised? | Architecture, module, interface and risk records | Named technical approvers |
| Implementation | Which exact source and configuration implement it? | Repository, dependencies, build and settings baseline | Engineering release owner |
| Verification | What evidence supports acceptance? | Review, analysis, simulation, FAT/SAT and agreed qualification | Protocol/test approvers |
| Release | What is accepted, deferred or residual? | Defects, deviations, approvals, backup and release note | Customer/OEM release authority |
Document architecture
Documents exist to control decisions
A proportionate set may include requirements, functional/system design, software and module design, interfaces, configuration, risk, traceability, test, release and recovery evidence.
Design
Architecture & interfaces
Responsibilities, modules, data, devices, failure behaviour and configuration.
Explore this routeProve
Trace, verify & release
Controlled versions, reviews, tests, defects, deviations and residual risk.
Explore this routeVerification evidence
Allocate proof to the right environment
Review, analysis, unit/regression tests, simulation, bench tests, FAT, SAT and qualification support answer different questions. The strategy states what each stage proves, the controlled baseline, prerequisites, objective evidence, deviation route and approval authority.
Review FAT/SAT and qualification supportLifecycle and remote support
A released system still needs controlled change
Incident authority, access, baseline capture, diagnosis, intervention, source reconciliation, result, rollback and access closure form one support record.