Skip to content

RapidDraft Studio Master Vision and Product Blueprint

Source files: - Architechture & Research/RapidDraft Studio/Vision/RapidDraft Studio Master Vision.md - Architechture & Research/RapidDraft Studio/Vision/RapidDraft Studio Master Vision.docx Last synthesized: March 2026

Single Source of Truth (Synthesis + Appendices)

Document Fact Value
Primary objective Combine all research outputs into one readable master document
Source corpus size 27 files across markdown, text, docx, jsx, drawio, and images
Output mode Synthesis + appendices
Decision posture Recommend one path while preserving alternatives
Visual policy Curated key visuals with captions and rationale
Style baseline Claude-style formatting patterns from existing Claude-output docs

How To Use This Document

  • If you need a fast understanding now, read Part A (Sections 1 to 8).
  • If you need full provenance and completeness, read Part B (Appendices A to E).
  • If you need implementation-ready structure, use Section 6 (Roadmap) plus the architecture sections.

PART A - SYNTHESIS (Reader-First)

1. Executive Summary (Read This First)

1.1 Vision in one line

RapidDraft Studio is an AI-first engineering workflow IDE where the IDE orchestrates end-to-end work, while native CAD/CAE tools remain the human authoring authorities.

1.2 Product boundary (what it is and what it is not)

Product Is Product Is Not
A run-and-artifact orchestration platform for engineering workflows A replacement for CATIA, NX, SOLIDWORKS, or HyperMesh
A deterministic review/release system with full traceability A black-box AI design tool that asks engineers to trust ungrounded outputs
A PLM-first engineering cockpit with pause/resume intervention loops A thin plugin inside one CAD tool with limited workflow scope

1.3 Why this matters

The repeated signal across sources is clear:

  • Engineers want automation and speed, but not loss of control.
  • AI should help with orchestration, summarization, and guidance.
  • Deterministic checks must remain the source of truth.
  • Collaboration must be attached to geometry, findings, and revisions, not disconnected chat.

1.4 Canonical recommendation

Adopt a hybrid architecture with:

  • deterministic run/artifact core,
  • PLM-first ingestion,
  • governed native-format translation,
  • external native-tool intervention loop,
  • IDE-first user experience,
  • browser/classic review surface as compatibility shell.

2.1 Decision snapshot

Decision Topic Recommended Why
Product interaction model IDE as orchestrator Differentiates product while preserving engineer control
Core architecture Hybrid (shared backend + desktop/agent bridge + web control plane) Best balance of speed, quality, enterprise realism
Source of truth Deterministic checks + artifact lineage Enables trust, auditability, and reproducibility
Native formats PLM-first + commercial translator service Realistic way to support CAT/NX/SW/Creo ecosystems
Human intervention Pause/resume contracts + one-click open in native tools Achieves radical UX without illegal/fragile embedding
AI authority boundary Advisory only for critical engineering outcomes Required for adoption in physics/math driven domains

2.2 Non-negotiable architecture boundaries

  1. Snapshot-Run-Artifact model is the system backbone.
  2. Connector boundary isolates customer-native tools and environments.
  3. Translation pipeline is a governed service, not ad-hoc conversion.
  4. Geometry anchor remapping strategy is required for revision-safe collaboration.

2.3 End-to-end operating loop

  1. Open item from PLM (item + revision + configuration).
  2. Create immutable workspace snapshot with metadata and source refs.
  3. Run workflow (translation, checks, findings, reports, issue generation).
  4. If blocked, pause with explicit intervention request.
  5. Launch native tool with exact context, perform human edit, capture outputs.
  6. Validate outputs, resume from paused step, rerun affected steps only.
  7. Publish evidence package and status back to PLM.

2.4 Architecture visual concept

The recommended architecture shows the stable contract between UI shell, orchestration core, translation service, deterministic skills, and external tools. Key layers:

  • UI Shell: Code-OSS-based desktop or browser classic
  • Orchestration Core: Workflow execution, state management, pause/resume
  • Translation Service: Commercial SDK for native formats
  • Deterministic Skills: DFM, meshing, analysis, checks (truth layer)
  • Connector Layer: PLM adapters, tool intervention APIs, publication pipelines

2.5 Human-in-the-loop sequence

The product's core differentiator: seamless intervention and deterministic resume. The sequence is:

  1. Workflow executes deterministically until blocked.
  2. System pauses with explicit intervention request (what/where/why).
  3. User clicks "Open in CATIA" or "Open in HyperMesh" with exact context.
  4. User edits geometry, saves/exports.
  5. System detects updated artifact, validates output.
  6. System resumes from paused step with validated artifact.
  7. Affected downstream steps rerun automatically (cached steps skip).
  8. Engineer reviews new findings and disposition.

3. Canonical Product Model

3.1 Core entities

Entity Definition Why it exists
Snapshot Immutable reference to source item/revision/configuration and translation profile Guarantees reproducibility
Run Versioned workflow execution instance with step states and events Captures process truth
Artifact Typed output with hash, schema version, lineage, and producer step Enables audit and cache reuse
Finding Deterministic issue record with measured value, threshold, rule, and geometry anchor Trustworthy engineering signal
Issue/Task Ownership and lifecycle wrapper around findings Team execution and accountability
Decision/Approval Sign-off, waiver, rationale, signer, timestamp Governance and release defensibility
Publication Controlled writeback package to PLM with evidence Enterprise workflow integration

3.2 Trust model (authoritative vs advisory)

Layer Role
Deterministic engines Authoritative for findings and pass/fail outcomes
AI assistant (Dexter) Advisory for summaries, prioritization, suggested fixes, workflow guidance, and drafting
Engineer Final authority for dispositions, edits, waivers, and release decisions

3.3 Native format and PLM strategy

  • Prefer PLM-first entry with item/revision/configuration context.
  • Use commercial translator SDK path for native datasets.
  • Keep both geometry truth artifacts and viewer artifacts.
  • Use precise geometry artifacts for deterministic checks.
  • Use optimized viewer artifacts for responsive interaction.
  • Treat translator version/profile as first-class provenance.

3.4 Deployment strategy

Evolution from desktop-first or web-first toward hybrid: whichever path starts first should evolve toward a hybrid control-plane architecture, preserving flexibility while avoiding shell lock-in.

3.5 Snapshot-to-publication artifact flow

The full lifecycle connects snapshots, runs, findings, decisions, logs, and evidence publication into one governed sequence:

  1. Source Snapshot (immutable): PLM item/revision/config
  2. Run (orchestration): Workflow steps with state
  3. Findings (deterministic): Measured outcomes with thresholds
  4. Issues (collaboration): Team tasks and decisions
  5. Approvals (governance): Sign-offs and waivers
  6. Publication (release): Evidence package back to PLM

4. UX and Workflow Synthesis

4.1 Canonical shell model

The strongest recurring UI pattern is a five-surface cockpit:

  • CAD — Model tree, 3D viewer, geometry context
  • Review — Findings, anchored comments, issue list
  • Workflows — Workflow canvas, run configuration, step execution
  • AI — Assistant panel, commands, proposals, handoff guidance
  • Releases — Checklist, approvals, diff summaries, publication status

4.2 UX principles consolidated

  1. Keep the engineer oriented with persistent project tree + context sidebars.
  2. Keep operations visible with runs/logs/jobs/artifacts panel.
  3. Keep findings actionable with geometry-anchored evidence and issue hooks.
  4. Keep AI constrained to explicit commands and workflow steps.
  5. Keep release state transparent with checklist, sign-offs, and diff summaries.

4.3 Visual design language

The integrated cockpit brings together model context, findings, intervention state, and AI guidance in one workspace. Dark theme with blue accents, consistent left sidebar activity bar, bottom status/jobs panel. Each surface (CAD, Review, Workflows, AI, Releases) is a distinct interaction mode accessible from the activity bar.

5.1 Timeline summary

Topic Explored Recommended Rationale
Interaction model CAD plugin-first, conventional web review IDE-orchestrator-first with compatibility shell Highest differentiation with controlled adoption risk
Shell foundation Electron-first app, Code-OSS fork, Tauri, full native Code-OSS fork + extension platform Preserve strategic flexibility while moving fast
Native CAD embedding In-tab/containerized native CAD External launch + deterministic pause/resume Realistic with licensing, GPU, and support constraints
Data source model Uploaded STEP-first PLM-first + governed translation path Required for enterprise truth and traceability
AI role Free-form AI decision making Advisory AI + deterministic authority Needed for trust in engineering domain
Collaboration Generic comments/chat Geometry-anchored review sessions tied to runs and revisions Preserves context across lifecycle

5.2 Option matrix retained for transparency

Domain Explored options Current status
UI shell Electron, Tauri, Code-OSS, full native, hybrid Recommended: Code-OSS fork with private extension registry
Deployment posture Desktop-first, web-first, hybrid Recommended: hybrid evolution
Translator path Vendor APIs, translator SDKs, neutral formats, reverse engineering Recommended: commercial translator SDK strategy
Collaboration model Basic issue list, session-based anchored review Recommended: session-based anchored review
Release model Report-only export vs governed evidence pack Recommended: governed evidence pack + PLM publication

6. Implementation Roadmap (Decision-Complete)

Phase 1: Core contracts and provenance foundation

  • Finalize Snapshot-Run-Artifact contracts and versioning rules.
  • Define immutable source reference model for PLM entry.
  • Standardize artifact hashing, schema versions, and lineage fields.

Phase 2: PLM-first workspace and translator service integration

  • Build normalized PLM adapter contract (Teamcenter first, extensible).
  • Integrate commercial translator service as governed step.
  • Persist translator profile and diagnostics into run metadata.

Phase 3: Deterministic workflow execution and intervention loop

  • Promote run orchestration API surface.
  • Implement typed intervention requests and validators.
  • Implement pause/resume with affected-step recomputation only.

Phase 4: IDE cockpit surfaces and browser compatibility shell

  • Ship CAD, Review, Workflows, AI, and Releases surfaces.
  • Keep browser shell on same backend contracts to reduce adoption risk.
  • Add run timeline, logs, artifacts, and status controls.

Phase 5: Collaboration and publication hardening

  • Add geometry-anchored review sessions and issue lifecycle.
  • Add approvals, waivers, sign-offs, and release checklists.
  • Add PLM writeback pipeline for evidence package publication.

Phase 6: Scale and quality hardening

  • Improve anchor remap confidence and reattach workflows.
  • Expand skill ecosystem under strict typed interfaces.
  • Add benchmark datasets and deterministic regression gates.

7. Key Risks and Mitigations

Risk Why it matters Mitigation
Native format fidelity drift Can break trust and deterministic reproducibility Translator regression harness + versioned profiles
Geometry anchor instability across revisions Can break collaboration continuity Confidence-based remap + manual reattach UX + persistent IDs where possible
Over-powerful AI behavior Can undermine engineer trust Keep AI advisory, require deterministic evidence for authoritative outputs
Shell lock-in and maintenance drag Can slow delivery and increase technical debt Keep backend and extension contracts shell-agnostic
Enterprise integration friction Can block deployment and adoption PLM-first adapters, private extension registry, single-tenant/on-prem defaults
Performance on large assemblies Can hurt usability Multi-LOD artifacts, precompute pipelines, cache strategy

8. Immediate Action Checklist

  1. Freeze API contracts for workspace, run, intervention, artifact, publication.
  2. Choose translator vendor and define fidelity KPIs.
  3. Build one end-to-end pilot flow: PLM open → DFM run → intervention → resume → publish.
  4. Stand up review session objects with anchored findings and sign-off trail.
  5. Measure pilot success with precision and intervention-resume success metrics.

See linked pages for deep dives on architecture, human-in-the-loop, AI language, and research validation.