Volocopter Use Cases¶

Status: Customer evidence Validation status: Volocopter-specific pains are customer-described; no artifact, standard matrix, or paid pilot has been seen yet.

This page turns the Volocopter signals from Vinicius and Aaron into concrete use cases. The high-level direction is already clear: drawing standards and engineering search. The useful next step is to make each workflow specific enough that a demo can be built, falsified, or cut.

Evidence Boundary¶

Evidence	Source	How to treat it
NX drawing setup varies by engineer across layers, dimensions, reference sets, and validation targets such as Volohammer / Check-Mate	Volocopter / Vinicius	direct Volocopter evidence
Engineers need to search bolts or screws by real dimensions and geometry, not only text metadata	Volocopter / Vinicius + Aaron	direct Volocopter evidence
Search should span NX, PLM, and ERP; Aaron specifically asked for agentic ERP search	Volocopter / Vinicius + Aaron	direct Volocopter evidence
Former Volocopter context: informal review, weak enforcement of design guidelines, drawings first seen late, incomplete dimensioning, GD&T and Checkmate context	Julio meeting notes	supporting Volocopter context, not Aaron/Vinicius-specific
General June-July notes: drawings checked against company standard; missing dimensions, missing surfaces, missing material, bending parameters	June-July meeting notes	supporting drawing-release context, not Volocopter-specific

Priority Backlog¶

Priority	Use case	Owner signal	Why first
P0	V-01 NX Drawing Setup Matrix Checker	Vinicius	most specific, rule-based, and closest to a safe first demo
P0	V-03 Fastener Dimension Search	Vinicius + Aaron	clear daily workflow: find an existing screw/bolt by dimensions
P1	V-02 Volohammer / Check-Mate Companion	Vinicius	likely easier if validation output already exists
P1	V-04 NX + PLM + ERP Federated Search	Aaron	valuable, but integration scope can grow quickly
P1	V-05 New Part Duplicate / Variant Gate	Vinicius + Aaron	monetizable if duplicate part creation is painful
P2	V-06 Standards Drift And Onboarding Dashboard	Julio context + Vinicius	useful after checks run repeatedly
P2	V-07 Drawing Release Completeness Preflight	supporting notes	adjacent, but should not be attributed to Aaron/Vinicius without confirmation

V-01 NX Drawing Setup Matrix Checker¶

Persona: CAD standards owner, drawing owner, or design lead reviewing an NX drawing before release.

Trigger: An engineer creates or updates an NX drawing and wants to know whether the setup follows the company matrix before the drawing reaches release review.

Current failure mode: Drawing setup is person-dependent. Layers, dimensions, reference sets, and validation targets are not applied consistently, so the release reviewer finds issues that should have been caught earlier.

Required inputs to request from Volocopter:

one anonymized NX drawing or exported drawing metadata
the company layer/setup matrix
one known failing example and the expected finding list
allowed object types per layer, such as model curves, centerlines, construction geometry, dimensions, notes, title-block objects, and view-dependent geometry
required drawing-view reference sets
dimension style and association rules
required Volohammer / Check-Mate validation targets and sample report output

RapidDraft behavior:

Check	Concrete behavior	Example finding
Layer assignment	Compare each drawing object against the allowed layer matrix	"Dimension object is on a geometry layer, expected dimension/annotation layer."
Object-type split	Detect geometry, construction lines, notes, dimensions, and view objects living in mixed or prohibited layers	"Construction geometry is visible in the release drawing view."
Reference set usage	Verify each drawing view references the approved model/reference set, not a temporary or work reference set	"Main view uses working reference set instead of release reference set."
Dimension association	Flag dimensions that are dangling, suppressed, not associated to model geometry, or using the wrong style	"Diameter dimension is not associated with a model edge."
Validation target	Check that the required Check-Mate / Volohammer target exists and passed	"Required release-validation target missing or not run."

Output: A pass/fail setup matrix, issue cards with evidence, affected NX object IDs where available, layer/reference-set/dimension details, and a reviewer-ready PDF/CSV report.

MVP slice: Read-only upload of exported NX metadata plus a setup matrix. No NX plugin, no writeback, and no autonomous approval. The demo succeeds if it catches three deliberate setup deviations and explains them in terms the CAD standards owner already uses.

Validation questions:

What exact file/report can be exported from NX, Volohammer, or Check-Mate today?
Who owns the setup matrix: CAD admin, methods, quality, or design engineering?
Which setup errors actually block release versus only annoy reviewers?
Is the pain per drawing, per release package, or per engineer onboarding cycle?

V-02 Volohammer / Check-Mate Companion¶

Persona: CAD admin, standards owner, or drawing reviewer who already receives validator output but still has to interpret and triage it.

Trigger: Volohammer or Check-Mate has been run, but the output is too raw, scattered, or detached from the release-risk story.

Current failure mode: Native validators can catch formal issues, but they do not necessarily explain which findings matter, how to fix them, or whether the same mistake keeps recurring across engineers and product teams.

Required inputs:

sample Volohammer / Check-Mate HTML, XML, CSV, PDF, or screenshot output
mapping from validation IDs to the company setup standard
sample NX drawing metadata, ideally with object IDs or names
severity mapping: release blocker, warning, informational

RapidDraft behavior:

parse validator results into normalized issue records
group findings by release risk, owner, object type, and drawing sheet
explain each finding in plain release-review language
link each issue back to the violated company rule
produce a short "what to fix first" list
track repeated setup deviations across drawings once multiple reports exist

Output: A clean release-readiness report: blocker count, warning count, affected sheets, likely fix owner, and evidence for each finding.

MVP slice: Parse one exported validator report and manually mapped rule table. Do not try to replace Volohammer or Check-Mate; complement them by making the results useful for review and learning.

V-03 Fastener Dimension Search¶

Persona: Design engineer selecting a screw, bolt, washer, or standard part for an assembly.

Trigger: The engineer knows the required physical constraints but cannot find the existing part through text search.

Current failure mode: NX/PLM search depends on part names and metadata. If the engineer searches by geometry or dimensions, such as length, thread, diameter, or head style, the system does not return reliable existing candidates.

Example queries to test:

"Find M6 screws around 20 mm long with released status."
"Show socket-head cap screws with thread M5 and usable length between 16 and 25 mm."
"Find the same bolt but 5 mm longer."
"Show fasteners with this head diameter and shaft length used in similar assemblies."

Required inputs:

a sample fastener library from CAD/PLM
part number, description, lifecycle/release status, revision, and where-used data
available dimensions: nominal diameter, thread, pitch, length, head type, head diameter, material, coating, and standard
CAD geometry or exported geometric features if metadata is incomplete
expected hits for two or three real engineer queries

RapidDraft behavior:

Parse the natural-language query into normalized constraints.
Search exact structured fields first: thread, length, standard, material, status.
Fall back to geometry-derived dimensions or inferred attributes only when metadata is incomplete.
Rank candidates by exact fit, acceptable tolerance band, release status, and previous use.
Show why each candidate matched and how it differs from the requested part.

Output: Ranked part cards with CAD preview if available, matched dimensions, PLM status, ERP stock/procurement summary, where-used examples, and a "why not" explanation for close misses.

MVP slice: Fasteners only. Read from CSV/Excel exports or a static PLM snapshot. Use CAD geometry extraction later only where metadata is missing or unreliable.

Success metric: Reduce time to find an existing fastener and prevent creation of a duplicate part number.

V-04 NX + PLM + ERP Federated Search¶

Persona: Engineer or PLM/ERP-aware design lead who needs to know not only whether a part exists, but whether it is released, available, stocked, purchasable, and already used.

Trigger: A candidate part has been found in NX or PLM, but the engineer still needs ERP context before reusing it.

Current failure mode: CAD knows geometry, PLM knows revision and lifecycle, and ERP knows material master, supplier, stock, lead time, and cost. The engineer has to jump systems or ask someone else.

Example queries to test with Aaron:

"Find released M5 or M6 fasteners with stock in ERP and approved supplier status."
"Show existing brackets with similar hole spacing and active PLM revision."
"Which existing part has this geometry, and is it already purchasable in ERP?"
"For this PLM part, show ERP material number, stock, supplier, and last purchase status."

Required inputs:

NX or CAD identifier
PLM part number, revision, release status, owner, and where-used data
ERP material number, stock, supplier, cost, lead time, and procurement status
a join key between CAD/PLM and ERP, even if it is imperfect
permission boundary: read-only search versus any writeback

RapidDraft behavior:

resolve the same part across CAD, PLM, and ERP
show source badges so users know where each field came from
distinguish "geometrically suitable" from "released and procurable"
expose missing links, such as a PLM part with no ERP material number
keep the human in the loop for reuse, new-part creation, or supplier decisions

Output: One result card per candidate: geometry preview, PLM lifecycle, ERP stock/procurement, supplier, where-used, and missing-data warnings.

MVP slice: Read-only federated search over exported snapshots. Do not start with live ERP writeback or broad agentic action. The first demo should answer one real query with expected hits.

V-05 New Part Duplicate / Variant Gate¶

Persona: Engineer or PLM creator about to request a new part number.

Trigger: Before a new fastener or standard component is created, the engineer enters the intended dimensions and functional constraints.

Current failure mode: Existing similar parts are hard to find, so teams create variants that differ only slightly from existing released parts. This increases master-data cleanup, inventory complexity, and purchasing load.

Required inputs:

proposed new part description and dimensions
standard part library and current PLM part list
ERP stock/procurement fields
where-used data for close alternatives
company tolerance for "close enough" reuse versus new part creation

RapidDraft behavior:

compare the proposed part against existing released and stocked alternatives
classify matches as exact, equivalent, close variant, or unsuitable
show dimensional deltas in engineering terms
warn when an existing part is reusable but hidden by bad naming or metadata
create a reviewer summary for approving or rejecting the new part request

Output: "Possible existing alternatives" table with exact differences, lifecycle status, stock status, and reuse recommendation.

MVP slice: Start with bolts/screws only. If the part family is narrow, the search can be credible before general geometry search is solved.

V-06 Standards Drift And Onboarding Dashboard¶

Persona: CAD standards owner, team lead, or onboarding owner.

Trigger: After V-01 has run on multiple drawings, the team wants to understand repeated standards drift rather than only single-drawing defects.

Current failure mode: New engineers learn rules informally, and recurring setup mistakes are fixed one drawing at a time. The organization does not get a clear picture of which rules are confusing or which setup mistakes repeat.

Required inputs:

repeated V-01 or V-02 results across drawings
rule IDs and severity mapping
team, project, or product-family metadata if allowed
onboarding checklist or training material, if it exists

RapidDraft behavior:

aggregate recurring failures by rule and drawing type
identify rules that are frequently misunderstood
generate onboarding checklists from the actual failure history
separate "individual mistake" from "ambiguous standard"

Output: Standards drift dashboard and a short onboarding checklist based on observed mistakes.

MVP slice: Only after at least 10-20 drawing checks exist. This is not the first demo.

V-07 Drawing Release Completeness Preflight¶

Evidence note: This is supporting Volocopter/drawing context, not a direct Aaron/Vinicius claim yet.

Persona: Drawing reviewer or release owner.

Trigger: A drawing is about to move to release, manufacturing, supplier handoff, or PLM/ERP package creation.

Current failure mode: Drawings can miss simple but release-critical information: dimensions, surfaces, material, bending parameters, or standard notes. Former Volocopter context also points to drawings being seen late and design guidelines not being enforced early enough.

Required inputs:

drawing PDF or NX export
release checklist
mandatory title-block fields
material and surface-treatment rules
manufacturing-process-specific table requirements, such as bending parameters for sheet metal

RapidDraft behavior:

verify mandatory fields are populated
flag missing material/surface information
detect obvious missing dimensions or dangling dimensions where extraction is reliable
compare process-specific requirements against the drawing package
present findings as reviewer support, not autonomous release approval

MVP slice: Treat this as an adjacent demo only if Volocopter confirms it is their pain too. Otherwise keep it in the broader release-readiness backlog.

Recommended Demo Sequence¶

Start with V-01 NX Drawing Setup Matrix Checker because it is specific, rule-based, and directly tied to Vinicius's feedback.
Add V-02 Volohammer / Check-Mate Companion if Volocopter can provide validator output quickly.
Build a narrow V-03 Fastener Dimension Search proof with 20-100 standard parts and two real expected queries.
Expand to V-04 NX + PLM + ERP Federated Search only after the join keys and ERP read boundary are known.

Do not start with a broad "agentic ERP" product. Aaron's request is important, but the first proof should be one bounded read-only search where the expected answer is known.

Validation Assets To Ask For¶

one anonymized NX drawing setup matrix
one anonymized NX drawing or export with known setup deviations
one Volohammer / Check-Mate result file
one list of drawing setup rules with severity
20-100 fastener or standard-part records with dimensions
two real bolt/screw search queries and the expected correct hits
a sample PLM export with lifecycle/revision/status
a sample ERP export with material number, stock, supplier, and procurement status
the join key currently used between PLM and ERP

Open Questions¶

Is Volohammer / Check-Mate currently mandatory, optional, or inconsistently run?
Does Volocopter have a formal layer/setup matrix that can be shared, or is the standard partly tribal?
Which PLM system is in use, and how reliably does it connect to ERP material numbers?
Which part family should anchor the first search demo: screws/bolts, washers, brackets, or another recurring component?
Is the budget owner closer to CAD standards, design engineering, PLM, ERP/master data, or manufacturing engineering?
What is the cost of a failed drawing setup: reviewer time, release delay, manufacturing mistake, supplier clarification, or audit risk?

Sources¶

docs_pivot/_sources/usecases-erpdrawing/rapiddraft-usecases-scenarios.md
docs_pivot/_sources/usecases-erpdrawing/meeting minutes June-July.rtf
docs_network/04_Meetings/survey_and_research_julio.md
docs_network/04_Meetings/2026/Meeting_with_Julio.md