Two representations, different purposes
Graphical PMI preserves how an annotation is presented. Semantic PMI represents information that software can interpret as structured product requirements. A file can contain both, one or incomplete portions of either. The model may therefore look convincing while carrying less usable information than expected.
Why the difference matters
A revision review may need to compare a tolerance value, identify a datum reference or associate a characteristic with geometry. Software cannot reliably infer all of that meaning from a visual label. Treating the label’s appearance as a structured requirement can hide a missing association or a change in meaning.
Use a small verification sample
Select representative requirements in the authoring model. Include a dimension, a geometric control and a datum relationship. After export, inspect the values, units, modifiers and geometry associations in a tool that exposes semantic content. Also review whether the displayed annotation is understandable to a human.
Keep unsupported content visible
Record graphical-only or unresolved characteristics separately. Do not label an absent semantic result as an unchanged requirement. If the downstream task requires structured data, request a revised export or document the manual review needed to proceed.
How PartDatum presents the boundary
PartDatum works with the supported information found in the supplied file. Its comparison and inspection-preparation results must be read together with coverage and unresolved findings. In the public CTC03 pocket example, the derived candidate’s missing PMI prevents a full value comparison even though geometric observations and affected-characteristic review are available.