Verifying results
CoPilot is built on AI models that are probabilistic, not deterministic. This page explains what that means for your work, and the habits that catch a wrong answer before it costs you anything. It is the most useful page on this site.
Why this page exists
Most of what CoPilot does is correct, and it is faster than doing it by hand. But it is not a calculator: it predicts a likely response rather than following fixed rules. Three consequences matter in engineering work.
- The same instruction can produce different results on different runs — a different sequence of operations, or different numbers.
- Output can be confidently wrong. CoPilot may state that an operation succeeded, or report a dimension, mass or stress figure, and be mistaken. Confidence in the wording is not evidence.
- It can act on the wrong geometry — the wrong face, the wrong body, the wrong file — while describing exactly what you asked for.
Your licence agreement puts this plainly: you remain the engineer of record. Everything CoPilot produces is a draft for your review, never an approved result.
Rule 1 — ask for the measurement, not the summary
The single most useful habit. CoPilot's prose summary is written after the work; the measurement comes from the CAD system itself. Ask for the second one.
Compare that against what you expect. If you asked for a 40 × 30 × 10 mm block, the volume should be 12 000 mm³. A number that is close but not equal usually means an extra or missing feature; a number that is wildly different usually means it built something else entirely.
Rule 2 — state the expected value in the prompt
An instruction that carries its own acceptance criterion is worth several that do not. CoPilot cannot fake a measured number, so a stated target converts a hopeful request into a checkable one — and silent no-ops become impossible to miss.
An approximate target is enough. “About 22,000” still catches a change of zero, and a change of 60,000.
A volume change of zero means nothing happened
This is the most common silent failure, and it has one common cause: the cut or extrude went the wrong way. The fix is one sentence.
Rule 3 — a matching volume never proves placement
This one costs people whole afternoons. A block extruded 40 mm adds exactly the same volume whether it starts at Z = 0 or Z = 11. A slot cut through it removes the same volume at either height. The totals agree perfectly, and the part is wrong.
Two independent checks defeat this.
The bounding box
A bounding box catches a part built in the wrong orientation, at the wrong scale, or shifted along an axis — none of which a volume can see.
The probe cut
When you need to know what exists at a particular height, cut a thin test slab there, read the volume removed, and undo it.
Worked example: if a 30 × 40 mm prong should occupy that band, a 1 mm slab through it removes 1 200 mm³. Removing 3 mm³ instead tells you, unambiguously, that the prong is not there — whatever the total volume says.
Rule 4 — read the placement evidence
When a feature is created away from the model origin, the reply includes the world coordinates the geometry actually landed at — the sketch plane's real origin, a rectangle's world centre, a line's world start and end, an extrude's direction and the volume before and after. This is read back from the created geometry, not echoed from your request.
Compare those numbers against what you asked for before building the next feature. If the sketch is on the wrong plane, everything after it is wasted work.
Rule 5 — check that a feature exists, not that it was reported
“Added the fillet” and “there is a fillet in the tree” are different claims.
For a cut or a fillet, the volume should also have changed. If you add a 5 mm fillet to a 40 mm cube and the volume is still exactly 64 000 mm³, the fillet did not happen no matter what the reply said.
For fillets specifically, the reply carries per-edge evidence: each edge's type, midpoint, length and the distance from the point you gave. Edge lengths are a good identity check — if you know what the edges should measure, matching lengths prove the right edges were picked.
Rule 6 — different objects need different evidence
| What you changed | What to ask for |
|---|---|
| A solid feature | Volume and bounding box; a probe cut if position matters |
| A hole or pattern | Feature list plus face count, and the volume removed |
| An assembly mate | The solver status, the two bound faces' axes and radii, and the assembly bounding box |
| An assembly in general | Component count and bounding box — not volume, which is unreliable at assembly level |
| A drawing | A listing of views and annotations with their values, plus a screenshot |
| A translated part | Volume and bounding box against the source; expect a small fraction of a per cent |
| A simulation | Face areas and normals, load direction, reaction force, a hand calculation, a second mesh size |
Assembly mates: existence is not health
A mate can sit in the tree and be broken. Every mate CoPilot creates is checked against the solver, and one that does not come back healthy is deleted and reported rather than left looking finished. Read the status.
Solved is what you want. Between fixed is also healthy — it means both components are grounded, so there is nothing to solve. Then confirm nothing was dragged across the model:
Drawings verify themselves, partly
When CoPilot knows what a dimension should read, it reads the created dimension back from the sheet and deletes it if the value does not match. That is why a dimension you asked for is sometimes simply missing — it was wrong, so it was removed rather than left on a controlled document.
What that gate does not check is whether the drawing is complete or sensibly laid out. For that:
Simulation needs more care than modelling
A stress result is only as good as its setup, and the setup involves choices that are made for you unless you state them. See Simulation for the detail, but the short version:
- Name the faces geometrically — “fix the minX face”, not “fix Face1”. A face number belongs to the exact solid that produced it and can mean a different face on a rebuilt part.
- Name the load direction — “downward” is not a defined quantity. Loading a bracket across its thin dimension rather than its wide one can change the deflection by an order of magnitude, and both answers look reasonable.
- Sanity-check against hand calculation. For a simple cantilever, tip deflection is PL³/3EI. If the model disagrees with that by more than a few per cent, question the setup before believing the model.
Take a checkpoint before anything risky
Before a multi-step change, give yourself a way back.
If the result is wrong you can return to that state instead of unpicking it by hand. Your PDM system's revision history serves the same purpose for released files — see SOLIDWORKS PDM or Autodesk Vault.
When something is wrong, say what you observed
CoPilot corrects itself far better from a measurement than from a complaint. “That is wrong” gives it nothing; “the volume is 9 000 mm³ but should be 12 000” tells it exactly what to look for.
A refusal is good news
CoPilot increasingly stops rather than guessing: an unresolved fillet edge, a cut that would remove more material than the body contains, a mate that will not solve, an unknown face reference. The refusal text names the measurable reason — the nearest real edge and its coordinates, the actual gap, the solver status. That is usually the fastest route to the corrected prompt. Treat it as the tool protecting the model, not as the tool failing.
Where not to rely on it at all
Do not use CoPilot as the sole basis for a decision affecting safety, structural integrity, regulatory compliance or significant cost. It is not certified for safety-critical, medical, aerospace-airworthiness or nuclear work. Treat it as a capable colleague whose work you check, not as an authority.
A note on model changes
Behaviour can shift when a provider updates or retires a model, when your organisation selects a different one, or when you supply your own provider key. A prompt that worked reliably last month is worth re-verifying after a model change rather than assumed.