FllumaOne-100K: Code-Native CAD Dataset

• FllumaOne-100K is a code-native multimodal CAD dataset that represents editable CAD models via executable Python programs and structured construction histories.
• It employs a rigorous generation pipeline with template-driven program synthesis, kernel validation, and cross-modal alignment across geometry, text, and metadata.
• The dataset enables benchmark tasks in text-to-program synthesis, classification, and reverse engineering with 100K samples spanning diverse complexity regimes.

Searching arXiv for the specified paper and topic to ground the article in the current record. FllumaOne-100K is the primary release of FllumaOne, introduced as a code-native multimodal CAD dataset for learning editable parametric CAD construction (Zhan, 16 Jun 2026). Its defining premise is that a CAD object should not be represented only by final geometry, but by the construction history that determines how the part can be modified: ordered operations, parameters, semantic roles, and dependencies. In this release, every sample is generated from an executable Python CAD program in Flluma, a Qt/C++ CAD system with a Python-facing API and an OpenCASCADE geometry backend, and every accepted sample is paired with a structured feature history and several derived modalities. The release contains 100,000 accepted samples across four template-level complexity regimes, and programs are executed and retained only after kernel geometry, solid validity, and export checks.

1. Definition and representational model

FllumaOne-100K is organized around a source-of-truth construction representation rather than a geometry-only record. In the paper’s formulation, each sample aligns an executable Python program, a structured feature tree, a training-oriented intermediate representation, STEP geometry, a surface point cloud, natural-language descriptions, metadata, and eight canonical visible-edge renderings (Zhan, 16 Jun 2026). The canonical record is a structured feature tree paired with an executable Python view in an OpenCASCADE-based runtime, and all released geometry, views, point clouds, and text are derived only after acceptance from the same validated construction record.

In this setting, “code-native multimodal CAD dataset” has a specific meaning. “Code-native” denotes that the model is fundamentally represented as a Python program that can be replayed in the Flluma runtime to regenerate the part. “Multimodal” denotes that the same accepted construction is exported into multiple synchronized modalities: structured history, compact IR, STEP, points, images, text, and metadata. The dataset is therefore neither only text paired with geometry nor merely a collection of scripts without geometry validation. The paper makes the cross-level alignment explicit by tracing samples through program.py, feature_tree.json, training_ir.txt, model.step, point_cloud.npz, canonical view images, text descriptions, and provenance files.

The motivation follows directly from editable CAD practice. A final mesh or B-Rep can reproduce a boundary representation while omitting the feature logic required for design reuse, parametric variation, manufacturing feature analysis, or reverse engineering into editable form. FllumaOne-100K is designed to expose inspectable construction history, replayable executable code, kernel-validated geometry, and aligned learning-ready modalities in a single release. This suggests that the dataset is intended not merely for shape reconstruction, but for learning CAD objects as editable programs with explicit dependency structure.

2. Generation pipeline and kernel-grounded acceptance

The dataset construction pipeline begins from a scheduled distribution of parametric templates, generates executable CAD programs and aligned feature trees, applies deduplication by canonical construction signature, then performs kernel-in-the-loop execution and validation, and only afterward exports the derived modalities and packages the release (Zhan, 16 Jun 2026). The paper summarizes the process as: scheduled template distribution, program and feature-tree generation, signature-based deduplication, execution in Flluma, OpenCASCADE validation, export of geometry and other modalities, and release packaging into raw folders, reports, split files, and Parquet tables.

Flluma itself is described as a parametric CAD application and execution environment with a Qt/C++ application layer, a Python-facing CAD API, and an OpenCASCADE-based B-Rep backend. Two modes are used: a GUI for visual inspection, debugging, and manual checks, and FllumaCLI for headless batch generation. In the automated pipeline, FllumaCLI executes each generated Python program, resolves geometry through the CAD kernel, validates the resulting solid, and produces release assets. Modeling operations are resolved to OpenCASCADE B-Reps; Boolean joins, cuts, and intersections use OCC Boolean operators from the BRepAlgoAPI family; resulting shapes are checked with the OCC B-Rep check analyzer, including face-, edge-, and vertex-level validity; volume and surface-area facts are computed with BRepGProp; and STEP export/reload checks use STEPControl writer and reader APIs.

Program generation is template-driven. Every sample is generated by an executable Python CAD program using a regularized Flluma API with explicit operation names, typed parameters, stable argument order, and direct variable binding for intermediate solids, sketches, and feature operations. The paper notes that a line of code usually introduces one modeling step, one parameterized operation, or one explicit dependency. The operation family includes commands for plate creation, sketch construction, extrusion, cylinders, boxes, Boolean joins and cuts, hole patterns, rectangular pockets, fillets, chamfers, linear and circular patterns, lofts, sweeps, shells, and face-based features.

The executable program and the structured feature tree are aligned during generation. The program is the human-readable source; the feature tree records the same construction in machine-readable form with ordered operations, parameters, semantic roles, dependencies, and topology references or selectors. The feature tree can be replayed in the Flluma runtime and converted back into executable Python code for reconstruction. A compact training-oriented IR is derived from the feature tree and serialized into training_ir.txt as a compact sequence-learning target.

Acceptance is defined operationally and strictly. Candidates are checked against canonical construction signatures before execution, and any candidate with a previously seen design signature is rejected and regenerated. A candidate is accepted only when the resulting model passes solid validation and the required exports can be produced. Invalid samples are rejected for duplicate canonical construction signature, geometry invalidity at kernel level, invalid Boolean outcomes, degenerate faces, non-manifold geometry, unstable topology, or inability to produce required exports. The release-level manifest records 100,000 evaluated release slots, 77 retries caused by duplicate construction signatures, and no unrecovered generation failures.

This validation regime is one of the dataset’s central technical claims. The acceptance target is a kernel-accepted B-Rep solid, not merely a syntactically valid program. A plausible implication is that downstream models trained on the corpus can be evaluated against executable and kernel-valid targets rather than only against lexical or image-level surrogates.

3. Modalities, file structure, and cross-modal alignment

Each accepted sample contains a coherent set of source, derived, supervision, and provenance files (Zhan, 16 Jun 2026). The core files are program.py, feature_tree.json, and training_ir.txt; the geometry files are model.step and point_cloud.npz; the visual files are under images/canonical/; the text files are text/descriptions.json and text/llm_descriptions.jsonl; and the provenance file is metadata.json. Release-level files include dataset_manifest.json, quality_report.json, scheduler_report.json, splits/, schema/, vocab/, and the Parquet split files.

Component	Files	Role
Executable construction	program.py	Replayable Python CAD program
Structured history	feature_tree.json, training_ir.txt	Canonical feature tree and compact IR
Geometry and views	model.step, point_cloud.npz, images/canonical/	STEP B-Rep, points with normals, eight views
Text and provenance	text/descriptions.json, text/llm_descriptions.jsonl, metadata.json	Auditable text, enriched text, validation and hashes

STEP geometry is exported as model.step using the OpenCASCADE STEP writer with the AP214 automotive-design schema. The point cloud modality is a surface point cloud with normals and face identifiers. Each accepted sample includes 2,048 float32 surface samples with float32 normals. Sampling is produced by the Flluma surface-UV sampler, with sample counts allocated across CAD faces in proportion to face area; small-face preservation enabled; at least one point assigned to each face when feasible; candidate points drawn in the trimmed UV domain; candidates filtered by the face classifier; and acceptance controlled by the local surface Jacobian so sampling better follows surface area rather than raw UV coordinate density. Normals are computed from the cross product of the first derivatives of the underlying OpenCASCADE surface and adjusted for face orientation. Metadata records this policy as sampling=surface_uv.

The visual modality consists of eight feature-aware visible-edge renderings: six axis-aligned orthographic views and two isometric views. The paper explicitly distinguishes these from photorealistic renders. Their role is to preserve visible feature boundaries so that holes, pockets, bosses, patterns, and local feature geometry remain visible from fixed viewpoints; pure silhouette projections would hide many internal or back-facing construction cues.

Text is produced in two stages. Deterministic descriptions are generated directly from validated metadata and written to text/descriptions.json; they include part category, dimensions, operation counts, construction steps, and B-Rep facts, and they are described as the main auditable text modality. A second stage uses a local Qwen2.5-7B model, conditioned on descriptions.json and paired training_ir.txt, to rewrite structured descriptions into more natural CAD-oriented language while preserving numeric dimensions, operation counts, hole and pattern counts, and bounding-box facts. The output file text/llm_descriptions.jsonl stores a compact retrieval caption, a detailed technical description, and three natural user prompt variants. The paper stresses that this LLM stage does not choose CAD parameters, change geometry, repair failed programs, or participate in validation.

The key structural property is cross-modal alignment. The modalities are generated from the same accepted CAD record and are not independently collected annotations. This suggests that one modality can function as supervision, conditioning input, or verification target for another without requiring post hoc correspondence recovery.

4. Corpus composition, statistics, and integrity

FllumaOne-100K contains 100,000 accepted complete samples, with an official train/validation/test split of 80,000 / 10,000 / 10,000 (Zhan, 16 Jun 2026). The generator uses a controlled library of parametric templates that includes primitive stocks, sketch-profile plates, circular flange patterns, motor brackets with cutouts, shelled enclosures, intersected mounting blocks, swept pipe brackets, revolved hub components, lofted transition brackets, face-feature service covers, ribbed heat-sink mounts, and irregular sketch-profile parts. Across templates, the generator varies parameter values, feature counts, operation order, and semantic roles.

The scheduler allocates samples into four template-level complexity regimes. These levels are assigned before generation and are not post-hoc thresholds on generated feature count, history depth, or topology statistics. The target allocation is L1: 3,000; L2: 17,000; L3: 55,000; L4: 25,000. The accepted allocation is L1: 3,056; L2: 16,966; L3: 55,219; L4: 24,759, and the accepted proportions remain within 0.25 percentage points of target.

The release provides extensive complexity statistics. Program length has mean 17.442 lines, median 17.000, minimum 7, and maximum 26. Feature-tree nodes have mean 8.245, median 7.000, minimum 2, and maximum 16. Feature count has mean 5.458, median 6.000, minimum 1, and maximum 11. History depth has mean 4.348, median 4.000, minimum 1, and maximum 7. Dependency edges have mean 4.678, median 5.000, minimum 0, and maximum 10. Parameters have mean 6.983, median 7.000, minimum 1, and maximum 13. Training-IR tokens have mean 179.878, median 167.000, minimum 28, and maximum 307. B-Rep faces have mean 28.789, median 20.000, minimum 1, and maximum 191; B-Rep edges have mean 72.144, median 48.000, minimum 2, and maximum 415; B-Rep vertices have mean 46.567, median 32.000, minimum 1, and maximum 227. Bounding-box aspect ratio has mean 6.032, median 4.487, minimum 1.000, and maximum 28.394.

Vocabulary and diversity statistics further characterize the release. The template or category count is 53. The operation-token vocabulary size is 44, and the feature-tree operation-label vocabulary is 60. The most frequent template or category is lofted_transition_bracket, with ratio 8.0%; the top-10 template or category coverage is 47.4%; template normalized entropy is 0.915; and template Gini coefficient is 0.446. The most frequent feature-tree label is HolePattern, with ratio 14.2%; feature-tree label normalized entropy is 0.747; and feature-tree label Gini coefficient is 0.734. In the 44-token model-facing operation vocabulary, OP_HOLE_PATTERN appears in 88.1% of samples and accounts for 17.8% of operation-token instances; the ten most frequent operation tokens cover 82.2% of instances.

Release integrity is reported as perfect on the accepted set. Complete samples number 100,000 (100.00%), with incomplete or unstable samples equal to 0. STEP completeness, point-cloud completeness, canonical 8-view completeness, and deterministic-text completeness are each 100,000 (100.00%). Duplicate program hashes, duplicate feature-tree hashes, duplicate training-IR hashes, and duplicate solid-signature hashes are all 0. The release additionally states that no exact duplicates were found under program, feature-tree, training-IR, metadata, geometry, solid-signature, or shape-signature hashes. Missing required files by type are reported as none, and unstable or unreadable files by type are also none.

These statistics delimit both scale and regularity. The corpus is large by editable-CAD standards, but it remains explicitly generator-controlled. The paper’s own reporting therefore couples scale claims with auditable integrity and validation metadata rather than treating sample count alone as the salient property.

5. Benchmark tasks and baseline performance

The paper proposes benchmark tasks spanning classification, structured prediction, retrieval, and executable synthesis (Zhan, 16 Jun 2026). These include template classification from image, point cloud, or text; complexity-level prediction from image, point cloud, or training IR; next-operation prediction from a prefix of the training IR; feature-tree reconstruction from image, point cloud, or text; CAD retrieval from text, image, or point cloud queries; and program validity, where generated programs or IR are evaluated by syntax rate, kernel-valid rate, and export-valid rate.

The reported baseline is a text-to-program model that maps natural-language CAD descriptions to executable program.py code. The base model is Qwen2.5-Coder-1.5B-Instruct, fine-tuned with LoRA. Training uses the official 80,000-sample training split. For each sample, either a deterministic description from text/descriptions.json or the LLM-generated comprehensive description in text/llm_descriptions.jsonl is chosen with equal probability using a fixed seed. The setup uses one epoch, maximum context length 4096 tokens, learning rate $2\times10^{-4}$, cosine scheduling, warmup ratio 0.03, LoRA rank 16, LoRA alpha 32, dropout 0.05, effective batch size 8, FP16 with TF32 enabled, training time 27,318 seconds, and one 16-GB NVIDIA RTX 5060 Ti. Test-time decoding is greedy, with at most 2,048 generated tokens.

The official split is sample-disjoint and not template-disjoint. The paper therefore states that the benchmark measures interpolation within the released generator distribution, not generalization to unseen template families. This is a consequential qualification for interpreting the baseline.

On the held-out 10,000-sample test split, the baseline reports the following exact results.

Metric	Result	Notes
Python syntax-valid rate	99.98%	9,998 of 10,000
Required part definition rate	99.98%	Code-level criterion
Flluma load rate	99.97%	Execution-level
Flluma build rate	99.97%	Execution-level
Kernel solid-valid rate	99.14%	83 built programs fail solid validation
STEP-export-valid rate	99.14%	All 9,914 solid-valid programs export successfully
Chamfer-evaluated samples	9,909	5-case gap from stricter point-cloud export path
Mean / median Chamfer Distance	0.002124 / 0.001491	Normalized point-cloud comparison
P90 / P95 Chamfer Distance	0.003502 / 0.004854	Distribution tails
Maximum Chamfer Distance	0.180119	Worst case
Mean source-code similarity	87.34%	difflib.SequenceMatcher ratio
Operation precision / recall / F1	99.97% / 99.95% / 99.96%	Multiset overlap of part.* calls
Operation LCS ratio	99.94%	Order-sensitive operation metric

The paper also reports a per-complexity breakdown. L1 has test $n=321$, build 100.00%, STEP valid 100.00%, code similarity 83.13%, operation F1 100.00%, Chamfer $n=320$, mean 0.002906, median 0.001668. L2 has test $n=1,682$, build 99.94%, STEP valid 99.05%, code similarity 84.12%, operation F1 99.93%, Chamfer $n=1,665$, mean 0.001570, median 0.001235. L3 has test $n=5,513$, build 99.98%, STEP valid 99.55%, code similarity 86.83%, operation F1 99.95%, Chamfer $n=5,485$, mean 0.002061, median 0.001292. L4 has test $n=2,484$, build 99.96%, STEP valid 98.19%, code similarity 91.18%, operation F1 100.00%, Chamfer $n=2,439$, mean 0.002541, median 0.002012. The paper notes that L4 has the lowest STEP-valid rate and the highest median Chamfer Distance, but also the highest source-code similarity, reflecting regularity within those template families rather than lower geometric difficulty.

A further comparison uses only LLM-generated comprehensive descriptions at test time without retraining. Under that condition, the same mixed-trained adapter achieves 99.98% Python syntax validity, 99.96% Flluma build success, 99.18% STEP-export-valid rate, 99.92% operation F1, and 87.96% mean source-code similarity. The paper emphasizes that this is not a separately trained LLM-only baseline.

6. Use cases, limitations, and release status

The dataset is explicitly framed as supporting conditioned CAD reconstruction, executable program synthesis, feature-tree prediction, B-Rep analysis, retrieval, design completion, and editable reverse engineering (Zhan, 16 Jun 2026). Text modalities can supervise text-to-CAD and program synthesis; canonical views can support image-to-CAD reconstruction; surface point clouds with normals and face IDs can support point-cloud-to-CAD and editable reverse engineering; partial feature histories or IR prefixes can support next-operation prediction, parameter prediction, dependency prediction, and design auto-completion; and aligned STEP geometry can support B-Rep analysis and manufacturing-oriented feature extraction for holes, pockets, bosses, chamfers, fillets, and repeated patterns. Because all modalities are aligned to the same accepted record, cross-modal retrieval can return not only a similar shape but also matching editable code and feature history.

The paper is also explicit about limitations. FllumaOne-100K is generated by a controlled procedural pipeline, so the distribution reflects template-family choices, parameter ranges, level allocation, and validation constraints. It may inherit generator-specific biases common in synthetic CAD and program datasets and may underrepresent long industrial assemblies, surface-heavy consumer products, and manually authored design histories. The benchmark split is sample-disjoint but not template-disjoint, so reported baseline results do not measure unseen-template generalization. Although deterministic text is auditable, LLM-enriched text may contain awkward phrasing or fact mismatches; the paper recommends auditing deterministic and LLM-enriched text separately. Programs are executable Python in the Flluma API, so trained models may learn conventions specific to the Flluma API, its program schema, and the controlled operation vocabulary. The local LLM is used only for text enrichment and is not a geometric agent; it does not perform repair loops or autonomous CAD correction.

Future directions identified in the paper include broader template families, stronger text-faithfulness checks, and additional benchmarks measuring generalization beyond the generator distribution. The conclusion also identifies evaluation under parameter edits and template-disjoint splits as an important next step, because those settings make preservation of construction intent measurable.

The release and reproducibility provisions are unusually explicit. The project repository is listed as https://github.com/Cad-Kernel/FllumaOne-100K, and the Flluma runtime is listed as https://www.flluma.com. The repository provides dataset documentation, download instructions, a text-to-program reproducibility package, and scripts for data preparation, LoRA training, generation, Python evaluation, Flluma execution evaluation, Chamfer geometry evaluation, run configuration, prompt-source comparison, and summary JSON files used for the reported tables. The downloadable archive contains the complete dataset, release manifests, schemas, split definitions, validation reports, vocabulary files, and license information. The Flluma software ecosystem, including GUI, CLI, and Python API wrappers, is stated to be publicly available free of charge for academic research, dataset validation, and program execution.

Within the scope defined by the paper, FllumaOne-100K occupies a specific position in CAD representation learning: it is a 100,000-sample, executable, kernel-validated, multimodal dataset centered on the claim that editable CAD should be learned from construction history plus replayable code, not final shape alone. Its most distinctive property is the tight synchronization of executable source, structured feature history, kernel-accepted B-Rep geometry, point samples, visible-edge renderings, text, and provenance, all derived from the same accepted construction record.