Features/MCP Workflows/Onshape/Onshape Part Studio against the architecture

Onshape Part Studio against the architecture

The report opens with what it could not reach, then leads with the findings that are requirements violated in the geometry rather than names that do not match.

OnshapeRead-only

The problem this solves

A structural comparison between CAD and a model mostly produces naming noise. The finding worth having is different in kind: a requirement that constrains a dimension, where the CAD value can be read and does not comply. That one is buried if the report treats every difference alike.

How it works

Divergences within the Part Studio scope, led by requirements the geometry violates. A requirement violated in the geometry is worth more than any naming mismatch, so where the CAD value can be read and differs from what a requirement states, that leads the report.

01
State the scope before comparing
A Part Studio in the configured document, not an assembly tree and not other documents, said at the top so nobody reads a partial comparison as a complete one.
02
Show the matching
Part number, attribute, naming convention, or nothing established. The basis is stated per item, inferred matches are marked, and unmatchable parts go in their own lists rather than being forced into pairs.
03
Lead with requirement violations
Where a requirement constrains a dimension and the CAD value can be read and differs, that section leads the report. It is a requirement broken in the geometry, not a naming mismatch.
04
Then the structural divergences
CAD-only, model-only split between not-yet-designed and bought-in, identifier disagreements with duplicate part numbers first, and property disagreements where both sides record a mass or material.

About this connector

The Onshape connector is pointed at the configured document and Part Studio. Read-only throughout.

The Onshape connector is a FeatureScript environment. It reads and writes Feature Studios and evaluates FeatureScript against a Part Studio in a configured document. Geometry and mass data are reachable by evaluating FeatureScript, but this is not an assembly or BOM connector, and these workflows are scoped to a Part Studio in the configured document rather than to a full assembly tree. If you need assembly-level rollups today, this connector cannot do it.

The prompt

You are comparing the parts in an Onshape Part Studio against the
parts in the Dalus model [model name], and reporting where they have
diverged.

SCOPE HONESTLY FIRST. This connector reaches a Part Studio in the
configured document, not an assembly tree and not other documents.
State the scope of the comparison at the top of the report, so
nobody reads a partial comparison as a complete one.

THIS WORKFLOW IS STRICTLY READ-ONLY. Evaluate FeatureScript to
query; write nothing to the document.

CHECK THE CONNECTION FIRST: confirm the configured document and Part
Studio, and confirm the Dalus model is reachable. Read the
FeatureScript notes before writing any evaluation code.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Part Studio; how parts are meant to correspond (part number,
attribute, naming convention, or nothing established); and whether a
previous comparison exists. Ask anything else in the same message.
Then begin.

READ BOTH SIDES: from Onshape, the parts with names, part numbers or
attributes, materials and masses; from the model, the parts in the
corresponding scope with their identifiers, multiplicities and
allocated requirements.

MATCH AND SHOW THE MATCHING: state the basis per item, mark inferred
matches, never force a pair, and put unmatched items in their own
lists.

CLASSIFY: in CAD not in the model; in the model not in CAD, split
between not-yet-designed and bought-in; identifier disagreements,
with duplicate part numbers leading that section; and property
disagreements where both sides record a mass or material.

ALSO REPORT: model parts carrying requirements with no CAD
representation, which are obligations nobody has designed for; and
requirements that constrain a dimension where the CAD value can be
read and differs. That last group is the most valuable output here,
because it is a requirement violated in the geometry rather than a
naming mismatch, and it should lead the report where it exists.

DO NOT ADJUDICATE which side is correct, except where the model
disagrees with itself.

DELIVER a report with the scope statement first, the requirement
violations second, the structural divergences third, and a table for
review. Stamp it with the Dalus branch and revision and the Onshape
document and version. Lead with the delta if a previous run exists.

OFFER, do not execute: opening tasks for the violations, and
re-running after the next CAD change.

Replace the [bracketed] placeholders with your model and project names.

What you get

A scope statement first, naming the limits of the comparison
Requirements violated in the geometry, leading the report where they exist
Identifier disagreements, with duplicate part numbers first
Model parts carrying requirements with no CAD representation
Dalus + Onshape

Evaluates FeatureScript to query and writes nothing to the document. The report is stamped with the Dalus branch and revision and the Onshape document and version, and a previous run makes the next one lead with the delta.

Common questions

What is the finding worth having here?
A requirement that constrains a dimension where the CAD value can be read and differs. That is a requirement violated in the geometry, and it leads the report wherever it exists, ahead of every structural or naming difference.
Does it cover our whole assembly?
No, and it says so first. The connector reaches a Part Studio in the configured document. The scope statement sits at the top of the report specifically so a partial comparison is not read as a complete one.
Which side does it say is right?
Neither, with one exception: where the model disagrees with itself. Everything else is reported as a difference for you to resolve.