Home / Courses / Engineering Graphics and CAD / Lesson 23

Engineering Graphics and CAD · Lesson 23 of 35

Feature order, design intent, and robust models

The capstone CAD-reasoning lesson, building models whose feature order and parent-child structure express intent and survive change.

Readiness check

Learning objectives

By the end of this lesson you can:

Explain parent-child relationships in a feature tree.
Order features to minimize fragile dependencies.
Encode design intent (what should change together).
Diagnose why a model failed after an edit.
Separate design parameters from incidental dimensions and name key features.

Check your starting point

Five to ten minutes.

If feature B was built on an edge created by feature A, what happens to B if A is deleted or changed?
What does "design intent" mean to you in a CAD model?
Have you ever changed one dimension and had a model break? What might cause that?

Interpretation.

Q1: B may break or move, because it depends on A. This is a parent-child dependency, the core of the lesson.
Q2: The idea that the model should update the way the designer meant (what stays together, what changes with what).
Q3: A feature referenced to a fragile parent (an edge that moved or disappeared). Skill 23.4 diagnoses this.

You need L18-L22 (the full CAD toolkit); this lesson makes models robust.

0 or 1 weak itemsContinue with this lesson.

2 weak itemsReview Lesson 21, Lesson 22, then return.

3 or more weak itemsWork through the prerequisite examples before continuing.

The core idea

What it is. A robust model is one whose feature order and references are chosen so that the model expresses design intent and survives edits without breaking. Features form parent-child relationships: a feature built on another depends on it, and edits propagate down the tree.

Why an engineer needs it. The downstream courses (Manufacturing, Machine Design) and real practice depend on editable models. A model that looks correct but breaks on the first change wastes everyone's time. Robustness is what separates a professional model from a fragile one.

What problem it solves. It makes models survive change: resize a part, and features update the way the designer intended, instead of erroring or shifting.

What goes wrong when it is ignored. Features referenced to fragile geometry (an edge from a fillet, an incidental face) break when that geometry changes. A model with tangled dependencies fails on edits, sometimes catastrophically, and nobody can tell why.

A simple mechanical example. If a mounting hole is positioned from a filleted edge, changing the fillet radius moves or deletes that edge, and the hole errors (a dangling reference). Positioning the hole from a stable datum (the origin or a base face) instead makes it survive the fillet change. Same hole, very different robustness.

Key ideas:

Parent-child dependency: a feature depends on the geometry it was built on; changing the parent affects the child.
Feature order: build stable, functional features first; add fragile finishing features (fillets, chamfers) last.
Stable references: reference the origin, default planes, and early stable faces rather than fragile edges (fillet edges, incidental faces).
Design intent: choose references and parameters so the model changes the way you mean (a boss stays centred, a hole stays a set distance from a functional face).
Design parameters versus incidental dimensions: the few dimensions that should drive the design (a bore diameter) are made explicit (named variables), so they are not buried among incidental sizes.
Naming: name important sketches and features so the tree is legible and intent is clear.

Neutral terminology: the rollback/edit-history bar (Onshape) is the rollback bar (SolidWorks) or timeline (Fusion); variables are called variables or parameters/equations across tools.

Part 4: Parametric CAD foundations.

Check: explain the decision in your own words before using a CAD command.

The lesson map. Feature order, design intent, and robust models becomes manageable when you move through the four checks in order and verify each result before continuing.

The skills, taught in order

Skill 23.1 - Read parent-child dependencies

Concept. Each feature may depend on earlier ones; edits propagate down the tree. Terminology. Parent-child dependency, downstream feature. Procedure. For each feature, note what geometry it references (its parents). Expect changes to a parent to affect its children. Reasoning. Understanding dependencies predicts what an edit will affect. Failure mode. Editing a parent without realizing it will change or break children. Check. For a hole on a face, name the hole's parent.

Skill 23.2 - Order features for robustness

Concept. Build stable, functional features first; finishing features last. Terminology. Feature order, stable feature, dress-up feature. Procedure. Base and functional features early; fillets, chamfers, and cosmetic features late; so early references stay clean. Reasoning. A good order limits fragile dependencies. Failure mode. Filleting early, then referencing the changed edge. Check. State where fillets belong in the order.

Skill 23.3 - Reference stable geometry and encode intent

Concept. Reference the origin, planes, and stable faces, choosing references that make the model change the way you mean. Terminology. Stable reference, fragile reference, design intent. Procedure. Position features from the origin, default planes, or stable functional faces. Ask, for each reference, whether it captures how the feature should behave when the part changes. Reasoning. Stable references survive edits; intent-matching references make edits do the right thing. Failure mode. Referencing a fillet edge or incidental face that moves or vanishes. Check. Re-reference a hole from a fillet edge to a stable datum.

Skill 23.4 - Diagnose and prevent edit failures

Concept. A model that breaks after an edit usually has a fragile reference or bad order; fix by re-referencing or reordering. Terminology. Rebuild/regeneration error, dangling reference, repair. Procedure. When a model errors after an edit, find the failing feature, identify its lost or changed parent, and re-reference it to stable geometry or reorder the tree. Reasoning. Most edit failures trace to a fragile parent; fixing the reference restores robustness. Failure mode. Patching symptoms (deleting the failed feature) instead of fixing the reference. Check. Given a dangling-reference error, name the likely cause and fix.

Worked example 1: repair a fragile L-bracket

Problem. An L-bracket has its mounting hole positioned from the inside filleted corner edge. When the fillet radius is changed from 5 to 8, the hole errors (a dangling reference). Diagnose and repair it so the hole survives fillet changes.

Planning. Identify the fragile parent (the fillet edge), then re-reference the hole to a stable datum.

Solution.

Diagnose. The hole was located by dimensions from the inside corner edge. That edge is created by the fillet, so it is a fragile reference. Changing the fillet radius moves or replaces that edge, orphaning the hole (a dangling reference), and the hole feature errors.
Root cause. The hole's parent is the fillet edge, a finishing feature that should not be a positional reference.
Repair. Re-reference the hole's location dimensions to stable geometry: the base faces (for example the bottom and a side face of the foot) or the origin. Now the hole is positioned independently of the fillet.
Verify the fix. Change the fillet radius from 5 to 8 again: the hole stays put (it no longer depends on the fillet edge). The model rebuilds cleanly.
General rule. Never position functional features from finishing-feature edges; use stable datums.

Result. The hole failed because it was referenced to a fillet edge (fragile); re-referencing it to the base faces (stable) makes it survive fillet changes.

Why the method works. Stable references (base faces, origin) do not move when finishing features change, so features positioned from them do not break.

How to verify independently. After the repair, edit the fillet radius across a range: the hole should stay fixed every time. Consistent survival confirms the reference is now stable.

Worked example 2: fragile versus robust feature tree

Problem. Build the same bracket two ways: a fragile tree (features referenced to each other's edges and finishing features early) and a robust tree (features referenced to stable datums, finishing features late, key parameters named). Apply a set of edits (change base length, change fillet radius, change hole position) and document which edits break the fragile model and why. The complication is comparing robustness directly.

Planning. Construct both trees, then run the edits and record behavior.

Solution.

Fragile tree. Base extrude; fillet the corners early; sketch the hole on a filleted face and position it from a filleted edge; add a boss referenced to the hole. Finishing features early, chained references.
Robust tree. Base extrude on a default plane, centred on the origin; hole positioned from the origin/base faces with a named variable for its offset; boss positioned from the same stable references; fillets and chamfers added last.
Edit 1, base length. Robust: updates cleanly (features referenced to stable datums). Fragile: the hole and boss, referenced to edges that shift with the base, may move unexpectedly or error.
Edit 2, fillet radius. Robust: fillets are last and nothing references their edges, so it updates. Fragile: the hole (on a filleted edge) errors with a dangling reference.
Edit 3, hole position. Robust: change the named variable; the hole moves and the boss (referenced to the same stable geometry) follows as intended. Fragile: the chained boss may drift or break.
Document. The fragile tree breaks on the fillet-radius edit (dangling reference) and misbehaves on the base-length and hole edits (unintended shifts). The robust tree survives all three.

Comparison. Same final shape, very different behavior: the robust tree (stable references, late finishing, named parameters) survives every edit; the fragile tree (early fillets, chained edge references) breaks or misbehaves. Robustness is a property of structure, not appearance.

Result. The fragile tree fails on the fillet edit and misbehaves on others because of chained, finishing-feature references; the robust tree survives all edits because it references stable datums, orders finishing features last, and names key parameters.

Independent check. Run each edit on both models. The robust model rebuilds every time; the fragile one errors or shifts. The contrast confirms the structural rules.

Misconceptions and diagnostics

Misconception	Why it seems reasonable	Why it is wrong	Evidence that reveals it	Correction	Diagnostic question
"Any order that gives the right shape is fine."	The model looks correct.	Order and references set fragility; the same shape can be robust or fragile.	One tree breaks on an edit; the other does not.	Order stable-first, finishing-last; reference datums.	"Will this order survive the likely edits?"
"A model that looks correct is robust."	It renders correctly now.	It may break on the first edit if references are fragile.	Changing a fillet orphans a hole.	Reference stable geometry, not finishing edges.	"What does each feature depend on?"
"Reference whatever edge is handy."	It is convenient.	Handy edges (fillets, incidental faces) move or vanish, orphaning children.	A dangling-reference error after an edit.	Reference the origin, planes, or stable faces.	"Is this reference stable or fragile?"

Practice ladder

Level A - Recognition

Task. In five feature trees, name the parent of a given child feature and mark any fragile references. Deliverable. Five annotated trees. Success criteria. Parents named; fragile references (fillet edges, incidental faces) flagged in at least four. Answer guidance. A child depends on the geometry it was built on. Common errors. Missing a fillet-edge reference. Difficulty. Low.

Level B - Guided application

Task. Fix a single dangling reference in a supplied model, with guidance, by re-referencing to stable geometry. Deliverable. The repaired model. Success criteria. The feature re-references a stable datum and the model rebuilds. Answer guidance. Move the reference from the fragile edge to a base face or the origin. Common errors. Deleting the failed feature instead of re-referencing. Difficulty. Medium.

Level C - Independent application

Task. Repair a broken model (model-repair task) and explain the failure and fix. Deliverable. The repaired model plus an explanation. Success criteria. The failure is correctly diagnosed (fragile reference or bad order) and fixed; the model survives the triggering edit. Answer guidance. Trace the failing feature to its lost parent. Common errors. Fixing symptoms, not the reference. Difficulty. Medium to high. (Model-repair assessment evidence.)

Level D - Transfer and design

Task. Given a part and a list of expected future changes, design a feature tree that survives them, name the key parameters, and justify the order and references. Deliverable. The model plus a design-intent statement. Success criteria. The tree survives the stated edits; key parameters are named; the order and references are justified against the changes. Answer guidance. Reference stable datums; finishing features last; expose driving parameters as variables. Common errors. Fragile references that break on a listed change. Difficulty. High. (Design-change test and design-intent statement evidence.)

Working with AI, and proving it yourself

Use AI as a tutor

Useful AI support:

Ask it to explain parent-child dependencies with your part.
Ask it to suggest a robust feature order and check it against the edit test.
Ask it to help diagnose why a described model broke.

Limits:

A text assistant cannot see your feature tree or references.
It may propose orders with fragile references.

Verify AI output against: the stable-reference principle, the finishing-features-last rule, and the edit test (does the tree survive the changes?).

Prove it yourself

A plausible but incorrect AI answer, and how to catch it. You ask, "Where should I position the mounting hole so the model is robust?" and the assistant replies: "Position it from the nearest rounded corner edge; it is easy to reference."

This creates a fragile reference. Detect it with the robustness principle: a rounded (fillet) edge is a finishing-feature edge that moves or disappears when the fillet changes, orphaning the hole. The evidence is the edit test: change the fillet radius and the hole errors. Correct conclusion: position the hole from stable geometry (the origin, a default plane, or a base face), never from a fillet edge.

Retrieval and spaced review

What is a parent-child dependency?
Why order finishing features late?
What makes a reference stable versus fragile?
What is design intent in a model?
How do you diagnose a model that broke after an edit?
Why name key parameters and features?
Cumulative (L21): How does the fillets-late rule from L21 support robustness here?
Reconstruction task: From memory, explain why a hole referenced to a fillet edge breaks when the fillet changes, and the fix.

Answers. 1: a feature depends on the geometry it was built on, so changing the parent affects the child. 2: they modify edges; referencing them creates fragility, so build them last. 3: stable references (origin, planes, base faces) do not move; fragile references (fillet edges, incidental faces) move or vanish. 4: choosing references and parameters so the model updates the way the designer means. 5: find the failing feature and its lost or changed parent, then re-reference to stable geometry or reorder. 6: to make the design drivers explicit and the tree legible. 7: adding fillets last means no functional feature references a fillet edge, so fillet changes do not break anything.

Suggested review intervals. 1 day, 3 days, 7 days.

Reference mapping and next step

Read further

Onshape docs (feature list, variables, references).

Standards details must be checked against the current official edition used by your institution or employer.

Finish the lesson

You can now: read parent-child dependencies; order features for robustness; reference stable geometry and encode intent; diagnose edit failures; and expose and name design parameters.

Self-assessment checklist.

I know what each feature depends on.
I build stable features first, finishing features last.
I reference the origin, planes, and stable faces.
I can diagnose and repair a dangling reference.
I name key parameters and features.

Next lesson: L24 - Multi-feature mechanical parts and mating geometry (Part V begins). Why it follows: you can now build robust single parts. Part V scales up to realistic multi-feature parts and the interfaces where parts meet, then to assemblies, drawings, and change management.

Required files or submissions: submit your Level C model repair and your Level D robust tree with a design-intent statement. Optional extension: take one of your earlier models, deliberately break it with an edit, and repair it by re-referencing to stable geometry.

End of Part IV (L18-L23), the parametric CAD foundations. Part V (Parts, assemblies, and drawings) begins with L24-L29 in 16-part5-lessons.md.

# Engineering Graphics and CAD - Phase 4: Full Lesson Content, Part V (Parts, Assemblies, and Drawings), L24-L26

Lessons L24-L29 make up Part V. This file holds L24 (multi-feature parts and mating geometry), L25 (assemblies and mates), and L26 (degrees of freedom, interference, and clearance). L27-L29 are in 17-part5-lessons-cont.md. CAD actions given for Onshape with the software-neutral principle first. No em dashes.