Decision Log¶
Purpose: Record of key strategic and product decisions made during TextCAD's development. Captures what was decided, why, and what alternatives were considered. Last updated: March 2026
Operational note: Live project-management decisions and operating-structure decisions are also tracked in 07_Project_Management > Decision Log.
When a decision changes, update the entry rather than deleting it - add a "Revised:" note.
Product Strategy Decisions¶
DS-001 — Focus on NX + Teamcenter exclusively for v0¶
Status: ✅ Decided (November 2025) Decision: Build RapidDraft v0 for NX + Teamcenter only. Do not attempt multi-CAD support at this stage. Rationale: NX + Teamcenter is one integrated ecosystem. Mastering the NXOpen API and Teamcenter's data model is a significant technical investment. Splitting attention across CAD systems in v0 risks building nothing well. Target customers (Mittelstand, industrial machinery) are heavily NX+TC. Alternatives considered: Multi-CAD from day one (STEP-based approach); SolidWorks + PDM first (larger user base but different buyer profile). Next review: When v0 has 3+ pilots — reassess whether STEP-based multi-CAD broadens addressable market meaningfully.
DS-002 — Deterministic checks are the source of truth (not AI)¶
Status: ✅ Decided (November 2025) Decision: All checks that can be deterministic must be deterministic. AI is advisory only for engineering-critical outputs. Rationale: Engineers working in safety-relevant manufacturing contexts cannot trust outputs they cannot explain. A deterministic check (rule + measured value + threshold) is reproducible, auditable, and defensible. An AI-generated finding that says "this looks risky" without a traceable rule is not adopted. Trust is the core adoption risk. Alternatives considered: AI-first with LLM-driven checks (too opaque, no auditability); hybrid from the start (too complex for v0). Applied to: Every rule check in the DFM module and drawing check module. Vision-based checks are labelled "DFM Assistant Notes" and require manual confirmation.
DS-003 — Human-in-the-loop is non-negotiable¶
Status: ✅ Decided (November 2025) Decision: Engineers remain the decision authority in all critical engineering outcomes. RapidDraft never auto-approves, auto-closes, or auto-modifies without explicit human action. Rationale: Liability, trust, and adoption. Engineers who feel a tool is "doing things for them" without their oversight will distrust and abandon it. The product goal is to make the human's job faster and more traceable — not to replace human judgement. Applies to: Issue closure (always requires human disposition), drawing generation (always requires post-generation checklist + sign-off), DFM findings (always requires human confirmation before "resolved"), carry-forward issues (manual rebind required for unresolved items).
DS-004 — Collaboration-first positioning, not automation-first¶
Status: ✅ Decided (February 2026) Decision: Lead RapidDraft's narrative with "AI collaboration platform for engineers" rather than "automated drawing generation tool." Rationale: The automation-first framing limits the perceived value (feels like a plugin, not a platform). Collaboration-first framing captures the real coordination pain in engineering teams — fragmented feedback, lost decisions, repeated review loops — and positions RapidDraft as a systemic solution. See Master Narrative for the canonical language. Alternatives considered: "Automated drawings" headline (more concrete but too narrow and sounds commodity); "AI for manufacturing" (too vague). Usage: All pitch materials, applications, investor conversations use the collaboration framing as the headline, with automation as proof points.
DS-005 — RapidDraft Core before Studio¶
Status: ✅ Decided (March 2026) Decision: Build RapidDraft Core (focused MVP) to market before developing RapidDraft Studio (the IDE vision). Rationale: Studio is the compelling long-term vision but requires significant technical investment (PLM integration, workflow engine, IDE shell, multi-tool orchestration). Core generates revenue, builds customer trust, and validates the underlying value proposition with real workflows. Studio is the evolution path, not the starting point. Alternatives considered: Studio-first (high risk, too many unknowns, long time-to-market); parallel development (dilutes focus, under-resources both). Review condition: When Core has 5+ paid pilots and clear adoption patterns, begin Studio architecture investment.
Architecture Decisions¶
AD-001 — NXOpen for snapshot extraction¶
Status: ✅ Decided (November 2025) Decision: Use NXOpen (Siemens' official NX API) to extract drawing and model snapshots into schema-versioned JSON. Not STEP conversion, not screenshot OCR. Rationale: NXOpen gives direct, structured access to NX's internal data model — dimension objects, notes, title block attributes, view properties, feature parameters. STEP conversion loses semantic information. OCR on screenshots is unreliable for structured data extraction. NXOpen is the only reliable path to "what is the exact value of this dimension in this drawing." Risk: NXOpen requires an NX licence on the extraction machine. Mitigated by: customers already have NX licences; the extractor runs as a plugin inside the customer's NX environment.
AD-002 — Local-first backend for v0¶
Status: ✅ Decided (December 2025) Decision: RapidDraft v0 runs as a local backend (FastAPI + SQLite), not cloud-first. Rationale: IP sensitivity is a core buyer concern in industrial manufacturing. Customers will not send their CAD data to an external cloud service in v0. Local-first removes this objection. SQLite is sufficient for single-user pilot. Cloud migration path is clear when multi-user/enterprise scale is needed. Revised: When multi-user pilots begin, migrate to Postgres + evaluate on-premises deployment vs. private cloud options.
AD-003 — Hybrid architecture for RapidDraft Studio¶
Status: ✅ Decided (March 2026) Decision: Studio uses a hybrid architecture: shared backend + desktop/agent bridge + web control plane. Not pure desktop (Electron) and not pure web. Rationale: Pure Electron is too heavy and limits cloud capabilities. Pure web struggles with native tool integration and local file access. Hybrid gets the best of both: desktop agent handles local file access and NX/CATIA handoffs; web control plane handles collaboration, reports, and PLM connectivity. See: Tech Stack Options
AD-004 — Rules-based + vision DFM are complementary¶
Status: ✅ Decided (January 2026) Decision: Run both rules-based geometry analysis and vision-based DFM simultaneously, not as alternatives. Rationale: Rules-based checks are precise and deterministic but cannot read drawing annotations or interpret manufacturing notes. Vision-based checks can read drawings like a human but miss precise geometric measurements. Together they cover the full surface. Rules generate "hard findings"; vision generates "DFM assistant notes" labelled with uncertainty. Applied in: DFM module v0, DFM benchmarking codebase.
Go-to-Market Decisions¶
GTM-001 — Germany / Central Europe first¶
Status: ✅ Decided (November 2025) Decision: Target initial pilots within 150 km of Munich. Germany/Central Europe is the first market. Rationale: Founder's network and domain knowledge. Dense concentration of Mittelstand industrial machinery and heavy equipment companies. NX+Teamcenter penetration is high. Pragmatic buyers with manageable decision cycles. Physical proximity enables in-person pilot support.
GTM-002 — Industrial machinery and heavy equipment as primary vertical¶
Status: ✅ Decided (December 2025) Decision: Lead with industrial machinery and heavy equipment as the pilot vertical. Not aerospace, not automotive OEMs. Rationale: Industrial machinery: high volume of machined/sheet metal/welded parts, drawings still drive manufacturing, frequent change orders (perfect for "what changed"), teams are pragmatic and less bureaucratic than aerospace. Aerospace OEMs: too regulated, too slow, too customised. Automotive OEMs: long sales cycles, strong incumbent tools. See: Ideal Customer Profile
GTM-003 — Fatigue Agent as a parallel product (not bundled with RapidDraft)¶
Status: 🟡 Open — not fully decided Current thinking: Develop Fatigue Agent as a separate product targeting the same buyer profile (Mittelstand engineering teams) but different buyers within the company (stress analysts vs. design engineers). Same go-to-market motion but distinct product and pricing. Alternative: Bundle as a RapidDraft module. Deferred until RapidDraft Core has traction.