Skip to content

DFM Pipeline Architecture

Source files: integrated RapidDraft runtime and April 2026 CAD-intelligence handovers Last synthesized: April 2026

Overview

The active RapidDraft DFM path is now a rule-driven review-preparation pipeline rather than a blanket "extract everything, then review" flow. The system resolves process context and active rules first, derives the evidence families those rules actually need, reuses compatible cached Part Facts where possible, and only then runs the missing extraction work.

Viewer-load preparation is now a separate runtime lane. Original-model viewing can start from a preview mesh while canonical selectable geometry warms asynchronously and lazily per component. DFM review progress should therefore be read as review-preparation state, not as a proxy for viewer readiness.

This keeps the customer-facing review path faster and more legible, especially for injection-molding parts where CNC-heavy geometry extraction was previously doing unnecessary work. The injection-molding path now adds an explicit scan-depth choice: Light scan is the fast default, while Deep scan requests richer molded feature evidence when the user needs ribs, bosses, draft, side actions, and sink/mass screening.

The April 2026 scanner-pipeline loop makes the long CAD work visible. Review jobs can now report planned scanners, the active scanner, elapsed time, cache state, and overtime status instead of hiding all geometry extraction behind one coarse progress phase. Multipart STEP review also has a selected-component safety rail: scanner evidence must stay inside the selected component envelope, and newer resolution prefers matching OCC solids by scene bounds before falling back to ordinal component_N mapping.

Active Review Flow

flowchart TD
    A["User clicks Generate review"] --> B["Resolve selected component and saved profile"]
    B --> C["Determine effective process route and active rule packs"]
    C --> D["Collect rule inputs_required and evidence families"]
    D --> E["Apply geometry_scan_depth: light or deep"]
    E --> F["Map evidence families to concrete scanner units"]
    F --> G["Check compatible cached Part Facts and scanner artifacts"]
    G --> H["Run only missing scanners for the selected component"]
    H --> I["Bridge resulting Part Facts into review facts"]
    I --> J["Execute selected rules"]
    J --> K["Assemble one stable final review"]
    K --> L["Frontend shows findings, scanner status, standards, cost, export options"]

Core Design Shift

Old default mental model

  1. load STEP
  2. extract broad Part Facts
  3. bridge everything into review facts
  4. evaluate rules

That model still described some historical specialist and benchmark paths, but it no longer matches the active user-facing review path well.

Current active model

  1. resolve route/process context first
  2. inspect active rules and their inputs_required
  3. map those inputs into evidence families or extraction capabilities
  4. reuse only compatible cached Part Facts
  5. respect the selected geometry scan depth
  6. resolve the selected component and validate scanner artifacts against that scope
  7. run only the missing scanner units
  8. execute one stable final review with staged progress

Stage-by-Stage Breakdown

1. Context and Route Resolution

The pipeline starts by resolving the current component profile and effective route. This can use saved profile data, explicit user choices, and route/planning logic. The key point is that process context is known before deep extraction begins.

This matters because process applicability now changes what evidence should be gathered at all.

2. Rule Applicability and Evidence Planning

The active rules are inspected before extraction work is scheduled.

Important consequences:

  • rule applicability can differ by process
  • inputs_required drives what evidence must exist
  • drawing, manual, or weld context should not trigger unrelated OCC geometry work
  • plastics review should avoid blanket CNC-heavy extraction unless a selected rule truly needs it

The internal planner now works with finer evidence families and scanner units rather than one coarse "geometry complete" assumption.

3. Capability-Aware Part Facts Reuse

Part Facts remain the reusable geometry-and-manufacturing cache, but reuse is no longer treated as always safe.

Cached Part Facts are reused only when the capability scope and normalized profile remain compatible with the new review request. That prevents stale facts from one route or capability set silently driving another.

For geometry scan depth, compatibility is intentionally asymmetric: Deep scan can satisfy a later Light scan request, but a Light scan cache does not satisfy a Deep scan request.

4. Missing Capability Extraction

If required evidence is missing, the backend runs only the extraction capabilities needed for the active review.

Examples:

  • plastics review usually wants core_geometry plus plastics-oriented evidence
  • Light scan keeps wall, hole, and basic molded evidence fast
  • Deep scan adds richer molded bosses, ribs, collars, pins, gussets, low/zero draft, grouped side actions, and sink/mass screening
  • CNC corner metrics are requested only when active rules need them
  • exact full inventory remains available for benchmark, candidate, parity, and diagnostic paths
  • scanner rows keep heavy detectors visible as queued, running, overtime, cached, completed, skipped, or failed

This is the main reason the newer review path is more viable for molded parts than the older blanket extraction model.

5. Part Facts to Review Facts Bridge

The bridge still converts rich Part Facts into the flatter review-facts vocabulary used by the rule engine. That contract remains important because the review layer should not have to understand every low-level feature candidate.

The remaining long-term gap is not the bridge itself. It is better provenance and topology-linked mapping back to geometry for trustworthy highlighting and later remediation.

6. Async Review-Preparation Jobs

The active DFM sidebar now uses review-preparation jobs rather than a single opaque blocking call.

Users see staged progress while the backend:

  1. checks route and active rules
  2. reuses or prepares evidence
  3. runs missing extraction capabilities
  4. evaluates rules
  5. assembles one final review

The product goal is stable output with visible progress, not a progressively mutating review.

7. Scanner Artifacts and Selected-Component Scope

The scanner layer is becoming the boundary between "what the review needs" and "what OCC has to compute." Scanner artifacts are written independently where possible and reused only after they pass selected-component scope validation.

For multipart STEP files, DFM review is selected-component scoped by default. Part Facts reads the selected component bounds from the scene artifact, resolves the analysis shape against those bounds, and rejects scanner evidence that escapes that envelope. This is intentionally strict: if a scan cannot prove it belongs to the selected part, the product should show a scope problem rather than issue cards based on another body in the assembly.

8. Final Review Output

The review response still returns one stable final payload with findings, standards traces, cost information, and plan metadata. The major change is how the system got there: planned evidence work, selective extraction, and clearer staged behavior.

Part Facts and Warmup Behavior

Part Facts are now part of a broader runtime behavior model, not just a manual extraction button.

Current runtime behavior:

  • uploads can auto-start Part Facts preparation
  • first-open drawer behavior can surface warmup status instead of a blocking blank state
  • explicit refresh remains available
  • warmup status is persisted so the frontend can poll rather than guess

This makes Part Facts more pilot-safe without turning them into the only orchestrator of review behavior.

Runtime Boundaries

The active user-facing review path should now be described as:

  • process-aware
  • rule-driven
  • capability-aware
  • scanner-transparent
  • selected-component scoped for multipart STEP files
  • cache-compatible
  • async in preparation behavior
  • stable in final review output

The following paths may still use richer or broader extraction logic:

  • benchmark validation
  • candidate-regenerated review
  • parity checks
  • explicit diagnostics

That separation is intentional. The product path and the specialist validation path no longer need to be identical to stay trustworthy.

What This Architecture Enables

  • faster default plastics review behavior
  • explicit Deep scan for more physically credible injection-molding evidence
  • product-vs-tooling gating so mold assemblies do not produce noisy product-part findings
  • less hidden waiting in the DFM sidebar
  • safer selected-part review for multipart STEP assemblies
  • a non-blank viewer during heavy-model canonical warmup
  • clear separation between viewer progress, Part Facts progress, and review progress
  • clearer reasoning about which evidence a review actually used
  • better separation between pilot-facing runtime behavior and heavyweight specialist paths

Sources

  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\main.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\part_facts.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\dfm_part_facts_bridge.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\server\dfm_scanner_plan.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\scripts\validate_injection_molding_loop.py
  • D:\02_Code\45_merged_macos_colabui_dfmanim\docs\contracts\dfm-scan-pipeline.md
  • D:\02_Code\45_merged_macos_colabui_dfmanim\docs\validation\dfm-scan-benchmark.md