Skip to content

CAD Drive Collaboration Mode

Last synthesized: 2026-05-15
Operational source: Repo review of the active collaboration/runtime code, CAD Intelligence central plan/tracking, and the CAD format interoperability note.
Purpose: Capture the revised Collaboration mode direction: a Google Drive / Docs-like workspace for CAD models that supports sharing, comments, versions, and documentation before requiring DFM or manufacturing intelligence.

Why This Page Exists

RapidDraft should not force every pilot conversation through manufacturing review, DFM closure, or automated remediation. Those remain important and differentiated capabilities, but they are a heavier first pitch.

The simpler collaboration wedge is:

Upload a CAD model, share a link, let another engineer comment on it, upload a new version, and click through the model history with the comments still attached.

That product should feel like Google Drive / Docs for CAD. Expert mode remains the optional intelligence layer. Collaboration mode must stand on its own for teams that only need human feedback, version history, notes, and lightweight documentation.

Current Implementation Status

As of 2026-04-29, CAD Drive is share-ready for a small trusted-user trial, not yet a broad production collaboration suite.

Working in the active repo:

  • dedicated Collaboration workspace with Drive view and Part view
  • signed-in file tree with owned models and backend support for grant-shared access
  • share links as the visible pilot sharing path; email access grants remain a backend capability but are not the foregrounded pilot UX after the share-modal simplification
  • pinned comments, replies, markdown rendering, initials avatars, and comment deep links
  • model revisions with upload/list/switch behavior and origin-revision comment chips
  • per-file format capability badges and Open-in-Expert handoff
  • short polling for comments and revisions while a part is open
  • product access on app.rapiddraft.ai through Stytch existing-user magic links
  • pilots.rapiddraft.ai as a redirect alias to the app domain

Adjacent hosted runtime status:

  • DraftLint Drawing Analysis is connected from Railway to the IONOS CVAT/Nuclio detector gateway through draftlint-gateway.rapiddraft.ai.
  • Detector IDs 10 through 15 are visible from the live app, with detector 10 as the default.
  • Vision/DraftLint scan limits are active at 20/minute and 100/user/month.
  • A production visibility layer has been pushed to hide pinned standards, Batch Mode, and Design Review from public builds while preserving them locally. This was still queued in Railway at last verification, so it should be treated as pushed and locally validated rather than live.

Still open before broader rollout:

  • durable backend activity stream
  • SSE/WebSocket replacement for short polling
  • carry-forward/re-pin UX across versions
  • side-by-side version compare
  • email notifications or deliberate invite/admin UX reintroduction
  • stronger format-specific import routing, especially for non-STEP and mesh formats

What The Rendering Pipeline Actually Is Today

The current collaboration experience is still a single live 3D viewer, not a true multi-page A4 document surface.

The active runtime shape is:

  1. the backend stores the uploaded source revision
  2. the import path generates a preview.glb for fast browser display
  3. the viewer progressively loads canonical scene data when exact review semantics are available

That means the browser-visible part is already split into two layers:

  • preview GLB for fast rendering
  • canonical scene for exact faces, edges, component identity, and review-grade selection

This is an important boundary. GLB is the fast visual asset, not the full semantic truth. STEP is still the strongest full-capability path because it can support the fast preview, the exact canonical scene, and DFM on the same revision.

The current collaboration comments are already revision-aware, but they are not page-aware. Today the system stores "comment on revision plus 3D anchor plus camera state," not "comment on page 4 of a CAD document." A true document-style review mode would need an extra page or view layer above the current revision and anchor model.

What Gets Expensive

The document side is cheap. A4 layout, notes, comment threads, and page metadata are small compared with geometry work.

The expensive part is keeping many 3D views live at once.

If the current viewer were duplicated naively, each page would add:

  • another WebGL canvas and context
  • another cloned preview scene in memory
  • another canonical-scene polling and fetch loop
  • another GPU draw budget
  • another chance to load heavier canonical detail

For a simple part, that can still feel fine. For large parts or assemblies, ten fully live pages would be the wrong default architecture.

The tracked timing evidence already points in the same direction: the cold cost is dominated by import and first canonical-scene generation, while cached reopen behavior is dramatically cheaper. So the system should prepare geometry once and reuse it many times, not behave as if each page is a brand-new viewer session.

What Would Work For A4-Style Multi-Page Review

The stable design is not "ten independent viewers." It is:

  1. one shared CAD document and revision asset set
  2. page records that store camera, visual mode, markup, and page text
  3. static or snapshot pages by default
  4. one active live 3D page at a time
  5. optional shared-canvas multi-viewport rendering only for a small number of simultaneous live pages

This keeps the document experience cheap while still preserving exact review when the user is actively inspecting geometry.

Page mode Compute cost Best use
Static snapshot page Low Browsing, notes, exports, document composition
One active live 3D page Medium Inspection, re-pin, live commenting, version checks
Many simultaneous live 3D pages High Specialist power mode only; not the safe default for heavy assemblies

For user trust, the product promise should be: "many review pages over one shared model" rather than "ten fully live assembly viewers running independently."

Format Implication For Multi-Page Duplication

The file format matters because not every format carries the same review semantics.

Format family Multi-page review implication
STEP / STP Best current path for shared preview plus exact review plus DFM
IGES / BREP / XBF Good collaboration candidates, but DFM should stay behind an explicit STEP bridge
STL / OBJ / glTF / GLB / VRML Fine for visual pages and mesh-pinned comments, but not topology-stable in the same way

So yes, the same part can appear multiple times in a document-like review. But the stable version should reuse one revision asset set and treat most pages as views over that asset set, not as ten separate heavy geometry runtimes.

  1. Add a page or view_preset object under the CAD document so comments can belong to a page as well as a revision anchor.
  2. Split inactive pages from active 3D pages; render inactive pages from cached snapshots or deterministic generated views.
  3. De-duplicate asset loading and canonical polling across pages so one document does not behave like ten separate viewers.
  4. Add level-of-detail and assembly-budget rules before promising ten-page heavy-assembly reviews.
  5. Keep the UI language honest about anchor confidence for mesh-only formats.

For complicated assemblies, confidence comes from shared assets, caches, snapshots, and explicit runtime budgets. It does not come from brute-force viewer duplication.

Product Boundary

Collaboration mode should use plain workflow language:

  • Files
  • Versions
  • Comments
  • Notes
  • Activity
  • Share

It should avoid making the user think in terms of DFM runs, tickets, manufacturing review, or remediation unless they explicitly open Expert mode. Internally, the backend may still reuse the existing ReviewTicket and review-store contracts, but the product language should be conversational and document-oriented.

Core User Workflow And Architecture

User workflow Architecture behind it Changes needed
User opens Collaboration mode and uploads a non-STEP file Create or reuse a model_document; create a model_revision; store original filename, extension, MIME/type, checksum, detected format, and capability flags Stop forcing every upload into source.step; add format detection and source metadata
Import pipeline prepares the model for viewing Generate a revision-scoped preview artifact; exact CAD where available, mesh/visualization artifact where exact CAD is not available Add a format-aware preview pipeline that can route STEP, IGES, BREP/XBF, STL, OBJ, glTF/GLB, and VRML differently
User sees the model in browser Viewer loads the selected revision artifact and capability flags Support a view/comment-only mode when canonical or DFM artifacts are unavailable
UI shows what the file supports Capability flags drive badges such as "Comments ready", "Mesh comments", "DFM requires conversion", or "DFM unavailable" Add viewer_ready, comment_ready, dfm_ready, conversion_available, and anchor_mode style fields
Owner generates a share link share_links point to the CAD document with a scoped role: view, comment, or edit/upload version Enforce link scope on model, revision, source, artifact, comment, reply, note, and activity endpoints
Reviewer opens the link Backend resolves token, creates or resolves actor identity, and grants scoped document access Add guest identity flow with name/email before commenting; prevent anonymous mutation unless explicitly allowed
Reviewer clicks the model and leaves a pinned comment Store comment thread against document + revision + anchor payload + camera state Extend comments/tickets with model_document_id, model_revision_id, anchor_type, anchor_payload, and anchor_confidence
Comment is on exact CAD geometry Anchor may include body, face, edge, position, normal, and camera state if available Prefer topology/face IDs for STEP, IGES, and BREP/XBF when reliable; keep fallback anchors
Comment is on mesh or visualization geometry Anchor uses mesh hit position, normal, mesh node id if available, and camera state Show that mesh pins may drift if the mesh is regenerated; do not present them as topology-stable
Second user sees the comment Activity/event stream emits comment.created; frontend updates without refresh Add activity_events writes and SSE/WebSocket, or a short polling fallback for internal validation
Owner uploads v2 of the same part Same document, new revision, new source file, new preview artifact, new capability flags Add "Upload new version" flow; fix revision numbering and preserve version history
Users click v1, v2, v3 Revision selector loads selected preview artifact and comment filters Add revision timeline API and UI; support "current version" and "all versions" comment filters
Old comments remain visible on newer versions Comment origin revision is preserved and shown as an origin tag Do not silently hide, drop, or auto-resolve comments when a new version is uploaded
User carries a comment forward Explicit action creates a target revision anchor or marks the thread as needing re-pin Add carry-forward, re-pin, and anchor-confidence states
User resolves a comment Comment status changes with resolver and timestamp Reuse existing resolve model, but make revision context visible
User writes review notes Notes are document-level or revision-linked artifacts Add a simple notes artifact first; defer full collaborative rich-text editing
User requests DFM on IGES or BREP/XBF UI asks whether to convert through a STEP bridge for DFM Add explicit conversion endpoint with provenance and loss tracking; never silently bridge
User requests DFM on mesh-only format UI explains DFM is unavailable for this format Gate Expert/DFM entry points from capability flags

Target Domain Model

The core product object should be a CAD document:

CAD Document
  -> Revisions
    -> Source file
    -> Preview artifact
    -> Capability flags
    -> Comments and anchors
  -> Share links and access grants
  -> Notes
  -> Activity events

The key design rule is to separate view/comment readiness from DFM readiness. Collaboration mode should answer "can the team view and discuss this model?" Expert mode should answer "can RapidDraft reason about or improve this model?"

Format Support Policy

Collaboration should support every runtime-available OCC/FreeCAD-renderable format for comments where the reader succeeds.

Format family Collaboration support Expert / DFM support Notes
STEP / STP Viewer, comments, canonicalization, DFM Full first-class path Still the strongest exact CAD common denominator
IGES Viewer and comments first DFM only after explicit STEP bridge Bridge must record provenance and loss state
BREP / XBF Viewer and comments first DFM only after explicit STEP bridge Useful for exact OCC geometry workflows
STL Viewer and comments only No current exact CAD / DFM path Mesh-hit anchors can drift
OBJ Viewer and comments only No current exact CAD / DFM path Visualization/mesh format
glTF / GLB Viewer and comments only No current exact CAD / DFM path Visualization format; good for lightweight review
VRML Viewer and comments only No current exact CAD / DFM path Visualization format
SAT Not supported in current open stack Not supported Known AutoCAD Standard handoff gap; likely requires HOOPS Exchange or another ACIS-capable commercial translator

Multi-User Sharing Model

A generated link should be only the doorway. Collaboration still needs a server-side document, actor, role, and permission boundary.

Recommended first scopes:

Scope Capability
View Open model, inspect versions, read comments and notes
Comment View plus create comments and replies
Edit / Upload version Comment plus upload a new revision
Owner Manage share links, revoke access, and administer document settings

Before external pilot links are exposed, the backend should prove that model, revision, source, artifact, comment, reply, note, activity, and review endpoints all enforce signed-in, access-grant, or share-token scope.

Version And Comment Behavior

Default behavior should be conservative:

  1. A comment belongs to the revision where it was created.
  2. Newer revisions still show older open comments with an origin revision tag.
  3. The system never silently drops or auto-resolves comments when a newer CAD version is uploaded.
  4. Users explicitly resolve, re-pin, or carry a comment forward to the newer geometry.
  5. Mesh comments should show lower anchor confidence than topology-backed comments.

This makes version history legible and protects user trust. The comment history becomes a durable record of how the part evolved.

Evaluation-Driven Implementation

Collaboration should not be blind-built. Each slice should start with an acceptance checklist and close only after backend and browser workflow feedback pass.

Backend evals should cover:

  • auth and share-link scopes
  • document, revision, comment, reply, note, and activity lifecycle
  • format detection and capability flags
  • version carry-forward and origin-revision behavior
  • event, polling, or SSE delivery
  • non-STEP import paths without source.step assumptions

Browser-use evals should exercise the real workflow:

  1. Upload a supported model.
  2. Generate a share link.
  3. Open the link in a second browser context or tab as a Stytch-allowed user.
  4. Leave a pinned comment.
  5. Observe the comment from the other participant.
  6. Upload a newer version.
  7. Click between versions.
  8. Verify comment origin tags, filters, console health, and screenshots.

Build success alone is not enough.

Next Safe Implementation Slice

The first infrastructure slice has largely landed. The next safe slice should harden the share trial before expanding scope:

  1. Run the deployed two-person validation: sign in, upload/open, share link, comment, reply, upload v2, switch versions, and check console/network health.
  2. Patch only share blockers from that trial.
  3. Add durable backend activity and SSE/WebSocket event delivery.
  4. Add explicit carry-forward/re-pin behavior for comments across versions.
  5. Strengthen format-aware import routing so non-STEP files that are marked comment-capable actually route through the right preview path.
  6. Run browser-use workflow evals before calling the slice complete.

STL/OBJ/glTF/VRML comments can follow once exact CAD collaboration is stable, because mesh anchors introduce drift and UI explanation work.

Open Questions

  • Should link-based commenting require Stytch sign-in for every pilot user, or should a lower-friction guest flow be introduced after the first trusted trial?
  • Should the first shared links allow comment access, or should external links start as view-only until auth enforcement is proven?
  • Which non-STEP format should be the first pilot target after STEP: IGES, BREP/XBF, STL, or OBJ?
  • How should carry-forward be represented in the UI: re-pin action, "still relevant" button, or a dedicated carry-forward queue?
  • When should SAT support move from known gap to active roadmap item?

Sources

  • Operational plan: C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\01_tracks\cad-intelligence\MASTER_PLAN.md
  • Operational tracking: C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\01_tracks\cad-intelligence\TRACKING.md
  • Active repo: D:\02_Code\45_merged_macos_colabui_dfmanim
  • Repo runtime wiring: D:\02_Code\45_merged_macos_colabui_dfmanim\web\src\components\CollaborationWorkspace.tsx
  • Repo viewer runtime: D:\02_Code\45_merged_macos_colabui_dfmanim\web\src\components\ModelViewer.tsx
  • Repo import/runtime services: D:\02_Code\45_merged_macos_colabui_dfmanim\server\main.py
  • Repo import/runtime services: D:\02_Code\45_merged_macos_colabui_dfmanim\server\cad_service.py
  • Repo canonical scene pipeline: D:\02_Code\45_merged_macos_colabui_dfmanim\server\canonical_scene_service.py
  • Repo technical note: D:\02_Code\45_merged_macos_colabui_dfmanim\docs\CAD_Viewer_Architecture_and_Tech_Stack.md
  • Repo technical note: D:\02_Code\45_merged_macos_colabui_dfmanim\docs\contracts\canonical_scene_pipeline.md
  • Format research: CAD Format Interoperability and AICAD
  • Related wiki page: Collaboration Infrastructure
  • Related wiki page: CAD Viewer and Annotation Architecture