BeautifulMachines
Tau overview

Tau: infrastructure for engineering RL — whitepaper

A bespoke 2D + 3D CAD/CAE platform with integrated data and verification pipelines, enabling scalable RLVR directly on native CAD assets.

San Francisco, California
01

Background

Our customer engagements and internal benchmarking indicate that frontier models already possess substantial latent knowledge of hardware engineering. Their limitation lies in operationalizing that knowledge reliably inside native CAD environments, where most high-value engineering work is performed.

Addressing this requires training models on real-world, long-horizon engineering workflows. Our in-house work on CAD RL has identified three fundamental bottlenecks in this regime:

  • Data: Native CAD file formats are proprietary binaries, so the best production-grade data (the kind that carries design intent, feature trees, constraints, etc.) is inaccessible for pre- and post-training.
  • Environment: Existing CAD systems are poorly suited for RL. Open-source tools lack the robustness required for complex geometry while closed-source systems have legal constraints and are difficult to operate at scale.
  • Verification: Engineering correctness extends beyond geometric similarity. Useful rewards must also capture properties such as constraint completeness, manufacturability, and functional performance.

To solve this, we are building Tau; a bespoke 2D + 3D CAD platform with integrated data and verification infrastructure, enabling scalable greenfield and brownfield RLVR directly on native CAD assets.

02

The hardware engineering task distribution

Most engineering work in industry is “brownfield”: modifying an existing design rather than creating one from scratch. Engineering change orders, constrained revisions, design-for-manufacturability (DFM) fixes, supplier substitutions, and tolerance adjustments are 75% of the job texture [1].

Yet most MCAD post-training efforts today focus almost exclusively on “greenfield” reconstruction tasks. The reason is structural: production CAD data is stored in encrypted binary formats that are not readily accessible. Greenfield tasks route this issue by using neutral representations. The input specification is supplied independently as an image, drawing, or text prompt. Then, the model constructs geometry in an arbitrary environment and exports it into open formats like STEP, IGES, DXF, PDF, etc.

The upside is that these tasks are usually easy to instantiate and verify deterministically against the oracle geometry. The downside is that engineers perform them rarely, and they omit everything hard about the real workflow, such as navigating feature trees, maintaining design intent across edits, and constraining sketches with proper relations. More fundamentally, geometric equivalence is a poor proxy for engineering correctness: two parts can differ materially in geometry while remaining equivalent in manufacturability, tolerance behavior, constraint completeness, and downstream function.

This creates a categorical mismatch between the training distribution and economically valuable engineering work: the world’s best CAD data remains largely inaccessible to pre-training, while post-training focuses on tasks and reward signals that poorly reflect engineering practice. Closing this gap requires a training stack that can (a) convert native CAD assets into a canonical representation that preserves their design history and (b) execute them in a robust, high-throughput environment with observable state and action histories, turning every new human/agent interaction into usable training data.

03

A survey of the environment landscape

Closed-source environments

Using commercial CAD applications is the obvious starting point. They can load native documents and expose feature-based modeling semantics through their APIs.

However, license agreements for the leading softwares—including SolidWorks, NX, CATIA, Creo, and Fusion 360—typically do not allow AI training or the development of competing technologies. Even if custom licensing is negotiated, operating at reinforcement learning scale remains prohibitive: professional licenses typically cost thousands of dollars per seat per year. And because these applications are fundamentally single-process desktop programs, large-scale rollout parallelization requires provisioning thousands of independent Windows instances, each with its own CAD seat, costing tens of millions in recurring infrastructure. Worse, these costs are platform-specific: supporting the multitude of CAD applications in the oligopoly market (SolidWorks, NX, CATIA, Creo) requires separately licensing and scaling each one.

These environments also suffer from rollout latency. Feature trees are rebuilt sequentially, causing execution time to grow linearly with model complexity. While this overhead is modest for toy examples, enterprise-relevant CAD workloads rarely resemble such cases: individual production parts and assemblies routinely contain hundreds to thousands of features. In an internal test run of 100 API code-to-CAD rollouts across 1,000 SolidWorks models spanning 10–1,000 features, median rebuild time increased from seconds for small models to approximately 10 minutes for large models. And because rollouts may trigger multiple rebuilds per episode, this latency compounds, severely limiting training throughput on practical tasks.

Much of this latency arises from application-layer overhead rather than geometric computation. Commercial CAD APIs are designed for interactive desktop workflows, triggering document updates, feature tree recomputation, GUI refreshes, and other state synchronization after nearly every operation.

Open-source environments

Open-source environments invert the tradeoff. They can be containerized and deployed cheaply at scale, but they cannot faithfully represent or operate on production CAD. Script-based options like CADQuery and build123d do not support feature trees, which largely rules them out. FreeCAD supports persistent feature trees, but it cannot import the parametric content of proprietary formats, so the most useful training signal is lost.

Even when features can be translated via human labor, robustness is a bottleneck. FreeCAD is built on the OpenCascade boundary representation kernel, or OCCT. OCCT’s boolean and fillet/chamfer operations are famously brittle on real-world inputs; there are dozens of public issue threads in which a boolean fuse on two seemingly trivial solids returns invalid topology [2–7]. Other documented cases show nominally valid B-Rep models becoming unusable as accumulated tolerances produce self-intersections [8–12]. These limitations have a history of plaguing commercial product attempts: Shapr3D initially built its application on OCCT but replaced it with Parasolid after geometric robustness became a bottleneck to meeting the quality requirements of a professional CAD system [13].

During the long-horizon modeling tasks we observe in our user data, the aforementioned boolean operations stack and reaching numerically delicate states is routine. The resulting kernel failures cause otherwise semantically valid trajectories to terminate prematurely or receive incorrect rewards, introducing noise that materially degrades policy learning on real-world tasks [14]. FreeCAD also introduces additional failure modes on top of OCCT and incurs startup, recomputation, and model build times that are orders of magnitude longer than those of commercial applications when operating on large feature trees [15, 16]. We have personally spoken with core FreeCAD and OCCT contributors and determined that these limitations stem from foundational architectural choices that are unlikely to be resolved in future versions.

04

A purpose-built environment

The noted shortcomings motivate a purpose-built environment for scaling physical engineering post-training. We propose an architecture with the following properties:

  1. Robust: A proven geometric kernel capable of handling complex assemblies and long modeling sequences reliably.
  2. Scalable: Headless, CLI-first execution with minimal application overhead, enabling high-throughput, containerized rollouts with massive parallelism.
  3. Composable: First-class access to geometry, topology, feature history, and document state enables deterministic, task-specific reward functions over the final artifact and the creation process that produced it.
  4. Interoperable: Data and API adapters ingest native formats into a canonical representation and enable persistent execution against the feature history. Learning transfers to workflows in commercial CAD systems.

For (1) and (2), the environment will be implemented directly in Rust on top of the Parasolid kernel. Parasolid is the default choice for hundreds of live CAD/CAE applications because it is highly stable for complex geometries and natively supports >900 functions for creating, editing, interrogating, and storing solid, surface, sheet, and assembly geometry. Its cross-platform, thread-safe architecture is well suited to a lightweight, headless runtime that avoids the application-layer overhead of a desktop CAD system while supporting highly parallel execution.

Beyond robustness, Parasolid provides significantly better wall-clock times for boolean operations. In one comparative benchmark on a complex ship assembly, the OCCT build required 597.8 seconds, compared with 6.1 seconds for Parasolid—an approximately 100× speedup [17]. Although this result is workload-specific, complementary evidence comes from prior work on a direct Parasolid-based RL environment, which reported a ~40× end-to-end speedup over a Fusion 360-based implementation while also enabling efficient multi-environment sampling and inter-process communication [18].

Above the kernel, we will implement a topological naming system and document model that represent each modeling operation, its parameters, geometric references, and dependencies as a persistent feature graph. The feature tree history and operations will be exposed through a typed action interface with Python, CLI, and RPC bindings, allowing environments to run as isolated containers and scale horizontally across thousands of Linux workers.

This same state exposure enables requirement (3): a broad library of composable verifiers. A sketch can be checked for remaining degrees of freedom; a drawing tolerance stack-up can be evaluated to determine whether an assembly maintains its required clearance; and a CNC part can be checked for unmanufacturable internal sharp corners or undercuts. Assembly-level verifiers can similarly detect interference, insufficient clearances, or violated mating relationships. These checks turn engineering objectives that would otherwise require rubric-based or LLM-as-a-judge evaluation into programmatic tests executable on every rollout.

For (4), we will define a common action interface for modeling primitives shared by commercial CAD systems (like sketches, extrudes, revolves, patterns, fillets, assemblies, and constraints). Policies trained in our environment will therefore generalize to SolidWorks, NX, Onshape, and related platforms, utilizing thin adapters to map actions to each system's native APIs. To support data interoperability, the environment will also import, export, and convert native formats such as .sldprt, .sldasm, .slddrw, and .prt, etc. into the canonicalized representation.

Together, these components provide the data, environment, and verification infrastructure needed to scale reinforcement learning on real-world engineering workflows.

05

References

  1. [1]

    Fastabend, J., Agovic, I., Roth, D., Neumann, R., Hammer, C., & Kreimeyer, M. (2026). How would engineers use LLMs for assembly search if they could? – An empirical study for fostering generative AI-driven design reuse in the future. Proceedings of the Design Society, 6, 2293–2302. https://doi.org/10.1017/pds.2026.10587

  2. [2]

    skelliam. (2026, February 1). Boolean fuse operation fails when rotation is involved (Issue No. 1041) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/1041

  3. [3]

    elias-bananaz. (2025, February 4). Incorrect result when cutting a model with another model (Issue No. 344) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/344

  4. [4]

    pieterhijma. (2026, March 31). Fillet/Chamfer cannot meet opposite edges (Issue No. 1177) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/1177

  5. [5]

    mkcft. (2025, September 23). Fillet operation produces shape with artefact (Issue No. 736) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/736

  6. [6]

    flaviut. (2026, February 22). mkoffsetshape bad geometry (wrench.brep) (Issue No. 1107) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/1107

  7. [7]

    Open CASCADE Technology. (2019). Boolean operations (Version 7.4.0) [Software documentation]. https://dev.opencascade.org/doc/occt-7.4.0/overview/html/occt_user_guides__boolean_operations.html#occt_algorithms_10

  8. [8]

    blwfish. (2025, December 12). Part: Boolean operations fail on compounds with coincident faces (Draft Array) (Issue No. 26119) [GitHub issue]. FreeCAD/FreeCAD. https://github.com/FreeCAD/FreeCAD/issues/26119

  9. [9]

    provos. (2026, July 14). MakeFillet on a closed B-spline rim silently returns a self-intersecting solid (Issue No. 1371) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/1371

  10. [10]

    blwfish. (2026, April 6). ShapeUpgrade_UnifySameDomain introduces self-intersections on fused coplanar wedges (Issue No. 1193) [GitHub issue]. Open-Cascade-SAS/OCCT. https://github.com/Open-Cascade-SAS/OCCT/issues/1193

  11. [11]

    blwfish. (2025, December 20). OCC: Shell.extrude() produces CompSolid with coincident internal faces, causing downstream failures (Issue No. 26327) [GitHub issue]. FreeCAD/FreeCAD. https://github.com/FreeCAD/FreeCAD/issues/26327

  12. [12]

    valpackett. (2025, May 14). [PD] Hole modeled threads create broken faces (“Invalid Tolerance Value”) that results in “Base shape is not valid for boolean operation” (Issue No. 21325) [GitHub issue]. FreeCAD/FreeCAD. https://github.com/FreeCAD/FreeCAD/issues/21325

  13. [13]

    Siemens Digital Industries Software. (n.d.). Shapr3D integrates PLM Components in a leading application for computer-aided design on iPad Pro [Case study]. Siemens. https://resources.sw.siemens.com/en-US/case-study-shapr3d/

  14. [14]

    Giannone, G., Doris, A. C., Nobari, A. H., Xu, K., Srivastava, A., & Ahmed, F. (2026). GIFT: Bootstrapping image-to-CAD program synthesis via geometric feedback [Preprint]. arXiv. https://arxiv.org/abs/2603.27448

  15. [15]

    ActorNightly. (2024, May 21). Ask HN: How does modern FreeCAD compare with SolidWorks? [Online forum post]. Hacker News. https://news.ycombinator.com/item?id=40432337

  16. [16]

    greatflyingsteve. (2026, February 3). Sketcher: In moderately complex sketches, every UI action causes a huge delay (Issue No. 27319) [GitHub issue]. FreeCAD/FreeCAD. https://github.com/FreeCAD/FreeCAD/issues/27319

  17. [17]

    Liang, S., Huang, H., Liang, H., Tang, W., Bao, A., Shen, E., Wang, J., & Yang, Y. (2025). Efficient Boolean operations for B-Rep models [Article in Chinese; extended English abstract]. Journal of Computer-Aided Design & Computer Graphics, 37(11), 1993–2005. https://doi.org/10.3724/SP.J.1089.2024-00367

  18. [18]

    Yin, X., Lu, X., Shen, J., Ni, J., Li, H., Tong, R., Tang, M., & Du, P. (2025). RLCAD: Reinforcement learning training gym for revolution involved CAD command sequence generation [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2503.18549