Skip to content

RapidDraft Studio — Code-OSS Architecture and 8-Plane System Design

Source: Architechture & Research/RapidDraft Studio/Architecture/RapidDraft CodeOSS.docx (March 2026, internal technical reference) Status: Reference — architecture design for RapidDraft Studio Key concept: 8 independent system planes with clean typed contracts between them

Code-OSS / VSCodium Fork Consideration

A Code-OSS (VS Code open-source) fork is the right choice specifically when:

"Your product IS an IDE distribution + extension platform" — you want the "engineering platform like VS Code" identity and a third-party extension story from day one.

If you are not building a developer IDE distribution but rather an engineering review cockpit, you have more freedom (see Fastest vs Best Vision for the full analysis). The architecture below applies regardless of UI shell choice.

The 8-Plane System Architecture

The platform is organised into eight independent planes. Each plane has a clear responsibility and communicates through typed contracts. This separation is independent of which UI shell you choose (Code-OSS fork, Electron, Tauri, or web).

Plane 1 — Presentation (Studio UI)

The presentation plane is the user-facing cockpit. It is not "new CAD" — editing geometry and meshes happens in native tools when required. The Studio UI is a control plane for orchestrating, reviewing, and approving engineering work.

Core capabilities: - Browse and open parts/assemblies from PLM in native dataset formats - Display 3D assemblies/parts, 2D drawings, FE models, ECAD views, documents, and spreadsheets - Overlay findings: pins, highlights, measurements, callouts anchored to geometry - Workflow cockpit: run status, step logs, pause/resume controls - Review and approvals: revision diff, sign-offs, release checklists - Dexter agent chat + command palette ("run DFM check," "generate report," "summarise changes") - Extension UI: install and configure skill plugins (DFM, mesh, cost, drafting, CFD, post-processing)

Plane 2 — Data (Artifact Graph)

The data plane is the system of record and the backbone of agentic engineering with legally acceptable artefacts. Everything is stored as typed, versioned, connected objects with full provenance.

Core artefact types: - CAD snapshots (tessellation + B-Rep + PMI + assembly structure) - Simulation results (mesh, results, post-processing outputs) - Findings (DFM, drawing checks, mesh quality, simulation anomalies) - Reports and evidence packs (PDF + JSON manifest + hashes + logs + approvals) - Approval records and sign-offs - Comments and tasks anchored to geometry revisions

Storage strategy:

Layer Technology
Metadata + lineage PostgreSQL (relational, queryable, recursive lineage queries)
Artefact payloads S3-compatible object storage (MinIO for on-prem, S3 for cloud)
Search/index OpenSearch or Elastic (optional early — for finding issues across projects)
Audit log Append-only event log in database + immutable export, or event bus + WORM storage

Plane 3 — Execution (Workflow Orchestration)

The execution plane delivers the "Cursor-like continuous loop" while preserving determinism and full traceability. It is the engine that runs agents, manages caching, and handles the human-in-the-loop pause/resume cycle.

Core capabilities: - DAG/Step Orchestration: translation → checks → documents → publish, with parallel branches where dependencies allow - Cache/Reuse: Re-run only affected steps when inputs change. Cache key = hash(step_version + input_hashes + ruleset_versions + config) - Pause/Resume: Explicit intervention contracts with validators — workflow pauses with a typed request and resumes only when validated outputs are provided - Strict Provenance: Every step logs tool versions, input artefact hashes, output artefact hashes, and timestamps - Multi-Run Comparison: Diff summaries across revisions showing which findings are new, resolved, or unchanged

Implementation pattern: Start with a simple internal state machine backed by PostgreSQL step/run tables. Evolve to a durable workflow engine (Temporal-like) when run complexity and reliability requirements demand it. Every step emits artefacts and a manifest — never hidden state.

Plane 4 — Tools (Capability Services / Skills)

The tool plane is where extensions live. Each tool is a callable service with strict typed inputs, typed outputs, and versioning. Agents orchestrate tools; tools produce truth artefacts.

Core tool categories:

Tool Description
Translation Service Native CAD → B-Rep + tessellation + PMI + assembly structure (via commercial SDK)
DFM Checks Thin wall, draft angle, undercut, minimum edge distance, deep holes, corner radii, tolerance stack-up
Meshing Mesh quality checks + meshing automation (Gmsh, Netgen, or commercial)
Defeature Feature recognition and suppression for analysis simplification
FEM Setup Boundary conditions, contacts, materials, load cases sanity checks
Solver + Post-Processing Runner integration and result visualisation
CFD Setup + Post Flow domain, boundary conditions, solver configuration (future)
Cost Estimation Parametric costing per manufacturing route
Drafting Drawing generation and review
Sheet Plugin Spreadsheet operations (material databases, tolerance tables, BOM)
PowerPoint Plugin Slide/report pack generation
Change Tracking Diff engine — geometry, solver settings, documents
Doc Factory Templated PDF reports + evidence packs (PDF + JSON manifest + hashes + logs + approvals)
Vision Services Drawing review (GD&T, title block, dimension style); AI visual awareness via screenshots/recordings
Sketch-to-CAD Vision model extracts intent, generates workflow or parametric instructions, validates outcome

Plane 5 — Edge (Connector Agents + Native Tool Control)

The edge plane integrates CATIA, NX, SolidWorks, Creo, HyperMesh, ABAQUS, and other native tools without shipping their binaries. It preserves the continuous loop without bundling proprietary CAD and without forcing PLM check-in for every micro-iteration.

Responsibilities: - "Open in CAD/CAE" one-click launch with correct workspace and context - File and workspace management (local or VDI) - Watch outputs, hash and validate expected deliverables, upload only what's needed - Collect screenshots, recordings, and GUI action logs (for AI visual awareness) - Optional: invoke CAD APIs (NXOpen, SolidWorks API, CATIA VBA) for semi-automation of repetitive edits

Plane 6 — Agent (Dexter + Third-Party Agents)

Dexter is the primary AI assistant persona in the platform. It operates as a meta-agent that can see all artefacts, invoke other agents and tools, summarise results, draft reports, create tasks, and propose fixes — but never silently decides safety-critical outcomes.

Dexter's operating pattern: - A chat participant (the main assistant persona visible in the Studio UI) - Tool access governed by RBAC and workflow policy - Reads all artefacts attached to the current snapshot and runs - Generates workflows, summarises diffs, drafts reports, proposes remediation, creates tasks - Calls heavy compute via backend tool services (MCP-style) - Calls UI actions via local UI tools (open artefact, highlight faces, create issue, attach report)

Plane 7 — Collaboration / Governance

Enterprise-grade collaboration and governance features that are non-negotiable for adoption in manufacturing environments.

  • SSO/OIDC authentication, role-based access control, project and part scoping
  • Approval workflows with sign-offs and release checklists
  • Audit trail export (immutable, complete, reconstructable)
  • Controlled publishing back to PLM (reports, findings, sign-off status, release bundles)
  • Comment anchors that survive revisions via persistent IDs or geometry signatures with remap confidence and "reattach" UX
  • Clear separation: deterministic findings vs human decisions — each tracked independently

Plane 8 — Deployment

Multiple deployment modes to serve different customer segments:

Mode Description
Single-tenant on-prem / private cloud Enterprise customers with data sovereignty (defence, automotive supply chain). Customer runs full stack on their infrastructure.
Hybrid Server-side control plane (artefact graph, orchestration, AI) + desktop edge agents on engineer workstations (native tool launch, local file operations, screenshots/recordings).
Pure desktop (air-gapped) Most restricted environments. Harder for collaboration but possible with local-first architecture and periodic sync.

Critical Product Requirements (All Stack Options)

These requirements apply regardless of UI shell choice:

Native Format Support

  • Commercial translator SDK from day one
  • Treat translation as a governed, versioned compiler step
  • Produce: B-Rep (for deterministic checks) + tessellation (for viewing) + PMI + assembly graph + diagnostics

Human-in-the-Loop

  • Intervention contracts: pause with typed expected outputs + validators; resume on validated delivery
  • Connector Agent: one-click launch + watch + validate + resume
  • PLM-based sync as governed path

PLM Sync

  • Publish to PLM as official record
  • Fast working copy loop for micro-iteration; formal publish when ready

Collaboration Across Revisions

  • Geometry anchors via persistent IDs or geometric signatures with confidence-based remap + reattach UX

AI (Dexter) + Vision

  • Sees all artefacts, run logs, findings, screenshots, GUI action logs
  • Vision reviews drawings; deterministic checks are the truth for release decisions
  • Evidence packs: PDF + JSON manifest (inputs, versions, hashes) + run logs + approvals + digital signatures

Relationship to Other Architecture Documents

This document describes the full Studio architecture. The build path decision (how quickly to get there and in what order) is in: