Skip to content

System Architecture

Source files: integrated RapidDraft runtime and current project-management sources Last synthesized: April 2026 Purpose: Technical overview of the active RapidDraft runtime surface, deployment path, and key backend responsibilities.

Architecture Overview

RapidDraft is currently best understood as one integrated product shell backed by one active integration repo:

D:\02_Code\45_merged_macos_colabui_dfmanim

That shell hosts multiple workflow modes, but they now share one practical runtime surface rather than living mainly as separate product implementations.

At a high level:

  • the React frontend hosts the shared review workspace and mode-specific shells
  • the FastAPI backend handles model ingestion, canonical scene generation, Part Facts, DFM review, review export, and related runtime services
  • hosted traffic reaches the same active app runtime through app.rapiddraft.ai and the protected pilots.rapiddraft.ai path

Frontend Surface

The frontend is a shared workspace shell with mode-specific entry points rather than separate products.

Current responsibilities include:

  • STEP/model workspace orchestration
  • viewer state and selection context
  • DFM sidebar workflow and review progress
  • Light scan / Deep scan control for scan-depth-aware DFM review
  • Part Facts drawer state and polling
  • mode switching across the integrated shell
  • review export capture orchestration

The architectural point is that the product now behaves like one integrated surface with bounded workflow modes, not a loose collection of disconnected shells.

Backend Responsibilities

The backend owns the main runtime contracts behind the integrated product:

  • model upload and storage-path management
  • canonical scene generation and viewer-ready state
  • component profile and metadata handling
  • Part Facts extraction, warmup, and status artifacts
  • scan-depth-aware Part Facts cache compatibility, where Deep scan can satisfy later Light scan requests but Light scan does not satisfy Deep scan
  • DFM bundle/config delivery
  • rule-driven review-preparation jobs
  • DFM review execution and cost/standards outputs
  • DFM PDF export assembly

The most important April shift is that DFM review preparation now orchestrates evidence work instead of assuming broad extraction should always happen first.

For injection molding, this evidence orchestration now has two explicit depths:

  • Light scan is the default first-pass path for fast wall, hole, and basic molded evidence.
  • Deep scan runs richer molded feature extraction for ribs, bosses, collars, pins, gussets, low/zero draft, grouped side actions, sink/mass screening, and localized bbox/face-index evidence.

The plastics route also computes product-vs-tooling applicability. Mold/tooling assemblies are gated out of product-part boss/rib/wall findings and receive a clear selection warning instead.

Deployment and Runtime Topology

The current hosted story should be described simply:

  • app.rapiddraft.ai is the main live app path
  • pilots.rapiddraft.ai is the protected pilot path
  • both should be treated as one active runtime path
  • Cloudflare Access stays in front of pilots.rapiddraft.ai

This is simpler than the older staging-service story and should replace documentation that implies pilots are still running a meaningfully separate primary app runtime.

When talking about rollout confidence, keep three states distinct:

  • implemented in the current branch
  • validated locally
  • runtime-verified on the hosted path

Data and Runtime State

RapidDraft currently combines bundle-level shared knowledge with model-local persisted state.

Examples:

  • shared DFM bundle and rule metadata
  • model-local component profiles
  • canonical scene and viewer artifacts
  • Part Facts cache and warmup-status artifacts
  • export manifests and generated review PDFs

This allows the app to stay integrated without pretending every operation is globally stateless.

Current Design Priorities Reflected in the Architecture

The architecture is now optimized more around pilot usability and runtime legibility than around maximal extraction depth on every request.

That shows up as:

  • shared shell first, separate specialist paths second
  • staged review progress instead of opaque waits
  • explicit Light scan versus Deep scan instead of one hidden extraction depth
  • cached or prewarmed Part Facts instead of first-use blocking
  • evidence-planned extraction instead of blanket extraction
  • product-vs-tooling gating for plastics so mold assemblies do not create noisy molded-product findings
  • protected pilot access without a different product story

Remaining Gaps

The architecture is materially clearer than it was in March, but some gaps remain:

  • topology-linked geometry localization is still not strong enough, even though Deep scan now improves bbox and face-index coverage for plastics findings
  • bounded edit workflows are not yet production-worthy
  • the collaboration and issue-management layer is still shallower than the review runtime
  • rollout verification still needs stronger end-to-end discipline than a green deploy alone

Sources

  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\part_facts.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\main.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\web\src\components\DfmSidebar.tsx
  • D:\02_Code\45_merged_macos_colabui_dfmanim\docs\validation\injection-molding-dev-loop-review.md