AI for Design Quality & DFM
CAD design review comments work only when pinned to the face they are about. How model space pins, persistent identifiers and revision context keep review findings alive.
·
⏱
8 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
A design review comment is a claim about a specific piece of geometry, and it should be stored that way. Pinned to a face, it keeps its subject; typed into a document, it keeps only its wording. The hard part is not making the pin, it is keeping it through a rebuild, because the faces in a feature based model are regenerated output rather than fixed identities, and they split, merge and disappear as the design moves. The practical answer is to store the entity reference, the revision, the viewpoint and the constraint behind the note, then surface orphaned comments honestly instead of guessing where they should reattach. Do that and a review stops being an event that produces a list, and starts being something that accumulates into a usable record of why the part looks the way it does.
A design review produces two things: a decision and a pile of comments. The decision usually survives. The comments often do not, and the reason is almost always where they landed. A note typed into meeting minutes says that the boss on the bracket looks thin. A note pinned to a face says it about that face, on that revision, in a form the next engineer can click rather than reconstruct.
That gap is small to describe and expensive to live with. It is the difference between a review finding that gets fixed in the next rebuild and one that gets rediscovered weeks later in a first article inspection report, when the tool is already cut. This article covers what it actually means to attach a comment to geometry, why that attachment is harder to keep than it looks, and what a pinned comment has to carry if it is going to be worth anything on the revision after next.
Where CAD design review comments actually land
Most review feedback never touches the model. It lands somewhere adjacent to it, and every one of those destinations drops something on the way.
Meeting minutes and shared documents. The comment keeps its wording and loses its geometry. Two weeks later, nobody is certain which of the three bosses was being discussed.
Screenshots and PDF markups. The comment keeps a picture of the geometry and loses the model. A red circle on a flattened view is anchored to pixels, not to a face, so it cannot follow the part when the part changes.
Email and chat threads. The comment keeps its author and its timing and loses almost everything else, including any chance of being found by the engineer who inherits the project.
Issue trackers. The comment keeps its status, which is genuinely useful, and loses the feature it was about unless somebody writes a careful description by hand every single time.
None of these are bad tools. They are just the wrong container for a statement about a specific piece of geometry. The cost shows up as rework: the reviewer explains the same concern twice, the designer fixes the wrong feature once, and the finding reappears downstream. The same pattern is why automated design review is valuable mainly when its output is attached to something, rather than delivered as another list to read.
The useful question is not which tool to log comments in. It is what a comment has to be attached to before it can survive contact with a revision.
IN PRACTICE
With Leo, our team improves design quality, reduces mistakes, and shortens time-to-market.
- Uriel B., Field Warfare and Survivability Specialist
What it means to pin a comment to a face
A solid model is a boundary representation: a closed shell of faces, edges and vertices that together bound a volume. Those faces are not decorations on a picture. They are addressable entities, each with its own identity inside the model, which is what makes it possible to point at one of them rather than at a region of a screen.
That gives two very different things that both get called a pinned comment:
A screen space pin. The note is stored against a coordinate on a rendered image, or against a camera position in a viewer. Rotate the model and the pin is already approximate. Change the model and it is wrong.
A model space pin. The note is stored against a topological entity, a face or an edge, plus a point on that entity and the viewpoint it was written from. Rotate the model and the pin stays on the feature, because it was never about the camera.
Engineers already have a mature version of this idea in model based definition. Under ASME Y14.41 and ISO 16792, a tolerance or a datum on a 3D model is not floating text placed near a feature; it is a semantic annotation associated with the faces it controls, which is exactly why a model based definition dataset can be consumed downstream instead of read and retyped. The comparison between that approach and flat documentation is worked through in more detail in our piece on model based definition versus 2D drawings.
A review comment is a weaker claim than a tolerance, since it is an opinion rather than a requirement, but it wants the same plumbing. Attach it to the face, record the viewpoint so the next reader sees what the reviewer saw, and the note stops being a description of the geometry and becomes a property of it.
The hard part is surviving the next revision
Pinning a comment is the easy half. Keeping it pinned through a rebuild is where this gets genuinely difficult, and it is worth being honest about why.
In a feature based modeller, the faces in the boundary representation are an output, regenerated every time the feature tree is evaluated. Reorder two features, change a fillet radius so that two surfaces merge, suppress a cut, and the set of faces that comes out the other side is not the set that went in. A face can be split into two, two faces can merge into one, or a face can simply cease to exist. The identifier your comment was holding may now point at nothing, or worse, at something adjacent and plausible.
This is a known problem in data exchange, not a quirk of any one system. The CAx Interoperability Forum publishes a recommended practice for persistent identifiers that exists precisely for this: assign UUIDs to product versions, semantic PMI and topological entities such as faces and edges, require a receiving system to preserve incoming UUIDs on re-export rather than mint new ones, and record transformations explicitly when entities split or merge. Their standing example is a hole that one system carries as a single cylindrical surface and another carries as two half cylinders. Without a recorded relationship between the old entity and the new ones, a reference into that geometry is orphaned by the translation alone, before anyone has touched the design.
Practically, a comment can be in one of three states after a revision:
Still attached. The face it referenced persisted, and the comment is on the same feature it was always about.
Attached but stale. The face persisted, but the thing the comment objected to has been changed or removed. The pin is correct and the note is obsolete.
Orphaned. The face no longer exists under that identity. The comment is still in the record but no longer points anywhere.
A review system that quietly deletes the third category is losing findings. A system that quietly reattaches them to a nearby face is doing something worse, because it produces confident nonsense. The honest behaviour is to surface orphaned comments as orphaned and make somebody look at them, which is the same discipline that keeps a change record trustworthy; we wrote about the underlying data shape in what an ECO record has to carry.
What a pinned comment has to carry besides the text
The note itself is the least interesting part of the record. What makes a comment usable later is the context stored alongside it.
The entity reference. Which face or edge, in which component instance of which assembly, not just which part file.
The revision it was written against. Without this, a reader cannot tell whether the comment has already been addressed.
The viewpoint. The camera position and section state that the reviewer was looking at, so the next reader starts from the same view.
Author, date and status. Open, addressed, rejected with a reason. A rejected comment with a reason is often more valuable than an accepted one.
The constraint behind the note. Not just that the wall is too thin, but the draft, tooling or inspection rule that makes it too thin.
That last item is the one teams skip, and it is the one that pays. A comment recording a constraint is reusable design rationale; a comment recording only a verdict expires the moment the person who wrote it moves teams. This is the same loss described in our article on capturing tribal knowledge before it walks out the door, arriving through a different door.
This is where an AI intelligence layer sitting on top of the design record earns its place. Leo lets reviewers leave design review comments directly from the 3D viewer, clicking a part or a face to pin a note to that exact feature, so the comment is captured against geometry at the moment it is made rather than retyped into a document afterwards. Because Leo connects to an organisation's wider knowledge base, including PDM, PLM, local and network directories and ERP, a pinned comment stops being an isolated note and becomes one more retrievable piece of the reasoning behind a part. Leo offers integrations with leading PDM and PLM platforms, including SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter and Arena PLM, among others. Leo is SOC-2 certified and GDPR compliant, no AI is trained on customer data, and customer IP stays protected, which matters when a review record holds the sharpest things anyone has said about an unreleased design.
How to run a review so the comments stay useful
Tooling helps, but most of the value here comes from a handful of habits that cost nothing to adopt.
One comment, one feature. A note that covers three bosses cannot be pinned, closed or rejected cleanly. Split it.
Pin before you speak. If the comment is made in a live review, put it on the face while the model is on screen. Reconstructing pins from memory afterwards is where most of them are lost.
State the constraint, not the fix. Write the rule the feature violates and let the designer choose the remedy. Fix instructions age badly and constraints do not.
Record the revision in the comment, not in your head. This is the single cheapest thing on this list and it decides whether the comment can be triaged later.
Agree a policy for orphaned pins before you need one. Decide in advance who reviews comments whose geometry has disappeared, and on what cadence. Without a named owner these accumulate silently.
Close every pin explicitly. Addressed, rejected with a reason, or deferred with a date. An open comment of unknown age is indistinguishable from an ignored one.
Where the comments live matters less than whether they are attached to geometry and whether they have an owner. Teams already managing released data in a vault have a natural home for the record, and the trade offs between those systems are covered in our comparison of PDM software for mechanical engineers. Teams without a vault can still get most of the benefit, as long as the comment is stored against the model rather than against a screenshot of it.
FAQ
CAx Interoperability Forum (MBx Interoperability Forum), Recommended Practices for Persistent Identifiers, version 1.7.
ASME Y14.41, Digital Product Definition Data Practices.
ISO 16792, Technical product documentation: Digital product definition data practices.
Leo AI Releases and Updates changelog, Sept 22 to 27, 2026 entry on design review comments in the 3D viewer.
Keep every review finding attached
Pin comments to the face they are about, straight from the 3D viewer
See how Leo keeps design review comments attached to the geometry they concern, with the revision, the viewpoint and the reasoning behind each note stored alongside it.
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
