Skip to content

RapidCraft — Product Requirements Document

Source: Architechture & Research/RapidDraft Studio/AI Layer/RapidCraft Product Requirements Document.docx Status: Reference — product requirements for the RapidCraft review + workflow cockpit Note: RapidCraft is a specific product concept within the RapidDraft Studio vision — focused on engineering design review, issue closure, and correctness checks across revisions.


Product Vision

RapidCraft's core purpose: Make engineering design decisions faster, more correct, and more traceable by turning "CAD + drawings + reviews + action items" into a single, version-aware workflow that engineers can trust under real production pressure.

This is not a "commenting layer" or a generic collaboration app. It is an engineering decision system.

Market gap: The defensible wedge is:

"Engineering-grade review + issue closure + correctness checks across revisions — without requiring everyone to be CAD/PLM experts."


The Cost of the Problem

  • NIST estimates $8.4B spent on engineers answering questions and creating additional drawing documentation; plus $3.8B for machinists doing the same
  • Interoperability costs estimated at $20.9B–$42.9B
  • Root cause: people cannot reliably access the right context (latest version, intent, decisions, constraints) at the moment they must act

Three Non-Negotiable Properties

Property What it means
Context fidelity Feedback must be tied to geometry/view state/drawing region AND to a specific version (and ideally a change-set)
Closed-loop workflow Issues must transition from discovery → assignment → fix → verification → closure with auditable evidence across versions
Engineering correctness The platform must proactively reduce technical mistakes (drawing standards, tolerancing, manufacturability, "wrong version in production") — not just host discussions

Users and Jobs-to-Be-Done

Primary User Groups

Design Owner (Mechanical Design Engineer / CAD owner) - Owns model and drawings, initiates reviews, routes decisions, executes changes, demonstrates traceability

Reviewers (Manufacturing, Quality, Sourcing, Test, Simulation/Stress, Field/Service) - Have domain expertise but may lack CAD licences, time to attend meetings, or familiarity with PDM - Browser access is a key unlock — many reviewers miss reviews because they can't attend or don't have CAD access

Engineering Manager / Project Lead - Needs visibility into risk, open issues, review readiness, and closure pace - Cares about cycle time and escape defects

External Partners (suppliers, contractors, customers under NDA) - Need limited access to view, comment, and close actions without exposure to internal Vault/PLM complexity

Engineer-Grade Jobs-to-Be-Done

  1. "Get expert feedback on a CAD/drawing change without scheduling hell" — async-first, but supports live
  2. "Turn review comments into tracked issues with owners, priorities, and closure evidence"
  3. "Prove what changed between revisions and confirm the change addresses the issue"
  4. "Prevent classic technical failures — wrong revision used, unclear tolerances, ambiguous notes, missing standards compliance"

Value Proposition

RapidCraft delivers value when it can credibly claim: "We reduce rework and late-stage surprises by making design reviews faster and more complete — then we close issues across revisions with traceable evidence and built-in engineering checks."


Domain Objects

Object Definition
Project/Programme Top-level container (permissions, retention, integrations)
Artefact A CAD model, assembly, drawing, PDF package, or review bundle
Version Immutable snapshot of an artefact (who, when, source, hash)
Review A time-bounded or state-bounded evaluation of a version (async or live)
Comment/Markup User input anchored to a specific view/geometry region
Issue Tracked work item derived from one or more comments/markups
Decision Recorded resolution with rationale ("accept risk," "change required," "defer") tied to version and approver
Checklist/Rule set Engineering standards and organisation-specific review gates

Core Functional Requirements

Ingestion and Version Control

SHALL: - Support importing: PDF and DXF drawings (DWG via conversion); STEP for 3D neutral exchange - Treat every imported artefact as an immutable version with a stable identifier - Capture at ingest: source system, author, timestamp, checksum; for drawings: sheet count, title block extraction (where possible), revision label, units; for 3D: assembly structure, part count, bounding box, mass properties

SHOULD: - Support branching-like workflows at the review layer (even if CAD remains external)

Viewing, Measurement, and Markup

For 2D drawings (SHALL): - Pan/zoom, sheet navigation - Dimension-aware measurement when scale is known - Redlines/markups: shapes, callouts, text, stamps - Pinning comments to a region (anchor) - Exportable review package (PDF with markups + issue list)

For 3D models (SHOULD): - Model navigation, section planes, explode/isolate, hide/show - Measurement tools (distance, angle) - Comment pinning to geometry with saved camera/view state

Review Modes

Asynchronous review (SHALL): - Scope: artefact version(s) - Reviewers and roles - Checklist template (e.g., "Sheet metal DFM," "Battery enclosure structural readiness," "Supplier drawing approval") - Due date / SLA

Live review (SHOULD): - Participants see each other's comments/markups in real time

Issue Tracking and Closure

Issue fields (SHALL): - Title, description - Owner/assignee - Severity (blocker/major/minor), priority - Status state machine: Open → In progress → In review → Closed (configurable) - Linked artefact version + anchor location + evidence snapshots

Issue closure requires (SHALL): - "Fix version" link (the version where the issue is resolved) - "Verification" step (reviewer sign-off or checklist pass) - Changelog note or diff snippet

Integrations (SHOULD): - Bi-directional syncing of issues to Jira for project-level visibility

Built-In Engineering Analysis

Analysis must be implemented in layers — trust is earned incrementally.

Drawing and documentation correctness (SHOULD): - Outdated drawing risk: surface "current / superseded / unknown" status on every exported/printed drawing package - Ambiguity hotspots: missing tolerances, unclear datum strategy, conflicting notes - Team rule encoding: teams can encode drafting rules and review gates into checklists

Standards alignment layer: The analysis rules should explicitly align with: - ASME Y14.5 — GD&T language and interpretation - ASME Y14.100 — Engineering drawing preparation and revision - ASME Y14.41 — Digital product definition data sets - ISO 16792:2021 — Digital product definition data practices - ISO 10303 (STEP) — Product data representation and exchange

Manufacturability layer (SHOULD): - Surface manufacturability problems before review (rule-based checks + checklist templates) - Add "AI assist" only where results are inspectable and tied to evidence - Never allow AI suggestions to auto-close issues; closure must remain a human accountability event


Reporting and Traceability

SHALL generate: - Review report (PDF + issue list + closure summary) - Audit trail (who said what, when, tied to versions) - Exportable issue log for compliance / customer deliverables


Integrations

Integration Priority
Cloud drives / file stores (import/sync) SHALL
Jira (bi-directional issue sync) SHOULD
PLM export / PLM-aware outputs SHOULD
Engineering Change Request / ECO mapping Later

Security and Enterprise Readiness

Shall plan for: - Encryption in transit and at rest - Tenant isolation (multi-tenant SaaS) - Role-based access control (internal vs supplier vs customer) - Audit logs for access + actions (who viewed/downloaded/exported) - Data retention and deletion policy controls per customer

External collaboration safety model (SHOULD): - Expiring links - Watermarking and download restrictions (configurable) - Supplier-only views (no repository browsing) - Per-issue visibility controls for mixed-sensitivity designs

Compliance targets: SOC 2 Type II, ISO/IEC 27001


Success Metrics

Metric Description
Review cycle time Time from "review launched" → "all critical issues closed"
Issue closure integrity % issues closed with linked fix-version + verification evidence
Rework reduction # review iterations before release; # late ECOs triggered by preventable issues
Participation lift # cross-functional reviewers providing input per review (especially non-CAD users)
Wrong-version prevention # times system blocked/flagged outdated drawing usage

Positioning Against Alternatives

Alternative What they do well RapidCraft's edge
Cloud-native CAD (Onshape) Real-time editing + version control Not competing on CAD authoring; winning on review + issue closure
Review specialists (CoLab) Browser review + pinned comments + Jira sync Engineering correctness checks; NX/Teamcenter-native signals
PDF markup tools (Bluebeam) Realtime markup sessions + tracked activity Structured issue workflow + version closure evidence
PDM-lite (GrabCAD Workbench — now shut down) Simple version/share/markup Engineered replacement with stronger correctness and traceability

RapidCraft's strategy must be: "We are the fastest path to reliable issue closure and engineering correctness across revisions." — Not "we do all of the above."


Priority Investment Order

  1. Make the core loop undeniable: Import → Review → Issues → Fix → Diff/Verify → Close → Export evidence
  2. Solve the "wrong version" failure mode early: "Current / superseded / unknown" banner; "verify revision" link/QR for shop floor/suppliers
  3. Build analysis as rule-based checks first, not AI magic: Checklist templates + rule-based drawing checks aligned with standards language; add assistive AI only once trust and labelled data exist
  4. Integrate with systems engineers already live in: Jira sync as minimum; PLM-aware outputs for change management

What to Avoid

  • Building a full CAD authoring tool — viewer + markup + issue closure is already a large, valuable scope
  • Big AI bets before high-quality closure loops and real labelled failure cases exist
  • Over-indexing on "collaboration" as the headline — collaboration is table stakes; closure and correctness get budgets

"Five-Minute Demo" Target

Within the next iteration, demonstrate on a customer's own file:

  1. Upload a drawing + (optionally) STEP
  2. Start a review with a domain checklist
  3. Reviewer pins 3 issues with severity/owners
  4. Design owner uploads a revised version
  5. RapidCraft highlights what changed and links it to each issue
  6. Reviewer verifies and closes issues
  7. Export a review report suitable for internal sign-off or supplier communication