The drawing had passed every internal review. Package, mass, interfaces and nominal performance were all green. Long-lead tooling had already been released when the supplier finally demonstrated what its process could repeatedly hold. One critical tolerance was possible in principle, but not at the required capability on the nominated machine, with the selected material and the planned cycle time. The geometry had to change.
At that point, the change was no longer just an engineering decision. It was a tooling change, a sourcing discussion, a prototype rebuild, a test-plan update and a programme delay. The organisation paid twice: first to design the part without definitive manufacturing evidence, then to redesign it after the physical world supplied that evidence.
This is one of the central inefficiencies in vehicle development. OEM programmes use physical samples to convert uncertainty into evidence, but decisive supplier and process knowledge often arrives after the design decisions it should have informed. The result is a sequence of A-, B-, C- and D-sample loops in which design, documentation, procurement, tooling, build, test and analysis are repeated. The work differs in each loop. The expensive serial shape does not.
Verified Engineering changes the source and timing of that evidence. It turns relevant supplier, manufacturing, part and programme data into a computable knowledge graph; expresses the engineering gate as an auditable reward function; and places both inside an AI-native CAD proof kernel. Designs can then be generated, challenged and improved in digital space against the constraints that will govern them in production.
The objective is not to make the quality gates easier. It is to reach the same or better evidence earlier, so that fewer physical loops are required to reach them.
The physical sample loop is an evidence machine - and a very expensive one
A mature vehicle programme does not build samples because engineers enjoy prototypes. Each phase answers a different class of question.
An A-sample explores an innovation or competing technical concept. A B-sample proves function, package, assembly, service and early product characteristics. A C-sample is close to series intent and establishes durability, reliability and lifecycle performance. A D-sample confirms the final design using series materials, series tools and the nominated production process; it supports initial sampling, production release, homologation and the production trials that lead to start of production.
That evidence structure is rational. The cost structure is not. One complete physical loop requires a design status, released drawings and specifications, prototype tooling, procured parts, build capacity, test assets and analysis. Tool and part procurement is serial. Durability time is set by physics. A missed manufacturing constraint can restart the chain.
More engineers cannot compress a supplier's tooling lead time or make a corrosion cycle finish sooner. Removing weeks from the critical path therefore requires removing or combining a serial chain, not asking every function to work faster inside it.
The industry already tailors sample logic to programme risk. Proven concepts may skip the A-phase. Low-impact derivatives may move directly from B to D. Minor changes with high carry-over can combine C and D. The governing principle is simple: a loop may disappear only when its questions have been answered elsewhere. Today, that decision often rests on expert judgement and inherited experience. Verified Engineering makes the substitute evidence explicit, computable and auditable.
Why does manufacturability arrive after the decisions it should govern?
Before a design is fixed, the OEM has requirements, predecessor knowledge, internal simulation and supplier promises. Definitive evidence that a part can be reproduced comes much later: from process development, capability studies, measurement-system analysis, initial sample inspection and the product-and-process release.
That creates a timing gap. Component requirements and implementation specifications are completed early. Long-lead tools are ordered while some durability evidence is still incomplete. The design is frozen before the production-verification gate proves that the nominated supplier can make the final geometry with the final tool and process. By the time a capability conflict becomes undeniable, change is expensive.
APQP is explicitly a gated launch discipline, and the current
AIAG APQP third edition gives greater emphasis to sourcing, change management, programme metrics and risk mitigation. Yet most operating models still exchange crucial supplier capability through drawings, spreadsheets, presentations, emails and late review meetings. Those artefacts document knowledge; they do not make it executable.
The breakthrough is therefore not a better simulation image. It is an earlier engineering contract between requirement, design and process: this feature must satisfy these functions; it will be produced by this process family; these are the feasible materials, tolerances and joining methods; this capability distribution is supported by this evidence; and these assumptions remain unverified.
What is Verified Engineering?
Verified Engineering is a development method in which every significant design claim is tied to evidence, every optimisation is bounded by explicit constraints and every release decision produces a replayable proof chain.
It is different from conventional generative design. A generative system can propose a bracket that looks plausible or optimises mass under a simplified load case. It does not know, unless the engineering environment makes it know, whether the proposed wall can be cast at the supplier, whether a cutter can reach the pocket, whether the tolerance stack still closes after coating, whether the gauge can resolve the characteristic, whether a special characteristic has propagated into the control strategy, or whether a material substitution violates an approved requirement.
It is also different from a conventional digital twin. A twin can represent behaviour or manufacturing state, but its result is not automatically credible for a release decision. NIST's work on
digital-twin credibility is direct on this point: verification, validation and uncertainty quantification are necessary to establish fitness for the twin's intended use. A model validated for package clearance is not thereby qualified to replace a durability test.
Verified Engineering combines three layers:
1. A knowledge graph that knows what the programme requires, what the design contains, what the supplier can make and what evidence supports each statement.
2. A reward function that converts the quality gate into hard constraints and ranked objectives.
3. An AI-native CAD proof kernel in which geometry and the evidence for accepting that geometry are created and evaluated together.
The AI may propose. The proof kernel decides whether the proposal has earned the right to proceed. A qualified human still owns safety-critical approval.
Build the vehicle programme's knowledge graph before generating geometry
OEMs do not lack data. They lack a shared, executable representation of the relationships between data.
For one e-axle housing, information may exist in the requirement specification, CAD and PLM system, supplier quotation, casting guideline, material card, tolerance analysis, DFMEA, PFMEA, control plan, process-capability study, measurement-system analysis, DVP&R, issue tracker and lessons-learned database. Each document can be locally correct while the programme is globally inconsistent.
The knowledge graph makes the links first-class. Its nodes include requirements, functions, CAD features, materials, interfaces, loads, failure modes, special characteristics, manufacturing operations, machines, tools, supplier plants, capability distributions, measurement systems, simulation models, tests, standards, releases, changes, costs and approvals. Its edges state relationships such as satisfies, depends on, manufactured by, measured by, causes, mitigated by, verified by, derived from and supersedes.
This graph must preserve evidence, not just conclusions. A claim that a bore can hold a tolerance is incomplete without the supplier plant, machine, fixture concept, material state, sample size, date, process stability and measurement system behind it. A claim inherited from a predecessor must carry the boundary conditions that make inheritance valid. Missing or stale evidence must remain visibly missing or stale.
Supplier data is the pivotal addition. Candidate suppliers declare machine-readable process envelopes before the implementation specification is fixed: achievable dimensions and tolerances, material and surface options, joining constraints, tool access, draft and wall rules, thermal windows, minimum volumes, cost drivers, lead times and capability evidence. The requirement specification can then be written against reality instead of an internal ideal.
This does not mean disclosing every supplier secret to every participant. The graph can enforce ownership, access, abstraction and provenance. The OEM needs the verified envelope and evidence lineage; the supplier can retain protected process detail where the decision does not require it.
Turn the quality gate into a reward function
Engineering optimisation fails when the objective is easier to score than the product is to approve. A model rewarded mainly for mass reduction will produce a light part. It may also produce an unmachinable, fragile or uninspectable one.
The reward function must therefore mirror the hierarchy of an engineering release. It begins with hard gates: safety requirements, legal constraints, package, interfaces, load capacity, thermal limits, material compatibility, process envelope, tool access, tolerance closure, minimum process capability, inspectability and configuration integrity. A design that violates one does not receive a slightly lower score. It is rejected, with the failed rule and affected geometry identified.
Only candidates that pass the hard gates enter multi-objective optimisation. The programme can then trade mass, cost, energy efficiency, NVH, thermal performance, serviceability, embodied carbon, lead time and supply resilience. The weighting can change by vehicle or aggregate, but it cannot silently relax a mandatory constraint.
This is why the reward function should not be one opaque number. It is better represented as a gated scorecard with traceable sub-scores, acceptance thresholds, model confidence and residual uncertainty. Every accepted candidate must answer four questions: Which requirements does it satisfy? Which evidence and models support that verdict? Which assumptions remain? Which risks still require physical confirmation?
As programmes run, the reward function improves. Gate-C findings, engineering changes after design freeze, test failures and field data feed back into the graph. The system learns not from attractive geometry, but from approved proof and the exceptions that escaped it.
Put the proof inside an AI-native CAD kernel
Today's engineering stack often treats requirements, CAD, CAE, manufacturing validation and quality documentation as separate stations. A change moves from one tool to the next, and consistency depends on people noticing what the change invalidated.
An AI-native CAD proof kernel treats the part and its proof as one object. A geometry feature is linked to its requirement, manufacturing operation, tolerance, inspection method, failure modes, simulation results and approval status. When the geometry changes, affected claims are invalidated automatically and re-evaluated.
The generative layer proposes candidates. Deterministic geometry checks verify topology, dimensions, tolerances and interfaces. Qualified solvers evaluate structural, thermal, fluid, electromagnetic or NVH behaviour within their validated domain. Manufacturing checks evaluate process rules, tool access, fill or forming behaviour, assembly sequence, cycle time and cost. Quality checks trace special characteristics and confirm that proposed controls and measurement systems can demonstrate conformity.
The kernel returns more than CAD. It returns a proof package: the candidate geometry, the constraints evaluated, model and data versions, pass/fail results, uncertainty bounds, exceptions, human decisions and the artefacts needed downstream. That record is what allows digital evidence to enter a gate review without becoming an act of faith.
The
ISO 23247 digital-twin framework provides useful architecture for manufacturing twins, while its newer digital-thread and composition work recognises that lifecycle data and multiple twins must interoperate. Verified Engineering adds the release discipline: no claim is accepted merely because a model produced it.
What happens to A-, B- and C-sample programmes?
The effect should be decided by component class and uncertainty, not by a vehicle-wide slogan.
A-samples become exceptional. For known technology, proven materials and validated physics, concept options can be explored against supplier process envelopes before a physical carrier is built. Physical A-samples remain valuable where the programme is learning genuinely new material behaviour, joining physics, sensory quality or human interaction.
B-samples are the first major target. Their functional and integration questions are increasingly addressable through executable requirements, full-vehicle digital mock-up, software- and hardware-in-the-loop, validated multiphysics models and supplier-backed manufacturing envelopes. Instead of building a broad B-fleet to discover mismatches, the OEM can build a small number of targeted confirmation articles for the uncertainties the graph marks as unresolved. For some aggregates and component families, the B-loop can be eliminated or clubbed with the first C build.
C-samples can be reduced, combined or selectively eliminated - but only with a higher bar. C is where durability, reliability and near-series behaviour are normally proven. For carry-over architectures, well-characterised loads, validated material models and processes with deep historical evidence, the programme may reduce sample count, shorten the matrix, combine C and D, or remove a component-level C loop whose questions have already been answered digitally and by inherited evidence. A new battery chemistry, crash structure, brake system or thermal concept does not qualify simply because simulation is available.
The credible ambition is not "no physical prototypes." It is no default physical loop without a named question. Every retained build should state which residual uncertainty it will close. Every eliminated build should point to the digital evidence that replaced it.
What must remain physical?
Some questions exist only in the physical system or remain beyond the validated domain of available models. Long-duration ageing, corrosion, contamination, wear, coupled whole-vehicle interactions, abuse, craftsmanship, subjective perception and rare manufacturing variation often need real material and time. Homologation and market-specific certification may prescribe physical evidence. Functional-safety activities must remain integrated into the OEM's governed lifecycle; the current published
ISO 26262:2018 series is itself process- and evidence-oriented, and its next edition is still under development as of this review.
Most importantly, the D-phase and production-verification gate retain a unique purpose. A digital model can show that the design should be manufacturable. The series tool, series material, nominated plant and production process must still prove that the part is reproducible. Initial sample inspection, product-and-process release, production trials and final human approvals remain the control against model error and supplier drift.
Verified Engineering should make that gate quieter, not weaker. If first-time failures at production verification rise after a physical loop is removed, the substitution has failed. The programme has exchanged development time for launch risk.
How should an OEM introduce this without betting a vehicle programme?
The transition should be earned in stages.
First, build the graph from historical evidence. Choose one component family with repeated designs, capable suppliers, material data, PPAP or PPF packages, test results, engineering changes and field history. Reconstruct what the organisation knew at each gate and identify which later findings could have been predicted earlier.
Second, encode the gate and run in shadow mode. On a live programme, the system evaluates every design candidate and predicts manufacturability, capability conflicts and sample outcomes, but the existing process remains unchanged. Predictions are compared with B-, C- and D-sample results.
Third, qualify models for defined uses. Each solver and rule set receives an intended-use statement, validation evidence, uncertainty limits and an owner. A model can be accepted for a narrow component class and rejected outside it. This is slower than announcing an enterprise digital twin and much faster than recovering from an unjustified release.
Fourth, substitute evidence progressively. Reduce the B-sample scope first. Then remove a B-loop for a low-risk component family. Consider C reduction only after production-verification findings, late engineering changes and early warranty remain flat or improve over multiple programmes.
Finally, change commercial interfaces. Supplier capability data must arrive before award and design commitment. Contracts need rules for data ownership, permitted use, confidentiality, evidence refresh, model access and liability. Procurement cannot optimise price after engineering has optimised geometry and then expect the knowledge graph to reconcile the two.
How does Gottlieb make the transition from submissions to verified parts?
Gottlieb's Engineering AI thesis starts with the verifier: engineered matter becomes optimisable when the system can score correct against merely plausible. The near-term wedge is the evidence already produced around production approval.
SAFE cross-validates submission packages, and the
Proving Ground shows a staged chain from requirements to geometry, toolpath, verification and traceability.
That staged positioning matters. Gottlieb labels its current verification core as live, CAD and CAM as live-capable, intent capture and verified generation as assisted, and metrology and making as roadmap. The long-term architecture is visible in
Declared Intent,
Verified Generation and the
Verified Twin: constraints become computable, candidates are scored against the gate, and the part travels with its proof.
For an OEM, the practical sequence is to verify today's submissions, turn their evidence into the graph, calibrate the reward function against accepted and rejected parts, and only then run the verifier forward into design.
Architect captures intent as a computable specification; the proof kernel tests generated or human-designed geometry against physics, manufacturability and compliance; the human release authority closes the loop. The intervention is better evidence upstream. Fewer samples are the earned consequence.
The business case is measured in removed serial time, not faster activity
The value model should follow the program's existing evidence structure. Count physical design-procure-build-test loops by component class. Track prototype tooling, prototype parts, build slots and test capacity by phase. Measure time from concept approval to design freeze, engineering changes after series release, first-time failures at production verification, and first-year warranty and goodwill.
Success has a recognisable pattern: most of the component scope moves from three loops to two; prototype spend falls without a corresponding rise in series-tool rework; manufacturability-driven changes after design freeze approach zero; Gate-C findings remain flat or fall; and early field quality does not deteriorate.
The largest saving is calendar time. A removed loop removes a serial chain whose tooling, procurement and test durations cannot be compressed by effort. The second saving is avoided write-off: fewer prototype tools and fewer late series-tool changes. The strategic benefit is capacity. The same engineering and test organisation can run more vehicle and aggregate programmes because it spends less time rediscovering constraints that already existed in supplier and production data.
This is the real promise of Verified Engineering. It does not digitise the existing loop and call that transformation. It changes when the programme knows, what it can prove and therefore what it no longer has to build simply to learn.
Frequently asked questions
Does Verified Engineering eliminate physical vehicle testing?
No. It replaces only the physical work whose questions can be answered with qualified digital evidence. Series-process confirmation, prescribed homologation, safety-critical residual uncertainty, long-duration material behaviour and whole-vehicle phenomena outside validated model domains remain physical.
Which sample phase should an OEM target first?
The B-sample loop is usually the strongest first candidate because its function, package, interface and manufacturability questions are increasingly addressable through executable requirements, virtual integration, HIL/SIL and supplier process envelopes. The decision should still be made by component class.
Can a C-sample loop really be eliminated?
At component level, yes, in favourable cases: high carry-over, validated models, known loads and materials, capable processes, inherited durability evidence and an unchanged series-verification gate. More commonly, C scope and fleet size are reduced or C and D are combined. Novel or safety-critical systems require a much higher burden of proof.
Why is a knowledge graph necessary if the OEM already has PLM?
PLM manages product structures, files, revisions and workflows. The knowledge graph makes cross-domain claims executable: which supplier process supports a CAD feature, which evidence supports that capability, which failure mode a change reopens, and which tests or approvals become invalid when geometry changes.
Who signs a digitally verified release?
The qualified engineer or release authority defined by the OEM's quality and safety system. AI assembles evidence, identifies conflicts and checks the gate. It does not take unattended accountability for safety-critical approval.
Call to action: Start a Verified Submission and test the verification layer on evidence your program already produces.
Source notes
1. Gottlieb,
"Engineering AI" and
"The Proving Ground", accessed 2 September 2026.
2. Gottlieb,
"Security", including lineage, human approval and verification commitments, accessed 2 September 2026.
5.
ISO 23247-1:2021, digital-twin framework overview;
ISO 23247-5:2026, digital thread;
ISO 23247-6:2026, digital-twin composition.
6.
ISO 26262-1:2018, road-vehicle functional safety;
ISO/DIS 26262-1, Edition 3 under development as of 2 September 2026.
7. Internal editorial reference: The Vehicle Development Process - Reference Handbook, 31 August 2026.
