Skip to content

Human-in-the-Loop: The Pause-Resume Contract

Source files: - Architechture & Research/RapidDraft Studio/Vision/RapidDraft Studio Master Vision.md (sections 2.3, 2.5) Last synthesized: March 2026

Core Concept

The human-in-the-loop model is the product's central differentiator. It achieves seamless intervention without requiring proprietary CAD/CAE tools to be embedded in the IDE. The key is a stateful pause-resume contract where workflows can pause at specific steps, request explicit human intervention, and then resume deterministically from that point.

The Seven-Step Operating Loop

1. Open item from PLM

User selects an item + revision + configuration from the PLM system (Teamcenter, Windchill, etc.). The system creates an immutable workspace snapshot containing: - Source item references - Revision and configuration context - Baseline metadata (materials, approvals, effectivity) - BOM context if relevant

2. Create immutable workspace snapshot

The snapshot captures: - Which PLM system, which item ID, which revision, which configuration - Timestamp of snapshot creation - User who initiated - Translation profile chosen (e.g., "CATIA V5 to OCCT BREP v2.1")

This snapshot is never mutated. All downstream artifacts reference it. If the engineer wants to retry with a different configuration, a new snapshot is created and a new run begins.

3. Run workflow (orchestration)

The IDE executes the selected workflow as a directed acyclic graph (DAG) of steps: 1. PLM fetch (retrieve native geometry) 2. Translation (via commercial SDK into neutral geometry + metadata) 3. Tessellation (for viewport rendering) 4. Feature detection (optional, for context) 5. Deterministic checks (DFM, clearance, interference, fatigue rules, etc.) 6. Finding generation (measured values + thresholds + anchors) 7. Issue creation (wrapping findings for team action) 8. Report generation (formatted output for review)

Each step produces artifacts (with content hash, schema version, lineage). If an upstream artifact hasn't changed, cached results are reused.

4. If blocked, pause with explicit intervention request

At any step, the workflow can pause if human input is needed. The pause is explicit—not a silent failure or a best-guess workaround.

Example pause scenarios: - Mesh quality issue: "Critical fillets detected but mesh density is too coarse for accuracy. Manual refinement needed in HyperMesh." - Ambiguous geometry: "Three potential interpretations of feature 'boss_1' detected. Cannot proceed with rules check until geometry is clarified." - Missing boundary conditions: "Thermal analysis paused: material properties for 'Titanium_custom_alloy' not in library. Supply material data or select standard equivalent." - Tool-specific handling: "Fatigue analysis paused: weld bead profiles at 5 locations need manual specification. CAM-detected profiles are approximate."

The pause request includes: - What: What specifically is needed (mesh refinement, geometry clarification, parameter input, etc.) - Where: Geometry anchor (face IDs, edge coordinates, region highlights) - Why: Why the step is blocked (accuracy risk, ambiguity, missing data, etc.) - Context: The current run state, upstream artifacts, and step history - Expected output: What the system will accept as valid (e.g., "refined mesh with min element size ≥ 0.5 mm at weld toes")

5. User intervention in native tool

Engineer clicks "Open in [TOOL]" (CATIA, HyperMesh, Ansys, etc.).

What happens: - System launches the native tool with exact context: the geometry file, the flagged region (highlighted in the UI), the relevant boundary conditions or constraints, and optional guidance (e.g., "refine mesh to 0.5 mm here"). - The engineer makes the fix in the native tool. - Engineer saves/exports the result. - Tool closes.

The engineer never leaves the IDE mentally. The native tool is a focused, purpose-driven intervention, not a general workspace.

6. Validate outputs and resume

The system detects the updated artifact (via file watcher or explicit user signal "I'm done, resume").

Validation checks: - Output type: Is the file the expected format (mesh file, geometry file, parameter set, etc.)? - Completeness: Does the output contain all required elements (all weld regions refined, all material properties defined, etc.)? - Sanity checks: Do numeric values fall within plausible ranges? (Mesh elements > 0, material density > 0, etc.) - Consistency: Do the new artifacts align with upstream assumptions (geometry bounds, feature topology, etc.)?

If validation passes: - Register the new artifact in the artifact registry with proper provenance (who provided it, when, from which tool version). - Mark the paused step as "RESUMED_WITH_ARTIFACT". - Re-enter the orchestration loop at the paused step, now with the human-provided artifact as input. - Rerun the paused step and all downstream steps that depend on this artifact (cache hits for independent steps).

If validation fails: - Notify the engineer with the specific validation error. - Optionally allow retry ("Go back to HyperMesh and fix these issues: ..."). - Or allow skip/waive (risky; requires explicit acknowledgment).

7. Publish evidence and status back to PLM

Once the run completes (all steps executed, all findings reviewed, all dispositions recorded): - Engineer approves the release via a release checklist. - System assembles an evidence package: run manifest, all artifacts, all findings, all approvals/waivers, audit trail. - System publishes the evidence package back to PLM as an attachment or structured report. - PLM item status updates to reflect release sign-off.

The Intervention Request Data Structure

The system formally models intervention requests as first-class entities:

InterventionRequest:
  intervention_id: UUID
  run_id: UUID
  paused_step_id: str
  tool_id: str  // "catia" | "hypermesh" | "ansys" | "custom"
  instruction: str  // "Refine mesh at fillet regions to 0.5mm minimum"
  geometry_anchor: Anchor  // Face IDs, coordinates, region highlights
  launch_context: dict  // File paths, tool settings, expected files to open
  expected_outputs: list[OutputSpec]  // Expected files, formats, metadata
  validator: function  // Custom validation logic for this tool/step
  resume_policy: str  // "auto_validate_resume" | "manual_confirm" | "skip_on_error"
  created_at: timestamp
  resumed_at: timestamp (optional)
  resolution_status: "pending" | "resolved" | "skipped" | "failed"

Geometry Anchors and Stability

A critical technical challenge: how do you refer to the same geometric feature across revisions when the CAD tool can renumber faces/edges internally?

RapidDraft uses a multi-strategy anchor remapping approach:

  1. Persistent IDs: When the native format supports stable topological identifiers (e.g., feature history in Parasolid), use them.

  2. Coordinate-based anchors: For transient CAD systems, anchor by geometric position (face center coordinates + normal vector) with a confidence interval. The system can highlight potential matches and ask the engineer for confirmation.

  3. Feature-based anchors: For assemblies, reference features by their design intent (e.g., "boss_1" fillet at the base), with fallback to coordinate search if naming changes.

  4. Manual re-anchor: If automated remap fails, the engineer can manually select the corresponding feature in the updated geometry, and the system learns the new anchor mapping.

This ensures that findings from old runs can be visually and programmatically linked to new geometry, supporting the "what changed since last review" workflow.

Collaboration and Disposition

After a run completes, engineers review findings and "dispose" them:

  • Accept: Finding is correct; no action needed (e.g., "Wall thickness is adequate; no change required").
  • Fix: Finding indicates a real problem; engineer commits to design change.
  • Waive: Finding is technically valid but accepted as-is (e.g., "Corner fillet radius is below recommendation, but customer accepts the risk").

Each disposition is: - Linked to the finding - Attributed to a user (who decided) - Timestamped - Optional rationale attached

When the design is revised and a new run is executed, the system highlights which old findings are now "resolved" (the issue is fixed) vs. "still present" (the issue persists or has regressed).

Resume Correctness and Caching

The pause/resume contract is deterministic and auditable:

  1. Deterministic restart: When resuming, the paused step is rerun with the exact same inputs as before, except for the human-provided artifact. Outputs are identical (modulo timestamps).

  2. Cache invalidation: Only steps that depend on the human-provided artifact are rerun. Independent parallel steps reuse cached results.

  3. Audit trail: Every resume is logged with: what was paused, who provided the artifact, what artifact was provided, how long the human spent, what validation checks passed, which steps were rerun, and what new artifacts were produced.

  4. Reproducibility: Any historical run (including pauses and resumes) can be replayed deterministically, enabling investigation of "why did we get this finding in March but not in April?"

UX: The Intervention Panel

In the IDE, when a workflow pauses, the AI panel shows:

WORKFLOW PAUSED - HUMAN NEEDED

Step: Mesh Refinement (4/7)
Reason: Critical fillet regions have coarse mesh

What you need to do:
  Refine mesh at fillet roots to ≥0.5mm minimum element size
  See highlighted regions in 3D view (magenta = critical zones)

Suggested tool: HyperMesh (your current license is active)

[Open in HyperMesh]  [Skip this step]  [Edit manually]

Expected output:
  Mesh file (Ansys .msh or Nastran .bdf)
  Minimum element size at flagged regions: ≥0.5mm
  Total element count should remain <500k

Estimated time: 15–30 minutes
Already spent: 8 minutes (on previous intervention)

Once the engineer opens HyperMesh, the system launches the tool with the geometry and a visual overlay highlighting the regions needing refinement. The engineer works in the native tool. When they close it, the system detects the updated file, validates it, and resumes automatically (if validation passes).

If validation fails: 

VALIDATION FAILED

Artifact: refined_mesh.msh
Issues detected:
  - Element size at weld_toe_A: 0.7mm (goal: ≥0.5mm) ✓ OK
  - Element size at weld_toe_B: 0.3mm (goal: ≥0.5mm) ✗ REFINE MORE
  - Element size at boss_fillet: 0.2mm (goal: ≥0.5mm) ✗ REFINE MORE

[Go back to HyperMesh]  [Skip refinement]  [Accept with waiver]

Summary: Why This Works

  1. Preserves control: Engineers remain in command; they choose when/how to intervene.
  2. Preserves determinism: Workflows are reproducible; every run can be explained.
  3. Preserves native tools: No need to embed CATIA/HyperMesh; they remain the authoring authorities.
  4. Achieves radical UX: Seamless handoff between IDE and native tools, with auto-resume.
  5. Supports collaboration: Interventions are tracked, assigned, and reviewed like any other engineering task.
  6. Enables trust: Engineers can audit any finding back to the paused steps and human decisions that led to it.

This is the core of RapidDraft's differentiation: it makes orchestration and human-in-the-loop feel natural and transparent, not clunky or distrusted.