Runtime Architecture Direction¶
Last synthesized: June 18, 2026
RapidDraft's runtime should be split into clear workflows instead of one overloaded pipeline. Rendering, review interaction, geometry analysis, DFM checks, and report generation need shared identity where useful, but they should not all depend on the same heavy runtime path.
Direction¶
| Runtime area | Direction | Why |
|---|---|---|
| Upload and import | Accept supported CAD formats through the selected import stack; preserve original artifact metadata. | Avoid building the product around a single default intermediate file when users bring varied CAD formats. |
| Rendering | Keep rendering fast and separate from deep analysis. Use lightweight scene/mesh artifacts where appropriate. | A user opening a file should not pay the cost of full DFM or Part Facts extraction. |
| Selection and annotation | Maintain stable object identity for faces, edges, and review markers wherever the viewer supports it. | Geometry-pinned review is part of the product value and must survive ordinary review flows. |
| Part Facts / scanning | Run only when the user asks for review, DFM, or analysis. | Deep extraction should be purposeful, parameterized, and explainable. |
| DFM and drawing checks | Treat as on-demand review jobs with explicit process assumptions and evidence. | Engineers need to understand what was checked and why a finding appeared. |
| Report and artifact generation | Produce review-ready outputs from checked evidence, comments, and model state. | The artifact is what lets RapidDraft travel into supplier and internal review workflows. |
Architectural Boundary¶
The product should distinguish:
- display pipeline: open, render, inspect, navigate, select
- review pipeline: comments, issue markers, evidence, collaboration state
- analysis pipeline: Part Facts, surfaces, edges, process-specific checks
- artifact pipeline: summaries, reports, exported review packages
These can share identifiers and cached artifacts, but they should be independently understandable and testable.
Near-Term Implementation Principle¶
The no-FreeCAD direction should be pursued as a controlled architecture migration, not as a blind rewrite. The existing runtime audit should guide which behavior must be preserved before FreeCAD-dependent paths are retired.
Open Questions¶
- Which object identity scheme should be canonical for viewer selection and DFM evidence?
- Which CAD formats should be first-class in the no-FreeCAD path?
- Which checks can run in parallel safely, and which require ordered extraction?
Sources¶
docs/01_RapidDraft/04_Technical_Architecture/OCCT_FreeCAD_Runtime_Architecture_Audit.mddocs/01_RapidDraft/04_Technical_Architecture/No_FreeCAD_Architecture_Notes.mddocs/01_RapidDraft/04_Technical_Architecture/CAD_Viewer_and_Annotation_Architecture.md/Users/adeelyj/Library/CloudStorage/OneDrive-Personal/100_Knowledge/203_TextCAD/01_Product_Project_Management/TextCAD_Wiki/inbox/RapidDraft_AUDIT_gpt.md/Users/adeelyj/Library/CloudStorage/OneDrive-Personal/100_Knowledge/203_TextCAD/01_Product_Project_Management/TextCAD_Wiki/inbox/architectureupdate_gpt.md