Visible STEP Annotations and Machine-Readable Tolerance Meaning

Separate shape, appearance and dimensional meaning

A recipient can open an equipment-part model, see a dimension beside a hole and still lack the structured information needed to compare that hole's specified limits automatically. The visible result answers a useful question about readability. The automated task asks what the dimension means, which geometric feature it describes and whether the recipient can obtain that relationship as data.

Product and Manufacturing Information, or PMI, includes annotations and attributes describing product specifications. NIST's STEP File Analyzer and Viewer description separates semantic PMI representation, graphical PMI presentation and validation properties. Semantic PMI is computer-interpretable; graphical PMI records the visual appearance of annotations.

Nominal geometry supplies another kind of information. Measuring a represented cylindrical surface can yield its modeled diameter. That measurement alone does not establish the permitted variation around the specified nominal size. The same nominal boundary could accompany different dimensional requirements. A recipient needs the specified dimensional information for a tolerance comparison.

NIST's 2021 User Guide, section 6.1, describes semantic PMI as associated with model geometry and independent of graphical presentation. Section 6.1.3 separately reports dimensional values, plus-minus bounds and associated geometric entities. These distinctions explain why the visible number and the modeled surface are insufficient evidence of the required machine meaning.

References: [PM1][PM2]

Geometry references can survive in graphical PMI

Graphical PMI should not be described as necessarily disconnected from geometry. PTC's Creo 12 help says graphical annotation exchange preserves organization such as saved views and annotation planes, the capability to link annotations to associated geometry, and geometric references. Those relationships can be useful for visual review.

An annotation-to-geometry reference does not, by itself, establish that a recipient can retrieve a structured dimensional value, unit and tolerance interpretation. The distinction concerns the meaning available to the downstream task. A leader or linked annotation can identify where to look while its dimensional content remains a visual representation.

Keep product and protocol constraints attached to that conclusion. The cited Creo 12 page excludes assembly-level annotation import and export for the protocols it labels ap242 and ap242_e3. It also excludes legacy graphical and semantic annotations for ap242_e3. Those documented restrictions describe that product/version context; they are not a support matrix for other applications.

An AP242 declaration identifies a protocol context. It does not establish which required PMI concepts a particular delivery contains, or which the receiving implementation supports. A screenshot likewise cannot establish the populated semantic subset.

References: [PM1][PM3]

PM-01: two readable dimensions, two different deliveries

Original fictional example PM-01 concerns a bracket with two separately identified cylindrical holes, H1 and H2. Exchanges A and B carry identical stipulated nominal boundary geometry and two correct visible diameter annotations: H1 is 10 mm ± 0.1 mm; H2 is 12 mm ± 0.2 mm.

These are invented informational requirements, not tolerances selected for a real rack interface or part. The receiving task requires structured nominal values, units, bounds and associations to the intended features, without OCR or manual transcription. The records described here are conceptual information records, not valid STEP syntax, counts of STEP entities or actual import output. Receiving support for the stated content is stipulated.

Exchange A contains the two graphical labels and zero semantic dimensional records for these requirements. It can satisfy the stipulated visual reading requirement: a person can read the two correct annotations. Its geometry need not be wrong. Graphical geometry references may also be present. A nevertheless lacks the semantic dimensional content required for this specified extraction task.

Exchange B additionally supplies two correct structured records. The H1 record identifies the intended H1 geometry, a nominal diameter of 10 mm and deviations of −0.1 mm and +0.1 mm. The H2 record identifies H2, a nominal diameter of 12 mm and deviations of −0.2 mm and +0.2 mm. Each retains millimetres as the explicit length unit.

For this simple symmetric example, H1's interval is 10 − 0.1 to 10 + 0.1, or 9.9 mm to 10.1 mm. H2's interval is 12 − 0.2 to 12 + 0.2, or 11.8 mm to 12.2 mm. Under the stipulated content and recipient capability, B makes the requested extraction possible.

The purchase decision follows the task. A visual coordination recipient may find A sufficient. A recipient whose comparison depends on the structured values and their feature relationships needs the additional content and supported interpretation represented by B.

Return C: correct values attached to the wrong features

Now consider an independent fictional Return C. It keeps the same nominal geometry and the same two correct visible annotations. It also contains two semantic dimensional records with the correct numerical values, units and bounds, but swaps their feature associations.

The 12 mm ± 0.2 mm record is associated with H1. The 10 mm ± 0.1 mm record is associated with H2. A receiving application following those stipulated associations would therefore attach the 11.8 mm to 12.2 mm interval to H1 and the 9.9 mm to 10.1 mm interval to H2.

As an unordered collection of values and bounds, B and C contain the same information. As statements about the identified features, they differ. Counting two records, finding both nominal numbers and confirming millimetres would leave the association error undiscovered. The unchanged graphical presentation could also look convincing.

The meaningful comparison therefore follows each intended feature through to its interpreted dimension. For H1, the buyer needs the H1 requirement, rather than merely evidence that a 10 mm record exists somewhere. The same applies independently to H2. C shows how correct appearance and populated semantic content can coexist with wrong machine meaning.

Ask the recipient to return the interpreted relationship

For the proposed exchange, ask the recipient to demonstrate the actual dimensional task in its intended receiving application and version. Identify the delivered file issue, the source product/model revision, the STEP protocol and edition, and the particular dimensional concepts the task requires. A statement that the software supports PMI is too broad to resolve a requirement for specific values, bounds and associations.

In PM-01, a useful return starts from the independently identified H1 feature and reports the interpreted nominal diameter, length unit, lower and upper deviations, and resulting interval. It then does the same for H2. The return should explain how each selected feature corresponds to the intended source feature. A list of two dimension strings without that relationship would not distinguish B from C.

Ask the recipient to identify whether the values came from semantic PMI, a measurement of nominal geometry or a reading of graphical annotation text. Those routes answer different questions. Manual interpretation may be useful for a separately agreed visual task; it does not demonstrate the stipulated automated extraction.

Separate inspection of the supplied content from evidence of receiving behavior. A source-side review can establish that the required semantic relationships were supplied. The recipient's demonstration addresses whether the identified receiving implementation preserved and interpreted them for the intended use. Missing content and unsupported interpretation require different corrections.

NIST's analyzer description illustrates separate reports for semantic PMI, graphical PMI and validation properties, alongside basic syntax checks. The 2021 guide describes the historical reporting approach. These sources help define useful evidence; they do not establish an untested recipient's interoperability. A demonstration should expose missing, unsupported or differently interpreted information rather than silently treating it as a completed comparison.

References: [PM1][PM2]

Keep the dimensional result within its scope

A basic syntax result concerns the file's structure. A conformity review needs its own named scope. Neither result, by itself, establishes that H1 carries the intended requirement. Conversely, a successful two-feature interpretation demonstrates only the content and behavior actually examined.

Nominal shape fidelity remains a separate question. Use the related B-Rep and tessellated-mesh article when deciding which surfaces or approximations a dimensional task needs. Use the coordinate-frame article when deciding where that geometry belongs. Correct semantic associations cannot repair the wrong product geometry or its placement.

For building-information exchanges, the related IFC validation and IDS article addresses another task: which objects an information rule selects and what it requires of them. PM-01 concerns dimensional meaning attached to part features. Repeating a general property-presence check would miss its central association problem.

Semantic PMI also does not promise the original parametric feature history or every native application behavior. The responsible design source still determines the intended requirements. Extracting those requirements does not establish a manufactured result, fit, clearance or authorization for physical work. This article explains an engineering-data purchase decision rather than a tolerancing design method or field procedure.

Connect the requirement to physical planning

When supplied equipment information contributes to a physical IT layout or pathway package, explain what the next recipient must obtain from it. Distinguish a readable product reference from a requirement for automated dimensional interpretation. Identify who will supply and review any specialist STEP content.

Leviathan's Physical Infrastructure Planning & CAD service is the existing route for discussing layouts, pathway coordination and agreed documentation. A proposed engagement separately confirms the authoring software, available resources, reviewer and supported outputs before a deliverable is committed.

Use the related service and project inquiry to describe that physical planning decision, the authorized inputs available and the recipient's required output. The scope discussion can establish the planning work and any specialist responsibilities without treating this explanation as an offer of STEP translation or certification.