Knowledge Graph for CAD Parts and Dimensioning¶

Source files: Architechture & Research/RapidDraft/Technical Architecture/NX Graphy.md Last synthesized: March 2026

Concept: Knowledge Graph in CAD Context¶

A knowledge graph (KG) for a CAD part is a structured representation of the part's geometry, features, parameters, and design intent. Instead of treating a CAD model as a monolithic artifact, the KG decomposes it into typed nodes (entities) and relations (edges), enabling algorithmic reasoning about design decisions and automatic generation of manufacturing-ready outputs.

What a Knowledge Graph Represents¶

In RapidDraft's context, a KG for a CAD part contains:

Nodes – discrete entities with attributes: - Part – the overall model (e.g., model1.prt) - Feature – construction steps (Extrude, Hole, Blend, etc.) - Body – solid bodies created by features - Face – individual surface elements (planar, cylindrical, etc.) - Edge – boundaries between faces - Expression – parametric variables (lengths, diameters, rules) - Sketch – 2D profiles and constraints

Edges / Relations – connections between nodes: - PART_HAS_FEATURE(Part → Feature) – feature belongs to part - FEATURE_CREATES_BODY(Feature → Body) – feature generates solid body - BODY_HAS_FACE(Body → Face) – face is part of body - FACE_ADJ_FACE(Face ↔ Face) – faces are adjacent (topology) - FACE_HAS_EDGE(Face → Edge) – edge bounds face - FEATURE_HAS_EXPRESSION(Feature → Expression) – feature uses parameter - EXPRESSION_CONSTRAINT(Expression ↔ Expression) – parametric dependency (e.g., L_shaft = 1.5 * H_block)

Higher-level Intent Edges: - SHAFT_INSERTED_IN_BLOCK(ShaftFeature → BlockFeature) – design intent relationship - ALIGN_AXIS(CylFace → PlnFace) – geometric constraint relationship - DIMENSION(Feature, Face1, Face2) – prescribes which geometry to dimension

Example: Block with Shaft¶

For a simple rectangular block (Extrude 1) with a cylindrical shaft (Extrude 2):

Nodes:

Part: model1
Feature: BlockExtrude (Extrude 1)
Feature: ShaftExtrude (Extrude 2)
Body: Body1
Face: BlockTop, BlockBottom, BlockSide1–4
Face: ShaftCyl, ShaftEnd1, ShaftEnd2
Expr: L_block, W_block, H_block, D_shaft, L_shaft

Relations:

model1 -[PART_HAS_FEATURE]-> BlockExtrude
model1 -[PART_HAS_FEATURE]-> ShaftExtrude
BlockExtrude -[FEATURE_CREATES_BODY]-> Body1
ShaftExtrude -[FEATURE_CREATES_BODY]-> Body1
Body1 -[BODY_HAS_FACE]-> {BlockTop, BlockBottom, BlockSide1–4, ShaftCyl, ShaftEnd}
BlockExtrude -[FEATURE_HAS_EXPRESSION]-> {L_block, W_block, H_block}
ShaftExtrude -[FEATURE_HAS_EXPRESSION]-> {D_shaft, L_shaft}
D_shaft -[EXPRESSION_CONSTRAINT]-> H_block (rule: D_shaft = 0.25 * H_block)
ShaftExtrude -[SHAFT_INSERTED_IN_BLOCK]-> BlockExtrude

Extracting the Knowledge Graph from NX Using NXOpen¶

1. Topology Extraction¶

Extract base geometry and topology from the part:

' Get session and work part
Dim theSession = Session.GetSession()
Dim workPart = theSession.Parts.Work

' Iterate bodies
Dim bodies() As Body = workPart.Bodies.ToArray()
For Each b As Body In bodies
    ' For each body, get faces and edges
    Dim faces() As Face = b.GetFaces()
    Dim edges() As Edge = b.GetEdges()

    For Each f As Face In faces
        ' Extract face properties
        Dim faceID = f.Tag  ' Unique internal identifier
        Dim faceType = f.GetType()  ' planar, cylindrical, etc.

        ' Get face geometry (centroid, normal vector)
        Dim faceEvaluator As Face.Evaluator = f.GetFace()
        ' Use faceEvaluator.GetNormal(u, v) to get surface normal
        ' Use faceEvaluator.EvaluateUV(...) to get coordinates
    Next

    For Each e As Edge In edges
        ' Extract edge properties
        Dim edgeID = e.Tag
        Dim adjFaces() As Face = e.GetFaces()  ' Faces this edge bounds
        Dim edgeBody As Body = e.GetBody()  ' Body this edge belongs to
    Next
Next

Output: Nodes Body, Face, Edge with attributes (ID, type, geometry).

2. Features and Parametric Intent¶

Extract feature sequence and parameters:

' Iterate features to build PART_HAS_FEATURE and FEATURE_CREATES_BODY relations
Dim features() As Feature = workPart.Features.ToArray()
For Each feat As Feature In features
    Dim featName = feat.Name  ' e.g., "Extrude 1"
    Dim featType = feat.GetType()  ' Extrude, Hole, Blend, etc.

    ' Get bodies created by this feature
    Dim createdBodies() As Body = feat.GetBodies()
    For Each createdBody As Body In createdBodies
        ' Create edge: FEATURE_CREATES_BODY
    Next
Next

' Extract expressions (design parameters)
Dim expressions() As Expression = workPart.Expressions.ToArray()
For Each expr As Expression In expressions
    Dim exprName = expr.Name  ' e.g., "H_block"
    Dim exprValue = expr.Value  ' numeric value
    Dim exprFormula = expr.StringValue  ' formula if parametric
    ' Create node: Expression with Name, Value, Formula
Next

' Link features to expressions
' (Done during feature builder step: builder.Height.RightHandSide = "H_block")
' For existing features, parse parameters via sketch and builder references

Output: Nodes Feature, Expression and edges FEATURE_CREATES_BODY, FEATURE_HAS_EXPRESSION.

3. Parametric Relationships¶

Extract and store constraint rules between expressions:

' Build expressions with constraints
Dim mmUnit = workPart.UnitCollection.GetBase("Length")

' Example design rules
workPart.Expressions.CreateSystemExpressionWithUnits("H_block = 50", mmUnit)
workPart.Expressions.CreateSystemExpressionWithUnits("W_block = H_block", mmUnit)
workPart.Expressions.CreateSystemExpressionWithUnits("L_block = 2 * H_block", mmUnit)
workPart.Expressions.CreateSystemExpressionWithUnits("D_shaft = 0.25 * H_block", mmUnit)
workPart.Expressions.CreateSystemExpressionWithUnits("L_shaft = 1.5 * H_block", mmUnit)

' When an expression is created with a formula, it automatically defines
' an edge: EXPRESSION_CONSTRAINT between the referenced expressions

Output: Edges EXPRESSION_CONSTRAINT between expressions, forming a parametric dependency graph.

4. Storage Format¶

Store the complete KG as JSON for querying and visualization:

{
  "part": {
    "id": "model1",
    "name": "BlockShaft",
    "created": "2026-03-21T10:00:00Z"
  },
  "nodes": {
    "bodies": [
      {
        "id": "Body1",
        "name": "Body 1",
        "type": "solid",
        "volume": 15000.0,
        "faces": ["BlockTop", "BlockBottom", "BlockSide1", "BlockSide2", "BlockSide3", "BlockSide4", "ShaftCyl", "ShaftEnd"]
      }
    ],
    "features": [
      {
        "id": "BlockExtrude",
        "name": "Extrude 1",
        "type": "Extrude",
        "creates_bodies": ["Body1"],
        "parameters": {
          "height": "H_block",
          "length": "L_block",
          "width": "W_block"
        }
      },
      {
        "id": "ShaftExtrude",
        "name": "Extrude 2",
        "type": "Extrude",
        "creates_bodies": ["Body1"],
        "parameters": {
          "diameter": "D_shaft",
          "length": "L_shaft"
        }
      }
    ],
    "faces": [
      {
        "id": "BlockTop",
        "type": "planar",
        "normal": [0, 0, 1],
        "centroid": [50, 50, 100],
        "area": 10000.0,
        "feature": "BlockExtrude"
      },
      {
        "id": "ShaftCyl",
        "type": "cylindrical",
        "radius_expr": "D_shaft/2",
        "axis": [0, 0, 1],
        "feature": "ShaftExtrude"
      }
    ],
    "expressions": [
      { "name": "H_block", "value": 50, "unit": "mm" },
      { "name": "W_block", "formula": "H_block", "unit": "mm" },
      { "name": "L_block", "formula": "2 * H_block", "unit": "mm" },
      { "name": "D_shaft", "formula": "0.25 * H_block", "unit": "mm" },
      { "name": "L_shaft", "formula": "1.5 * H_block", "unit": "mm" }
    ]
  },
  "edges": {
    "part_has_feature": [
      { "from": "model1", "to": "BlockExtrude" },
      { "from": "model1", "to": "ShaftExtrude" }
    ],
    "feature_creates_body": [
      { "from": "BlockExtrude", "to": "Body1" },
      { "from": "ShaftExtrude", "to": "Body1" }
    ],
    "body_has_face": [
      { "from": "Body1", "to": "BlockTop" },
      { "from": "Body1", "to": "ShaftCyl" }
    ],
    "feature_has_expression": [
      { "from": "BlockExtrude", "to": "H_block" },
      { "from": "ShaftExtrude", "to": "D_shaft" }
    ],
    "expression_constraint": [
      { "from": "W_block", "to": "H_block" },
      { "from": "L_block", "to": "H_block" },
      { "from": "D_shaft", "to": "H_block" }
    ],
    "intent": [
      { "type": "SHAFT_INSERTED_IN_BLOCK", "from": "ShaftExtrude", "to": "BlockExtrude" }
    ]
  }
}

Using the Knowledge Graph for Dimensioning¶

1. Parametric (Model) Dimensioning¶

The KG makes parametric relationships explicit. Use it to:

Identify key parameters: Query nodes with high out-degree in EXPRESSION_CONSTRAINT edges (e.g., H_block controls many features).
Build design rules: Store intent edges like SHAFT_INSERTED_IN_BLOCK to reason about feature relationships.
Propagate changes: When H_block is edited, the expression system automatically updates L_block, D_shaft, L_shaft, and all geometry.

Example workflow:

User changes H_block from 50 to 60 mm
→ Expression system evaluates H_block → L_block, W_block, D_shaft, L_shaft
→ Features re-evaluate with new parameter values
→ Bodies and faces update automatically
→ All downstream dimensions update (memory system re-applies stored decisions)

2. Drafting Dimensioning¶

Use the KG to select which geometry to dimension and how:

Step 1: Select key geometric nodes - Query all Face nodes with feature = BlockExtrude - Filter for opposite planar faces (top and bottom) - These form the pair to dimension for "overall height"

Step 2: Use topology queries - For a cylindrical face ShaftCyl, find its axis and perpendicular end faces - For a planar face, find adjacent edges to determine logical width/length directions - Use face normals and adjacency to determine natural dimension placement

Step 3: Generate drawing dimensions - Create drawing sheet and base view (standard, multi-view projection) - For each KG rule like DIMENSION("overall_height", BlockBottom, BlockTop): - Project faces into drawing view - Find corresponding edges/points in the 2D projection - Call NXOpen drawing API to create linear dimension between projected points

Step 4: Apply parametric links - Link each drawing dimension to the corresponding Expression node in the KG - When the CAD changes, the drawing dimension automatically updates (parametric associativity)

Example NXOpen call:

' Create a horizontal dimension between two faces projected in a view
Dim view As Drawings.DrawingView = ...  ' the projection view
Dim dim = workPart.Dimensions.CreateHorizontalDimensionBuilder(
    "Overall Height",
    view,
    edge1_in_view,
    edge2_in_view
)
' The builder's value property can reference the expression:
dim.Value.RightHandSide = "H_block"

Applications in RapidDraft¶

1. Automatic Dimensioning¶

Use the KG to propose which faces/edges to dimension: - Extract all features from the KG - For each feature type (Extrude, Hole, Blend), apply standard dimensioning rules - Propose dimensions for key parameters (length, width, height, diameter, angle) - Present suggestions to engineer for approval; engineer selects which to keep

2. DFM and Manufacturing Checks¶

Use the KG to infer manufacturing constraints: - Identify thin walls by comparing face area to feature depth (KG traversal) - Flag undercuts by detecting reentrant edges on cylindrical/conical faces - Estimate tool access by checking face orientation against process assumptions - Score feature complexity using expression dependency depth

3. Drawing Memory and Regeneration¶

When the CAD model changes: - Extract the new KG - Compare it to the previous KG (structural diff) - Identify which features/faces are new, deleted, or modified - Re-apply stored dimensioning decisions to corresponding faces in the new KG - For modified faces, suggest re-dimensioning with AI assistance

4. Cross-Part Assembly Reasoning¶

For assemblies, extend the KG: - Create ASSEMBLY nodes and ASSEMBLY_HAS_PART edges - Add PART_MATED_WITH(Part1, Part2) edges for assembly relationships - Use assembly KG to suggest tolerance stack-up analysis and clearance checks - Propagate mating constraints to individual part dimensioning rules

Tools and Implementation¶

Graph Storage: - JSON (lightweight): suitable for small-to-medium parts and embedded storage - Neo4j (enterprise): full graph database with Cypher query language for complex traversals - NetworkX (Python): in-memory graph library for prototyping and rule testing

Extraction: - NXOpen + Journal Recorder: interactive API exploration and learning - Python bindings (NXOpen): easier scripting than VB.NET for graph construction - STEP/IGES parsing: neutral-format fallback when native CAD access is unavailable

Visualization and Debugging: - Cypher queries (Neo4j): inspect relationships and test rule logic - Graphviz: export JSON graph as visual diagram - RapidDraft UI: overlay KG nodes (features, faces, expressions) on 3D model with hyperlinks

Schema Summary¶

Node Type	Key Attributes	Typical Count (small part)
Part	ID, name, modified_date	1
Feature	ID, name, type, build_order	5–20
Body	ID, name, volume, created_by_feature	1–3
Face	ID, type (planar/cyl/cone/etc), area, normal, feature_source	10–50
Edge	ID, type, bounding_faces	20–100
Expression	ID, name, value, formula, unit	10–50

Edge Type	Cardinality	Use Case
PART_HAS_FEATURE	1:many	Feature history, build sequence
FEATURE_CREATES_BODY	many:many	Multi-body features, compound operations
BODY_HAS_FACE	1:many	Topology, dimensioning candidate selection
EXPRESSION_CONSTRAINT	many:many	Parametric propagation, sensitivity analysis
DIMENSION	feature:faces	Dimensioning automation, drawing regeneration

This schema is intentionally minimal to keep RapidDraft's KG lightweight and queryable; it can be extended with additional node/edge types (sketches, constraints, annotations) as needed for advanced features.

Functional Intent Graph: Full Node/Edge Model¶

Source: Architechture & Research/RapidDraft/Technical Architecture/Intent Graph Example.pdf — detailed worked example session (November 2025)

The basic knowledge graph above captures geometry and parametric structure. The intent graph adds a semantic layer that defines why geometry exists and what rules govern it. This section describes the full intent graph model and how it drives drawing generation.

What "Engineering Intent" Means Concretely¶

For one part or assembly, intent boils down to:

Which surfaces/features matter functionally — locating surfaces, sealing surfaces, bearing seats, interfaces
How parts relate to each other in the assembly — who locates whom, which surfaces must align, which gaps are critical
What manufacturing/inspection process is assumed — machined vs moulded, ground vs as-milled
What rules to enforce — standards (ASME/ISO), company rules, safety margins, past failures

Geometry (STEP, native CAD) tells you: "there is a cylinder of radius 20 here." Intent says: "this cylinder is a bearing seat; its position controls rotor runout; we inspect it to 0.01 mm relative to datums A/B."

Node Types in the Full Intent Graph¶

Node Type	Examples
Geometry nodes	`hole_feature_17`, `cyl_face_3`, `face_12`
Semantic nodes	`bearing_seat`, `locating_surface`, `sealing_interface`, `bolt_pattern`, `datum_A`
Process nodes	`milled`, `ground`, `anodized`, `inspection_method_CMM`
Requirement nodes	`req_rotor_runout_0p02`, `req_leakage_zero`, `req_clearance_min_0p1`
Rule nodes	`rule_tol_bearing_seat_ground`, `rule_sealing_surface_flatness`
Assembly nodes	`part_shaft`, `part_housing`, `joint_shaft_in_housing`

Edge Types in the Full Intent Graph¶

GEOMETRY_OF(part_housing) → face_12
TAG(face_12) → bearing_seat
MACHINED_BY(face_12) → ground
SUPPORTS_REQUIREMENT(bearing_seat) → req_rotor_runout_0p02
APPLIES_RULE(rule_tol_bearing_seat_ground) → bearing_seat
CONTACT(face_12) ↔ face_5_of_shaft
BELONGS_TO_DATUM_SYSTEM(face_12) → datum_A

Worked Example: Shaft in Housing¶

Scenario: A housing part contains a cylindrical bore. A shaft fits into that bore via a bearing.

Step A — Autodetect and suggest tags The algorithm analyses geometry and mates: - Detects cylindrical faces that are concentric in the assembly - Suggests: tag(cyl_face_1) → candidate_bearing_seat - Engineer confirms or corrects

Step B — Enrich with process and requirements Engineer provides: - For housing: process = bored + ground - Requirement: "rotor runout ≤ 0.02 mm"

Graph additions:

bearing_seat (semantic node)
req_rotor_runout_0p02 (requirement node)
process_ground (process node)

GEOMETRY_OF(bearing_seat) → cyl_face_1
SUPPORTS_REQUIREMENT(bearing_seat) → req_rotor_runout_0p02
MACHINED_BY(bearing_seat) → process_ground

Step C — Link to rules Pre-defined rule rule_tol_bearing_seat_ground:

For bearing_seat surfaces with ground finish and runout requirement R, suggest: surface finish Ra ≤ 0.4, cylindricity ≤ 0.01, position tolerance relative to datums A/B that keeps runout ≤ R.

APPLIES_RULE(rule_tol_bearing_seat_ground) → bearing_seat

The graph now knows: there is a functionally critical surface, why it's critical (rotor runout), how it's made, and which rule governs its tolerancing.

How the Intent Graph Drives Drawing Generation¶

When creating a drawing view of the housing, the rule engine walks the graph:

View selection — The system knows bearing_seat is important → ensures at least one view shows that cylinder clearly (section view through its axis)
Datums — Rules state "for bearing seats, use the main mounting flange as Datum A, bolt circle as Datum B." Graph gives which face is locating_surface and which pattern is bolt_pattern → datums selected automatically
GD&T callouts — rule_tol_bearing_seat_ground fires over bearing_seat → creates feature control frame with correct syntax; values pulled from requirement and process (0.01 cylindricity, proper datum refs); surface finish symbol from process_ground
Dimensions — Bore diameter dimension is created and tied back to the bearing seat node; if fit requirement changes, rule updates both value and tolerances
Traceability — For each callout: Feature: bearing_seat → face cyl_face_1, Rule: rule_tol_bearing_seat_ground v1.3, Requirement: req_rotor_runout_0p02, User approval timestamp

Why a Graph Is Better Than Ad-Hoc Tables¶

Complex relationships are natural — one surface can participate in multiple chains (locating, sealing, load path); assemblies are graph-shaped by nature
Change handling — when geometry changes, connected functional nodes are immediately identifiable; impacted tolerances/dimensions are known because they're linked
Powerful queries — "Show me all surfaces in this assembly tagged as sealing_interface that are missing flatness tolerance" is a graph query

Graph Stability Under CAD Changes¶

Source: Architechture & Research/RapidDraft/Technical Architecture/Intent Shaft Example.pdf — deep-dive on topological naming problem (November 2025)

Why This Is an Existential Problem¶

Geometry in a CAD system is not stable. When a designer changes a model — even something as innocent as increasing a radius or adding a chamfer — the internal identifiers of faces, edges, and features may change.

This is the Topological Naming Problem: - Each geometric entity (face, edge, vertex) has an internal ID - These IDs are not persistent - Operations like adding a fillet, re-ordering features, modifying sketches, or replacing booleans can cause the kernel to recreate topology with new IDs

face_12 in version 3 of the model is NOT guaranteed to be face_12 in version 4.

If the intent graph attaches rules like bearing_seat → cyl_face_12, and cyl_face_12 disappears after a chamfer is added: the graph breaks, the rule loses its anchor, the drawing loses its meaning, and automation collapses.

This is why nobody has a fully automated drafting pipeline today. The lack of topological persistence kills traceability. SolidWorks, CATIA, NX — all know this. It is the oldest unsolved pain in CAD kernels.

Four Strategies for Graph Stability¶

Approach 1 — Feature-level anchoring (not face-level)

Instead of anchoring to raw topology IDs, anchor logic to feature definitions, which survive more changes:

Bad:  bearing_seat → face_12
Good: bearing_seat → revolve_feature sketch_3

When the model updates, recompute which faces belong to that feature. Downside: only works well in parametric CAD, not neutral formats (STEP).

Approach 2 — Multiple signatures per entity

A face is identified not only by ID but by a signature: - Surface type (plane / cylinder / cone / NURBS) - Orientation - Bounding edges - Adjacency relationships (what touches it) - Parametric location (distance from origin, centre vector) - Semantic tags (if known)

The more stable the signature, the more resilient the link. If topology changes, entities are re-identified by matching signatures, not IDs. Similar to fingerprint hashing or subgraph isomorphism. Used in research at Siemens and Dassault but not exposed as user-facing capability.

Approach 3 — Intent-layer redundancy

Do not store a single link like bearing_seat → edge_id_55. Store a bundle of constraints:

bearing_seat = cylindrical face
  coaxial with axis X
  with radius between 19.95 and 20.05
  adjacent to flange F
  machined by process "ground"

If the model changes: - Search for a face matching this signature - If match is unique → stable link - If match is ambiguous → ask the engineer

This is the CAD equivalent of a Git merge conflict resolution.

Approach 4 — Assembly-relative identification

Faces are identified based on their role in the assembly, not as isolated geometry:

"This cylinder locates the rotor relative to the stator."

Even if the designer remodels the part, the role persists. This is how MBD (Model-Based Definition) wants the world to work. Nobody automates this today — it is a competitive moat.

Layered Stability Architecture¶

Rule → semantic_role → feature_signature → geometry_candidates → kernel_id

Layer	Stability	Fallback
Kernel identifier (face_id)	Least stable	Breaks on any topology change
Feature ownership	Moderate	Survives within same feature tree
Geometric signature	Good	Survives most edits
Intent anchor (bearing_seat)	Most stable	Survives even major redesigns

If layer 4 (kernel ID) changes, layers 1–3 can still restore meaning. This is not easy, but it is solvable — and the fact that it is hard is exactly why it is defensible.

Strategic Importance¶

Scenario	Without stability	With stability
Designer adds chamfer	Graph collapses, rules lost	Graph re-identifies, rules hold
Feature reordered	All links broken	Signature matching restores links
Part redesigned	Full re-tagging required	Assembly roles survive, partial re-tagging
Batch generation	Unreliable outputs	CI-grade validation with diff report

Long-Term Vision: Graph Search Across Models¶

Source: Architechture & Research/RapidDraft/Technical Architecture/Expansion of Graph Search Idea.pdf — strategic critique and roadmap (November 2025)

The Core Idea¶

Once each CAD/FEM model has an underlying intent graph, and those graphs are stored in a backend, the accumulated database becomes a search engine for engineering experience:

"Show me all bearing seats ground to this tolerance"
"Find all battery modules where this cooling channel layout was used"
"Retrieve all shaft designs with similar bearing interfaces"
"Show all models where this rib geometry was used for this load case and passed margin > 20%"

Engineering knowledge moves from tribal to computable and queryable.

What Already Exists (Honest Baseline)¶

Industry is not asleep here: - Shape/geometry search — Siemens Geolus, Dassault shape search, CADSEEK, 3DPartFinder (find similar shapes based on geometry) - PLM attribute search — material, size, project tags - FEA tool templates — search by model tags, load case names

What does not exist: a unified cross-model intent graph for CAD + FEM that searches by functional role rather than just shape or text.

Where Intent Graph Search Is Stronger¶

Search type	Existing tools	Intent graph
"Find parts with this shape"	✅ (geometry search)	✅
"Find bearing seats ground to tolerance X"	❌	✅
"Find all models where this interface was torque-critical"	❌	✅
"Find FEM models where this rib geometry cleared FoS > 2.0"	❌	✅
"Recover undocumented design knowledge"	❌	✅

Why This Will Be Brutally Hard¶

A. Graph quality is the bottleneck To search "by intent," the intent must actually be in the graph. Auto-extracting rich semantics from geometry alone is not realistic. Engineers must tag or review. Most past "knowledge-based engineering" attempts died because engineers refused to feed the system.

B. Scale and drift Millions of model versions, dozens of engineers modifying assemblies over years, graphs drifting. Requires robust feature and pattern matching per revision, expensive recomputation jobs, and a coherent versioning model for intent graphs themselves.

C. FEM adds complexity Mesh entities are even more volatile than CAD topology. Mesh topology changes every time you refine or update geometry. Mapping FEA regions → CAD faces → intent nodes requires stable named sets and region-based linking.

D. Engineer adoption If tagging feels like bureaucracy, engineers will ignore it. The system must pay them back immediately through automation (RapidDraft drawing generation, DFM checks) before they'll invest in enriching the graph.

Realistic Four-Phase Path¶

Phase	Focus	When
Phase 1	Drawing automation and checking — build the intent graph for the subset needed for better drawings, stable tolerancing, and change checking. Make immediate value obvious to engineers.	v0/v1
Phase 2	Local search — simple queries in the UI: "show me other parts tagged with `bearing_seat` made by this process"	v1/v2
Phase 3	Cross-model knowledge search — similarity search, embedding-based search (LLM over graph + metadata), pattern recognition for frequently used design motifs	v3+
Phase 4	CAD/FEM linkage — extend the graph to include simulation entities: loads, constraints, safety margins, convergence status	Future

Pitch Strategy¶

If you pitch graph search to CAD experts as a v1 feature, they will roll their eyes. If you pitch it as the long-term upside of an intent-centric documentation system, it looks extremely powerful and credible.

The search capability evolves organically out of the same infrastructure built for RapidDraft's core value. Every intent graph created during a drawing review is a data point in the future search index.