3D concrete printing has moved from laboratory demonstrations toward construction-scale experimentation; printed residential structures, bridges, and architectural elements have been produced in many countries worldwide using systems ranging from gantry extruders to six-axis robotic arms [1, 2, 3]. The technical literature now spans printable mortars, alkali-activated binders, fiber-reinforced systems, recycled aggregates, interlayer bond, anisotropic strength, rheology, buildability, and durability. The public record is large enough to support comparative analysis, but not yet consistently shaped enough to make that analysis straightforward.

The central problem is not that researchers fail to report data — many papers report substantial detail — but that the detail is not represented in a common structure. A material may appear as “GGBFS,” “slag,” “ground granulated blast-furnace slag,” or a supplier name; a dosage may be reported in kg/m³, percent of binder, or percent of total mass; a compressive strength may refer to a cast cube, a printed prism, a cored specimen, or a coupon loaded across the layer interface. These distinctions matter scientifically, yet they are often not preserved in a machine-readable way. The consequence is direct: datasets from different groups cannot be combined without extensive manual harmonization, so the field cannot easily build the large, multi-source corpora that modern analysis needs. The most widely used concrete dataset for machine learning — Yeh’s UCI Concrete Compressive Strength set [4] — captures only composition and age, with no process, rheology, or orientation fields, and predates 3DCP entirely (§3).

What makes 3DCP fundamentally different from cast concrete can be stated in four points:

These four properties are what a 3DCP record has to capture if printed-concrete results are to be compared across studies at all: a strength without a process, a rheology, and an orientation is not a comparable measurement. Open3DCP exists to record that fuller experiment, not to model it.

Open3DCP is a schema specification: it defines how to record data; it does not provide the data. It is scoped to extrusion-based (material-extrusion / FDM-style) 3D concrete printing — the process whose pump, nozzle, layer schedule, and toolpath the schema captures. Particle-bed / binder-jetting, spray, and slip-form methods are out of scope: they have different process variables and would need their own process block.

On materials chemistry, Open3DCP covers hydraulic cementitious systems — Portland and blended cements, calcium-aluminate and calcium-sulfoaluminate cements, and high-calcium alkali-activated slag, whose C-(A-)S-H binding gel is chemically continuous with Portland hydrates. Low-calcium fly-ash geopolymers (whose N-A-S-H gel is a distinct binder chemistry) are out of scope; the schema’s activator columns exist to record the high-calcium alkali-activated systems that are in scope, not to characterize geopolymers.

Open3DCP is:

Open3DCP is not:

The schema can record data used in qualification or research workflows, but any construction use still requires appropriate laboratory validation, professional engineering review, and approval under the governing jurisdiction.

The ICME paradigm and lessons from metals additive manufacturing. The idea that materials can be designed from performance requirements backward through processing–structure–property relationships was advanced by Olson’s work on hierarchical, systems-based materials design [15, 16]; this approach was later formalized as Integrated Computational Materials Engineering (ICME). The Materials Genome Initiative [17] sought to extend it through data infrastructure, funding repositories, ontologies, and schema patterns. In parallel, the FAIR principles for scientific data — Findable, Accessible, Interoperable, Reusable — were articulated by Wilkinson et al. [18]; together they shaped the data-stewardship practices Open3DCP follows. Metals additive manufacturing offers a particularly instructive parallel: early laser-powder-bed and directed-energy-deposition work used ad-hoc formats until ASTM F3049 [10] and the NIST AM Bench program established common reporting practices that enabled cross-laboratory comparison. That effort took most of a decade; 3DCP is at the start of a similar trajectory. The key insight carried over is that the manufacturing process is a design variable, not a constraint — printable concrete should be purpose-designed for layer-by-layer deposition, and capturing that requires a record of what makes extrusion different from casting.

Seminal work in 3D concrete printing. Automated construction with cementitious materials dates to Pegna’s solid-freeform work [19]; Khoshnevis developed Contour Crafting [20] and Cesaretti et al. demonstrated binder-jetting of regolith simulant [21]. The modern extrusion era began with two groups in parallel: at Loughborough, Buswell, Lim, Le and colleagues published early mix-design and construction-scale studies [22, 23]; at TU Eindhoven, Bos, Wolfs, Ahmed and Salet produced early structural printed elements — including a 3D-printed concrete bridge designed by testing [1, 24] — with Wolfs et al. on early-age behaviour [5] and Suiker on wall stability [25]. Roussel established the rheological framework for printable concrete [7], and Perrot et al. quantified structural build-up [26]. The NTU Singapore group contributed systematic rheology studies including geopolymers [27, 28], printability regions [29], and fresh/hardened characterization [30]. Interlayer bond — the defining weakness — has been studied by Kruger, van Zijl and colleagues on porosity [6], Sanjayan et al. on surface moisture [8], Moelich et al. on quantitative bond models [9], Van Der Putten et al. on surface modification [31], and Marchment and Sanjayan on mesh reinforcement [32]. Structural implications were addressed by Asprone et al. [33] and Gebhard et al. [34]. Broader reviews include Mechtcherine et al. on production physics [35], Buswell et al.’s research roadmap [3], Nerella et al. on strain-based build-up [36], De Schutter et al. on technical/economic/environmental potentials [2], large-scale UHPC work [37], a classification of building systems [38], particle-bed printing [39], fiber-reinforced and recycled-aggregate formulations [40, 41], the 3DCP.fyi citation network [42], and Wangler et al.’s digital-concrete review [43]; the RILEM TC 276-DFC state-of-the-art report consolidates digital-fabrication practice [46].

Standards development. RILEM TC 304-ADC has driven test-method standardization for 3DCP; its interlaboratory study coordinated testing across roughly thirty laboratories and quantified inter-laboratory variability [11, 12, 13], with an accompanying database system for sharing experimental data [14]. Vasilić reviewed the state of standardization, identifying the gap between established test methods (which RILEM provides) and a unified data schema for analysis-ready storage (which no formal standard yet provides) [44]. Conventional standards — ACI 318 for structural design, ASTM C39 (compressive), C496 (splitting tensile), C1583 (pull-off direct tension), C78 (flexural), C469 (modulus), C191 (setting), C1611 (slump flow), and the EN 197/206/12390 series — supply the measurement framework 3DCP inherits, but were written for cast concrete; the test methods remain valid while the conditions of production and the metadata needed to interpret results differ.

Existing datasets and their limitations. The most cited ML concrete dataset, Yeh’s UCI set [4], captures only composition and age in kg/m³ (requiring a density assumption for formulation-level comparison) and no process, rheology, orientation, specimen, or provenance fields. Repositories such as Mendeley Data and Zenodo host specialized concrete datasets, but — to our knowledge — none provide a general-purpose 3DCP-native schema with first-class process parameters. The closest prior art is the RILEM TC 304-ADC interlaboratory database system [14], the first multi-laboratory 3DCP dataset with standardized protocols; its schema, however, is scoped to that interlaboratory study (its entity model covers materials, specimens, and tests but not a general printing-process vocabulary), whereas Open3DCP aims at a reusable, analysis-ready record across studies. We position Open3DCP as complementary to [14], not a replacement.

Conventional concrete datasets focus on composition, age, and one or more hardened properties — useful for cast concrete, where placement and compaction are treated as standardized. 3DCP makes that assumption unsafe: the manufacturing process is part of the material definition. At minimum, a 3DCP record must distinguish what was weighed into the mix; how it was prepared and modified over time; how it was pumped and extruded; what geometry was deposited; how much time elapsed between adjacent layers; the environmental conditions during deposition; how the specimen was cured and extracted; the loading direction relative to the layer interface; the test method or local protocol; and whether each value was measured, calculated, estimated, or merely reported. Without these attributes, two identical-looking compressive strengths may describe physically different experiments — a cast cube and a printed coupon loaded across interlayers should not collapse into one data point merely because both report MPa.

Open3DCP is governed by a small set of principles, each motivated by the practical requirements of analysis and the lessons of data standardization in adjacent fields.

5.1 Flat schema. Every stored feature is a named column in a single table — no JSON nesting, no graph structure, no join required for basic analysis. This prioritizes adoption by the researchers, curators, and ML practitioners who overwhelmingly work with tabular data (pandas, CSV, SQL) over the representational elegance of graph models such as GEMD, which capture provenance chains and measurement hierarchies but add friction for the common “load a table and train a model” use case. A graph view can be constructed from the flat schema for the structure it captures; conversely, the flat row deliberately omits the full relational/provenance tree (§9), so flat→graph reconstruction is faithful only for the subset the row holds — the two are complementary, not equivalent.

5.2 Dual basis: mass-percent stored, kg/m³ preserved. To be precise about what sits where: the constituent columns store mass-percent of total wet mix — the self-normalizing projection (Σ ≈ 100 %) that pools cleanly across datasets — while the source’s kg/m³ (the convention the concrete industry and field actually use) is preserved exactly and is first-class, never approximated. Three columns make the two interconvertible without assumption: original_basis records what the source reported (kg_m3 | mass_pct | volume | lb_yd3), and total_batched_mass_kg_m3 and total_binder_kg_m3 carry the batched-mass and binder totals needed to convert exactly in either direction. This resolves a real tension: kg/m³ is what practitioners report and need, but normally requires a density assumption for cross-dataset comparison when density is unreported; mass-percent is self-normalizing and ideal for pooled analysis, but is foreign to field practice. Storing the projection plus the lossless bridge serves both without discarding information. (Schema versions ≤ v1.5 carried mass-percent only, with no recoverable kg/m³; v1.7 added the bridge columns that make kg/m³ exact. Admixtures are recorded on a solids basis where the source reports the solids fraction; where it does not — common in public datasets — the as-delivered mass is stored exactly and the row’s admixture_basis flag records as_delivered (v1.7.5), so nothing is assumed and solids remain derivable when a fraction is known. w_b_ratio counts only the water column, not admixture carrier water. The same preserve-don’t-presume principle gives unclassified constituents exact homes: cement_unspecified, fine_agg_unspecified, and coarse_agg_unspecified store the mass when the source states no type, fineness modulus, or size — the classification stays NULL instead of being defaulted.)

5.3 NULL is not zero. Open3DCP distinguishes missingness from absence. NULL marks a value that is unknown, not reported, not applicable, not measured, or not recoverable without an assumption; 0 is reserved for an explicit source-reported zero or absence. steel_fiber = 0 is appropriate when a paper states no steel fiber was used; steel_fiber = NULL when the paper is simply silent. The distinction is critical for statistics and model training, because false zeros bias means, correlations, feature importance, and learned absence effects.

5.4 Standards alignment without standards substitution. Column names and descriptions reference established standards where they define material classes or test methods — ASTM C150 (cement types), C618 (fly-ash classes), C989 (slag), C1240 (silica fume), C33 (aggregate grading by fineness modulus), C39 and EN 12390-3 (compressive testing), and RILEM TC 304-ADC orientation terminology. These are interoperability hooks, not endorsement or certification: a column can record that a result was produced under a given method, but the schema cannot verify the method was performed correctly.

5.5 Provenance by design and multi-age support. Every record carries a DOI or source citation, a measurement-confidence flag (measured / calculated / estimated / reported), and a laboratory identifier, so downstream users can filter by data quality and trace results to their source. A companion strength_measurements table stores results at multiple ages (one hour through 365 days) linked by formulation, supporting strength-development analysis — early-age strength governs buildability while 28-day strength governs structural adequacy, and most datasets report only the latter.

5.6 Documented trade-offs. Two further choices are deliberate departures from convention. Fineness modulus over maximum aggregate size: because 3DCP uses only fine aggregate (constrained by pump and nozzle, generally below 4 mm), Open3DCP classifies sand by fineness modulus (FM — the summed cumulative mass-percent retained on the standard sieve series, divided by 100; a single index of overall fineness), which is more discriminating than maximum particle size for the fine aggregate (well below the 4.75 mm sand boundary, often under ~4 mm) that printing uses — two sands of equal maximum size can have very different gradations and packing. Trade sand classes (mason / fine / concrete / coarse), mapped onto ASTM C33 grading, are one realization; EN/ISO grading maps onto the same field. SCM reactivity factors excluded: the schema stores what was weighed — the mass of each SCM — and leaves reactivity estimation to downstream feature engineering, because reactivity factors are modeling decisions, not raw data.

Open3DCP v1.7.5 defines 248 columns in its primary mix_designs record (companion tables — strength_measurements, sources, test_methods, curing_regimes, material_aliases — add linked rows and are not in this count). Figure 1 places the columns in the ICME chain; Figure 2 inventories them under a Composition–Processing–Conditions–Properties–Provenance (CPPC) view — a reporting-oriented refinement of the ICME process–structure–property chain that adds explicit Conditions and Provenance legs, not a competing standard. The canonical column-by-column specification is the repository’s Open3DCP_SCHEMA.md and sql/create_tables.sql; this section summarizes the categories.

The 248 is best read as a vocabulary, not a per-record dimensionality. It enumerates every reportable field — each cement type, each aggregate size, each fiber, each durability test is its own column — so a typical record leaves most columns NULL (the schema is sparse by design). Only four columns are computed from others (w_c_ratio, w_b_ratio, a_b_ratio, fiber_aspect_ratio); the rest are independent recorded fields, with five carrying measurement uncertainty, five referencing external files, and the remainder provenance/identity metadata (Figure 4). About three in four columns describe material and performance properties shared with conventional cast concrete; the printing-process and interlayer columns are the additive, 3DCP-specific part (Figure 3).

Composition. Portland and blended cements, calcium-aluminate and calcium-sulfoaluminate cements, fly ash (generic, Class F, Class C as separate columns per ASTM C618 oxide-sum classification), slag, silica fume, metakaolin, limestone, pumice, bottom ash, rice-husk ash, alkali activators, nanoscale modifiers, mineral powders, recycled sand, pigments, aggregates, fibers, admixtures, clay rheology modifiers, water, and derived ratios. The schema preserves chemically meaningful distinctions rather than collapsing all cementitious material into a single “binder” field, because fly-ash class, slag, silica fume, limestone, and metakaolin are not interchangeable in hydration, packing, rheology, or long-term performance.

Fibers. Eight core families — steel_fiber, pp_fiber, pva_fiber, glass_fiber, basalt_fiber, carbon_fiber, nylon_fiber, aramid_fiber — plus cellulose_fiber for natural-fiber compatibility (relevant to emerging 3DCP wall-qualification frameworks such as ICC 1150 [47]), with geometry captured separately (fiber_length_mm, fiber_diameter_mm, fiber_aspect_ratio, fiber_tensile_strength_mpa). Aspect ratio is the single strongest predictor of fiber contribution to post-crack toughness and is rarely derivable from papers that report only type and dosage.

Fresh-state and rheology. Slump, spread, J-ring, V-funnel, L-box, setting times, air content, fresh unit weight, bleeding, yield stress (static and dynamic), plastic viscosity, thixotropy / structuration rate, open time, and green strength. Printability is not a single property: pumpability, extrudability, shape stability, and open time can move in different directions as water, superplasticizer, VMA, accelerator, grading, and ambient conditions change.

Process parameters. Print speed, layer height and width, layer time gap, nozzle diameter / shape / area, filament width, extrusion rate, number of layers, path length, infill pattern, contour count, print direction, and pumping/mixing/environmental conditions — the processing leg of the ICME chain, absent from prior concrete datasets. The process columns and their typical downstream outcomes are specified in the repository.

Specimen and test context. Specimen preparation, geometry, dimensions, extraction method, curing conditions, test age, test method, number of specimens averaged, and test orientation — especially important because printed concrete is anisotropic. Orientation is a controlled vocabulary (Table 1).

* Indicative ordering for axial (compressive) loading, and mix-dependent. In flexure the ordering can invert: loading along the print path (X) bends the interlayer planes in tension, so X is typically the weakest flexural orientation — exactly what the worked demonstration measures (§6).

Table: Test-orientation controlled vocabulary. Strength ordering is typical; specific values depend on mix design and process parameters [5, 6].

Hardened, durability, and interlayer. Compressive, tensile, splitting tensile, flexural, modulus, bond, fracture energy, toughness, impact, fatigue, density, and Poisson’s ratio; a durability suite covering chloride transport, carbonation, shrinkage, creep, freeze–thaw, sulfate and ASR expansion, permeability, absorption, sorptivity, scaling, corrosion indicators, thermal properties, and fire resistance; and interlayer columns for bond, shear, void-area fraction, deposited air content, surface roughness, surface moisture state, and surface treatment. The schema does not assert that every dataset measures all of these; it provides stable homes when the measurements exist.

Provenance, basis, and uncertainty. Beyond DOI, citation, confidence, lab, and quality flags, v1.7 added per-measurement uncertainty columns (e.g. compressive_strength_stddev_mpa), raw-data references that keep large payloads external (raw_data_doi, stress_strain_file, rheology_curve_file, microstructure_image, raw_data_file), the basis columns of §5.2, a material_class classification, a batch timeline (batch_label, date_of_casting), and aggregate-conditioning columns (aggregate_moisture_state, aggregate_absorption_pct, aggregate_moisture_content_pct, aggregate_prewetted) that make effective mix water recoverable when aggregates are batched off the SSD reference.

Quantifying the cost of flattening. Projecting a heterogeneous or relational source onto one flat row can lose information. Rather than hide that, the fidelity of the mapping can be scored against the source and reported — a proposed, not-yet-calibrated convention (§10) — so the cost of each conversion is recorded rather than hidden. A machine-readable crosswalk to a normalized relational concrete database, and a specification of the process-parameter columns that have no conventional relational counterpart, are included in the repository.

Worked demonstration: five public datasets in one schema. To show the schema works on real data — not only by design — we ingested five openly-licensed public datasets into Open3DCP, chosen so that each lights up a different slice of the record (Figure 5, left). Two are flat kg/m³ tables that the open3dcp-ingest tool converts and scores automatically:

These scores are an honest ingestion-fidelity check on a curated excerpt, not a dataset-quality grade. The metric scores only the dimensions a flat source can actually exercise — relational-integrity and file-capture are reported not applicable and excluded rather than credited a free 100 — renormalizes over those, and caps the grade by its weakest applicable dimension, so near-complete field coverage cannot float a low value-fidelity to an “A”. Value-fidelity counts every cell that rests on a genuine assumption (a guessed solids fraction or product density, a volume dose without one, an incomplete-batch projection) against the cells stored exactly. The metric earned its keep against this very schema: an earlier draft defaulted unstated classifications — a cement type, two aggregate gradation buckets — and the metric priced those guesses at 79.9/C for UCI. Rather than accept fabricated certainty, v1.7.5 added the *_unspecified columns and the admixture_basis flag so the schema records exactly what a source states and nothing more; the same data then ingests with zero assumptions, and the unknowns are visible NULLs instead of silent defaults. A perfect score therefore means precisely “nothing was assumed” — and the report still lists every generically-recorded cell — while messy sources (volume doses, missing batch masses, unstated units) are penalized exactly as before. The convention is documented in §10, deliberately conservative, and not yet calibrated against a labelled benchmark.

Three more are curated through their native structure (a fidelity score for each awaits a dedicated reader, exactly as the tool is extended source by source):

A UHPC source surveyed for this work, the Stevens dataset (Mahjoubi & Bao), was excluded as reference-only: its mix variables are published as a coded ML feature matrix whose legend is paywalled, so it cannot be honestly re-ingested. Together the five light up complementary slices, and Open3DCP holds the union of these five sources in one shape — and the empty cells are as much the point as the full ones: what each source cannot supply is recorded, not hidden (Figure 5, left).

The demonstration also yields a characterization result that cannot be expressed without an orientation field, nor compared across laboratories without a shared schema: print anisotropy. Mapping the RILEM U/V/W loading codes onto Open3DCP’s test_orientation_code (X/Y/Z/CAST), printed concrete loaded along the print path is 32–55 % weaker in flexure than its cast reference in each of three independent single-lab datasets — three different commercial premixes tested at ~28–30 days (per-lab reductions 40 %, 32 %, and 55 %; n = 12–40 per group). The reductions agree in direction across all three, but the datasets share no formulation, so this is a consistent single-lab observation rather than a pooled estimate; the 55 % upper bound is the least-pinned, resting on a 12-specimen cast group with ~40 % coefficient of variation (roughly ± 7 percentage points of standard error). Literature reductions for specimens loaded across the layer interface run ~20–40 % [5, 6]; our along-path flexural reductions run higher because bending concentrates tension on the interlayer planes. (That is also why Table 1’s “typical strength” ordering — stated for axial loading — inverts here, as the table note and Limitation 4 say.) This is a demonstration of ingestion and interoperability — recording what was measured in one comparable shape — not a predictive-model benchmark; assembling and modelling a pooled multi-source corpus is future work (§11).

A full digital twin of a 3DCP process spans at least four layers of information: a material definition (composition, product identity, particle characteristics, water/admixture basis, fiber geometry); a process definition (mixing, pumping, nozzle geometry, motion, extrusion rate, layer schedule, environment, curing); state and structure (fresh rheology, thixotropic recovery, interlayer surface condition, porosity, moisture, temperature, hydration, fiber orientation, microstructure); and performance and provenance (mechanical and durability properties, test method, specimen geometry, orientation, lab, confidence, source). Open3DCP covers much of the first, second, and fourth, and a useful subset of the third (Figure 1). Open3DCP is not a digital twin. A digital twin, as the digital-fabrication community uses the term, requires live, bidirectional coupling to the running process; a static, scalar, single-row schema has none. Open3DCP is better described as a structured experiment record — a substrate from which many aspects of published 3DCP work can be reconstructed and compared, and on which future digital twins could be built. Full process twins will additionally require time-series machine logs, synchronized sensor data, imaging, and richer links to raw files.

This section identifies features that are physically important for 3DCP but cannot currently be measured reliably. The taxonomy is intended to guide instrumentation research and future schema extensions, not to claim the schema is complete.

8.1 Real-time process-monitoring gaps. The schema stores rheology as point measurements (typically a pre-print laboratory rheometer reading), but the material’s rheological state changes continuously from mixer through pump, hose, and nozzle; no inline rheometer exists for cementitious materials at production scale. Pump pressure is a single scalar, yet in practice it fluctuates with consistency and toolpath back-pressure in ways that correlate with segregation and flow discontinuities. Nozzle standoff is a nominal value that varies with robot positioning and substrate deformation. And print-head dynamics — acceleration, deceleration, cornering — cause local variation in deposition rate not captured by a single print-speed value.

8.2 In-situ material-state gaps. The actual interlayer moisture at the moment of deposition is a continuous field depending on ambient humidity, wind, time gap, and diffusivity; Sanjayan et al. [8] showed it affects bond by 20–40 % and Moelich et al. [9] modeled it quantitatively, yet no standardized protocol measures it in production. The degree of hydration at each interface forms a gradient across layers, but the schema stores a single destructively-measured value. Fiber-orientation distribution critically affects directional strength but can only be measured destructively by micro-CT after hardening. Aggregate packing within the filament and the internal temperature field during exothermic curing are likewise not measurable in-situ.

8.3 Characterization-protocol gaps. Interlayer void fraction requires destructive cross-sectional imaging with no standardized analysis; surface roughness at layer interfaces has no standard protocol for 3DCP; and ambient conditions reported as room averages may differ from the point of deposition in large-scale or outdoor printing.

8.4 Process inputs not yet captured. Beyond the real-time signals above, several extrusion-process inputs an operator sets are not yet schema columns. The priority gap is in-line accelerator dosing at the print head (set-on-demand): on dosing-pump systems it is the control variable an operator tunes to keep the print standing, and a record without it omits the knob that most directly sets buildability — today only admixture_addition_point and the bulk accelerator column hint at it. Next in line: material age at deposition and on-site retempering (water or admixture added as the hopper ages, which silently moves the as-deposited w/b away from the batch ticket), print-head auger / screw extruder speed (distinct from the bulk-mixer speed the schema records), colorant / pigment dosing, and vibratory-assist or compaction modules — alongside nozzle standoff, print acceleration / jerk, and surface dehydration of the resting layer (the dominant interlayer-bond control) (Figure 3, annex). These are an explicit future-work agenda; the schema extends additively as they are specified.

8.5 The digital-twin horizon. A complete twin would require on the order of 300+ parameters, including time-series data that cannot be represented as scalar columns. Open3DCP captures the formulation, process, and performance layers of a record well, plus a useful part of the in-situ state layer; the largest remaining gap is the real-time process data that current hardware does not routinely capture. As sensor technology improves — inline rheometers, thermal imaging tied to print-head motion, machine vision for filament geometry — the flat schema can extend additively without breaking existing queries. The gap analysis is not a criticism of the schema’s completeness: the features we cannot measure today are, in many cases, the features that most limit a complete characterization of the printed material, and closing these gaps requires instrumentation, not schema design.

Adoption does not require populating every column — null columns are ignored during analysis. A laboratory can adopt the schema by (1) mapping local column names to canonical Open3DCP names; (2) recording material quantities with the source basis preserved (original_basis) so kg/m³ ↔ mass-percent remains exact; (3) preserving missing values as NULL and using 0 only for explicit zeros; (4) filling provenance fields before analysis fields; (5) recording test method, specimen geometry, age, and orientation for every mechanical result; (6) depositing the dataset in a public repository when rights allow; and (7) citing the schema and the original test methods. The flat schema is database-agnostic (PostgreSQL, SQLite, CSV, Parquet, pandas/polars/R) and pairs naturally with standard ML libraries for an end-to-end, open-source pipeline. By design it is FAIR-aligned [18]: every record carries a DOI or citation (Findable), the schema is open under Apache-2.0 (Accessible), naming follows ASTM/EN/RILEM with SI units and controlled vocabularies (Interoperable), and the license plus provenance metadata supports reuse (Reusable).

Because most of the schema is shared with conventional concrete (§6), Open3DCP interoperates closely with a normalized relational concrete database (Figure 6). Material composition and test results map both ways — exactly for ages, geometry, and ratios; with a recorded density for the kg/m³ ↔ mass-percent step. The correlation is close but the round-trip is not lossless: relational structure that a flat row cannot hold (parametrized geometry, reinforcement layouts, devices, loading histories) collapses to a side record, and the extrusion-3DCP process and interlayer columns have no conventional relational table to map into. Stating these boundaries is what makes the mapping auditable rather than asserted.

We invite the 3DCP community to adopt common column names and units in published datasets — even partial adoption of shared names for fields like compressive_strength_mpa, w_b_ratio, layer_height_mm, and test_orientation_code would sharply reduce the effort of combining datasets — and we encourage standards bodies and the community to evaluate Open3DCP (or a derivative) as one input to future 3DCP data-reporting practice, extending the RILEM TC 304-ADC database approach [14] from interlaboratory studies to routine publication.

These limitations bound the claims above; §11 maps each to planned work.

Manuscript license. Copyright © 2026 Sunnyday Technologies LLC and Nicholas Sonnentag. This manuscript is licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). The Open3DCP schema, SQL definitions, machine-readable metadata, and repository artifacts remain under the Apache License 2.0 unless a specific file states otherwise; third-party standards, publications, figures, and trademarks remain the property of their respective rights holders.

Author contributions. Nicholas Sonnentag: conceptualization, methodology, software, data curation, writing — original draft, review & editing.

Competing interest. The author is the founder of Sunnyday Technologies, which develops Open3DCP and related 3DCP tools. Open3DCP is released under an open-source license (Apache 2.0) with no commercial restriction on use.

Acknowledgments. The author thanks the RILEM TC 304-ADC committee for foundational work on 3DCP test standardization and interlaboratory data sharing; the National Institute of Standards and Technology (NIST), the American Concrete Institute (ACI), Oak Ridge National Laboratory (ORNL) and its Manufacturing Demonstration Facility (MDF), and the ISO/ASTM 52939 committee together with its associated ASTM contributors, for advancing the measurement science, standards, and qualification frameworks on which additive construction depends; and the broader 3DCP research community whose published data motivated and informed the schema. Acknowledgment of these organizations reflects the standards and measurement foundations the schema builds on and does not imply their endorsement.

Corresponding author: Nicholas Sonnentag, Sunnyday Technologies (nick@sunn3d.com).