Reference architecture
Automation data-integrity evidence chain
A reference model following an attributable machine or user event through time, interface, record, review, retention, backup and recovery controls.
Evidence baseline
What is represented
- Representative PLC/HMI, user identity, interface and retained record boundary.
- Technical controls mapped to procedural owners and intended record use.
- No compliance conclusion, inspection result or customer record is represented.
Constraints
What shaped the engineering model
- Record trust depends on people, process and technology together.
- Clock, identity, audit and backup controls span automation and IT platforms.
- Restore success must include readability, integrity and operational reconciliation.
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 |
|---|---|---|---|
| Attributable event | Identity/context model | Role/action scenarios | Reference controls mapped |
| Complete timeline | Time/buffering rules | Disconnect and clock cases | Test design demonstrated |
| Recoverable record | Backup/restore chain | Restore/reconciliation protocol | No customer restore claimed |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Required events retain identity, time, context and reviewable meaning
- Interface faults surface missing, late or duplicate data
- Restored records reconcile to the approved backup and intended application
Deliverable manifest
What makes the decision reviewable
- Record/intended-use inventory
- Identity/access/audit model
- Time/interface/exception design
- Retention/backup/recovery evidence
- Technical/procedural gap register
Limitations
What this evidence does not establish
- Technical architecture alone cannot establish organisational data integrity.
- Applicable regulatory and retention requirements depend on customer intended use and jurisdiction.
Residual risk
What still requires ownership
- Privileged administration and procedural behaviour require ongoing control.
- Infrastructure and software changes can alter the record chain.
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.