Reference architecture
Private engineering assistant with controlled evidence
A bounded assistant architecture using approved engineering sources, citations, access control, abstention and human review without direct machine authority.
Evidence baseline
What is represented
- Representative approved manuals, design records and support questions.
- Retrieval and answer evidence separated from deterministic control.
- No customer data, accuracy result or autonomous production use is represented.
Constraints
What shaped the engineering model
- Answers must expose source evidence and uncertainty.
- Information access must respect the requesting identity and document class.
- Model output cannot authorise a machine or quality 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 |
|---|---|---|---|
| Evidence-backed response | Retrieval/citation flow | Grounded question set | Architecture demonstrated |
| Protect information | Identity/access filtering | Authorised/denied scenarios | Control pattern defined |
| Fail visibly | Abstention/escalation | Unknown/conflict scenarios | No accuracy claim made |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Responses provide reviewable evidence from approved sources
- Unauthorised sources are excluded for test identities
- Unknown, conflicting or insufficient evidence invokes defined fallback
Deliverable manifest
What makes the decision reviewable
- Intended-use/authority boundary
- Source and access model
- Retrieval/citation architecture
- Evaluation and failure scenarios
- Monitoring, update and escalation plan
Limitations
What this evidence does not establish
- Reference architecture does not demonstrate suitability for a customer intended use.
- Model and retrieval behaviour remains probabilistic and requires monitoring.
Residual risk
What still requires ownership
- Source quality and access metadata govern answer quality.
- Users may over-trust fluent output without effective training and interface design.
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.