Executive Summary

Picture a scene. A research team uploads three years of experimental measurements to a national repository. A DOI is issued, a license is attached, and it shows up cleanly in search. On paper, it's "open research data." A few months later, another team tries to train a model on it — and gives up. The columns are named var1, var2, var3, with units recorded nowhere. There's no telling whether a missing value is a blank, a 0, or -999, and the codebook explaining what the labels mean lives somewhere on the author's laptop. It was stored, but it can't be trained on. That gap is where this report begins.

This kind of break is closer to the rule than the exception. The open-data optimism that "if you publish it, it gets reused" has already collapsed against the evidence. Studies find that 38% of repositories fail FAIR's reusability (R1) requirement, and in 30% of cases the metadata is too ambiguous to interpret. Of the 250,000 samples in the gene-expression database GEO, only 11.5% shared complete metadata. More painful still is the gap between awareness and practice: researcher awareness of FAIR is near-saturated at 94.7%, yet only 11% meet all of FAIR's elements and just 23.8% have institutional support staff. The problem isn't ignorance — it's that the process between deposit and trainability has never been automated.

What has to go missing from that process to block training resolves into a handful of typical failure modes. Below are the five defects found again and again in data that was "stored but can't be trained on."

• ·No machine-readable schema: column types, units, meanings, and the codebook exist only as human notes, so code can't parse them automatically.
• ·Inconsistent labeling conventions: which field is the ground-truth label, and who labeled it by what criteria, is neither documented nor measured.
• ·Broken provenance: you can't trace what preprocessing turned the source data into this file, so neither reproduction nor audit is possible.
• ·Undefined training rights: redistribution is allowed, but whether it may be used for AI training, and how privacy and security exceptions are handled, is left unstated.
• ·Unmeasured representativeness and quality: how well the data represents its target population, and how many missing values or outliers it contains, is never captured as a number.

1.1Passing FAIR Still Doesn't Make It Trainable

A common misconception has to be addressed here: "Doesn't following the FAIR principles solve reuse?" FAIR (Findable, Accessible, Interoperable, Reusable; Wilkinson et al., 2016) is a set of 15 principles for making data findable, accessible, interoperable, and reusable. From the start it aimed at machine-actionable metadata rather than human-readable documents — an excellent floor. The catch is that FAIR is a set of principles, not a standard or specification. In particular, reusability principle R1 only asks you to "describe the metadata richly"; it doesn't define the concrete conditions ML training needs — field schemas, label reliability, representativeness, train/test splits, quantitative quality measurement.

So even the var1, var2 CSV above can nominally pass FAIR as long as it has a PID, a license, and minimal metadata. Training is still impossible. FAIR is "the floor for being found and reused," and AI-Ready is the higher bar that adds quality measurement, label reliability, representativeness, machine-loading specifications, and provenance on top of it. Fail to distinguish the two, and "FAIR-but-untrainable" data keeps piling up in the repository.

1.2Readiness Depends on the Task

Treating "AI-Ready" as a switch you flip on or off invites a misunderstanding. Neil Lawrence's Data Readiness Levels (2017) correct it precisely. Just as TRL measures technology maturity, this framework talks about data maturity across three bands — accessibility, faithfulness, and usability.

Most of Chapter 1's failure modes converge on one thing: metadata. But not all metadata is alike. Two fundamentally different kinds must be separated. One is discovery metadata that lets you find the data; the other is ML training metadata that lets code load and train on it directly. Most national repositories have the former and leave the latter empty. Understanding this dual structure is the crux of the process.

The discovery layer is already mature. Standards like DataCite's DOI, schema.org/Dataset markup, and DCAT tell you "this dataset exists, where it is, and who made it." Google Dataset Search crawls that markup to index datasets across the web. But this layer speaks only to "what is where." There's no room for the information ML needs to load data in code — each column's type and unit, which field is the label, what the train/test split is. As a result, even research data with complete metadata forces an ML engineer to write parsing code by hand every time.

What bridges this gap is Croissant, released by MLCommons and Google in 2024. It extends schema.org/Dataset into a standard metadata vocabulary that lets a dataset be not only machine-discoverable but directly loadable by an ML framework. The diagram below shows how the two layers stack.

The proof that this standard isn't idealism on paper is its adoption scale. At launch in 2024 more than 400,000 datasets were already in Croissant form, and by the 1.1 version of February 2026 the count had passed 700,000. Hugging Face, Kaggle, OpenML, and Harvard Dataverse have adopted it, and Google Dataset Search offers a filter for Croissant-only datasets. Hugging Face in particular auto-generates Croissant JSON-LD for every dataset via a /croissant endpoint — meaning ML training metadata is exposed in machine-readable form without the depositor lifting a finger. The dual metadata layer running from discovery (schema.org/Dataset) to training (Croissant) has already hardened into an industry standard.

2.1The Documentation Exists — But No One Reads It

The other axis of metadata is documentation meant for human judgment. Its lineage is clear. Gebru et al.'s Datasheets for Datasets (2018), inspired by electronic-component datasheets, proposed a questionnaire in which a dataset's creators answer seven lifecycle stages: motivation, composition, collection, preprocessing, uses, distribution, and maintenance. Google's Data Cards (2022) went a step further, aiming for a productized transparency artifact that lets consumers compare and judge datasets consistently.

The problem is execution. Even large organizations have been observed turning datasheets into pro-forma "launch-gate paperwork" that no one reads, while smaller ones skip them entirely. Standards settled what to record, but actually filling it in and verifying it remains a human job. This "paperwork no one reads" problem foreshadows the documentation automation discussed later.

2.2DataON Has Only the Discovery Layer

Turning to Korea, the gap comes into focus. The Metadata Design Guidelines of the national research data platform DataON draw broadly on international standards — Dublin Core, DataCite 4.1, DDI, ISO 19115, the re3data schema, and more. Metadata is structured into four layers (collection, dataset, file, repository), each field is graded as required, recommended, or optional, and one of DOI, Handle, or URI is mandatory for published datasets. On the discovery layer alone, it comes close to international practice.

But nowhere in the guidelines is there a requirement for ML training metadata like Croissant, automated schema validation, quality measurement, or provenance recording. Curation is a recommendation — "guidance to sustain quality continuously after publication" — and a manual process, not an automated validation pipeline. What the leading international repositories do "automatically," DataON leaves as "recommended and manual." That contrast is the starting point of the gap this report returns to again and again.

"The data quality is good" was a qualitative claim for a long time. Who judged good versus bad, and by what criteria, varied from person to person. What turned that claim into auditable numbers is the ISO/IEC 5259 series, completed between 2024 and 2026. Its formal title is "Artificial intelligence — Data quality for analytics and machine learning," and it defines a standardized approach to controlling, producing, and delivering data of sufficiently high quality for safe and trustworthy ML.

The series comprises six documents. Parts 1 (terminology), 2 (measurement), 3 (management requirements), 4 (process), and 5 (governance) are full International Standards (IS); Part 6 (visualization), published in May 2026, is a Technical Report (TR). It's often introduced as "5259 has N parts," but the count isn't the point — what matters is that this just-completed body of standards treats data quality across the full cycle of measurement, governance, and visualization. Underneath the series sits ISO 8000, the international standard for data quality in general, with Part 2 defining AI/ML-specific measurement dimensions on top of it.

The heart of it is the quantitative quality dimensions defined in Part 2. The table below sets out what each dimension measures, how it's measured, and how far it can be automated. Why the automation column matters becomes clear in Chapter 5: most of the dimensions are already measured automatically by open-source tools.

Why these dimensions are a prerequisite rather than an option is clear from label reliability alone. When Northcutt et al. (2021) audited the test sets of ten widely used ML benchmarks, an average of 3.3% of labels were wrong. The data treated as ground truth was itself mistaken. Per benchmark, the spread is even wider.

The principle "what isn't measured isn't managed" also has an economic basis. Gartner estimates the cost of poor-quality data at an average of $12.9M per organization per year and projects that 70% of organizations will adopt modern data-quality solutions by 2027. Quality measurement is a cost issue, not merely a regulatory one.

3.1The Measuring Is Already Automatic

Fortunately, most of these dimensions are already measured automatically with open source. Frictionless, using its Table Schema and Data Package patterns, automatically detects type-casting failures, missing required fields, and uniqueness violations at deposit time and produces a consolidated validation report. Great Expectations validates data as if unit-testing it and auto-generates human-readable HTML documents (Data Docs) explaining "what was checked and why." Soda's SodaCL lets you declare checks like missing_count(col) = 0 in near-plain language, and from 4.0 it continuously monitors production data with AI-based real-time anomaly detection. Combining these three complementarily with dbt and data catalogs is already an established pattern.

Even with quality measured as numbers, if you don't know where the data came from and how it changed, you can neither reproduce nor audit the result. That's why provenance and reproducibility are a prerequisite, not an option. And if the right to use it for training isn't clear, no amount of good data can be legally touched. This chapter covers the last three axes of the process — provenance, reproducibility, and rights.

4.1Tracing Where It Came From — PROV and PIDs

The standard for recording provenance is W3C PROV. It weaves the three elements involved in producing data — the Entity (the artifact), the Activity (the process of creation or transformation), and the Agent (the person or software that carried out that activity) — into a graph. It leaves a machine-readable directed acyclic graph of "what this data was derived from (wasDerivedFrom), by what process it was generated (wasGeneratedBy), and to whom it is attributed (wasAttributedTo)." The Croissant standard seen earlier also expresses provenance and usage permissions on top of this PROV ontology — the point where a provenance standard flowed into an ML metadata standard.

What pins the nodes of the provenance graph is the persistent identifier (PID). A DOI issued by DataCite doesn't change even when the location does, linking data, papers, people (ORCID), and institutions (ROR) into a single PID graph. This is how the practical infrastructure for tracing "what this data was derived from and what it was used for" is completed.

4.2If It Can't Be Reproduced, It Isn't Science

When provenance breaks, reproduction collapses. And the reproducibility crisis is already a reality confirmed in numbers. Kapoor and Narayanan (Princeton) showed that at least 294 papers across 17 fields reached over-optimistic conclusions due to data leakage, and classified eight types of leakage — train/test contamination, temporal leakage, applying preprocessing before splitting, and more. A separate survey found that only about 63.5% of ML papers were reproducible, and in NLP only 14.03% matched their reported results exactly. These numbers prove that reproduction and audit are impossible unless data, code, and environment are bound together and the split is specified. That's why the ML reproducibility checklist Pineau et al. introduced at NeurIPS nailed down train/val/test splits and hyperparameter ranges as required items.

4.3Rights as a Feature, Not a Document

The last axis is rights. Research data is entangled with privacy, security, and copyright, so if it isn't clear whether it may be used for training, nothing can start. The direction of leading infrastructure is unambiguous: it handles rights, privacy, and training-use conditions as "pipeline features" rather than "documents." Hugging Face's gated datasets define an access-request form (extra_gated_fields), let you choose automatic or manual approval, impose regional restrictions such as blocking EU users, and programmatically automate approval via API. The U.S. Genesis Mission makes security clearance, classification, and supply-chain security first-class requirements in its national-scale data pipeline, and even includes synthetic-data augmentation. Rights are enforced by the system.

The issues that Korea's National Research Data Act must nail down in its enforcement decree and subordinate guidelines emerge here too. Below are the items that should be defined as pipeline features rather than documents.

• ·Machine-readable training-use licenses: whether AI training and redistribution are permitted, expressed as a machine-parseable license field rather than a human-readable sentence.
• ·Gating for privacy and security exceptions: for sensitive data, enforce access request, approval, and regional restriction as system features.
• ·Mandatory provenance and version recording: automatically record preprocessing and derivation history and per-version identifiers from deposit time onward.
• ·Reproduction bundles required: mandate binding data, code, environment, and split into a single reproducible unit.

Everything so far converges into a single pipeline. For deposited data to become a training asset, it must pass through validation, standardization, provenance recording, gating, and curation — and each stage already has proven, existing tools. What's needed isn't invention but assembly. Below is a reference architecture that maps, stage by stage, the pipeline that leading international platforms have actually implemented.

5.1Where DataON Comes Up Empty

Overlay DataON on this reference architecture and the gaps come into precise focus. The table below contrasts what leading international repositories do automatically at each stage of the process with DataON's current position. Because DataON's total registration and federation counts have low snapshot reliability owing to its semi-annual collection and fluctuation structure, we don't cite them, and compare only by operating model and feature presence.

The diagnosis is clear. DataON approaches international practice on the discovery layer, but at the four points that decide the substance of AI-Ready — ① automated validation, ③ Croissant, ④ quality measurement, ⑦ curation automation — it leaves as "manual and recommended" what international peers do "automatically." And proven open source and standards already exist for each of those four points. This isn't about inventing new technology; it's a matter of adoption, integration, and automation.

5.2The 14 Conditions of AI-Ready

So what state, exactly, does "AI-Ready" satisfy? The 14 conditions (C1–C14) derived from the academic and standards literature are the answer. Each condition is backed by one or more standards or papers, and together they bundle the arguments of the earlier chapters — FAIR guarantees only C1–C2, quality measurement is C5/C7/C8, provenance/reproducibility/rights are C9–C11 — into a single checklist.

Two points run through this checklist. First, FAIR is a necessary condition that guarantees only C1–C2 and part of C9 and C11 — not a sufficient one. Drop C3–C8, C10, and C13, and "FAIR-but-untrainable" data remains exactly as it was. Second, C5/C7/C8 (label, quantitative quality, and representativeness measurement) and C13 (task readiness) are points where the scale doesn't fit exhaustive manual human work. This is the crux of the case for automation.

5.3What to Invest in First

A common piece of conventional wisdom has to be corrected here. "80% of data work is cleaning" has circulated for years, but its basis is a small 2016 survey (about 80 people). Recent measurements (Anaconda, Kaggle, and others) put the share spent on cleaning and preparation at 26–45%. The 80% figure shouldn't be cited as fact. The direction, however, doesn't change: cleaning and preparation are still a large share of data work, and cutting that share through automation is the essence of the investment.

Priority follows the order of the reference architecture's blanks. For a domestic repository, the sequence is: ① block "schema-less CSVs" at the door with automated schema validation at deposit (Frictionless/GX), ② auto-expose Croissant ML metadata so the data is recognized by the ML ecosystem, ③ measure and record quality against the ISO 5259 dimensions, and ④ automate curation to gain scale. All four stages have proven open source, so the crux is not technology but the decision — and the operations — to embed it into the deposit pipeline.

The reason Pebblous watches this topic is not national research-data policy itself. It's that the blanks in the reference architecture — automated validation at deposit and quantitative quality measurement — have exactly the same structure as the problems Pebblous DataClinic diagnoses in industrial data every day.

A Blank Is Where Automation Goes

Points ① (automated validation) and ④ (quality measurement) from the contrast table above map directly onto the classic data-quality defects: missingness, outliers, class imbalance, duplication, and label errors. And these defects overlap with the items DataClinic diagnoses automatically. Filling Chapter 1's failure modes — insufficiency, bias, missing licenses — is where AI-Ready Data and synthesis/augmentation come in. In short, at every blank in the reference architecture this report has drawn, there is a place for automation to take over the measurement and curation that people cannot handle exhaustively.

Quality Must Be Measured to Become a Strategic Asset

This report demonstrated the proposition that "training-data quality carries through to model output" with the evidence that a 3.3% label error flipped a benchmark's rankings. As high-quality public web text is projected to run out between 2026 and 2032 (Epoch AI, limited to web text), the strategic value of verified, domain-specific research data rises — but only when its quality has been measured. Unmeasured data injects bias and error straight into the model. This report's argument that quality measurement is a prerequisite rather than an option is also the condition for turning national research data into a strategic asset.

The Automation Has Already Begun

The evidence that this isn't a distant story is on the ground. In the State of Open Data 2025 survey, respondents using AI for metadata generation rose from 16.1% to 25.1% in a single year. The frontier agenda of leading infrastructure is explicitly "low-cost, scalable AI-ready curation" (InvenioRDM HORIZON-ZEN+, EOSC EDEN/FIDELIS). The recognition that human curation cannot keep up with scale is already shared by standards, institutions, and tools alike.

The law has passed, and the remaining question is "how do we actually build it now." The process this report has drawn — what to do, by which standard, how to measure it, and who is accountable — is a practitioner's blueprint that answers that question. Without standards there is no comparison, and without measurement there is no trust. Filling the process between deposit and trainability with automation is what makes that trust achievable at a scale people can handle.

Standards & Specifications

• 1.Maruseac, M. et al. (2024). Croissant: A Metadata Format for ML-Ready Datasets. arXiv:2403.19546; NeurIPS 2024 D&B Track. (originating paper for the ML training metadata standard)
• 2.MLCommons (2026). Croissant 1.1 Standard. (700K+ datasets adopted)
• 3.ISO/IEC 5259-2:2024. Data quality measures. (defines the quantitative quality dimensions)
• 4.ISO/IEC 5259-5:2025 (Governance framework), ISO/IEC TR 5259-6:2026 (Visualization). iso.org (a body of standards completed with 5 IS + 1 TR)
• 5.ISO 8000-1:2022. Data quality — Overview. (the standard underlying 5259)
• 6.W3C. PROV-O: The PROV Ontology. (the three provenance elements: Entity, Activity, Agent)
• 7.DataCite. DataCite Metadata Schema 4.x. (PID/DOI, PID graph)
• 8.Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles. Scientific Data 3:160018.

Papers — Documentation, Quality, Reproducibility

• 9.Gebru, T. et al. (2018/2021). Datasheets for Datasets. arXiv:1803.09010 / CACM 64(12).
• 10.Pushkarna, M., Zaldivar, A., & Kjartansson, O. (2022). Data Cards. FAccT '22, arXiv:2204.01075.
• 11.Lawrence, N. D. (2017). Data Readiness Levels. arXiv:1705.02245.
• 12.Northcutt, C. et al. (2021). Pervasive Label Errors in Test Sets. NeurIPS 2021 D&B, arXiv:2103.14749. (3.3% average label error across 10 benchmarks)
• 13.Kapoor, S., & Narayanan, A. (2023). Leakage and the reproducibility crisis in ML-based science. Patterns 4(9):100804. (data leakage in 294+ papers across 17 fields)
• 14.Pineau, J. et al. (2021). Improving Reproducibility in ML Research. JMLR 22(164). (the ML reproducibility checklist)
• 15.Bender, E. M., & Friedman, B. (2018). Data Statements for NLP. TACL 6.

Institutions, Infrastructure, Policy

• 16.KISTI. DataON Metadata Design Guidelines. (federation/registration split, discovery-layer standards)
• 17.EOSC. Multi-Annual Roadmap 2025–2027; InvenioRDM HORIZON-ZEN+. (low-cost, scalable AI-ready curation)
• 18.NIH. Data Management & Sharing Policy (2023); NOT-OD-26-046 structured DMP (2026). (machine-actionable DMP)
• 19.The White House (2025). Launching the Genesis Mission. (security clearance, gating, synthetic data)
• 20.Hugging Face. Croissant endpoint / Gated datasets. (auto-exposure, gating automation)
• 21.Frictionless Data Framework; Great Expectations; Soda (SodaCL). (deposit-time automated validation toolchain)

Figures & Surveys

• 22.Are the FAIR Data Principles Fair? IJDC. (38% fail FAIR R1, 30% ambiguous metadata)
• 23.Perceptions and behavior regarding FAIRification. PMC9142513. (94.7% awareness vs. 11% meeting all elements)
• 24.Epoch AI. Will we run out of ML data? (projected exhaustion of public web text, 2026–2032)
• 25.Digital Science/Figshare. State of Open Data 2025. (AI use for metadata generation, 16.1% → 25.1%)
• 26.Gartner (via Ataccama). Cost of poor-quality data & 2027 DQ adoption outlook. ($12.9M per org per year, 70% adoption)