Skip to content

Runtime Architecture Direction

Purpose: Capture the architecture direction implied by the current RapidDraft runtime audit and the inbox architecture update note. Last synthesized: May 2026

Core Direction

RapidDraft should continue toward a runtime model where preview rendering, canonical geometry, Part Facts, and DFM review are related but not forced into one heavy serial job.

The architectural direction is:

  • preview first
  • canonical detail second
  • exact specialty extraction only when needed
  • DFM and viewer flows treated as sibling consumers over the same geometry identity

What Should Be Preserved

  • no return to a FreeCAD-heavy runtime path
  • human-in-the-loop review as the primary UX contract
  • deterministic geometry and evidence handling where review trust depends on it

1. Preview First

The first user-visible surface should prioritize fast viewer readiness rather than broad exact semantic extraction.

2. Stage Canonical Detail

Canonical work should be layered:

  1. preview mesh / basic structure
  2. selectable faces and stable component identity
  3. feature hints and medium-cost semantics
  4. exact specialty metrics only for workflows that genuinely need them

3. Defer Exact Edge Extraction

Exact edge extraction is valuable, but it should not be paid for on every path by default. It is a specialty computation, not the baseline cost of opening a model.

4. Prioritize Selected-Component-First Work

When the user is focused on one component, warmup and extraction should prefer that component rather than behaving like every operation must complete at full-model scope first.

5. Keep External Viewer References as References

External material such as occviewer and OCCT visualization docs are useful benchmarks, but they are references, not requirements. Product architecture should stay grounded in RapidDraft's own runtime constraints and user flows.

Product Implication

This direction supports the current wedge better than a broad "one giant pipeline" design. Faster preview, staged exactness, and explicit review evidence make the app feel more trustworthy and more pilot-ready than brute-force extraction on every request.

Open Questions

  • Which exact extraction stages should remain synchronous for the user versus background-only?
  • Where should the selection-first warmup policy live: canonical warmup, Part Facts, or both?
  • Which runtime guarantees are required before the pilot workflow can claim strong responsiveness?

Sources

  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\TextCAD_Wiki\inbox\architectureupdate_gpt.md
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\TextCAD_Wiki\inbox\RapidDraft_AUDIT_gpt.md
  • System Architecture