Anonymised delivery pattern
Legacy CNC and motion controls modernisation
A non-identifying pattern for installed-state capture, behavioural equivalence, staged replacement, rollback and controlled recommissioning of an obsolete control system.
Evidence baseline
What is represented
- Representative brownfield CNC/motion system with incomplete documents and constrained shutdown.
- Legacy source, parameters, wiring and observed behaviour are treated as separate evidence sources.
- No named installation, availability improvement or shutdown duration is claimed.
Constraints
What shaped the engineering model
- Undocumented operating knowledge may exist only in maintenance and operator practice.
- Drive, feedback, I/O and machine mechanics constrain migration choices.
- A viable rollback state must survive each cutover decision.
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 |
|---|---|---|---|
| Preserve required behaviour | Equivalence matrix | Legacy/new scenario comparison | Method documented; result confidential |
| Recover failed cutover | Rollback architecture | Preflight and recovery test | Criterion defined |
| Support new baseline | Source/configuration pack | Rebuild and backup review | Evidence set described |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Critical behaviours with agreed legacy evidence and new verification
- Cutover preconditions and rollback criteria satisfied
- Released source/configuration reconstructs the accepted system
Deliverable manifest
What makes the decision reviewable
- Installed baseline and evidence-confidence record
- Behaviour/equivalence matrix
- Migration and interface design
- Cutover/rollback protocol
- Commissioning and new baseline pack
Limitations
What this evidence does not establish
- Hidden legacy behaviour cannot be guaranteed before discovery and representative testing.
- Modernisation does not by itself prove mechanical condition or complete machinery conformity.
Residual risk
What still requires ownership
- Rare operating modes may retain evidence gaps requiring operational monitoring.
- Obsolete connected equipment can remain a lifecycle risk.
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.