Thirty-eight entries across seven domains. Every entry carries its evidentiary standing, because a catalogue that overstates what it knows is worth less than no catalogue.
Nothing here was reproduced in running software. An entry marked verified means a cited source says this — never that I observed it. It is assembled from vendor documentation, release notes, published standards and public practitioner threads spanning 2018 to 2026 across several versions.
Some entries may describe behaviour already fixed in the release you run. Entries tagged [SILENT] fail without raising — they produce a plausible wrong value in an artifact that looks correct, which is the class that survives review.
gom.script.* command layer — where all the actual work happens — has no reference documentationZEISS documents 22 gom.api.* namespaces (91 entries). The gom.script.* layer — import, alignment, inspection creation, export, reporting — appears roughly 8 times in the entire 296 KB specification, all as incidental examples, with no reference section at all. The spec says so itself: *"Here you can find a detailed documentation of a subset of the App programming specification."* Autocompletion does not reach it either; a user in October 2025: *"many things after 'gom.script' is not accessible from VSCode nor python editor. So we don't know what text can be used."*
The recorder is the sanctioned discovery mechanism and it emits structurally non-reusable code: elements=[gom.app.project.inspection['DISTANCE_1'], gom.app.project.inspection['RADIUS_2'], ...], template_name='Custom_Template'. The user's own conclusion: *"I cannot make this python script parametric for all programs if I can't do this."* This is the ceiling nearly every self-taught scripter hits — "it worked once on my project" — and there is nothing in the recorder's output that hints at the way out.
Asked to script a report stage range, a user recorded the interaction and received four gom.script.view.set_tab_visible(view='properties', visible=True) calls plus one real command. His verdict: *"Not helpful for me. There are gui actions included."* Worse, some UI operations emit nothing: a user trying to align report labels found the software *"does not allow me to record basic commands like 'align labels on edge'"*, and the vendor-side answer was that the software *"is not set up to do this."*
Breakpoints existed in GOM Inspect 2021 and were gone in 2022. ZEISS's own account: *"instead of trying to implement all this in our own editor, we are providing a Visual Studio Code extension now"* — and, candidly, *"The communication about this did not went well, sorry about that."* Users have pushed back for four years running; a March 2026 thread is still open. Asked directly whether the built-in IDE can debug, ZEISS answered *"No, I'm afraid."* One respondent names the affected population exactly: *"many 'non-professional programmers' work [with the integrated editor], who are simply system maintainers, measurement technicians or other users."* The VS Code path is itself version-locked (2025 SP1+; pinned extension 2024.x for 2023 and earlier), d
Scripted* class family was renamed to Custom* in 2027A mechanical diff of the 2026 and 2027 Python API Specification pages: 2026 documents 200 gom.* symbols, 2027 documents 339 — 44 removed, 183 added. ScriptedElement→CustomElement, ScriptedActual→CustomActual, ScriptedInspection→CustomInspection, ScriptedDiagram→CustomDiagram and the rest; namespaces gom.api.scriptedelements and gom.api.scripted_checks_util replaced by gom.api.customelements and gom.api.custom_checks_util. The old names survive as documented *"Deprecated alias"* entries, so this is a soft break — but every tutorial, bookmark and internal wiki written against 2026 now points at dead URLs and stale class names.
Verifiable in under a minute today. /2027/howtos/scripted_elements/scripted_elements_toc.html and /2027/howtos/using_scripted_diagrams/using_scripted_diagrams.html both 404 (they exist on 2026); /2026/howtos/python_versions/python_versions.html 404s because that page is new in 2027. The examples repo's ScriptedCurveCheck still declares 'software-version': 'ZEISS INSPECT 2023' and links 2026 doc URLs, and three ScriptedCheck examples still import gom.api.scripted_checks_util — a name that appears zero times in the 2027 spec. The 2027 docs even carry stale paths in their own prose (C:\Program Files\Zeiss\INSPECT\2026\... in command-line examples). A practitioner'
Two documented breaks in one release. First: *"In ZEISS INSPECT 2025 and later versions, the command gom.read_parameters(globals()) is required to make the parameters available in the App."* A script written pre-2025 keeps running post-upgrade and simply sees stale defaults. The recommended development idiom compounds this — the docs suggest if "variable_1" not in globals(): variable_1 = "default_value_1" for editor testing, so a broken parameter handoff presents as a script that runs perfectly on defaults and quietly ignores what the caller passed. Second: *"Beginning with ZEISS INSPECT 2025, each module is a full featured native Python module and must be properly imported before use!"* — a user's App Configuration failed u
Projects still come in two flavours (create_project(type=2016) part-less vs type=2018 part-based, distinguished by gom.app.project.is_part_project). Old proxy references do not fail loudly: per the docs, *"If the scripting tries to resolve the elements for the Actual Master a mapping takes place and the ActualValues-Reference of the unique part is returned. The same happens for the All CAD Group proxy."* Related traps: measurements moved from actual_elements to a measurement_series category; the report alignment keyword can now return a comma-separated list; Original alignment must be addressed as alignments['<Part name>::Original alignment']. And the obs
ZEISS INSPECT Optical 3D Release 2026 states verbatim: *"Support for ISO 5459:2024 as default for planar datum features ensures compliance with current standards."* Read that as an operator: the default rule for establishing planar datums changed in a minor-year release. Datum establishment determines the datum reference frame; the DRF determines every position and orientation value reported against it. In a regulated shop that is a change to a validated inspection method arriving with no evidence package behind it.
The single most repeated packaging failure. *"When I am working on the App all the included sub scripts load fine, but when I run the script after hitting the 'Finalize App' the script stops with the error that the imported scripts are not found."* Another replier: *"I too had a similar issue & remember banging my head against the wall for a solid day."* The cause is architectural — a finalized App is an archive, so ordinary file I/O stops working and the Add-on API must be used instead. Relative imports inside an add-on fail with *"attempting to import beyond the top level package"*; this rendered ZEISS's own tensile kiosk mode inoperable in 2023. Compounding: the shared-environment path throws ModuleNotFoundError until the *provide
> Live trigger. ZEISS/zeiss-inspect-app-examples PR #200 "Migration to Python 3.14.x" (open, filed 2026-08-20, 182 files, +921/-649) bumps numpy 2.0.2→2.5.2, pillow 11.3.0→12.3.0, opencv-python 4.12→5.0, websockets 14.1→17.0.1 — every one a major-version jump. A Python 3.9-era App estate is heading into a coordinated migration.
.addon is a hand-editable ZIP with convention-driven folders and a developer-generated UUID — and no build pipelineAn App can request an interpreter via "python-version": "3.12.x" in metainfo.json (npm semver syntax). The catch: *"Protected Apps can only be used with Python interpreters approved by ZEISS."* Commercial protection and version pinning are mutually exclusive. Shipping a custom interpreter is manual: pymanager install, mandatory websocket-client, Compress-Archive into gom_edited_addons/<uuid>/python/<PythonXYZ>/, Refresh. The 2027 docs add a full CycloneDX SBOM procedure with its own trap (*"Do not install cyclonedx-bom into the Python distribution archive that you want to ship"*). This entire page is new in 2027.
The 2027 starting-options page documents -license, -packages, -nosplash, -minimized/-maximized/-fullscreen, -config, -eval and -script. Nowhere is a headless / no-render / server mode documented. For an overnight run across hundreds of parts that means a full GUI process per invocation, with all the fragility that implies. The docs' own "Non-interactive script execution" advice is the tell: replace gom.interactive.automation.execute_active_measurement_series(...) with gom.script.automation.execute_active_measurement_series(clear_measurement_data=True) — and recorder output is full of gom.interactive.* calls, which is preci
The working pattern is to string-format a dict into the -eval argument ('gom.script.userscript.test_function(parameters = ' + str(parameters) + ')') and then read it inside the target script as a global that may or may not exist. That is an implicit, unvalidated, injection-prone contract. One user reported it still failing outright: *"I can launch it with using your code structure but could not be able to access the passed variable in user script? Checking in globals() doesn't work for me and also tried to access using sys.argv but no luck."* No resolution in thread. Combined with B3 (gom.read_parameters) and the default-fallback idiom, the failure mode is an automated run that appears to succeed while processin
Two constraints that interlock into the hardest design problem in the platform. First, the FAQ: *"No, in general this is not possible. Due the Python Global Interpreter Lock, the ZEISS INSPECT App API was implemented non-thread-safe only."* Second, the services how-to: *"gom commands – gom.script.\* or gom.interactive.\* – cannot be used in a service script!"* So the parallel, non-blocking tier cannot drive the application, and since gom.script.* is what recording produces, code cannot simply be moved into a service to gain background execution. A concrete unanswered August 2026 case: an add-on needing a blocking scan while a Modbus polling loop keeps running — multiprocessing.Process worked in edit mode and died with
AttributeError, and parallel-instance limits are undocumentedA 2025 user hit AttributeError: module 'gom' has no attribute 'app' on a script that had worked for years. import gom succeeded; adding App scripts worked; only gom.app was missing. His own diagnosis: *"It happened because my license was not detected properly while running the script... After fixing the license issue, gom.app worked again."* A licensing failure presenting as an AttributeError with no mention of licensing is pathologically hard to diagnose. Related: a USB dongle not recognised when launching the exe from a script, and an unanswered May 2025 fleet question about whether four instances can run concurrently on one local dongle.
A 2023 operator with a working export/validation pipeline wanted to move it into Kiosk for operator-proofing: *"I've had a look/play with the custom patch generator and the other tools available for Kiosk mode but I can't find anything allowing me to run a script."* One post, no reply. A March 2026 user asked the same from the other side — *"before the kiosk closes itself, I needed to call the script"* — and the ZEISS answer routed around the request: use "Export CSV By Report Page", which needs no script but *"does not represent your table 1:1 probably."* So the sanctioned path costs you the report format you designed. A separate 2026 thread shows a two-setup scanning template that runs in Kiosk but never offers the reference-point transformation st
The most damning single line in the evidence, from a user describing his live production process: *"Currently we scrap out PDFs to create csv files for our records."* The report PDF is treated as the system of record and the machine-readable data is reconstructed from it afterwards — a lossy, unvalidatable round trip, in a shop that clearly cares enough to be keeping records. This is what happens when native export is coupled to report templates and element selection rather than to the data model.
A user exporting a section from an offset plane as CSV — an entirely ordinary request — hits *"An error occurred during executing the XSLT file. Choose or enter a delimiter"* and then *"There is no valid element selected in the explorer... This export format does not support element 'Plane Y +5.000 mm'"*, and reports he *"can never enable the OK button."* The accepted workaround from a 3,000-post community member is to export ASCII and treat it as text. The export path is format-coupled and element-type-gated in ways not discoverable from the UI, and it drags an XSLT/delimiter/locale layer along with it — the recorder emits decimal_separator and cell_separator as per-invocation parameters, which is a silent-corruption risk a
The shape repeats across current topic titles: *"Extraction of the Major and Manor strain for large number of project"*, *"Bulk Point Inspection App"*, *"Script for automatic exportation of STL FILE"*, *"combine reports from 2 different programs"*, *"Export report in csv"*. The data exists inside N saved projects; the user needs it aggregated into one table. The GUI is built around one open project at a time, so this is inherently a scripting problem. Even within one project the naive approach is punishing: a user extracting strain per surface point looped inspection['Point N.epsX'].get('result_dimension.measured_value') and reported it *"is also very time consuming (<30min)"*, with a considered fallback of exporting CSV and re-readin
Filed 2026-08-17 against ZEISS INSPECT 2025.4.0.398. Reading a stage-specific keyword to build a PDF filename, the user found *"the script only gives the value for the first stage"*, and diagnosed it himself: *"There is a difference between gom.app.project.in_stage and gom.app.project.stages. The first one only takes the enabled stages into account, while the second has all stages."* No ZEISS answer in the thread. It fails silently — returns stage 0's value rather than raising. If a batch of eight parts is eight stages in one project, every part inherits part 1's serial number, in a document that looks correct. Compounding this, the read/write API is asymmetric by design: read with the user_ prefix (gom.app.project.get('user_inspec
ZEISS INSPECT 2026 ships certified Q-DAS export for AQDEF v6.0 and PiWeb exposes a REST API. Between "a check has a result" and "the MES knows this serial passed" sits work nobody has done for you. Q-DAS DFQ files need K0100 (characteristic count), K1001/K1002 (part number and designation) and K2001/K2002 (characteristic number and designation) populated for records to be uniquely assignable — those come from project keywords and a characteristic map, not from element names. PiWeb's DataServiceRest/RawDataServiceRest are REST+JSON with a .NET SDK; no official Python client is documented, and INSPECT's scripting environment is Python.
Two variants of the same defect. Aerospace and automotive parts are routinely reported in several alignments; a user's actual working process is a script that *"changes the alignment and exports the table related to the alignment via report pages in a new folder, and merges the CSV files into one file"* — one export pass and folder per alignment, then a merge, with nothing in the artifact recording which alignment produced which row. Separately, multi-cavity: *"Is there a way in ZEISS INSPECT for the software to automatically recognize the cavity ID of scanned parts and then sort accordingly?"* The community answer: *"Yes, but not natively by cavity number. The most reliable method is to fixture the parts in known positions, use multipart scanning, a
The clearest evidence that this is a live problem rather than a textbook one. A user measuring a ~7 mm circular bushing, 259 points, no filters, no outliers, reports three answers from the same data: *"Max inscribe element = 7.07 / LSQ = 7.14 / Minimum Circumscribed Element = 7.33."* That is 0.26 mm of spread — far larger than most tolerances on such a feature — produced entirely by the choice of fit criterion. He then asks *"Shouldnt my max inscribe be bigger than lsq?"*, a fundamental misconception voiced in public by someone doing real work. Compounding it: standards require minimum-zone (Chebyshev) evaluation for form tolerances while many packages default to least-squares, which is known to reject good parts, and minimum-zone algorithms are the
A user building an ISO GPS template with datum A as the midplane of two drafted planes, B as the midplane of two more, and C normal to the axis, reports *"the actual fitted plane and the displayed coordinate are not perfectly aligned. There appears to be a slight angular difference as well as a small positional offset."* The replies expose three separate traps simultaneously: datum precedence (*"Do you really need datums in this order? I would start with C"*), degrees of freedom (*"You get from B only direction - it's not compensating tilt, and according to ISO/ASME it will be evaluated as perpendicular to A"*), and CAD representation (*"Inspect can interpret model edges wrongly... you see nice faces, but Inspect is secretly transforming this model i
On an airfoil profile form-and-position analysis: *"the Zeiss software automatically assigns clockwise as the positive direction for rotation (twist) analysis, I cannot find anywhere why this is or see any option to change it."* Over roughly two weeks the thread produced no authoritative answer — one responder had never used the module, another offered *"My guess is that the sign is tied to the section/airfoil orientation rather than the global Z-axis direction."* A guess. For twist on an airfoil the sign *is* the result, and a convention that can be neither confirmed nor changed means the reported value's meaning depends on an undocumented internal choice.
ISO 14253-1:2017 requires the tolerance be reduced by the expanded measurement uncertainty to prove conformity and expanded by it to prove nonconformity, leaving a range where neither can be proven; the 2017 revision replaced the default k=2 coverage factor with a default 95% conformance probability. ASME B89.7.3.1 is the US parallel. ISO/IEC 17025:2017 cl. 7.8.6.1 requires that a laboratory issuing a statement of conformity documents the decision rule employed. In practice the software colours a characteristic green or red against the drawing tolerance and the operator reads it as the verdict. That *is* a decision rule — simple acceptance with a zero guard band — but it is almost never declared as one, and on a structured-light system measuring a ti
F4 needs a number and most optical shops do not have one per characteristic. ISO 15530-3 (substitution using calibrated workpieces) is the method industry actually uses, deriving uncertainty from four contributions — systematic error of the process, the measurement procedure, calibration uncertainty of the artifact, and material/manufacturing variation — and it is explicitly *task-specific*. For optical 3D the acceptance frameworks are VDI/VDE 2634-2 and ISO 10360-13:2021, and NIST's comparison found that even 10360-13 length tests *"do not detect all parameters with high sensitivity."* A shop can therefore hold a valid acceptance certificate and still have no defensible per-characteristic U.
21 CFR 820.70(i) requires software used to automate any part of production or the quality system to be validated for its intended use per an established protocol, with documentation maintained; §820.72 adds requirements where the automated system includes inspection, measuring or test equipment. FDA's QMSR amendments took effect 2026-02-02, incorporating ISO 13485:2016 by reference. On the aerospace side, AS9100 cl. 7.1.5.2 (measurement traceability) ranked third among all clauses for nonconformances across the AS91XX family in 2019, out of more than 17,000 recorded nonconformances. A Python App that selects elements, applies tolerances, evaluates conformity and emits the customer's record is quality-system software by any reading. The shops running
The opportunity, and unusually well supported. A .addon is *"a ZIP archive with pre-defined folder- and filenames"* whose metainfo.json carries title, uuid, version, author, description, software-version, software-revision and licensing; key.enc holds protection. Testing is first-class: *"Both unit testing and integration testing is done with pytest and the coverage extension pytest-cov"*; tests are triggerable from script via gom.script.sys.execute_addon_tests(addon_uuid=...); AutoDialogContext automates dialog interaction so GUI-bearing code is testable unattended; a @coverage decorator handles services in separate processes; and ZEISS ships
Discovery works only if test filenames start with test_, test scripts contain only test_-prefixed functions — *"This means: no code outside of function definitions"* — and (recommended) tests live in a top-level tests/. That last constraint forces the code *under* test to be structured as importable functions too, which recorded-then-edited linear scripts are not. Reference data uses addon.ArrayDataTest and addon.ElementTest, generated by "Run tests (create data)…" and stored as App resources, with the docs warning against absolute paths *"since not everyone who installed your App will have access to this data."*
The project history is what a shop points at when asked how a result was produced, and scripting degrades it in both directions. A user generating many elements programmatically asks *"is there a way to do in script some actions but having only one step in history? I am making many points, but i would like to have it like one step"* — no answer in thread, and no documented mechanism found. Meanwhile a service, which runs outside the application and cannot call gom commands at all, leaves no trace in the history whatsoever. Either way the record of what was done drifts away from being a usable audit trail, in exactly the environments where that matters.
IATF 16949 cl. 7.1.5.1.1 requires statistical studies analysing variation in the results of each type of inspection, measurement and test equipment in the control plan, per the AIAG MSA manual; PPAP requires MSA studies in the submission package. For a structured-light system the operator-reproducibility component is real (fixturing, spray, scan strategy) and the study is a large repetitive campaign whose analysis is done off in a spreadsheet. ZEISS ships an example App described as *"MSA conformal measurement system analysis (ANOVA, ARM)"* — but the examples page carries a blanket caveat that examples *"are not intended for productive use"* and that *"ZEISS assumes no liability for their use."* The gap between shipped example and production-ready va
AS9102 Form 3 requires every characteristic on the design data to be uniquely ballooned with the balloon number matching the Form 3 row number exactly; characteristic accountability means nothing on the drawing may be omitted. On a 247-characteristic drawing that is 247 rows that must reconcile. The measurement side lives in INSPECT as named elements, the accountability side lives in a spreadsheet or FAI package, and the mapping between them is maintained by a person. Nothing in the metrology software enforces that the set of inspected characteristics equals the set of ballooned ones, so the failure mode is an omitted or duplicated characteristic that nobody notices until the customer's source inspector does.
If an entry is wrong, or fixed in your version, that is worth more to me than a compliment. The catalogue is versioned and corrections are credited.