About the standard

The standard and operating guidelines

Type · OverviewReading time · about 3 minAll readersAgent and AI developers (data users)

Parts 1–3 of the standard contain the measurement methods · recording format · tier system; the operating guideline contains threshold values and operational matters; the vocabulary contains all metadata elements.

Structure of the standard

The standard has five parts. Building on the common concepts of Part 1, Part 2 covers measurement, Part 3 recording, Part 4 judgment and Part 5 use. Parts 1–3 are the draft standard (TTAK deliberation draft v0.95); Parts 4 and 5 are follow-on parts.^follow-on

Work on Parts 1–3 began on March 9, 2026, and they were proposed to TTA (Telecommunications Technology Association) as a standard on May 13, 2026. The review is in progress at TTA regular meetings. Progress is described in Origins and progress.

Specification documents

Requirements are set by the specification documents. This site links to the specification instead of reproducing it. Where the explanation and the specification differ, the specification prevails. Links to the specification documents will be added at establishment.

Markers such as [Part 2 8.1] on this site refer to clauses of the specification. When the specification documents will be published is in Development status and upcoming releases.

Operating guidelines

Judgment criteria are set by an operating guideline separate from the standard. Tier elements follow the standard; operational elements are set by the operating guideline.

The threshold profile is part of the operating guideline. Organizations · institutions · domains can build operating guidelines independently. There is therefore more than one guideline publisher.

Whoever judges and publishes a tier must explicitly provide the operating guideline applied and make it publicly accessible to anyone. A tier is stated together with the operating guideline’s identifier · version. A result without an applied operating guideline is not given a tier and is recorded as “Not judged: no operating guideline applied”.

The operating guideline provided with the standard is released at establishment (expected December 2026). The structure of an operating guideline and the threshold profile items are in Building an operating guideline.

The standard and the vocabulary

The names · value ranges · obligation levels of metadata elements are given in the “AIRD vocabulary (v0.10.5)”. The deliberation draft and the vocabulary agree. The deliberation draft focuses on required elements; the vocabulary gives the complete list, including external vocabularies.

This site uses the 23 required discovery-layer metadata elements of the vocabulary’s demo profile. The list of elements is in Metadata elements.

Site menus and parts

Types of references

External documents cited by the specification are divided into normative references, which are part of the conformance obligations, and a bibliography, which aids understanding. Both lists are in the specification documents.

Preparing data › Procedure

Overview

Type · ProcedureReading time · about 4 minData providers

This is a map of the procedure that checks the data you hold and, through three stages, brings it to a state AI can use. Data judged Quality-Ready or higher under an operating guideline is distributed as a pack; before that, you publish the manifest.

Scope — For tabular (STRUCT) and time series (TSERIES) data, this guide goes down to concrete action items. Text (TEXT) · image (IMAGE) · instruction–response pair (PT) data follow the same procedure. Items specific to each type will be added in later versions.

Stages and outputs

Data starts in a raw state, and its readiness state rises through three stages. Each stage ends at a decision gate. AI-ready data means a state of Quality-Ready or higher. [Part 1 3.1 · 5.1]

A new manifest is issued for each version and points to the previous version. The tier judgment procedure is in Judgment procedure; pack contents and file formats are in Packaging and distribution.

Working principles

1. Follow the stage order. Make the data discoverable before you measure its quality.
2. Complete what is not met. If data does not pass a decision gate, complete the unmet items and check again. Not meeting a gate does not mean rejection.
3. Keep the original. Cleaned data and purpose-specific outputs are kept alongside the original.
4. You can split the work by stage. Stage 1 alone reduces the items an agent must guess.

What you can do now

Details are in What is AI-ready data — What you can do now.

Five-question self-check of your current state

For data that is already open, the five-question self-check decides your starting stage. Depending on your answers, you start at writing the manifest (stage 1) or measuring quality (stage 2).

Judgment rule — the first “No” decides the starting point. An answer to a later question counts only after the conditions of earlier questions are met. Even if a later question is “Yes,” the starting point follows the first “No.”

The numbers in the “Choosing the starting point” table are the numbers of the five questions in the self-check above.

Choosing the starting point

The number of “No” answers does not indicate errors by the data provider. Existing portal registration screens had no input field for some of the 23 metadata elements and did not support delivery in machine-readable formats.

Materials to gather before you start

Before starting, the data provider gathers the following materials. If a material is missing, start with the metadata elements you can fill in.

Before and after preparation

Stage 1 does not change data values. Stage 1 adds information that describes the meaning, format and source of the values. Fixing defects in stage 2 can change values. The data provider records what was fixed, how and why in the processing history. Stage-by-stage results for an example file are in Walkthrough with example data.

Labels used on this site

Recommended items are not requirements of the draft standard, so you can decide differently to suit your organization.

The mapping between these labels and shall · should · may in the specification text is not yet final.

Preparing data › Procedure

Checking your data

Type · ProcedureReading time · about 4 minData providers

Before starting stage 1, check the data type, character encoding and presence of personal information in the files you hold.

Determining the data type

The data provider decides the data type first. The measured items and metadata elements depend on the type. [Part 1 5.6 Table 5-5] Required

Data of multiple types Required

The data provider picks one representative type for the overall label. If a file or component falls under several types, apply the check items of each type to each component. Choosing a representative type does not mean skipping the check items of the other types. [Part 2 8.2]

Time series is a special case of tabular data. Apply the tabular check items to time series data as they are, and also record the reference time · measurement interval · unit. Recommended

What depends on the type

The data type determines the following three things.

Required formal indicators define “how much must be measured to be complete.” Minimum measurable indicators define “what must be measured at the very least.” The rules that determine Diagnostic Maturity are in Judgment procedure; the definition of each indicator is in Quality indicators. Action items for text · image · instruction–response pair data will be included in a later version after they are checked against the text of the standard.

Without reference data to compare against, accuracy cannot be measured. The diagnostic tool marks this state as “accuracy not measured.” “Accuracy not measured” is a measurement status, not a penalty. If an accuracy indicator is a required formal indicator for that type, Diagnostic Maturity does not reach DM-2. In that case the move to the next readiness state (transition), that is, the transition to Quality-Ready, does not take place. [Part 2 7.4 · 8.1] Required

Checking character encoding

The reference encoding is UTF-8. CP949 · EUC-KR are not the reference encoding and are judged non-conforming. Encoding is measured by the minimum measurable indicator D7-01 (Encoding consistency). [Part 2 Annex A.4] The data provider can check and fix the encoding directly.

1. Check with an editor. Open the file in a text editor and read the encoding indicator (status bar or the “Save As” dialog). The result is the name of the encoding.
2. Check with a command. In a terminal, run file -i <file> (Linux) or file -I <file> (macOS). If the result contains charset=utf-8, the file is UTF-8. charset=us-ascii means the file contains only English letters and digits and can be read as UTF-8.
3. Convert if it is not UTF-8. Save it again as UTF-8 in the editor, or run iconv -f CP949 -t UTF-8 <source> > <converted>. The result is a UTF-8 file.
4. Record the result. Write down the encoding you checked together with the data type.

If your organization specifies a different encoding rule, the data provider follows it and records the applied rule in the manifest. Whether a byte order mark (BOM) is present and differences in line-break characters are not measured, so no action is needed.

Data that contains personal information

References: “Pseudonymized Information Processing Guidelines” (revised March 2026) of the Personal Information Protection Commission (PIPC, Korea’s data protection authority). Public institutions also check the “Public AX Privacy Guide” (July 2026). The latest versions are in the PIPC resource library.

A dataset that contains personal information must state whether it has been de-identified. [Part 3 Annex A.1] Required The level, method and date of processing are recorded in stage 2.

This procedure covers public provision. Data with restricted release is not covered by this procedure. Whether such data can be prepared in a controlled environment is judged separately by the organization.

Preparing data › Procedure

Writing the manifest (stage 1)

Type · ProcedureReading time · about 7 minData providers

In stage 1 you fill in the 23 discovery-layer metadata elements and the column schema to create the manifest manifest.json (JSON-LD). The manifest is the basis on which the data reaches the Discoverable state.

Stage overview

The goal of stage 1 is to record, in machine-readable form, what the data is and where it is. The data provider can complete stage 1 using the guidance in the current version alone. For persistent identifiers, use the interim rules in Choosing persistent identifiers.

A full manifest example is in Manifest example, and the structure of the pack that contains the manifest is in Packaging and distribution. A new manifest is published for each version and points to the previous version.

Stage 1 does not change data values. The data provider keeps the content of the data and adds descriptions. [Part 1 5.2]

Who does what

The data provider can calculate checksums directly: run sha256sum <file> on Linux or shasum -a 256 <file> on macOS. The diagnostic tool also calculates checksums from the files. The data provider can write the manifest directly or revise a draft generated by the diagnostic tool.

At decision gate ①, the data provider and the diagnostic tool check whether the required metadata elements are met. [Part 4 6.4]^{follow-on part} Elements not met are completed and checked again.

Judgments stage 1 supports

The work in stage 1 supports finding data, accessing it, and checking the conditions of use. The identifier lets other resources refer to the data. Column descriptions convey the meaning of values. The rights statement is the basis for judging whether the data may be used. The data provider can complete stage 1 without knowing the FAIR principles.

Elements to check

There are 23 metadata elements (19 for the dataset + 4 for each distribution). This site uses the 23 elements of the AIRD vocabulary v0.10.5 demo profile. The deliberation draft requires 19 (15 for the dataset + 4 for each distribution). The demo profile adds 4: dataset structure type, theme, landing page, and maintaining department. Theme and landing page are required for public-sector data and recommended otherwise. [Part 3 Annex A.1]

The 4 distribution elements apply to each distributed file. With 3 files there are 19 + 4 × 3 = 31 values. The full list and judgment criteria are in Metadata elements.

The 6 elements most often missing or recorded incorrectly are:

The persistent identifier and the access URL are different. The persistent identifier identifies the dataset. The access URL is where the actual data is accessed. The data provider does not fill both elements with the same value. If the organization has no identifier issuance policy, apply the interim rules in Choosing persistent identifiers.

If there are several files, create several distributions. When tables, images, and videos are provided together, record the access URL, media type, file format, and checksum separately for each distribution.

A column schema is required for tabular data. The column schema is either written directly into the manifest or kept as a separate document that the manifest points to by address and hash. How to write it is in the “Writing the column schema” section, and the judgment criteria are in Metadata elements.

Writing the column schema

The column schema (csvw:tableSchema) is a table that records the name, data type, and meaning of each column. Without a column schema, the meaning of data values is hard to determine.

Why it is needed

Column descriptions in the source database can be lost when the data is exported to CSV. If only the column names remain, the meaning of a name like mkt_nm is hard to determine. Stage 2 quality measurement also uses the column schema as input.

Elements per column

Recommended elements are inputs to stage 2 measurement. If the column schema lacks the required flag, value range, inter-field relationships, derivation rules, or code list and its edition, the diagnostic tool cannot measure D1-01 · D5-02 · D2-01 · D2-03 · D2-02 in stage 2. Indicators that could not be measured are recorded in the diagnostic report together with the reason they were not measured (Reading the diagnostic report (stage 2)).

Empty value notation is not a requirement of the standard, but it often causes problems in practice. If blanks, -, N/A, and 0 are mixed, you cannot tell whether 0 is a real value or an empty one.

Choosing file formats Recommended

The reference encoding is UTF-8. How to check the encoding is in Checking your data.

Formats to avoid

• Providing only formats that open in one specific program
• Tables with merged cells, subtotal rows, or multi-line headers
• Files that split several tables across sheets without explanation

Image labels (ground truth), training and validation splits, the correspondence within instruction–response pairs, and document chunking units are not stage 1 requirements. Photos without labels can also become “Discoverable” data.

Examples and common errors

Title: Data
Description: Related data.
Update frequency: as needed
License: Includes third-party rights - N
Media type: text
Column schema: (none)

Title: Business registrations in ○○ City, 2025
Description: Industry, location, and business status of businesses registered in ○○ City.
      As of 2025-12-31, 12,480 records.
Keywords: business, permits, industry, ○○ City
Data type: STRUCT
Update frequency: http://publications.europa.eu/resource/authority/frequency/IRREG
License: KOGL-1  (vocabulary kr-license value)
Rights: KOGL Type 1. Free to use with source attribution. (notice)
Media type: text/csv
Access rights: PUBLIC
Column schema: name, data type, description, required flag, and code values recorded for all 14 columns

Common errors

The three most common errors in stage 1 are listed below.

Preparing data › Procedure

Choosing persistent identifiers

Type · ProcedureReading time · about 3 minData providers

How to give a dataset a persistent identifier that does not change. Check your organization’s identifier policy first; if there is none, follow the interim rules.

What the standard requires — a persistent identifier in URI form. A resolvable URI is the principle. [Part 3 Annex A.1] Required

If your organization (public institution, company, or association) has an issuance policy, that policy takes precedence. This page gives interim rules to use until a policy is in place. Recommended

Deciding on a persistent identifier

Never leave the identifier blank. Without an identifier, the dataset does not pass the stage 1 check.

Construction rules

An identifier has two parts: namespace + dataset name.

https://data.<org-domain>/id/dataset/<dataset-name>
└─────────── namespace ───────────┘└─ dataset name ─┘
   fixed area the organization controls   never changed once set

Key rule: do not put anything that changes into the identifier. The data provider records version, reference time, and format in separate elements: version in dcat:version, reference time in the temporal coverage, and format in dct:format.

Keeping identifiers stable once assigned

The purpose of an identifier is not to change. Changing an identifier breaks every reference that pointed to the data.

Points to confirm with the responsible department

When requesting a policy, the data provider passes on the following points.

The rules on this page are interim rules. Once an organizational policy or higher-level guideline is in place, that policy or guideline takes precedence. Identifiers already assigned are kept.

Preparing data › Procedure

Measuring quality (stage 2)

Type · ProcedureReading time · about 4 minData providers

In stage 2, quality measurement, the data provider prepares the material needed for measurement, and the diagnostic tool measures the indicators and produces the diagnostic report.

GoalHave the material needed for measurement ready, and check the scores and Diagnostic Maturity (DM) in the diagnostic report produced by the diagnostic tool.

What happens in this stage

The diagnostic tool computes indicator scores and Diagnostic Maturity even without an operating guideline. How many indicators are measured depends on the data type and the material the data provider has. For the tabular (STRUCT) example file, the file alone allows 6 of the 13 required indicators to be measured. With the stage 1 manifest filled in, 7 of the 13 are measured. The remaining indicators need external material (for example, code tables or a reference time). Results by step are in Walkthrough with example data.

The quality tier is judged with the threshold profile of an operating guideline.

The goal of stage 2 is to measure the quality of the data and leave the evidence for it.

The release version of the diagnostic tool is in development. The release plan is in Development status and upcoming releases.

The data provider does not apply the measurement formulas to calculate scores. The data provider prepares the material needed for measurement. The data provider checks the diagnostic report for low-scoring indicators and reasons for not measuring. The data provider records fixable values and unfixable limitations separately.

In stage 2, the data provider fills in missing values or corrects wrong values. Data values can therefore change in stage 2.

Seven dimensions Required

The standard measures quality in seven dimensions: Completeness (D1) · Consistency (D2) · Accuracy (D3) · Timeliness (D4) · Validity (D5) · Uniqueness (D6) · Machine readability (D7). [Part 2 5.2]

Check machine readability (D7) first. If the file cannot be opened, the other six dimensions cannot be measured. [Part 2 7.3]

The definitions, measurement formulas and preconditions of the 16 indicators are in Quality indicators. How to fix low scores is in Fixing defects (stage 2).

Scores versus tiers

Scores and the quality tier are different values. The diagnostic tool calculates a score for each indicator and records a score for each of the seven dimensions in the diagnostic report.

The quality tier is judged with the threshold profile of an operating guideline. The same scores can yield different tiers under different operating guidelines. A diagnostic report with no operating guideline applied records the quality tier as “not judged: no operating guideline applied.”

Tier judgment starts from the minimum dimension score (the lowest of the seven dimension scores). If one dimension scores low, that dimension determines the candidate tier even when the other dimensions score high. Averages are not used for tier judgment.

The example threshold profile in Part 2 Appendix I has the status EXAMPLE. It is used only for provisional calculations and tool development, not for tier judgment.

Results measured without an operating guideline are still valid baseline data. The data provider keeps the scores and the reasons for not measuring. When an operating guideline is applied, indicators whose measurement method changes with the guideline’s values (for example, the dummy-value patterns of D5-03) are measured again. Measuring again means issuing a new diagnostic report.

The operating guideline provided with the standard will be published when the standard is established (expected December 2026). Organizations and institutions can build their own operating guideline and judge tiers. How to build an operating guideline is in Building an operating guideline, and the steps of tier judgment are in Judgment procedure. Tier judgment is not a procedure the data provider performs.

Diagnostic Maturity Required

The diagnostic report records Diagnostic Maturity separately from the scores. Diagnostic Maturity is how far the required indicators have been measured. The diagnostic tool applies the decision table from the top and judges Diagnostic Maturity by the first row that is met. [Part 2 Annex B.5 Table B.4]

The Diagnostic Maturity reached without an operating guideline differs by data type. Tabular (STRUCT) and time series (TSERIES) data reach DM-0 (provisional). The diagnostic tool provisionally measures D5-03 (Statistical plausibility), a minimum measurable indicator (MMI), with the example patterns in Part 2 Appendix I and records the evaluation status as PROVISIONAL. Text (TEXT) data reaches DM-2 when all five required formal indicators are measured. Instruction–response pairs (PT) and images (IMAGE) are at DM-0. Measuring D3-02 (Label accuracy) for these two types requires expert review results. DM-1 is not judged. The lower bound of evaluation coverage for DM-1 is set by the operating guideline. [Part 2 5.1 · Annex A.4.1 · Appendix I]

The table by type is in Reading the diagnostic report (stage 2), and the row-by-row conditions of the decision table are in Judgment procedure.

If a file is empty (0 records) or damaged and cannot be opened, the diagnostic tool records Diagnostic Maturity and the tier as “not judged.”

The five indicator applicability values and reasons for not measuring

The diagnostic report records an applicability value for each indicator. What the data provider does depends on this value. [Part 2 Annex B.2]

NOT_APPLICABLE is not a deficiency. There is nothing to fix.

If even one indicator is PARTIALLY_APPLIED, Diagnostic Maturity cannot be DM-2. If Diagnostic Maturity is not DM-2, the quality tier is “not judged: below DM-2” however high the scores are. Scores and Diagnostic Maturity do not substitute for each other. [Part 2 8.1]

The full list of status values and reasons for “not judged” is in Status and judgment values.

Order for reading the diagnostic report

The six values in the diagnostic report and how to read each one are in Reading the diagnostic report (stage 2).

Preparing data › Procedure

Fixing defects (stage 2)

Type · ProcedureReading time · about 4 minData providers

This page shows how to fix low-scoring indicators in stage 2 and how to record limitations that cannot be fixed. Keep the fixed file (the cleaned version) separate from the original.

GoalFix the values behind low-scoring indicators and record the limitations that cannot be fixed. Keep the original file, the cleaned version and the diagnostic report separate.

Fixing low-scoring indicators Recommended

The data provider’s cleaning work falls into three categories.

Priority actions by dimension

Recording limitations that cannot be fixed Required

The data provider also records limitations that cannot be fixed. Users read the recorded limitations to decide whether to use the data and how far. Users cannot see constraints that are not recorded.

Recording a limitation is not a judgment of a defect. It is information users need to judge the scope of use.

Managing the original, the cleaned version and the diagnostic report Required

The cleaned version keeps the dataset’s persistent identifier. A cleaned version is not a different dataset. The data provider keeps the original file, the cleaned version, the release version, the manifest, the diagnostic report and the purpose-specific operation files distinct from one another.

Keep the original file. Do not overwrite the original file with the cleaned version.

When an existing diagnostic report can be reused

Reuse an existing diagnostic report only when all four of the following are the same. If any one changes, produce a new diagnostic report.

• The version measured
• The measurement rules
• The operating guideline applied
• The validity of the measurement time

If the data was cleaned or measured again, produce a new diagnostic report. The manifest points to the new diagnostic report by its address and checksum.

Items to record in the processing history [Part 4 12]^{Follow-on part}

Without a processing history, users cannot verify the cleaning results.

Common errors

The three most common errors in stage 2 are listed below.

• Judging the tier from the average score (tier judgment starts from the minimum dimension score)
• Publishing a tier calculated with values that are not an operating guideline (for example, the example threshold profile)
• Not updating the diagnostic report after cleaning

Why it matters

The work in stage 2 creates the basis on which users judge whether the data can be reused. The data provider leaves limitations and a processing history along with the quality scores. Without the state of the values and the reasons for changes, users cannot judge the data’s constraints.

Quality scores and tiers are requirements the standard adds for AI use. The international FAIR principles do not require quality scores or tiers.

Preparing data › Procedure

Reading the diagnostic report (stage 2)

Type · ProcedureReading time · about 4 minData providers

This page shows how to tell measured indicators from indicators that were not measured in the diagnostic report produced by the diagnostic tool, and how to choose the next action for each indicator that was not measured.

GoalSeparate what was measured from what was not measured in the diagnostic report, and find why each indicator was not measured and what material it needs.

This site does not accept files for diagnosis. The release version of the diagnostic tool is in development; the release plan is in Development status and upcoming releases. Actual measurement results are in Public data examples and Walkthrough with example data.

Structure of the diagnostic report

The diagnostic report records six values separately. The data provider reads them in order, from the top.

Scores and Diagnostic Maturity do not substitute for each other. If Diagnostic Maturity is not DM-2, the quality tier is “not judged: below DM-2” however high the scores are. The Diagnostic Maturity decision table is in Judgment procedure. The meaning of each indicator applicability value and what the data provider does for it are in Measuring quality (stage 2).

Diagnostic Maturity by data type

The Diagnostic Maturity reached without an operating guideline differs by data type. The indicators that block Diagnostic Maturity and the material the data provider must prepare also differ by type. The table below shows the results of measuring the cleaned versions of the public data examples.

The Diagnostic Maturity of the tabular (STRUCT) and time series (TSERIES) examples is a provisional value, with D5-03 measured using the example patterns in Part 2 Appendix I. Results measured with the example patterns are being checked against the standard text.

DM-1 does not appear in the four examples. DM-1 is judged by whether evaluation coverage is at or above the lower bound in the operating guideline. Without an operating guideline, DM-1 is not judged. A result that measured every minimum measurable indicator (MMI) but did not reach DM-2 is therefore DM-0.

The document (TEXT) example reaches DM-2 even without an operating guideline. D5-03 does not apply to the document type. The diagnostic tool measured all five required formal indicators for the document type. With an operating guideline applied, the quality tier of the document example can be judged.

The row-by-row conditions of the decision table are in Judgment procedure.

Quality tier and readiness state

The quality tier of all four examples is “not judged: no operating guideline applied.” This includes the document example, whose Diagnostic Maturity is DM-2. The quality tier is judged with the threshold profile of an operating guideline. This site does not assign tiers with the example threshold profile (status EXAMPLE).

The operating guideline provided with the standard will be published when the standard is established (expected December 2026). Organizations and institutions can build their own operating guideline and judge quality tiers. Whoever judges a tier records the operating guideline’s identifier and version with the tier and publishes the operating guideline it applied. How to build an operating guideline is in Building an operating guideline.

The readiness state of all four examples stays at Discoverable. A transition to Quality-Ready requires all three of the following conditions.

• Diagnostic Maturity DM-2
• Quality tier Tier 1 or higher
• An operating guideline applied

Even an example with a manifest, a diagnostic report, a processing history and purpose-specific operation files gets a quality tier only when an operating guideline is applied. The Quality-Ready transition can be judged only once there is a quality tier. [Part 1 5.1]

Sorting indicators that were not measured

The data provider sorts the indicators that were not measured into three groups by the material they need.

Preparing data › Procedure

Packaging and distribution

Type · ProcedureReading time · about 4 minData providers · Tool developers

This page covers the pack, the unit for distributing prepared data: its constituent files, the references between those files, and how to verify a pack before distribution.

A pack is a distribution unit [Part 1 3.15 · 5.5 · Part 3 5.1]. The operating guideline sets the detailed structure of a pack (file layout · bundle format). The operating guideline provided with the standard will be published when the standard is established (expected December 2026). All file names and addresses on this page are Example.

Basic principles

1. The dataset is the entity; the manifest is the document that describes the dataset. The manifest’s identifier differs from the dataset’s identifier. [Part 3 5.1]
2. The manifest points to the diagnostic report and the operation files by address and SHA-256 hash. [Part 3 5.2]
3. The diagnostic report is the source of record for quality judgment results. The quality elements in the manifest are a summary of the diagnostic report. [Part 3 5.2 · Part 2 9]
4. Data files are not placed in the pack. The distribution in the manifest points to the data files by address and hash. [Part 3 5.1]
5. Layers (discovery · understanding · operation) are divided by the function of the metadata, not by file format or location. [Part 3 5.1]

Files required by readiness state

The metadata scope of each state includes the scope of the preceding state. [Part 3 5.3]

In the Discoverable state, the manifest is published. A pack is a distribution unit created from Quality-Ready onward. The details of the decision gate judgment procedure are covered in Part 4^{follow-on part}.

Source and summary

The manifest points to the diagnostic report by address and hash and records a summary of some of the report’s values in the understanding layer. Part 2 Table 9-2 defines the items to summarize. If a summary value differs from the report value, the report value takes precedence and the mismatch is treated as a verification failure. [Part 3 5.2 · Part 2 9.2]

The manifest properties are the quality assessment (aird:QualityAssessment) elements of AIRD vocabulary v0.10.5. The mapping between Part 2 Table 9-2 and these properties is not in the body of the deliberation draft. The tier in the example values is the result of applying a fictional organization’s operating guideline (an OFFICIAL threshold profile).

Verification before distribution

Record a SHA-256 hash for every file that the pack contains or references, whether or not the file is placed in the pack. If even one hash does not match, verification fails. A hash mismatch is grounds for suspension (Stale). There are five verification items. [Part 3 9.2 · Table 9-3]

Passing verification does not by itself trigger a transition to Quality-Ready. The transition requires passing decision gate G2. [Part 3 9.3]

Distribution and publication

1. Keep the data files at their original distribution point (Korea Public Data Portal (data.go.kr) · internal repository). The pack points to the data files by address and hash.
2. Place the manifest and the pack files at a public address where users and agents can download them. For public-sector data, record the portal’s dataset detail page address in dcat:landingPage.
3. When you fix or re-measure the data, publish the manifest as a new version. Do not change the files of earlier versions.
4. The bundle format and file layout of the pack follow the operating guideline you apply.
5. Publication to catalogs · registries, discovery, and exchange are covered in Part 5^{follow-on part}.

The four Public data examples are materials that explain measurement results. They were not distributed in the pack structure on this page. Because no operating guideline was applied, their readiness state is Discoverable. A full manifest example is in Manifest example.

Preparing data › Examples

Walkthrough with example data

Type · ProcedureReading time · about 10 minData providers

This page applies the preparation stages one by one to a single example file (20 business registration records) and shows what is recorded at each stage and how the measurement results change.

Example The example file contains fictional data for illustration. It does not refer to any real organization or data. The figures on this page were obtained by measuring the example file with this site’s measurement engine (test version). To reproduce the results, use the same input file · tool version · measurement rules.

https://data.example.go.kr/id/dataset/biz-registry

rows 20 · columns 8 · encoding UTF-8

1. Metadata elements (23)   met 1 / 23
2. Column schema            none: a draft is generated from headers and values
3. Quality measurement
     D1-02  Required metadata completeness   0.0435
     D5-01  Format validity                  1.0000
     D5-03  Statistical plausibility         1.0000 (provisional)
     D6-01  Uniqueness                       1.0000
     D7-01  Encoding consistency             1.0000
     D7-02  Technical validity               1.0000

generatedAt   2026-10-05T...
datasetFile   example.csv
fileChecksum  SHA-256 7ad8add2...
dataType      STRUCT
recordCount   20
indicators    D1-01 1.0 (required) · D5-01 1.0 (required) · D5-03 1.0 (required · provisional) · ...
notMeasured   D2-02 (required): compare against actual values of the master code table
              D3-01 (required): an authoritative reference is needed
formalAssessmentCoverage  0.5385
diagnosticMaturity        DM-0
assessmentStatus          PROVISIONAL
thresholdProfile          example profile (EXAMPLE)
note   Provisional diagnostic report produced with an example profile. Do not use for official disclosure or cross-organization comparison.

Remaining work and why

The example file has completed stage 1 metadata and stage 2 measurement. Diagnostic Maturity DM-2 · the quality tier · purpose-specific operation files remain. The data provider records the reason for each remaining item by category, and does not mix unmet requirements in the data itself with the absence of an operating guideline. The list of reasons is in Status and judgment values.

Follow-up actions for the data provider

The follow-up action list that the measurement engine produced with the diagnostic report is as follows.

1. Obtain the industry classification · legal-district code tables. Result: D2-02 (Referential integrity) can be measured.
2. Obtain code–name mapping materials. Result: D3-01 (Standard name conformance) can be measured.
3. Compile the reference date and update history. Result: D4-01 (Currency) can be measured.
4. Record limitations that cannot be fixed. Example: “closedFlag may be updated later than the actual closure because closure reports are filed late.” Result: recorded limitations in the understanding layer of the manifest.
5. Apply an operating guideline and re-measure the indicators it requires. Needed: the operating guideline provided with the standard (published when the standard is established, expected December 2026) or an operating guideline built and published by your organization. Result: a new diagnostic report and a tier judged under that operating guideline.

Preparing data › Examples

Public data examples

Type · ProcedureReading time · about 6 minData providers

Measurements of four real public datasets show how stage 1 documentation increases the number of indicators that can be measured, and how results differ by data type.

Example Measurements were taken on 2026-10-06. Quality tiers were not judged because no operating guideline was applied (not judged: no operating guideline applied).

Four examples

Each example pairs one data type with one representative use purpose and is built from real public data. The types are STRUCT (tabular) · TSERIES (time series) · TEXT (documents) · PT (instruction · response pairs). The purposes are KG (knowledge graph) · Stats (statistical analysis) · RAG (retrieval-augmented generation) · FineTuning (fine-tuning).

Measured indicators before and after stage 1

Each example was measured three times.

1. The original data was measured before stage 1.
2. The same original data was measured after stage 1. In stage 1, the data provider recorded required fields · formats · value ranges · inter-field relations · derivation rules · code lists in the column schema (csvw:tableSchema).
3. The cleaned version, with defects fixed, was measured.

No data values changed between ① and ②. Yet the number of measured indicators increased, because the definitions recorded in stage 1 are the input to stage 2 measurement. Diagnostic Maturity (DM) by type is described in Reading the diagnostic report (stage 2).

Defects revealed by measurement

Defects can remain even when an indicator scores 1.0. D6-01 by identifier does not find rows that differ only in identifier but have the same content. The data provider handles such defects in preparation for a purpose (stage 3).

Catalog observation case

This is the result of observing the catalog metadata of one public dataset in the industry domain. The agency name is not shown. The subject is industrial complex company information (379 rows · 9 columns · CSV).

The basis for observation is the 19 required metadata elements of the deliberation draft (15 for the dataset + 4 for the distribution). The remaining 4 of the 23 in the vocabulary demo profile were added after the observation and were not classified.

If the portal provides column structure information, a draft column schema can be made without the file. In this case, drafts for the 9 columns were made from the observed column names · data types · counts of distinct values. The data provider then adds a description for each column.

The observation result also flags items that need a personal information check. In this case, the phone number column was flagged as an item whose disclosure scope must be confirmed with the responsible department.

Even for a dataset with catalog metadata on the portal, 10 elements must be newly written. Data that is already registered on the portal still needs separate preparation for AI use.

The catalog observation case covers only catalog metadata observation and the discovery layer check. Once the file is obtained, a diagnostic report is added.

For agents

What agents read

Type · ExplanationReading time · about 5 minAgent and AI developers (data users)Tool developers

This page maps the information an agent needs for each of the four judgments it makes before using data to the clauses and metadata elements of the standard.

Where the tiers agents read come from. The quality tier written in a manifest is judged not by the standard but by the threshold profile of an operating guideline. Whoever judged the tier records the operating guideline’s identifier · version along with the tier and publishes that operating guideline. When an agent reads a tier, it also reads which operating guideline was used to judge it. The conditions for using a tier as evidence are in Fields and handling by judgment.

The standard is not limited to public data. It covers all data published or provided by public institutions · enterprises · non-profit organizations. Its goal is to let AI agents access data, understand it, trust it, and judge whether they may use it. The design started from observations of public data. Agents judge from structured fields and measurement evidence, not from a single score. The “How the standard covers each judgment” table is based on tabular data (STRUCT). Documents · images · instruction · response pairs (PT) need different information for these judgments.

How the standard covers each judgment

Required required by the standard · Partial conditionally required · optional · recommended, or measured but not exposed as a field · Gap not in required elements or indicators (whether optional elements cover it is under review)

Of the 24 pieces of information needed: required 9 · partial 10 · gap 5

Fitness — fit to the question

Judgment question · Does it fit my question?

Reliability — grounds for trust

Judgment question · Can it be trusted?

Joinability — ability to join

Judgment question · Can it be joined with other data?

Usability — conditions of use

Judgment question · May it be used?

Proposal for exposing verified facts

Of the 7 facts in the “Standard status by fact” table, the standard already measures 5. The measurement results are recorded only in the diagnostic report. The manifest records only dimension scores. This site proposes a way to expose the measurement results in the manifest as facts.

Proposed exposure method

Summary of the coverage table

• Joinability has no gaps. The standard requires checking against the actual values of the code list. What remains is exposing the per-column check results as metadata fields.
• The 5 gaps are in fitness · reliability · usability. Temporal and spatial coverage are not required elements. Whether AI training is permitted appears only in an optional element. Agents use both kinds of information as conditions when selecting data.
• Reliability indicators are file-based. The 16 quality indicators target files. Availability and spec conformance of data provided through an API do not appear as facts recorded with the data.

For agents

Fields and handling by judgment

Type · ProcedureReading time · about 4 minAgent and AI developers (data users)Tool developers

This page shows in pseudocode which fields an agent reads from the manifest for each judgment and how it judges them. The fields and judgment values follow the standard; the judgment rules are this site’s recommendations.

Reading principle — do not replace a missing field with a guessed value. If there is no evidence, the agent states “no evidence” in its result. When a human judgment is needed, the agent hands the case over to human review. The standard aims to let agents judge without guessing, and the judgment rules on this page follow the same principle.

Fitness — fit to the question

Judgment question · Does it fit my question?

Fields read dct:description · csvw:tableSchema · dct:type · rai:dataLimitations · rai:dataBiases

schema = m.get("csvw:tableSchema")
if schema is None:
    return no_evidence("column meanings are not recorded")   # do not guess from column names
for col in columns_used_by_question:
    if not column(schema, col).get("dc:description"):
        return no_evidence(f"meaning of {col} is not recorded")
# rai:dataLimitations · rai:dataBiases are lists of human-written sentences.
# Do not filter them by string matching; present them as-is with the answer.
caveats = m.get("rai:dataLimitations", []) + m.get("rai:dataBiases", [])
return fit(caveats=caveats)

When the field is missing If the column schema (csvw:tableSchema) has no column description, the agent does not guess the meaning from the column name. It states “column meaning not recorded” in the answer.

Reliability — grounds for trust

Judgment question · Can it be trusted?

Fields read aird:lifecycleStatus · dcat:distribution[].spdx:checksum · dct:modified · dct:accrualPeriodicity · aird:diagnosticMaturity · aird:qualityTier · aird:thresholdProfile · aird:diagnosticReport

if m["aird:lifecycleStatus"] == "Stale":
    return exclude("validity suspended")
d = distribution(m, downloaded_url)               # each distribution has its own checksum
if sha256(downloaded_file) != d["spdx:checksum"]["spdx:checksumValue"]:
    return exclude("checksum mismatch — not the file the manifest points to")
dm = m.get("aird:diagnosticMaturity")
if dm is None:
    # null has two meanings. Tell them apart by the diagnosis status in the diagnostic report.
    if diagnosis_status(m) in ("SCHEMA_ONLY", "FILE_BROKEN"):
        return exclude("file could not enter diagnosis")
    return caution("Diagnostic Maturity not established — insufficient quality evidence")   # do not read as 0
# A tier is judged by the threshold profile of an operating guideline. Check all four conditions.
profile = threshold_profile(m.get("aird:thresholdProfile"))   # None if absent
guideline = operating_guideline(m)                 # identifier · version · URL — None if absent
tier_evidence = (
    dm == "DM-2"                                              # (a) Diagnostic Maturity DM-2
    and profile is not None
    and profile["status"] == "OFFICIAL"                        # (b) EXAMPLE is not tier evidence
    and evaluation_status(m) != "PROVISIONAL"                 # (c) not a provisional evaluation
    and guideline is not None and guideline.identifier and guideline.version
    and accessible(guideline.url)                             # (d) the published operating guideline can be checked
)
if not tier_evidence:
    return caution(f"Diagnostic Maturity {dm} · no tier evidence", score=m.get("aird:qualityIndexMin"))
return trusted(tier=m.get("aird:qualityTier"),
               guideline=(guideline.identifier, guideline.version),
               profile=(profile["profileId"], profile["version"]))

When the field is missing If Diagnostic Maturity (DM) is missing, the agent treats it as “insufficient measurement evidence”, not as “low”. The agent reads a tier as evidence only when all four of the following conditions are met.

If any one condition is not met, the agent sets the result to “caution (… no tier evidence)” and reads the score only for reference. The structure and publication requirements of operating guidelines are in Building an operating guideline.

Joinability — ability to join

Judgment question · Can it be joined with other data?

Fields read dct:identifier · csvw:tableSchema.primaryKey · csvw:tableSchema.columns[].dc:description · D2-02 result in the diagnostic report

a, b = join_columns_of_the_two_datasets
# The manifest has no dedicated field for a column’s code system (today it appears only in the column description text).
# Value-level check results are in the diagnostic report and are not exposed in the manifest — the verified-facts proposal fills this gap.
ra, rb = d2_02_result(report(a)), d2_02_result(report(b))   # None if the report cannot be read
if ra is None or rb is None:
    return candidate("value-level check results unavailable — do not join just because names match")
if ra.applicability != "APPLIED" or rb.applicability != "APPLIED":
    return candidate("values were not checked against a code list")
if ra.code_list != rb.code_list:
    return exclude("checked against different code lists")
return join(evidence=[ra.match_rate, rb.match_rate, ra.code_list_version])

When the field is missing If there is no value-level check result from D2-02 (Referential integrity), the agent keeps the join only as a “candidate”. It states in the result that there is no evidence for the join.

Usability — conditions of use

Judgment question · May it be used?

Fields read dct:license · dct:rights · dct:accessRights · dpv:hasPersonalData · aird:deidentificationLevel · odrl:hasPolicy

if m["dct:accessRights"] != "PUBLIC":
    return human_review("access-restricted data")
lic = m["dct:license"]
if lic not in KR_LICENSE:                      # value list kr-license in the vocabulary
    return human_review("license outside the value list — machines cannot read its conditions")
conditions = license_conditions(lic)
# No required element covers AI training permission — read only the optional odrl:hasPolicy; do not guess from dct:rights text
policy = m.get("odrl:hasPolicy")
training_allowed = permitted_actions(policy) if policy else "unconfirmed"
return usable(conditions=conditions, training_allowed=training_allowed)

When the field is missing Whether AI training is permitted is not a required element of the standard. It can be expressed in the optional usage policy (odrl:hasPolicy). If there is no usage policy, the agent does not guess from the rights (dct:rights) text and leaves it as “unconfirmed”.

Handling information the standard does not define

The following four kinds of information are not required elements of the standard. This site recommends the following handling on the agent side.

Automated-use eligibility conditions

Part 5^{follow-on part} defines 8 data-side conditions for automated-use eligibility. The pseudocode below covers all 8 conditions. Conditions for which the standard has not yet defined fields (2 · 3 · 4) are marked “under review”. Interface · exchange conformance of the providing system is handled at a separate level.

# Automated-use eligibility — 8 data-side conditions [Part 5 Table 9-2]follow-on part
# Only conditions whose fields the standard defines are written as code. Conditions with unconfirmed fields are marked.
def eligible_for_automated_use(m, file, url):
    d = distribution(m, url)
    return all([
        m["aird:lifecycleStatus"] == "Purpose-Ready",           # 1 Purpose-Ready data
        currently_provided(m),                                   # 2 field under review
        officially_published(m),                                 # 3 field under review
        purpose_tier(m) is not None,                             # 4 property name under review — aird:purposeTier / aird:purposeReadiness
        m.get("aird:diagnosticMaturity") == "DM-2",             # 5 all required items measured
        quality_tier_at_least_minimum(m),                        # 6 at least the minimum tier set by the operating guideline
        sha256(file) == d["spdx:checksum"]["spdx:checksumValue"],  # 7 checksum matches (per distribution)
        m.get("dct:license") in KR_LICENSE and m.get("dct:rights") and m.get("dct:accessRights"),
                                                                # 8 conditions of use can be confirmed — because this is
                                                                #   automated use, read as a machine-readable license
    ])

The “under review” marks in the pseudocode are where property names · interpretations are being checked against the original text of the standard.

The shape of a manifest is in Manifest example, and the list of properties is in Metadata elements. The release status of schema files and validation tools is in Development status and upcoming releases.

Other paths · Preparing data — Writing the manifest (stage 1) · Operating guidelines — Adoption brief

Operating guidelines

Adoption brief

Type · SummaryReading time · about 4 minAdopting and operating organizationsOrganizations that buy or procure data

This page summarizes the scope of the standard, operating guidelines, and the adoption steps for organizations considering adoption (public institutions, companies, industry associations, data platforms).

Operating guidelines

Building an operating guideline

Type · ProcedureReading time · about 6 minAdopting and operating organizationsOrganizations that buy or procure data

An operating guideline is a document that holds judgment threshold values and operational matters, built separately from the standard. An organization can adopt the standard-provided operating guideline or build its own.

What the operating guideline sets and what the standard specifies

Tier elements follow the standard; operational elements are set by the operating guideline. Each column is a separate list; items on the same row are not paired.

Standard-provided and organizational operating guidelines

The standard provides an operating guideline. The standard-provided operating guideline is published when the standard is established (expected December 2026). There is more than one guideline publisher. Organizations, institutions, and domains can build operating guidelines independently. [Part 1 3.20 · 3.21 · 7.1]

In every approach, tier elements follow the standard. The same score can yield a different tier under a different operating guideline.

Structure of the threshold profile

The threshold profile (judgment threshold values) is part of the operating guideline. It is a machine-readable file that holds the numbers adjusted during operation, such as tier bands, pass lines, and weights, with an identifier and a version. The operating guideline sets the identifier, version, and activation procedure of the threshold profile, and Part 2 Annex D specifies the structure of its elements.

[Part 2 Annex D Table D.1] · Machine representation: aird-threshold-profile-1.0.schema.json (Part 2 Table 9-3)

Tier labels and publication requirements

Whoever judges and publishes tiers observes the following four requirements.

• Tier label in the standard format. Write the tier in the form Gold (Tier 3, STRUCT). Always include the data type; do not include Diagnostic Maturity (DM) in the tier label. [Part 1 Annex A]
• Operating guideline identifier and version alongside. State the identifier and version of the operating guideline applied in the judgment together with the tier.
• Publication of the operating guideline and threshold profile. Publish the applied operating guideline and threshold profile so anyone can access them.
• Hash record. Record the identifier, version, and hash of the threshold profile in the diagnostic report. Data users can use the hash to verify the file used in the judgment. [Part 2 9.1]

Example threshold profile (Part 2 Appendix I)

Example Example threshold profile · status EXAMPLE · not used for tier judgment · source: draft standard (TTAK deliberation draft v0.95) [Part 2 Appendix I Tables I.1 – I.4]

The numbers in Part 2 Appendix I are not values with an established academic basis. The example threshold profile is a file that records the Appendix I numbers in the Annex D structure, and its status is EXAMPLE. The example threshold profile is used only for provisional calculation and tool development, not for tier judgment. All values in the tables for tier bands, per-dimension required pass lines, dimension weights, and other numbers are example values.

Tier bands (minimum dimension score) — example

Tier 0 applies in two cases. First, when the minimum dimension score is below 0.50. Second, when the candidate tier was Tier 1 but a dimension fell short of the Tier 1 pass line, so the result was demoted by one tier. [Part 2 7.3]

Per-dimension required pass lines — example

Dimension weights — example

Other values — example

Purpose-specific criteria

The judgment criteria for the purpose tier are set by the operating guideline. A purpose tier is judged only when an operation-layer profile in registered status (Registered) exists for the use purpose type. For a type without a registered profile, no purpose tier is judged (PROFILE_NOT_REGISTERED). In that case, data prepared for a purpose (Purpose-Ready) is not reached either. There are four profile statuses: Draft · Candidate · Registered · Deprecated. [Part 1 5.6 · Table 5-3 · Part 3 8.2 · Annex C.19]

Without an operating guideline

Measurement and writing the diagnostic report are possible without an operating guideline. The diagnostic tool measures D5-03 (Statistical plausibility) provisionally with the example patterns in Part 2 Appendix I and records the evaluation status as PROVISIONAL. Results without an applied operating guideline get no tier judgment (not judged: no operating guideline applied). After an operating guideline is applied, if its D5-03 patterns differ from the example, measure again and issue a new diagnostic report. Reuse an existing diagnostic report as is only when the target version, measurement rules, threshold profile, and measurement time are all the same. The steps for Diagnostic Maturity and tier judgment are in Judgment procedure.

Other paths · Preparing data — Writing the manifest (stage 1) · For agents — What agents read

Concepts and judgment

Key concepts

Type · ExplanationReading time · about 5 minAll readers

This page defines four groups of concepts needed to read the standard: readiness states and decision gates, three judgments that are not combined, outputs, and roles.

Readiness states and decision gates

Data is prepared in three stages. Each stage ends with a decision gate. When data passes a decision gate, its readiness state transitions. Data that does not pass is not rejected; it is improved and checked again. AI-ready data means a state of Quality-Ready or higher. [Part 1 3.1 · 5.1]

The details of the Quality-Ready transition conditions are in Judgment procedure.

Three judgments — not combined

Quality judgment is divided into three judgments. The diagnostic tool records the result of each judgment separately.

Even with high measured scores, the quality tier is not judged unless Diagnostic Maturity is DM-2. The two values cannot replace each other. When a judgment cannot be made, the diagnostic tool records “not judged” and the reason. It does not substitute a score of 0 or the lowest tier (Status and judgment values).

Outputs

Judgment results are kept as documents separate from the data. A new manifest is issued for each version. A new diagnostic report is created for each measurement. The manifest points to the data files by address and checksum.

Roles

Three parties share the work. The data provider prepares the materials and checks the results. The diagnostic tool computes scores and computes tiers with the threshold profile of the operating guideline. The guideline publisher builds and publishes the operating guideline. There is more than one guideline publisher. The standard publishes a standard-provided operating guideline at establishment (expected December 2026), and organizations, institutions, and domains can build operating guidelines independently. The division of work by stage is in the workflow on each guide page (e.g. Measuring quality (stage 2)).

Concepts and judgment

Judgment procedure

Type · ExplanationReading time · about 5 minAll readers

The diagnostic tool judges Diagnostic Maturity and the quality tier by applying, in turn, a decision table and the threshold profile of an operating guideline.

The diagnostic tool does the calculation. The judgment criteria are set by an operating guideline that is separate from the standard. Data providers do not perform this procedure themselves.

Diagnostic Maturity decision table

Diagnostic Maturity (DM) shows how far the required indicators have been measured. The diagnostic tool applies the table below from the top and ends the judgment at the first row that is met. [Part 2 Annex B.5 Table B.4]

• There are four MMIs: D5-03 · D6-01 · D7-01 · D7-02. Only those that apply to the data type are counted.
• If any required formal indicator is only partially measured (PARTIALLY_APPLIED), DM-2 is not met.

Evaluation coverage

Evaluation coverage is a value from 0 to 1 used to judge DM-1. [Part 2 Annex A.3 · B.5]

Evaluation coverage = Σ statusFactor(applicable required formal indicators) / n(required formal indicators excluding NOT_APPLICABLE)

• Numerator: the sum of statusFactor over the applicable required formal indicators. statusFactor is a value fixed for each applicability status of an indicator (see the indicator applicability table in Status and judgment values).
• Denominator: the number of required formal indicators, excluding NOT_APPLICABLE.
• Lower bound: set by the threshold profile of the operating guideline.

Example STRUCT (tabular) data has 13 required formal indicators. If one of them is NOT_APPLICABLE, the denominator is 12. If the statusFactor sum is 7 (for example, 7 APPLIED and the rest PRECONDITION_UNMET), evaluation coverage is 7/12 ≈ 0.58. Whether DM-1 is met is judged by comparing this value with the operating guideline’s lower bound.

Measurement without an operating guideline

Measurement works even without an operating guideline. D5-03 (Statistical plausibility) takes its dummy-value patterns from the threshold profile of the operating guideline. Without an operating guideline, the diagnostic tool measures D5-03 provisionally with the example patterns in Part 2 Appendix I and records the evaluation status as PROVISIONAL. [Part 2 5.1 · Annex A.4.1 · Appendix I]

D6-01 (Uniqueness) has no precondition. If there is no identifying column, the diagnostic tool counts fully identical records across the combination of all columns. All four MMIs (D5-03 · D6-01 · D7-01 · D7-02) can therefore be measured from the file alone, and DM-0 in row 4 of the decision table is met.

• DM-1 can only be judged with the operating guideline’s lower bound for evaluation coverage. Without an operating guideline, DM-1 is not judged.
• The status of the example threshold profile (Appendix I) is EXAMPLE. The example threshold profile is used for provisional calculation and tool development, not for tier judgment.
• The quality tier is judged only when an operating guideline is applied. The operating guideline provided with the standard is to be published when the standard is established (expected December 2026). Organizations, institutions and domains can build their own operating guidelines and judge with them. [Part 1 7.1]

Reach by data type

The table below shows the Diagnostic Maturity each data type reaches without an operating guideline. Without an operating guideline, the quality tier is “Not judged: no operating guideline applied” regardless of Diagnostic Maturity.

Without a lower bound for evaluation coverage, DM-1 is not judged for any data type.

Tier judgment steps

The diagnostic tool first checks two preconditions. If they are not met, it does not judge a tier and records the reason.

When both preconditions are met, the diagnostic tool judges the tier in the order below. [Part 2 6 · 7]

1. Find the minimum dimension score. Input: the seven dimension scores in the diagnostic report. Output: the lowest dimension score. [Part 2 6.2]
2. Set the candidate tier. Input: the minimum dimension score · the tier bands of the threshold profile. Output: the tier of the band that contains the minimum dimension score (candidate tier).
3. Check the required pass line per dimension. Input: the seven dimension scores · the per-dimension required pass lines of the threshold profile. Output: the list of dimensions below their pass line.
4. Demotion. If any dimension falls short, the candidate tier is lowered by one tier. Output: the demoted tier and the reason for demotion. [Part 2 7.3]
5. Record the final tier. Output: the final tier (for example, Gold (Tier 3, STRUCT)) and the identifier · version of the operating guideline applied.

• Averages (simple or weighted) are not used in tier judgment.
• Tier bands and per-dimension required pass lines are set by the threshold profile of the operating guideline. The items of a threshold profile are listed in Building an operating guideline.
• Tier names: Tier 0 Unqualified · Tier 1 Bronze · Tier 2 Silver · Tier 3 Gold · Tier 4 Platinum.

Quality-Ready transition conditions

At decision gate G2, data transitions to the Quality-Ready state when all of the conditions below are met. [Part 2 7.5]

• Diagnostic Maturity DM-2
• Quality tier Tier 1 or higher
• Threshold profile of an operating guideline applied
• Transition judged at decision gate G2

States and decision gates are defined in Key concepts.

Tier labels

• Never use a tier name on its own. Always state the data type with it. [Part 1 Annex A]
• Do not drop the P- prefix from a purpose tier.
• Diagnostic Maturity (DM) is not part of the tier label. It is recorded as a separate item in the diagnostic report.
• A tier always carries the identifier · version of the operating guideline applied.

Reference

Glossary

Type · ReferenceReading time · about 5 minAll readersAgent and AI developers (data users)

A list that pairs the standard’s terms with the plain terms used on this site. The explanations are not normative definitions; the definitions are in the “Terms and definitions” clause of each part.

Readiness states and decision gates

Outputs

Quality judgment

Use purposes

Operating guidelines

Standard documents

Data types

Publishers and provision modes (site classification)

Tier label rules

Tier names: Tier 0 Unqualified · Tier 1 Bronze · Tier 2 Silver · Tier 3 Gold · Tier 4 Platinum

• Never use a tier name on its own. Always state the data type with it.
• Do not drop the P- prefix from a purpose tier.
• Diagnostic Maturity (DM) is not part of the tier label; it is recorded as a separate item in the diagnostic report.
• State the identifier · version of the operating guideline applied next to the tier label, not inside the label format itself (for example, Gold (Tier 3, STRUCT) · operating guideline example-guideline 1.0).

[Part 1 Annex A]

Reference

Metadata elements

Type · ReferenceReading time · about 51 minAll readersAgent and AI developers (data users)

This page lists the metadata elements written in the manifest. The required discovery-layer metadata elements are the 23 in the demo profile of AIRD vocabulary v0.10.5 (19 for the dataset + 4 for each distribution): the 19 required in the deliberation draft (15 for the dataset + 4 for each distribution) plus 4 more.

The 4 added by the demo profile are dataset structure type · theme · landing page · maintaining department. Theme and landing page are required for public-sector data and recommended for other data. The deliberation draft and the vocabulary are consistent. The deliberation draft focuses on the required elements, while the vocabulary is the complete list, including external vocabularies. The discovery layer is written in stage 1 and the understanding layer in stage 2. If there are several distributions, the number of discovery-layer values is 19 + 4 × (number of distributions).

Discovery layer · 19 dataset elements Required

Discovery layer · 4 per distribution Required

If the data is distributed in several forms, describe each distribution (dcat:Distribution) separately.

Conditionally required

Understanding layer · key elements

Grouping and cardinalities follow vocabulary v0.10.5. Within a group such as the quality assessment (aird:QualityAssessment) or the decision gate record, “required” means required when that group is written. Elements the data provider fills in directly are shown in bold.

Version · history

Quality assessment — 2.2.1 conditionally required · lifecycleStatus = Quality-Ready

Dimension scores — 2.3.1 quality measurement · required · one each for D1–D7

Structural · semantic readiness

Trust · ethics

Provenance

Decision gate judgment record

Purpose readiness

Security · privacy

Value lists

Values for the following elements are chosen from a fixed list and are not written as free strings.

Update frequency — data provider input and manifest value

Other values

[Part 3 Annex A.1] [Part 3 Annex A.2] [Part 3 Annex C]

Reference

Quality indicators

Type · ReferenceReading time · about 4 minAll readersAgent and AI developers (data users)

This page lists how the 16 formal quality indicators apply to each data type, with their preconditions and formulas. All scores range from 0 to 1. Weights and tier bands follow the threshold profile of the operating guideline.

Application by data type

● required formal · ○ optional · — not applicable. MMI is a minimum measurable indicator (an entry requirement for diagnosis).

Preconditions and formulas by indicator

(1 / |Freq|) × Σ_{f∈Freq} [ n(f ≠ NULL ∧ f ≠ '') / N ]

n(required metadata elements filled in) / n(all required metadata elements)

1 − ( n(records violating a rule) / N )

1 − ( n(unmapped code cells) / n(valid code cells) )

1 − ( n(computed value ≠ stored value) / n(values checked) )

1 − ( n(code cells not matching the reference) / n(matched code cells) )

n(matches) / n(items reviewed). For text and paired text, only an exact match counts as a match

1.0 if days elapsed ≤ update interval. Otherwise max(0, 1 − (days elapsed − update interval) / grace period). The grace period equals the update interval in days

n(updates carried out) / n(updates scheduled)

n(actual measurement points) / n(expected measurement points)

1 − ( n(cells with format mismatch) / n(cells checked for format) )

1 − ( n(out-of-range cells) / n(cells with a defined range) )

1 − ( n(cells with obviously wrong values) / n(numeric cells evaluated) )

n(unique keys) / N. If identifier columns are defined, duplicates of the same entity are measured; if not, the combination of all columns is used as the key and fully identical duplicate records are measured

n(files using the reference encoding) / n(all files)

n(files that open normally ∧ meet the specification) / n(all files). A file meets the specification when parsing completes under the official specification of its file format and the required structure is valid

Calculation

Sk is the score of each required formal indicator for that data type whose measurement is complete. Optional indicators and incomplete indicators are excluded from both numerator and denominator. If a dimension has no completed formal indicator, Di is recorded as null. The weighted average is not used for tier judgment. Tier judgment starts from the minimum dimension score (Judgment procedure). Evaluation coverage is compared with the lower bound set in the operating guideline when judging Diagnostic Maturity DM-1.

Partial measurement

Indicators that allow partial measurement (PARTIALLY_APPLIED): D2-02 · D3-01 · D5-02. coverage = n(measurable targets) / n(identified measurement targets). Only targets that meet the precondition form the population. Targets that could not be measured are excluded from both numerator and denominator. The score is not multiplied by coverage again. If any measurement is partial, DM-2 cannot be reached. The upper limit of Diagnostic Maturity (DM) is DM-1.

Exclusivity — no double counting of the same defect across indicators

Reference encoding

[Part 2 Annex A.1–A.4] [Part 2 Annex B.1–B.6]

Reference

Status and judgment values

Type · ReferenceReading time · about 3 minAll readersAgent and AI developers (data users)