Fusion structure against the architecture
The physical build and the architecture drift apart quietly. This finds where, and strips out the differences that are really just naming.
Autodesk FusionRead-only
The problem this solves
Comparing a CAD tree to an architecture by hand produces a page of disagreements, most of which are fasteners or a different name for the same bracket. The two or three that matter are buried in it, so the comparison gets done once and never again.
How it works
Where the physical build and the architecture have diverged, with the naming noise stripped out. Splits what CAD has and the model does not into substantial items and small hardware, and notes plainly that a hierarchy difference is often legitimate rather than an error.
01
Establish the correspondence rule
Part number, naming convention, or nothing established. Where nothing exists it offers to propose one from what it observes rather than inventing matches, because a comparison built on guessed names is a list of non-findings.
02
Split what CAD has and the model does not
Substantial items the architecture is missing lead; small hardware is grouped and counted, with a single question about excluding fasteners from future runs.
03
Report quantity and identifier clashes
Occurrence count against multiplicity, both stated. The same part number on two different things leads that section, because it is the serious one.
04
Treat hierarchy differences carefully
A CAD tree reflects manufacturing and modelling convenience; the model reflects system decomposition. Differences are reported with that noted, since they are often legitimate rather than errors.
What you need
Autodesk's own Fusion MCP, connected through the Fusion desktop app with your Autodesk account. The separate Fusion Data MCP covers projects, folders and permissions rather than geometry, so it is not needed for these. Read-only on both sides.
The prompt
You are comparing the component structure of an Autodesk Fusion design against the parts in the Dalus model [model name], and reporting where the physical build and the architecture have diverged. THIS WORKFLOW IS STRICTLY READ-ONLY on both sides. Read the Fusion design; never modify or save it. CHECK THE CONNECTION FIRST: confirm Fusion is running, report the active document and its last-saved date, and confirm the Dalus model is reachable. CONFIRM FIRST, in one message: which Dalus model and branch; which Fusion design and configuration; the scope; how components are meant to correspond to model parts (part number, naming convention, or nothing established); and whether a previous comparison exists. Ask anything else in the same message. Then begin. IF NO CORRESPONDENCE CONVENTION EXISTS, say so and offer to propose one from what you observe rather than inventing matches silently. A comparison built on guessed name matches produces a list of disagreements that are really just naming, and that list gets ignored. READ BOTH SIDES: from Fusion, the component tree with names, part numbers, occurrence counts, and nesting; from the model, the part hierarchy with names, part numbers, multiplicities and the requirements allocated to each. MATCH AND SHOW THE MATCHING, exactly as above: state the basis per item, mark inferred matches, never force a pair. COMPARE AND CLASSIFY: - IN CAD, NOT IN THE MODEL. Split it, because the two halves mean different things: substantial items the architecture is missing, and small hardware the architecture deliberately does not track. Lead with the first, group and count the second, and ask once whether fasteners and standard hardware should be excluded from future runs. - IN THE MODEL, NOT IN CAD. Distinguish not-yet-designed from bought-in items that legitimately live outside CAD, using status or supplier attributes where the model records them. - QUANTITY DISAGREEMENT: occurrence count in CAD against multiplicity in the model, both stated. - HIERARCHY DISAGREEMENT: matched components sitting under different parents. Report it, but note plainly that a CAD tree reflects manufacturing and modelling convenience while the model reflects system decomposition, so a difference here is often legitimate rather than an error. - IDENTIFIER DISAGREEMENT: same item, different part numbers, or the same part number on two different things. The second is serious and leads that section. Reconciliation: CAD components = matched + CAD-only; model parts = matched + model-only. ALSO REPORT: model parts with requirements allocated but no CAD representation, since those are obligations nobody has designed for yet, and CAD components carrying no requirement at all. DO NOT ADJUDICATE which side is right. Report what differs and let the engineer decide whether the design moved or the model is stale. DELIVER a report with the summary and counts, the substantial divergences first, the grouped small hardware, and a table for walking through in a review. Stamp it with the Dalus branch and revision and the Fusion document and its date. If a previous comparison exists, lead with the delta. OFFER, do not execute: proposing the missing parts into the model via the structure-proposal workflow, opening tasks, and re-running after the next CAD release.
Replace the [bracketed] placeholders with your model and project names.
What you get
Substantial divergences first, small hardware grouped and counted
Quantity disagreements between occurrence count and multiplicity
Duplicate part numbers, leading the identifier section
Model parts carrying requirements with no CAD representation
Dalus + Autodesk Fusion
Reads the active document and its last-saved date, and writes nothing to either side. The report is stamped with the Dalus branch and revision and the Fusion document and date, so a comparison can be cited and re-run against a later release.
Common questions
Won't most of the differences be fasteners?
Yes, which is why they are grouped and counted rather than listed, and why it asks once whether standard hardware should be excluded from future runs. The substantial items the architecture is missing lead the report.
Our CAD tree does not match our decomposition. Is that a problem?
Usually not, and the report says so. A CAD tree reflects how something is manufactured and who drew what; the architecture reflects functional decomposition. Hierarchy differences are reported with that context rather than as errors.
Which side does it say is correct?
Neither. It reports what differs and leaves you to decide whether the design moved or the model went stale. What it does flag on its own is model parts with requirements allocated and no CAD representation, since those are obligations nobody has designed for.