GOM Inspect is now ZEISS INSPECT: what the rename changed, and what actually moves your numbers

2026-08-25 · long read · no math background needed

If you learned this software as GOM Inspect, the splash screen now says something else. The rename is real, it is documented, and it is also the least important thing that happened to your inspection process. A name is not in the arithmetic. What is in the arithmetic is a handful of settings that live inside your project templates — and this note shows one of them turning a conforming face into a rejected one, with six numbers you can check on paper.

1. What actually happened to the name

ZEISS acquired GOM in 2019; the entity was renamed Carl Zeiss GOM Metrology GmbH in 2022. For several years after the acquisition the software kept its old badges. With Release 2023 the GOM software line was consolidated under a single name, ZEISS INSPECT, and the individual products were remapped like this:

Three practical points come from the vendor's own transition page and are worth stating plainly, because they are the questions people actually ask. First, the free version survived the rename, as did the viewer, now called ZEISS INSPECT Viewer — though the vendor also stated that some features would move into the pro version at the same time. Second, existing licenses were not invalidated by the rename — the same entitlement carries over under the new product name. Third, existing projects and legacy data are carried forward by the software upgrade rather than requiring a manual rebuild.

That is the whole naming story, and it is genuinely uneventful. Stated as plainly as it can be: GOM Inspect is now ZEISS INSPECT Optical 3D, and the rename changed no measured value. The reason it still causes friction years later is that the industry did not switch vocabulary in step. Drawings, work instructions, quality manuals, job postings, supplier requirements, and internal script libraries are all still full of the string GOM Inspect. A supplier quality engineer reading "inspect per GOM Inspect Pro report" on a 2021 document has to know that the current equivalent is the pro tier of ZEISS INSPECT Optical 3D before they can even find the software. So the rename is a documentation problem, not a metrology problem.

2. A rename is not in the arithmetic

Here is the sentence worth pinning above the workstation: the fitting algorithm does not know what the software is called. A least-squares plane through six points returns the same plane whether the title bar says GOM Inspect 2020 or ZEISS INSPECT Optical 3D 2026. Renaming a product cannot move a measured value, because the name is not one of the inputs.

This matters because renames get blamed for changes they did not cause. When a shop upgrades, three separate things usually happen at once: the software is renamed, the version number advances, and somebody rebuilds or re-imports a project. Only the last two can move a number, and in practice it is almost always the third. The instinct to say "our numbers changed when we went to ZEISS INSPECT" is understandable and almost always misattributed.

What genuinely can change across a version boundary is a short and checkable list:

• Defaults inside project templates — the association method for a fit, the outlier rejection policy, the point-selection rule, the number of decimal places a report shows.
• The alignment recipe — whether a part is placed by a global best fit, by a datum reference frame, or by RPS points, and in what order.
• Mesh preparation — smoothing and thinning parameters applied during mesh editing before anything is evaluated.
• Script and app interfaces — a renamed or restructured scripting API means an automation script may need updating even when the underlying computation is unchanged.

Every item on that list is a setting, not a name. Which brings us to the part you can verify yourself.

3. Where an inspection number actually comes from

Whatever the software is called, an inspection number is produced by four stages in sequence, and each one is a place where a decision gets made on your behalf. A single software interface hides all four, which is exactly why they are easy to forget.

Stage one, acquisition. A sensor produces raw 3D data. For fringe-projection scanners and laser scanners that means point clouds, which are then used to create polygon meshes. For X-ray systems it means volume data that has to be surfaced before anything can be measured. For tactile coordinate measuring machines it means a modest number of discrete probed points. Different physics, same next step.

Stage two, nominal. You import CAD data so the measurement has something to be compared against. The CAD import brings in surfaces and, if the CAD model carries it, product manufacturing information — the geometric dimensioning and tolerancing callouts themselves. If you import CAD data without that information, the tolerances live in somebody's head or on a separate drawing, and the inspection process becomes a manual transcription exercise.

Stage three, alignment. The measured data and the CAD model start in unrelated coordinate systems. Something has to decide how the part sits relative to the nominal. This is the stage that this note is about, because it is the one that most quietly changes answers.

Stage four, evaluation. Features are associated — a plane fitted to a patch, a circle fitted to a bore — and compared against the nominal to produce a deviation, a form value, or a pass/fail. Surface inspections, nominal-actual comparison and the reporting functions all draw their numbers from this stage, and so do the geometric dimensioning and tolerancing inspection tasks. The association step is where the fitting rule lives; if you want that layer in detail, see Gaussian vs Chebyshev.

Notice that only stage one involves hardware. Stages two through four are software decisions, which is exactly why "the same part, measured on the same measuring machine, reported two different numbers" is such a common and such a solvable quality control complaint.

4. The experiment: one flat face, six points

Take a mounting face, nominally flat, 100 mm by 80 mm. The CAD model says every point on it should sit at height zero. We inspect it at six locations and record how far each measured point sits above nominal, in millimetres.

Three of those six locations are not ordinary points. They are datum targets — the three spots specified as the ones that establish datum A, the primary datum plane. Call them A1, A2 and A3. Three points is exactly what it takes to fix a plane, which is why drawings specify three of them; the reasoning behind that is worked through in the datum reference frame.

These are hypothetical numbers chosen to be checkable on paper, not data from any real part or customer. Everything below is arithmetic you can redo with a calculator.

The face carries a profile-of-a-surface tolerance of 0.05. That is a total zone width of 0.05 mm, and unless the callout is marked unilateral or unequally disposed, that zone is equally disposed about the true profile — so the surface must lie within ±0.025 mm of nominal. The nominal face here is coincident with datum A, which is why distance from the datum plane is the profile deviation in what follows.

And here is the fork in the road: a profile callout with a datum reference is evaluated with the part locked to those datums, while a profile callout without a datum reference lets the zone float to wherever it best contains the surface. Both are legal callouts. They are not the same requirement, and the software will happily compute either one. So treat what follows as two alternative drawings of the same part — one that references datum A on this face and one that does not — measured from one set of points.

5. Alignment one: the best-fit plane, by hand

A global best fit asks: what single plane sits closest to all six measured points at once, in the least-squares sense? Write the plane as a height that varies linearly across the face:

The arithmetic gets easy if we measure position from the centre of the point pattern rather than from the corner. The six x values are 0, 100, 0, 100, 0, 100, which sum to 300, so the average is 300 / 6 = 50. The six y values are 0, 0, 40, 40, 80, 80, which sum to 240, so the average is 240 / 6 = 40. Define the centred coordinates u = x − 50 and v = y − 40.

This particular pattern is symmetric, which makes the three unknowns separate cleanly instead of tangling together. The reason is the cross term: Σu v comes to 2000 − 2000 − 2000 + 2000 = 0 — those are P1, P2, P5 and P6, with P3 and P4 contributing nothing because v is zero there — and when that sum vanishes the two tilts stop interfering and can be solved one at a time. Three sums then do the work:

• Height. The best-fit plane always passes through the average of the points. The average height is 0.300 / 6 = 0.050.
• Tilt in x. Take Σu z and divide by Σu². Every point has u of ±50, so Σu² = 6 × 2500 = 15000. Then b = −9.0 / 15000 = −0.0006.
• Tilt in y. Four points have v of ±40 and two have v = 0, so Σv² = 4 × 1600 = 6400. Then c = 1.6 / 6400 = 0.00025.

So the best-fit plane is z = 0.050 − 0.0006(x − 50) + 0.00025(y − 40). Multiply that out: the constant becomes 0.050 + 0.030 − 0.010 = 0.070, giving

Now evaluate that plane at each point and subtract to get the deviation. At P1 (0, 0) the plane sits at 0.070, and the point is at 0.060, so the deviation is −0.010. At P2 (100, 0) the plane is 0.070 − 0.060 = 0.010 and the point is at 0.020, so +0.010. At P3 (0, 40) the plane is 0.070 + 0.010 = 0.080, matching the point exactly, so 0.000. At P4 (100, 40) the plane is 0.070 − 0.060 + 0.010 = 0.020, again exact, so 0.000. At P5 (0, 80) the plane is 0.070 + 0.020 = 0.090 against a point at 0.100, so +0.010. At P6 (100, 80) the plane is 0.070 − 0.060 + 0.020 = 0.030 against a point at 0.020, so −0.010.

Deviations under the best fit: −0.010, +0.010, 0.000, 0.000, +0.010, −0.010. They sum to zero, which is the signature of a correct least-squares fit — if they did not, the plane could be slid up or down to do better. The largest deviation is 0.010 mm and the spread from lowest to highest is 0.020 mm.

6. Alignment two: three datum targets, by hand

Now take the drawing that references datum A. Datum A is established by the three datum targets A1, A2 and A3 — that is, by P1, P2 and P5. A plane through three points is not a fit at all; it is an exact solution, because three points that do not lie on a straight line determine a plane uniquely. Ours are not collinear: P1, P2 and P5 form a right angle across the face. Solve for the same three unknowns.

At P1, (0, 0), the plane must equal 0.060, and since both coordinates are zero the constant is read straight off: a = 0.060.

At P2, (100, 0), the plane must equal 0.020. So 0.060 + 100b = 0.020, giving 100b = −0.040 and b = −0.0004.

At P5, (0, 80), the plane must equal 0.100. So 0.060 + 80c = 0.100, giving 80c = 0.040 and c = 0.0005.

Evaluate at all six points. At P1 the plane is 0.060 and the point is 0.060, so the deviation is 0.000 — by construction. At P2 the plane is 0.060 − 0.040 = 0.020, deviation 0.000, again by construction. At P5 the plane is 0.060 + 0.040 = 0.100, deviation 0.000, likewise. The three datum targets always land exactly on their own datum; that is the definition.

The other three are where it gets interesting. At P3 (0, 40) the plane is 0.060 + 0.020 = 0.080 and the point is at 0.080, so the deviation is 0.000 — a coincidence of this data set, nothing more. At P4 (100, 40) the plane is 0.060 − 0.040 + 0.020 = 0.040 against a point at 0.020, so −0.020. At P6 (100, 80) the plane is 0.060 − 0.040 + 0.040 = 0.060 against a point at 0.020, so −0.040.

Deviations under the datum alignment: 0.000, 0.000, 0.000, −0.020, 0.000, −0.040. The largest deviation is 0.040 mm.

7. Same points, four times the deviation

Put the two columns side by side.

Four times the deviation, from identical measured data. Now apply the 0.05 profile tolerance, which permits ±0.025 about the true profile.

If the callout carries no datum reference, the zone floats to whatever position best contains the surface — a minimum-zone criterion, not a least-squares one. For this data set the two happen to coincide: section 8 proves that the least-squares plane is also the minimum-zone plane here, so the half-width is 0.010 mm either way, comfortably inside ±0.025. The face conforms.

If the callout is referenced to datum A, the part must be locked to the datum targets, the datum-aligned column is the right evaluation, and the largest deviation of 0.040 mm falls outside the ±0.025 zone. The face does not conform.

This is why a project rebuilt after a software upgrade can honestly report different numbers than the project it replaced. This is not incompetence; somebody rebuilt an alignment from memory and reached for a global best fit, the choice that makes a nominal-actual comparison look tidiest, where the part's drawing had asked for datum targets. The color map looked better, and the answer was wrong.

Which one applies is not a matter of taste. The drawing in front of you decides. A profile tolerance referenced to a datum reference frame has to be evaluated in that frame; a best fit substituted for it is not a more forgiving evaluation of the same requirement, it is an evaluation of a different requirement.

8. The one number that does not move

There is a satisfying exception, and it is worth knowing because it gives you a check that survives any alignment argument. Flatness does not depend on the alignment at all.

Flatness is defined as the width of the thinnest slab that contains the whole surface — the minimum zone. Because you are free to choose whatever slab orientation contains the points best, no external alignment can influence the result. Rotate the part, re-datum it, throw the alignment recipe out and build a new one: flatness is unchanged. What a new release can still move is the association default behind the form value — but that is a setting, not an alignment, and section 10 is how you catch it.

For our six points, the answer is 0.020 mm, and it can be proved rather than merely computed. Notice that P1 at (0, 0) and P6 at (100, 80) have the midpoint (50, 40), and P2 at (100, 0) and P5 at (0, 80) have that same midpoint. Any plane, being flat, gives the same value at (50, 40) whichever pair you average across. Writing each point's height as the plane value plus its deviation and cancelling the plane terms leaves one identity:

You can check the constant directly from the measured heights: (0.020 + 0.100) − (0.060 + 0.020) = 0.120 − 0.080 = 0.040. Since two quantities add to 0.040, at least one of them is 0.020 or more, so the deviations must span at least 0.020 mm under any plane. The best-fit plane achieved exactly 0.020. Therefore 0.020 mm is not just the least-squares answer — it is provably the minimum possible, so it is the true minimum-zone flatness.

Both columns confirm the identity. Under the best fit: (0.010 − (−0.010)) + (0.010 − (−0.010)) = 0.020 + 0.020 = 0.040. Under the datum alignment: (0.000 − 0.000) + (0.000 − (−0.040)) = 0 + 0.040 = 0.040. Same constant, as it must be.

So when two reports disagree, compare their form values first. If flatness matches and the profile deviations do not, the dispute is about the evaluation, not about the measurement — and alignment is the first setting to check.

9. What to carry across when you migrate

A migration between releases — or between the free version and a pro version, or from a legacy GOM software project into ZEISS INSPECT — is safe when you treat the project as a recipe rather than a file. Written down, the recipe for each inspected characteristic is short:

1. The alignment, in order. Prealignment, then what: global best fit, datum reference frame, RPS points? Which measured features or targets feed each step? This is the item that moved the number by a factor of four above, so it belongs first.
2. The association method per feature. Least squares, minimum zone, maximum inscribed, minimum circumscribed. A default that differs between two project templates will differ silently forever.
3. Point selection and filtering. Which region of the mesh feeds a fit, and what smoothing or thinning ran during mesh editing before it did.
4. The outlier policy. Whether points are rejected, by what criterion, at what threshold. Automatic outlier rejection is the setting most likely to be on without anyone remembering.
5. Reporting precision. A value shown to three decimals in one release and two in another is not a changed measurement, but it will start an argument that costs a morning.
6. Script and app dependencies. Any automation attached to the project, plus which release its interfaces were written against.

Six lines per characteristic, and they answer the only question that matters during a software upgrade: would this recipe produce the same number tomorrow? That record is also what makes trend analyses meaningful across a release boundary — a trend built from values computed under two different alignment recipes is not a trend, it is two data sets in one chart. The same goes for a digital assembly built from several inspected parts: if the parts were aligned by different recipes, the assembly is comparing incomparable numbers.

10. The migration acceptance test

The record above tells you what should be the same. One test tells you whether it is.

Pick one part you have already measured and archived. Re-evaluate the archived measurement in the new release — the same data, not a fresh scan, because a fresh scan introduces measurement variation and confounds the comparison. Export both result sets and subtract them characteristic by characteristic.

Every difference should be zero or explainable. Exactly zero means the recipe survived; a difference at the last displayed decimal is a precision-display change; anything larger is a setting that did not carry across, and the six-line record tells you where to look. This is a half-day of work that converts "we think the upgrade was fine" into evidence, and it is the same discipline as any other measurement system check: if you would run a gage R&R before trusting a gage, run a difference test before trusting a new evaluation path.

Two things this test does not do, and should not be asked to do. It does not tell you which of the two answers is right — only that they differ; the drawing settles correctness. And once you know which evaluation the drawing requires, the leftover difference does not fold into your stated measurement uncertainty — a setting nobody chose is a mistake to be eliminated, not a random effect to be budgeted. Where the drawing itself is genuinely ambiguous about the required association or datum scheme, that ambiguity is a legitimate uncertainty contributor. The distinction is between a requirement you have not pinned down and a setting you simply got wrong.

Run the test once per release you adopt, on one representative part per part family. Keep the exports. The first time a customer asks whether your results changed when you upgraded, the answer is a file rather than an opinion.

11. Why automation raises the stakes

Everything above is manageable when a person opens each project, looks at the alignment tree, and notices something odd. Automation removes the person.

The whole point of scripting an inspection process is that the same recipe runs on part after part without intervention — which is exactly why a wrong setting is more expensive in an automated cell than at a workstation. The factor-of-four above would have been caught in minutes by an engineer who opened the alignment tree and read it against the drawing. Frozen into a script that runs a 24-hour cell, it becomes a month of reports built on the wrong alignment.

The same property cuts the other way, which is the reason to automate at all. A recipe written down once and executed by software is the only kind of recipe that is genuinely repeatable — no interpretation, no operator-to-operator variation in how a fit region was picked, no drift as the technique passes between shifts. Automation does not create the risk; it makes an existing, invisible risk visible and fixable. What it demands in exchange is that the recipe be explicit, versioned, and tested — which is precisely what the record in section 9 and the acceptance test in section 10 are for.

So the honest summary of the rename is this. GOM Inspect becoming ZEISS INSPECT changed a name, a set of documents, and the search terms you use to find a download. It did not change a single number. The things that change numbers were always the settings underneath, and the upgrade is simply a good excuse to finally write them down.

Further reading

• ASME Y14.5 — dimensioning and tolerancing; profile of a surface with and without datum references.
• ISO 1101 — geometrical tolerancing: form, orientation, location and run-out.
• ISO 5459 — datums and datum systems, including datum targets and constrained association.
• ASME Y14.5.1 — mathematical definition of dimensioning and tolerancing principles; the source of candidate datum sets.
• ISO 12781-1 — flatness: vocabulary and parameters, including the minimum-zone reference plane.
• ISO 10360-13 — acceptance and reverification tests for coordinate measuring systems: optical 3D CMS.
• Reference data sets published by national metrology institutes — the National Institute of Standards and Technology in the US and PTB in Germany — exist so that fitting algorithms can be tested against known answers rather than against each other.
• GOM Software is now ZEISS INSPECT — the vendor's own transition page, and the source for the name mapping in section 1.

Related notes: the datum reference frame — how three surfaces decide where your part is, and where the datum alignment above comes from — plus Gaussian vs Chebyshev — the fitting rules behind the association step — and industrial CT, where volume data has to be surfaced before any of this arithmetic can start. Worked demonstrations on real geometry are on the examples page.

If your inspection projects carry settings nobody has written down, that is a solvable problem.