Demonstrator
Controlled AI-assisted engineering change
A demonstrator routing an approved change through bounded AI proposals, source control, peer review, automated checks, tests, traceability and human release.
Evidence baseline
What is represented
- Representative engineering software change and repository controls.
- AI output is treated as a proposal, not an approved implementation.
- No customer productivity, defect reduction or regulatory outcome is claimed.
Constraints
What shaped the engineering model
- Sensitive inputs remain within the approved tool/data boundary.
- Reviewers must understand the changed behaviour and dependencies.
- Release cannot be delegated to the generative model.
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 |
|---|---|---|---|
| Controlled input | Context/data policy | Allowed/blocked examples | Workflow demonstrated |
| Reviewable change | Repository/review gates | Diff, checks and reviewer record | Method demonstrated |
| Accountable release | Human authority gate | Approved release record | No productivity claim made |
Measurable acceptance
What a real engagement would measure
These are acceptance measures, not published customer results.
- Proposed changes linked to an approved task and reviewed diff
- Required checks/tests complete before release eligibility
- Dependencies, provenance and exceptions retained with the change
Deliverable manifest
What makes the decision reviewable
- Approved-use and data boundary
- Change/requirement trace
- Versioned proposal and review record
- Automated/manual test evidence
- Human release and rollback record
Limitations
What this evidence does not establish
- Demonstrator evidence is not a general productivity or safety result.
- Tool/model behaviour changes require reassessment for material use.
Residual risk
What still requires ownership
- Competent review remains the principal control for plausible errors.
- Generated dependency and licence risks require automated and manual checks.
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.