Propose architecture parts from a Fusion assembly
A CAD tree is not an architecture. This proposes a starting point a systems engineer then shapes, and it says so rather than presenting the result as a finished decomposition.
Autodesk FusionWrites · gated
The problem this solves
Importing a CAD tree wholesale gives you a model that looks complete and reasons badly: nine hundred components including every washer, arranged by who drew what rather than by what the system does. It takes longer to unpick than it would have taken to build by hand.
How it works
A starting point a systems engineer then shapes, never described as an architecture. Triages the tree before proposing anything, and refuses to infer interfaces from assembly adjacency, because mating faces are not a data flow.
01
Triage before proposing
Likely architecture elements, likely not — fasteners, reference geometry, modelling constructs — and uncertain with a reason. Counts shown before anything is proposed, because a list of nine hundred items is a refusal dressed as thoroughness.
02
Carry the provenance
Names and part numbers verbatim, multiplicity from occurrence count, mass and material with their computed-or-overridden status, and the Fusion component ID stored so a later re-run matches on it rather than on name.
03
Infer no interfaces
Physical adjacency is not an interface and mating faces are not a data flow. Parts and hierarchy only; anything the assembly suggests is listed as an observation for a human, never as a proposed connection.
04
Approve per item, on a branch
Item by item or by subassembly, never in bulk, on a branch so the whole pass can be discarded in one step.
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. Writes to a Dalus branch after per-item approval; Fusion is read-only throughout.
The prompt
You are reading an Autodesk Fusion assembly and proposing corresponding parts in the Dalus model [model name]. BE HONEST ABOUT WHAT THIS PRODUCES. A CAD tree reflects manufacturing, modelling convenience and who drew what. A system architecture reflects functional decomposition. They are not the same structure, and a mechanically faithful import produces a model that looks complete and reasons badly. This workflow proposes a starting point that a systems engineer must shape. Say so in the summary, and never describe the result as an architecture. CHECK THE CONNECTION FIRST: confirm Fusion is running, report the active document and 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 deep to go, since importing to fastener level is almost never wanted; where the parts should sit in the model; and whether the model already has architecture these should merge into or is empty. Ask anything else in the same message. Then begin. TREAT FUSION AS READ-ONLY. This workflow writes only to the Dalus model, only on a branch, and only after per-item approval. READ THE ASSEMBLY: the component tree with names, part numbers, occurrence counts, materials, masses, and nesting. TRIAGE BEFORE PROPOSING ANYTHING, and show it: - LIKELY ARCHITECTURE ELEMENTS: components that plausibly correspond to something the system model should know about. - LIKELY NOT: fasteners, standard hardware, cosmetic or reference geometry, modelling constructs, and duplicated instances that add nothing structurally. Counted and excluded by default. - UNCERTAIN: say why, and let the user decide. Never propose the whole tree. A proposal list of nine hundred items is a refusal dressed as thoroughness. FOR EACH PROPOSED PART: the name and part number taken verbatim from CAD, never tidied; the proposed parent in the model and why; the multiplicity from occurrence count; mass and material carried as attributes with their computed-or-overridden provenance; and the Fusion component identifier stored as an attribute so a later re-run can match on it rather than on name. WHAT YOU MUST NOT INFER: interfaces, connections, flows, functions or requirements. Physical adjacency in an assembly is not an interface, and mating faces are not a data flow. Propose parts and hierarchy only. Where the assembly suggests a possible interface, list it separately as an observation for a human to consider, never as a proposed connection. APPROVE PER ITEM, or per subassembly where the user prefers, but never in bulk. Work on a branch so the whole pass can be discarded in one step. DRY RUN before writing: the triage counts, the proposed parts in full with their parents, the name collisions with existing model parts, and the reconciliation, meaning components in scope = proposed + excluded by class + uncertain. AFTER WRITING: report what was created, what was skipped, the observations about possible interfaces, and one plain paragraph on what a systems engineer should do next, which is usually to restructure the hierarchy functionally and add the interfaces the CAD could not tell you about. Offer, do not execute: the mass budget rollup now that parts exist, and the structure comparison as a recurring check.
Replace the [bracketed] placeholders with your model and project names.
What you get
Triage counts, and the reconciliation of proposed against excluded and uncertain
Proposed parts with verbatim names, parents, multiplicity and provenance
Possible interfaces listed as observations, not as proposed connections
A closing note on what a systems engineer should restructure next
Dalus + Autodesk Fusion
Reads the assembly and writes only to the Dalus model, only on a branch, and only per approved item. The Fusion component identifier is stored on each created part so a later run updates rather than duplicates when a component is renamed.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Will this give us an architecture?
No, and it will not describe the result as one. A CAD tree reflects manufacturing and modelling convenience; an architecture reflects functional decomposition. This produces a starting point, and the summary says what a systems engineer needs to do to it.
Why will it not infer our interfaces?
Because physical adjacency in an assembly is not an interface and mating faces are not a data flow. Inferring them produces connections that look authoritative and are wrong. Anything suggestive is listed as an observation for a human to consider.
How deep does it import?
As deep as you say, and it asks, because importing to fastener level is almost never wanted. The triage excludes standard hardware and modelling constructs by default and shows you the counts before proposing anything.