RapidCraft — Product Requirements Document¶
Source:
Architechture & Research/RapidDraft Studio/AI Layer/RapidCraft Product Requirements Document.docxStatus: 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¶
- "Get expert feedback on a CAD/drawing change without scheduling hell" — async-first, but supports live
- "Turn review comments into tracked issues with owners, priorities, and closure evidence"
- "Prove what changed between revisions and confirm the change addresses the issue"
- "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¶
- Make the core loop undeniable: Import → Review → Issues → Fix → Diff/Verify → Close → Export evidence
- Solve the "wrong version" failure mode early: "Current / superseded / unknown" banner; "verify revision" link/QR for shop floor/suppliers
- 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
- 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:
- Upload a drawing + (optionally) STEP
- Start a review with a domain checklist
- Reviewer pins 3 issues with severity/owners
- Design owner uploads a revised version
- RapidCraft highlights what changed and links it to each issue
- Reviewer verifies and closes issues
- Export a review report suitable for internal sign-off or supplier communication
Related Documents¶
- Master Vision — RapidDraft Studio big-picture vision
- Tech Stack Options — architecture for the Studio platform
- RapidDraft MVP v0 — the simpler first step (RapidDraft Core review companion)