The Hard Part of CAD Automation Is the Exception Queue

The concrete problem Generating one mechanical drawing is increasingly automatable. Generating hundreds of drawings that an engineer can safely release is a different problem. A batch of machined parts may share the same basic shape, hole pattern, title block, and dimension style. That makes the batch look like an ideal target for automation. But a single extra hole, changed datum face, or unusual section view can turn a time-saving rule into an error repeated across dozens of sheets. The real bottleneck is therefore not placing views. It is deciding which parts can share a rule, showing why they were grouped, and routing exceptions back to a human before the drawings reach purchasing or the shop floor. The current signal On July 30, a developer posted a tool that generates technical drawings from a 3D file path, with controls for layout and featured views. The developer said doing the same work manually for hundreds of models would have taken ages. At RayTally's August 4 observation boundary, the post had accumulated 69 likes, 4 reposts, and 1,851 views since publication. Those numbers are a bounded snapshot, not market validation. They are useful because the demo makes a familiar batch-workflow problem concrete. The surrounding tooling also shows how much of the lower layer already exists. Autodesk's Inventor API exposes operations for base, projected, and section views. DraftAid says it can learn company drawing standards from existing models and drawings, apply uploaded templates, and support several machined and sheet-metal part types. A new product cannot win merely by saying it turns 3D into 2D. Product direction The more interesting product is a review system built around part families and exceptions. An engineer imports a batch, and the system groups parts using explainable geometric features: bounding-box ratios, major planes, hole patterns, wall thickness, and assembly faces. It generates one representative drawing per family. The engineer approves the primary orientation, section locations, dimension references, and notation on that representative. Only then are the rules propagated to siblings. Every propagated result should retain a traceable link from annotation to model feature. If one part contains an unmatched hole or cannot use the approved section, it leaves the happy path. The interface should say exactly how it differs from the representative part and place it in an exception queue. It should never invent a tolerance to make the sheet look complete. That changes the value proposition from "AI makes drawings" to "engineers review fewer drawings without losing control of the risky ones." The measurable workflow outcome is not sheets generated per minute. It is how many sheets require full review, how many exceptions are caught before release, and whether a reviewer can reproduce why each rule was applied. The full product brief and source evidence on RayTally goes deeper into the target user, competitors, and evidence boundaries. Minimal entry point Start narrower than a general CAD copilot: Build an Inventor plug-in for prismatic machined parts. Accept editable IDW or DWG files as templates, not arbitrary PDFs. Extract a small, inspectable feature vector for each part and cluster by explicit distance rules. Generate base, projected, and section views through the existing drawing API. Let the reviewer approve one representative part, then propagate only view, section, and dimension-reference rules. Send unmatched geometry and missing tolerances to a visible exception queue. Assembly drawings, freeform surfaces, automatic tolerance generation, and cross-CAD support should stay out of the first release. A public STEP set with deliberately modified holes and faces would make a better early test than a polished demo on perfectly uniform parts. The strongest case against The uncomfortable possibility is that the exception system does not reduce review work at all. STL-like geometric similarity is not design intent. Legacy drawings contain conventions that layout analysis cannot recover, and tolerances, datums, and surface finishes often depend on assembly relationships outside the part file. False grouping can propagate a serious mistake; conservative grouping can leave engineers reviewing every sheet anyway. There is also a credible build-versus-buy objection. Existing CAD APIs and internal scripts already work well for companies with stable part rules, while commercial drawing automation is moving toward template adaptation. A new layer must prove that maintaining its grouping logic costs less than extending those scripts. One bad release can erase more trust than a month of successful drafts creates. Question for readers If you automate CAD or manufacturing documentation today, where does human review actually concentrate: view placement, dimension references, tolerance decisions, or detecting the one part that should not have inherited the batch rule?