What qualifies for an Engineering Workflow MVP Pilot?

A suitable case has one repeated engineering decision, a named technical owner, defined inputs and outputs, reference cases or data, and a measurable manual-work, error or traceability problem.

Does the pilot replace existing engineering software?

No. The pilot can preserve or connect existing spreadsheets, Python code, CAE tools, test files and CAD workflows. It replaces one fragmented workflow, not the organisation's complete software stack.

Does AI make the engineering decision?

No. AI may support requirements extraction, data mapping, comparison, explanation and documentation. Physics, deterministic calculations, validation limits and engineering authority remain explicit and engineer-controlled.

Breshev Engineering · Selective build pilot

One engineering workflow. One working MVP.

The Engineering Workflow MVP Pilot turns one repeated engineering decision — currently trapped in spreadsheets, scripts, manual CAE handoffs, test files, or one expert’s head — into a controlled internal application with acceptance cases and explicit decision limits.

Describe one workflow Check qualification See AURA as proof

The commercial problem

Your calculation may work. The workflow around it may not.

Many engineering teams already have the physics, software licences, spreadsheets, scripts, simulations, and test data they need. The delay comes from repeated setup, manual transfer between tools, undocumented judgement, inconsistent units, fragile reporting, and no controlled boundary between a result and the decision it supports.

This pilot does not begin with “add AI.” It begins with one engineering decision, the existing method behind it, and the evidence required to trust a working MVP.

Four entry cases. One pilot structure.

Calculation workflow

Spreadsheet or script → controlled app

Preserve or refactor a proven calculation, add controlled inputs and units, candidate comparison, regression cases, provenance, and automatic reporting.

Simulation workflow

Repeated CAE loop → reusable decision tool

Automate model preparation, parameter studies, selected solver handoffs, result extraction, comparison, and the applicability boundary of surrogate or reduced-order outputs.

Test-data workflow

Test files → model and evidence loop

Align conditions and channels, compare model and test, expose residuals and tolerance bands, identify missing evidence, and prioritise the next useful test.

Configuration workflow

Requirements → feasible engineering configuration

Capture constraints and expert rules, screen feasible variants, connect the result to CAD or drawing inputs, and preserve why a configuration is acceptable.

What the MVP contains

Workflow contract: one decision, named users, controlled inputs and outputs, exclusions, and acceptance criteria.

Engineering kernel: the existing calculation, rules, scripts, data transformations, or solver handoffs are preserved, tested, or refactored — not silently replaced by a language model.

Reference and regression cases: known cases are converted into repeatable checks so changes can be compared against an accepted basis.

Working application: a usable interface for the selected workflow, with unit control, configuration state, comparison, result export, and a defined deployment boundary.

Evidence and provenance: calculated, measured, imported, assumed, and inferred information remain distinguishable.

Handover package: application build, acceptance record, technical note, limitations, and the next scale-up decision.

Qualification gate

The strongest first case meets most of these conditions:

Repeated: the workflow occurs often enough that manual effort, inconsistency, or delay is measurable.

Bounded: one engineering decision can be isolated without rebuilding the company’s complete PLM, CAE, or ERP environment.

Owned: a technical owner can explain the current method and approve reference cases.

Testable: known calculations, datasets, reports, drawings, or prior cases exist for acceptance.

Valuable: success can be measured as less engineering time, fewer handoff errors, faster comparison, better traceability, or a clearer decision boundary.

Bounded AI

Where AI can help

Requirements extraction, document and data mapping, comparison, cited explanation, report drafting, change-impact explanation, and next-action suggestions.

Engineering authority

What AI does not replace

Physics, deterministic calculations, solver configuration, reference cases, validation envelope, acceptance criteria, and the final engineering decision.

A scoped path from pain to proof

01QualifyOne workflow, one decision, one technical owner.

02MapInputs, tools, rules, handoffs, evidence, and failure modes.

03BuildWorking application around the accepted engineering kernel.

04VerifyReference cases, regressions, limits, and user acceptance.

05DecideUse, extend, integrate, or stop with the evidence recorded.

AURA is the proof of delivery. AURA connects direct and inverse gas-static bearing synthesis — including adjustable conical support systems — to manufacturable spindle geometry, rotor dynamics, validation evidence, and release boundaries. It demonstrates the same capability needed here: physical modelling, engineering configuration, software implementation, verification, and an inspectable decision surface in one working system.

What this pilot is not

Not a generic AI transformation programme. The scope is one engineering workflow and one measurable decision.

Not a replacement for enterprise platforms. The MVP may connect existing CAD, CAE, test, PLM, or data tools; it does not pretend to replace the entire stack.

Not autonomous engineering authority. The application exposes assumptions and decision limits; the responsible engineer retains authority.

Not speculative software before pain is visible. No build starts until the current workflow, reference basis, user, and value test are explicit.

Current commercial status

Selective pilot launch — one qualified workflow at a time.

Commercial scope, duration, deployment, and fee are defined in writing after qualification. No generic package is forced onto a workflow that does not fit. A strong first message contains the current workflow, the repeated decision, the tools or data involved, and what delay or uncertainty the team wants to remove.

Describe one workflow Back to services

Confidential workflows can be discussed under NDA. Client data and project-specific results remain client-confidential. Breshev Engineering background IP, AURA methods, and pre-existing reusable components remain separately identified. Final release authority remains with the client organisation.