KazakhLawCorpus: A Large-Scale Metadata Corpus for Kazakh Legislation

Abstract

The availability of large, structured legal datasets is essential for advancing legal natural language processing, information retrieval, and the development of reliable language technologies. However, such resources remain scarce for Kazakh, a morphologically rich and comparatively low-resource language, limiting the development and evaluation of domain-specific NLP methods. This data descriptor presents KazakhLawCorpus, a curated corpus of 215,889 document-level legislative metadata records from the Republic of Kazakhstan. The dataset was derived from a PostgreSQL export containing 223,245 source records and constructed through Kazakh-language field selection, essential-field filtering, source-preserving normalization, schema reconstruction, and systematic quality validation, resulting in a retention rate of 96.705%. The final release comprises 25 fields covering document identifiers, temporal attributes, legal status, registry information, Kazakh-language titles and descriptions, legal and institutional categories, geographical information, and source URLs. The records cover legislative acts adopted between 30 October 1947 and 20 July 2026. Quality-control procedures confirmed unique law_id values, complete title and description fields, and parseable adoption dates, while 4635 records with potential source-level or historical anomalies were retained and transparently documented through diagnostic flags. KazakhLawCorpus provides a large-scale, traceable resource for metadata-based legal information retrieval, document classification, temporal and institutional analysis, provenance tracking, and the development of downstream Kazakh legal NLP resources.

Dataset: https://doi.org/10.5281/zenodo.21787361 (accessed on 25 August 2026); https://huggingface.co/datasets/Arailym-tleubayeva/KazakhLawCorpus-clean (accessed on 25 August 2026).

Dataset License: Creative Commons Attribution 4.0 International (CC BY 4.0).

1. Summary

This data descriptor presents KazakhLawCorpus, a curated corpus containing 215,889 Kazakh-language legislative metadata records from the Republic of Kazakhstan. The analyzed version of the dataset is persistently archived in Zenodo [1]. It was derived from the legislative component of the original multilingual KazakhLawCorpus collection [2], based on a PostgreSQL database export provided by NUBA Solutions LLP. Where available, the records retain links to corresponding legislative documents in the Adilet Legal Information System of the Republic of Kazakhstan [3].

The source legislative table contained 223,245 records. Following Kazakh-language field selection, removal of records without usable Kazakh-language content, essential-field filtering, schema reconstruction, and diagnostic validation, 7356 records were excluded. The resulting dataset retains 96.705% of the source collection. Each row represents one legislative act and is identified by a unique law_id. The final release contains 25 fields describing provenance, document identifiers, adoption and modification dates, publication and registration information, legal status, official source URLs, Kazakh-language titles and descriptions, forms and legal-force categories of acts, adopting and regulatory bodies, geographical scope, places of adoption, and source-database sections. The adoption dates range from 30 October 1947 to 20 July 2026. Of the released records, 74,941 acts are marked as repealed in the analysed source snapshot, whereas 140,948 are not marked as repealed.

Large-scale legal resources such as LEGAL-BERT, LexGLUE, LEDGAR, MultiEURLEX, and MultiLegalPile have supported progress in legal language modelling, document classification, information retrieval, and multilingual evaluation [4,5,6,7,8]. However, comparable datasets remain limited for Kazakh. This limitation is particularly important because Kazakh is a morphologically rich and comparatively low-resource language in which agglutinative word formation, extensive inflection, lexical variation, and limited domain-specific data complicate tokenization, retrieval, similarity estimation, and question answering [9,10].

KazakhLawCorpus is a document-level legislative metadata corpus rather than a complete full-text collection of Kazakhstan legislation. The title and description fields support document identification, indexing, classification, filtering, and metadata-based retrieval. However, the released table does not systematically contain the complete articles, clauses, subclauses, or paragraphs of the corresponding legislative acts. For downstream applications requiring provision-level evidence, the corpus identifiers and official source links can be used to identify relevant legislative acts, after which the corresponding full texts may be obtained and verified through authoritative legal-information sources.

The corpus was constructed through a reproducible and source-preserving workflow. Dedicated Kazakh-language fields were retained and standardized, while language-independent identifiers, dates, status indicators, registry numbers, and source URLs were preserved. Records without substantive Kazakh-language information or without complete titles and descriptions were excluded. Quality assurance included schema verification, identifier and duplicate checks, date parsing, URL diagnostics, source-placeholder detection, CAPTCHA-pattern scanning, Unicode and encoding analysis, language heuristics, and text-length assessment.

The final dataset contains no missing or duplicated law_id values, no missing titles or descriptions, and no unparseable adoption dates. Additional diagnostic procedures identified 4635 records with at least one review flag. These records were retained and documented rather than removed automatically because unusual strings, repeated titles, historical institutional names, and sparse optional metadata may represent valid characteristics of legislative records.

KazakhLawCorpus supports legislative document retrieval, legal-act classification, legal-category prediction, temporal analysis, duplicate and version grouping, institutional and geographical entity normalization, metadata completion, corpus linguistics, and candidate-document selection for retrieval-augmented generation. The dataset is openly distributed through Hugging Face and persistently archived through Zenodo under the Creative Commons Attribution 4.0 International license. Its structured and reusable organization supports the principles of findability, accessibility, interoperability, and reusability [11,12].

The principal contributions of this work are as follows:

• the release of a large-scale Kazakh-language legislative metadata corpus containing 215,889 uniquely identified records;
• the organization of 25 textual, temporal, legal, institutional, geographical, registry, source, and provenance-related fields in a consistent one-record-per-act structure;
• a reproducible workflow for Kazakh-language field selection, record filtering, source-preserving normalization, and validation;
• machine-readable quality-control outputs documenting metadata completeness and residual source-level anomalies;
• a quantitative characterization of the corpus in terms of temporal coverage, text length, legal status, document categories, and metadata availability; and
• open distribution through Hugging Face and persistent archiving through Zenodo under the CC BY 4.0 license.

2. Related Works

The development of legal natural language processing has been closely linked to the availability of specialized corpora and standardized evaluation resources. Legal documents differ from general-domain text in their terminology, formal structure, citation practices, institutional context, and jurisdiction-specific interpretation. Consequently, models trained predominantly on general-domain data may not adequately represent legal concepts or recurring patterns of legal language. LEGAL-BERT demonstrated the value of legal-domain adaptation through pre-training on legal corpora and evaluation across several downstream tasks [4]. LexGLUE subsequently introduced a unified benchmark for English-language legal understanding [5], while LEDGAR provided nearly 100,000 contractual provisions annotated for large-scale multi-label classification [6]. Multilingual resources further broadened this research direction. MultiEURLEX contains 65,000 European Union laws in 23 languages and supports multilingual, multi-label, and temporally informed classification [7], whereas MultiLegalPile assembled approximately 689 GB of legal text from 17 jurisdictions and 24 languages for domain-specific language-model pre-training [8]. Together, these resources demonstrate the value of legal datasets for domain adaptation, classification, cross-lingual transfer, contract analysis, and large-scale language modelling. However, they do not provide a structured national legislative inventory for Kazakhstan with consistent identifiers, legal-status fields, registry information, institutional metadata, and links to authoritative sources.

National-scale legislative collections address a related but distinct need. Libgober compiled a comprehensive dataset of United States federal laws, illustrating the value of preserving legislation as an analyzable national corpus rather than only as isolated task-specific examples [13]. Nevertheless, differences in jurisdiction, legal organization, language, document structure, and source infrastructure limit the direct transfer of such resources to Kazakhstan. KazakhLawCorpus addresses this gap by providing a structured document-level inventory of Kazakh-language legislative metadata from the Republic of Kazakhstan.

Legal datasets increasingly support tasks beyond document classification. CODE-ACCORD contains regulatory sentences from the building regulations of England and Finland annotated with entities and relations for rule generation and automatic compliance checking [14]. LexSumm brings together multiple English-language legal summarization datasets from several jurisdictions [15], while research on long legal documents has shown that standard Transformer architectures often require adaptation to process extended legal contexts efficiently [16]. These studies demonstrate that the usefulness of a legal collection is not limited to its original task. A well-documented source corpus may later support information extraction, summarization, terminology analysis, compliance checking, document comparison, and task-specific annotation. Such reuse, however, depends on the preservation of document identity, legal source, jurisdiction, institutional origin, temporal status, and applicable version. KazakhLawCorpus contributes this metadata layer, although it does not systematically include the complete normative texts required for direct provision-level analysis.

Information retrieval is another major application of legal corpora. LePaRD contains millions of examples derived from citations by United States federal judges to earlier decisions and formulates legal retrieval as the identification of relevant passages from precedent [17]. LegalBench-RAG focuses specifically on the retrieval component of legal retrieval-augmented generation by linking queries to precise evidence spans rather than treating complete documents as relevant units [18]. CLERC combines legal case retrieval with retrieval-augmented analysis generation, requiring systems both to identify relevant precedents and to produce analyses supported by those authorities [19]. These resources illustrate a broader transition from document-level search towards passage-level retrieval and citation-aware generation. KazakhLawCorpus occupies a complementary position within this pipeline: it supports candidate-document identification, metadata-based filtering, and provenance tracking, while provision-level retrieval requires the corresponding full legal texts to be obtained and processed separately.

The development of legal question-answering datasets follows a similar progression towards evidence-aligned evaluation. LLeQA provides expert-annotated French-language legal questions accompanied by detailed answers grounded in statutory provisions [20]. Its retrieve-then-read setting separates evidence identification from answer formulation, which is particularly important in legal applications because a linguistically plausible answer may still be unreliable when based on an irrelevant, outdated, or repealed provision. RIRAG further addresses regulatory information retrieval and answer generation, with particular emphasis on obligations and evidence-supported responses [21]. In aviation regulation, Zheng et al. constructed 4688 question–answer instances through generation, augmentation, and expert correction and evaluated a RAG pipeline combining document conversion, provision-level processing, vector retrieval, reranking, and answer generation [22]. These studies show that legal QA depends on reliable links between the user query, retrieved evidence, document version, and generated response. KazakhLawCorpus is not itself an evidence-grounded QA benchmark, but its identifiers, legal categories, status information, and official source links can support the selection and verification of documents from which specialized QA resources may be constructed.

The shortage of reusable legal data is particularly pronounced for low-resource languages. Fatwaset addressed this limitation for Arabic by collecting fatwas from authenticated sources and preserving associated metadata for language modelling, classification, topic identification, summarization, and question answering [23]. MAFQA subsequently transformed authentic fatwa material into a specialized multi-hop QA benchmark containing supporting contexts, decomposed questions, sub–answers, and structured reasoning patterns [24]. KoLegalQA provides another example of a task-specific resource for an underrepresented language, comprising Korean legal consultations with professionally written or verified responses and associated statutory provisions [25]. These resources illustrate an important data-development pathway: a broad source collection may first be documented and released, after which narrower expert-validated datasets can be created for individual downstream tasks.

For Kazakh, publicly available NLP resources remain comparatively limited. KazNERD contains more than 112,000 Kazakh-language sentences annotated for 25 named-entity classes and demonstrates the feasibility of openly releasing task-specific annotations and baseline models for a morphologically rich language [26]. In the legal domain, Rakhimova et al. compiled question–answer data from Adilet, Zqai, and governmental sources, supplemented them with manually created synthetic examples, and evaluated several models for Kazakh legal question answering [27]. Their work established the feasibility of Kazakh-language legal QA, but its primary objective was model training and evaluation rather than the construction of a consistently structured national legislative inventory.

Recent studies have also examined retrieval and model adaptation for Kazakhstan’s legal domain. Tleubayeva et al. investigated document-segmentation strategies for retrieval-augmented generation over Kazakh legal texts and showed the importance of preserving legally meaningful structural boundaries when transforming full documents into retrievable passages [28]. Yeleussinov et al. compared LoRA-adapted Qwen3 models for bilingual Kazakh–Russian legal question answering, demonstrating growing interest in specialized models for Kazakhstan-specific legal terminology and bilingual interaction [29]. Previous Kazakh-language research has additionally examined text similarity in agglutinative languages and the performance of large language models and retrieval-augmented generation for Kazakh question answering [9,10]. Collectively, these studies indicate increasing maturity in Kazakh NLP while also highlighting the need for reusable and well-documented legal data infrastructure.

KazakhLawCorpus serves a complementary role to these existing resources. It is not designed primarily as a language-model pre-training corpus, classification benchmark, consultation dataset, or evidence-grounded QA collection. Instead, it provides a large-scale, structured, document-level inventory of Kazakh-language legislative metadata, with consistent organization of document identifiers, temporal attributes, registration information, legal status, titles and descriptions, legal categories, institutional descriptors, geographical scope, and official source links. Compared with model-oriented corpora, it places greater emphasis on document identity, provenance, and source traceability. Compared with QA benchmarks, it offers substantially broader legislative coverage but does not contain question–answer annotations. Compared with full-text legal collections, it provides a discovery and provenance layer rather than complete articles, clauses, and paragraphs. The resource is therefore intended to support direct metadata-level analysis and the subsequent development of specialized datasets for classification, temporal evaluation, institutional normalization, duplicate and version grouping, candidate-document retrieval, full-text corpus construction, and evidence-grounded Kazakh legal question answering.

3. Data Description

3.1. Dataset Scope and General Characteristics

KazakhLawCorpus is a large-scale corpus of Kazakh-language legislative metadata from the Republic of Kazakhstan. Table 1 summarizes the general characteristics. The curated release contains 215,889 records and 25 metadata fields. It was derived from a source legislative table comprising 223,245 records. Following Kazakh-language field selection, essential-field filtering, schema reconstruction, and quality validation, 7356 records were excluded, resulting in a retention rate of 96.705%.

Table 1. General characteristics of KazakhLawCorpus.

Characteristic	Value
Source legislative records	223,245
Released records	215,889
Excluded records	7356
Retention rate	96.705%
Number of metadata fields	25
Unique law_id values	215,889
Missing titles	0
Missing descriptions	0
Temporal coverage	30 October 1947–20 July 2026
Acts marked as repealed	74,941
Acts not marked as repealed	140,948
Licence	CC BY 4.0

Each row represents one legislative act and is identified by a unique law_id. The dataset contains no missing or duplicated primary identifiers and no missing values in the essential title and description fields. The records cover legislative acts adopted between 30 October 1947 and 20 July 2026.

3.2. Metadata Schema

The 25-field schema was reconstructed from the supplied source database and was not designed as a formal implementation of the European Legislation Identifier (ELI) or as an Akoma Ntoso encoding. Nevertheless, several fields have conceptual counterparts in established legal-information standards. The law_id field and the adilet_url and ekb_url fields support resource identification and traceability; date_adopted, date_modified, date_published, and ministry_registration_date provide temporal metadata; title and description provide textual metadata; and act_form, legal_force, adopting_body, and region describe document type, authority, and territorial context. The current release does not provide ELI URI templates, controlled vocabularies, RDF relations among legal resources, expressions, and formats, or explicit lifecycle and amendment relations. It also does not encode the full structural and semantic content of legal documents, such as articles, clauses, citations, and amendments, in Akoma Ntoso XML. KazakhLawCorpus should therefore be viewed as a source-preserving discovery and provenance layer rather than as a standards-compliant legal-document representation. Future interoperability work may map selected metadata fields to ELI properties and link separately acquired, versioned full texts to Akoma Ntoso-compliant structural representations [30,31].

The 25 fields are organized into five functional groups: identifiers and provenance, temporal attributes, legal status and registration, textual and source-access fields, and legal, institutional, and geographical descriptors (see Table 2).

Table 2. Metadata schema of KazakhLawCorpus.

Functional Group	Fields	Description
Identifiers and provenance	source_id, law_id, law_registry_number	Source-system and document-level identifiers
Temporal attributes	date_adopted, date_modified, date_published, ministry_registration_date	Adoption, modification, publication, and registration dates
Legal status and registration	is_archive, is_repealed, state_registry_number, gov_registration_number	Status indicators and official registration numbers
Text and source access	title, description, official_publication_info, adilet_url, ekb_url	Kazakh-language textual metadata, publication information, and source links
Legal and administrative descriptors	act_form, legal_relation_area, legal_force, adopting_body, regulatory_body, developer_body, region, place_of_adoption, database_section	Document type, legal domain, authority, institution, geography, and source classification

The law_id field serves as the principal record key and provides the main link between the curated metadata and the corresponding source record. Registry numbers should not be assumed to be globally unique because their interpretation may depend on the issuing authority, document type, administrative context, or historical period.

The date_adopted field is complete for all records, whereas other temporal fields are optional and reflect differences in publication, modification, and registration practices. The is_repealed field represents the legal-status value recorded in the source snapshot used to construct the dataset. It should not be interpreted as a permanent or real-time confirmation of the current validity of an act. The is_archive field has a constant value throughout the release and is therefore not informative for comparative analysis.

The principal textual fields are the Kazakh-language title and description. Their median lengths are 19 and 24 whitespace-delimited words, respectively. A small number of unusually long strings were retained because they may correspond to valid amendment acts, lists of affected regulations, or complex official titles. Text length was therefore treated as a diagnostic indicator rather than as an exclusion criterion.

3.3. Temporal Coverage and Legal Status

The temporal distribution of KazakhLawCorpus is shown in Table 3. Only 53 records, corresponding to 0.025% of the dataset, predate 1990. The corpus contains 9455 records from the 1990s, 28,302 from the 2000s, 91,706 from the 2010s, and 86,373 from the period between 2020 and 20 July 2026.

Table 3. Distribution of records by adoption period.

Adoption Period	Records	Share
Before 1990	53	0.025%
1990–1999	9455	4.380%
2000–2009	28,302	13.110%
2010–2019	91,706	42.478%
2020–2026 *	86,373	40.008%

* The analyzed release includes records only up to 20 July 2026.

Records adopted from 2010 onwards account for 178,079 documents, or 82.49% of the corpus. The highest annual count is observed in 2023, with 15,092 records. The count for 2026 represents a partial year because the dataset includes records only up to 20 July 2026 (see Figure 1).

Figure 1. Annual distribution of legislative records adopted between 1990 and 2026. The centered five-year moving average illustrates the long-term temporal pattern.

The concentration of records in recent decades may reflect both changes in legislative activity and improvements in the digitization and coverage of the underlying information systems. It should not therefore be interpreted solely as evidence of increased legislative production. Similarly, the limited number of records from earlier decades restricts the reliability of comparative historical analyses for those periods.

Of the 215,889 records, 74,941 acts, corresponding to 34.71%, are marked as repealed in the source snapshot, whereas 140,948 acts, or 65.29%, are not marked as repealed. These values describe the status information available at the time of dataset construction and must be verified against an authoritative legal source before being used in legal interpretation or practice.

3.4. Legal and Administrative Composition

KazakhLawCorpus covers a broad range of legislative forms, levels of legal authority, subject areas, adopting institutions, and geographical scopes (Table 4). The most frequent analytically normalized act form is Шeшiм (Decision), represented by 58,192 records (26.95% of the corpus), followed by Қayлы (Resolution) with 47,797 records (22.14%) and Шeшiм, Өзгepтy (Decision, Amendment) with 26,388 records (12.22%).

Table 4. Top three high-frequency values across selected legal and administrative dimensions.

Dimension	Category	Records	Share	Total Distinct Values
Normalised act form	Шeшiм (Decision)	58,192	26.95%	594
	Қayлы (Resolution)	47,797	22.14%
	Шeшiм, Өзгepтy (Decision, Amendment)	26,388	12.22%
Legal force	Mәcлиxaттың aктici (Act of the Maslikhat)	48,714	22.56%	43
	Әкiмдiктiң aктici (Act of the Akimat)	34,549	16.00%
	Yкiмeттiң қayлыcы (Resolution of the Government)	34,151	15.82%
Database section	Қapжы (Finance)	64,854	30.04%	38
	Koнcтитyциялық құpылыc жәнe мeмлeкeттiк бacқapy нeгiздepi (Constitutional Structure and Fundamentals of State Administration)	42,911	19.88%
	Шapyaшылық қызмeт (Economic Activity)	15,126	7.01%
Region	Қaзaқcтaн Pecпyбликacы (Republic of Kazakhstan)	81,739	37.86%	2468
	EypAзЭҚ. EAЭO (EurAsEC; Eurasian Economic Union)	2671	1.24%
	Шығыc Қaзaқcтaн oблыcы (East Kazakhstan Region)	1641	0.76%
Adopting body	Қaзaқcтaн Pecпyбликacының Yкiмeтi (Қaзaқcтaн Pecпyбликacының Пpeмьep-Mиниcтpi) (бұpынғы aтayы: Қaзaқ CCP Mиниcтpлep Kaбинeтi; Қaзaқ CCP Mиниcтpлep Coвeтi; Қaзaқ CCP Пpeмьep-Mиниcтpi; Қaзaқ CCP Xaлық кoмиccapлapы Coвeтi; ҚP Mиниcтpлep Kaбинeтi)	37,807	17.51%	4252
	Қaзaқcтaн Pecпyбликacының Пpeзидeнтi (бұpынғы aтayы: Қaзaқ Coвeттiк Coциaлиcтiк Pecпyбликacының Пpeзидeнтi; Қaзaқ CCP Пpeзидeнтi)	4723	2.19%
	Қaзaқcтaн Pecпyбликacының Пapлaмeнтi (бұpынғы aтayы: Қaзaқ CCP Жoғapғы Coвeтi; Қaзaқ CCP Жoғapғы Coвeтiнiң Пpeзидиyмы; ҚP Жoғapғы Keңeciнiң Tөpaлқacы; ҚP Жoғapғы Keңeci)	3569	1.65%

The most frequent legal-force category is Mәcлиxaттың aктici (Act of the Maslikhat), represented by 48,714 records (22.56%), followed by Әкiмдiктiң aктici (Act of the Akimat) with 34,549 records (16.00%) and Yкiмeттiң қayлыcы (Resolution of the Government) with 34,151 records (15.82%). These distributions indicate substantial representation of local representative bodies, local executive authorities, and the national Government.

The largest source-database section is Қapжы (Finance), containing 64,854 records (30.04%), followed by Koнcтитyциялық құpылыc жәнe мeмлeкeттiк бacқapy нeгiздepi (Constitutional Structure and Fundamentals of State Administration) with 42,911 records (19.88%) and Шapyaшылық қызмeт (Economic Activity) with 15,126 records (7.01%).

The most frequent geographical value is Қaзaқcтaн Pecпyбликacы (Republic of Kazakhstan), occurring in 81,739 records (37.86%). The next most frequent values are EypAзЭҚ. EAЭO (EurAsEC; Eurasian Economic Union) with 2671 records (1.24%) and Шығыc Қaзaқcтaн oблыcы (East Kazakhstan Region) with 1641 records (0.76%). The large difference between the most frequent region value and the subsequent values illustrates the strongly long-tailed nature of the geographical metadata.

For adopting_body, the most frequent value occurs in 37,807 records (17.51%). Importantly, this value is a single raw source string corresponding to the Government of the Republic of Kazakhstan; its parenthetical content includes the Prime Minister and several historical predecessor designations already present in the source database. It was not produced by aggregating multiple adopting-body strings. The second- and third-most frequent adopting-body values correspond to the President of the Republic of Kazakhstan, with 4723 records (2.19%), and the Parliament of the Republic of Kazakhstan, with 3569 records (1.65%), respectively.

Categorical fields preserve source-level spelling, ordering, naming, and historical variation. Table 4 therefore reports the three highest-frequency values for each selected dimension together with the total number of distinct non-empty values. For act_form, the distinct-value count refers to 594 analytically normalized combinations derived from 862 raw source strings. For legal_force, database_section, region, and adopting_body, the corresponding counts are 43, 38, 2468, and 4252 distinct non-empty source strings, respectively. These values should not be interpreted as counts of fully canonicalized legal concepts, geographical entities, or institutions.

For example, the raw act_form field contains 862 distinct strings. Some values represent different orderings of the same multi-valued category, such as Шeшiм, Өзгepтy (Decision, Amendment) and Өзгepтy, Шeшiм (Amendment, Decision). After separating comma-delimited components, trimming whitespace, removing repeated labels, and sorting the values, the number of distinct analytical combinations decreases to 594. This normalized representation was used for descriptive analysis, whereas the original source values were retained in the released dataset.

The broader concentration pattern of the analytically normalized act_form values is illustrated in Figure 2, which shows the 20 most frequent categories together with their cumulative share.

Figure 2. Pareto distribution of the 20 most frequent analytically normalized act_form values. Categories outside the 20 most frequent values are aggregated into “Other”. Bars show the number of records, while the dashed line represents the cumulative share of records. The horizontal dotted line indicates the 80% cumulative-share threshold.

The same source-preserving principle applies to the other categorical dimensions. In particular, the adopting_body value represented by 37,807 records is a single raw source string whose parenthetical content lists the Prime Minister and several historical predecessor designations. It was not generated by merging multiple adopting-body values. Consequently, raw distinct-value counts should be interpreted as counts of source strings rather than as counts of canonical legal or institutional entities.

3.5. Metadata Completeness

Metadata availability varies across the 25 fields. Core identifiers, adoption dates, status indicators, titles, and descriptions are complete, whereas several optional publication, registration, modification, and institutional attributes are less consistently populated, as shown in Figure 3.

Figure 3. Raw non-null completeness across the 25 metadata fields of KazakhLawCorpus. Literal source placeholders are counted as populated values and are analyzed separately.

Raw non-null completeness is 50.45% for date_modified, 31.28% for developer_body, 13.38% for ministry_registration_date, and 11.64% for date_published. Source-access and registration fields have higher availability: adilet_url is populated for 99.63% of records, gov_registration_number for 88.36%, state_registry_number for 85.70%, and ekb_url for 84.37%.

Raw non-null rates do not always correspond to meaningful information because some optional fields contain literal source placeholders, including ЖOҚ (N/A), hyphens, and em dashes. Such values are technically non-null but indicate unavailable information. When documented placeholders are treated as missing in the analytical representation, estimated completeness decreases to 56.79% for regulatory_body, 80.73% for official_publication_info, and 29.51% for developer_body.

The original source values were preserved in the released dataset to maintain provenance. The accompanying analytical outputs distinguish between raw field population and placeholder-adjusted semantic completeness.

3.6. Technical Quality Indicators

The final dataset passed the principal structural integrity checks. It contains the expected 25 fields, no missing or duplicated law_id values, no missing titles or descriptions, and no unparseable adoption dates.

Additional diagnostic checks were performed to identify records that may require task-specific review. Four records triggered temporal-consistency conditions, and 104 records belonged to duplicated normalized title–description groups. Twenty-eight records contained no Kazakh-specific Cyrillic characters in either the title or the description. This language heuristic was deliberately conservative and was used only to identify records for manual review rather than to determine language automatically.

Manual inspection of all 28 language-heuristic flags confirmed that the flagged records contain Russian-language titles and descriptions rather than numeral-only or abbreviation-only strings. These records correspond to historical source entries adopted between 2 April 1993 and 28 June 2001. Twenty-seven of the 28 records contain at least one Latin character, most commonly “N” (Latin U+004E) in document-number notation. Several records also contain legacy typographic or character-substitution patterns. For example, the title “Дәyip” appears in the source as “Дayip”, where the Latin character “i” (U+0069) is used instead of the visually similar Cyrillic character “i” (U+0456). Similar substitutions include Latin “p” (U+0070) in positions where Cyrillic “p” (U+0440) would be expected. These characters are visually similar but represent different Unicode code points and scripts. One additional record contains only Cyrillic text but no Kazakh-specific Cyrillic characters. Because these values originated from source fields designated as Kazakh, they were retained unchanged to preserve source fidelity and provenance. Users requiring a strictly Kazakh-language subset should exclude records carrying the language-heuristic flag.

The technical and encoding analysis presented in Table 5 flagged 1388 records, including strings containing a known encoding artefact and cases of excessive character repetition. Five titles matched CAPTCHA or bot-verification patterns. In addition, 794 records did not contain an Adilet URL.

Table 5. Summary of technical validation results.

Validation Area	Result	Interpretation
Missing or unexpected schema fields	0/0	Passed
Missing or duplicated law_id values	0/0	Passed
Missing titles or descriptions	0/0	Passed
Unparseable adoption dates	0	Passed
Records with temporal-consistency flags	4	Diagnostic review
Records without an Adilet URL	794 (0.368%)	Known limitation
Normalised duplicate-group members	104 (0.048%)	Diagnostic review
Language-heuristic flags	28 (0.013%)	Diagnostic review
Encoding or technical flags	1388 (0.643%)	Diagnostic review
CAPTCHA-pattern title matches	5	Correction recommended
Records with at least one diagnostic flag	4635 (2.147%)	Retained diagnostic subset

Overall, 4635 records, corresponding to 2.147% of the corpus, received at least one diagnostic flag. These records were retained because repeated titles, historical language fragments, unusual institutional names, non-standard source strings, and sparse optional metadata may still represent valid characteristics of legislative records. The diagnostic flags are intended to support transparent, task-specific filtering rather than to define a universally invalid subset.

4. Methods

4.1. Source Data Acquisition and Provenance

The corpus was constructed from a PostgreSQL database dump provided by NUBA Solutions LLP. The database contained legislative records and associated metadata collected and consolidated from publicly accessible governmental and legal-information resources in the Republic of Kazakhstan.

According to the data provider, the underlying records had previously been obtained using automated data-extraction procedures. The principal source systems included the Adilet Legal Information System and the EKB legal-information resource hosted at law.gov.kz. The Adilet system is maintained by the Institute of Legislation and Legal Information of the Ministry of Justice of the Republic of Kazakhstan [3].

The authors did not perform direct web scraping as part of the present study. Instead, they received the consolidated PostgreSQL database export and transformed it into a research-oriented dataset through schema reconstruction, Kazakh-language field selection, record-level filtering, text normalization, metadata validation, and quality-control procedures.

Where available, links to the corresponding source records were preserved in the $adilet\_url$ and $ekb\_url$ fields. These links support document identification, provenance verification, and downstream access to official legal materials. However, the availability and completeness of source URLs varied across records and historical periods.

The resulting release should therefore be understood as a curated derivative of a database assembled by NUBA Solutions LLP from publicly accessible legal-information resources, rather than as a direct reconstruction of the source websites by the authors. Official legal-information systems remain authoritative for verifying the current wording, amendment history, and legal status of individual legislative acts.

4.2. Schema Reconstruction and Kazakh-Language Field Selection

The source table contained multilingual field families represented by unsuffixed fields and corresponding Kazakh $(\_kk)$ and Russian $(\_ru)$ variants. The schema was reconstructed by selecting the Kazakh-language $(\_kk)$ member of each multilingual field family and renaming it to the corresponding canonical base field name. The associated Russian-language $(\_ru)$ variants and unsuffixed mixed-language fields were excluded when a dedicated Kazakh-language field was available. Consequently, the released corpus contains only the selected Kazakh-language members of the multilingual field families.

Language-independent fields were retained without modification. These included source_id, law_id, adoption, modification and publication dates, registry numbers, Boolean status indicators, and source URLs. The resulting schema comprised 25 fields organized into five functional groups: provenance and identifiers; temporal metadata; status and registry information; Kazakh-language textual metadata and source links; and legal, institutional, and geographical descriptors.

Field selection was based on the source-language designation and did not involve machine translation or record-level language conversion. Therefore, values retained from the _kk fields could still contain official abbreviations, historical organization names, referenced entities, technical strings, or occasional fragments written in Russian or Latin script. Such cases were preserved to maintain source fidelity and were examined through diagnostic language analysis rather than removed automatically. This conservative approach prevented the exclusion of valid legislative records solely because individual values did not contain Kazakh-specific Cyrillic characters.

4.3. Record Eligibility and Corpus Assembly

Record selection was performed in two stages. First, each source record was assessed for the presence of usable Kazakh-language information across 12 principal textual and categorical fields. A value $v$ was considered usable when it was non-null, remained non-empty after whitespace trimming, and was not a recognised source placeholder:

$$usable(v)=\{\begin{array}{cc}1,& \mathrm{if} v \mathrm{is} \mathrm{non}\text{-}\mathrm{null}, \mathrm{non}\text{-}\mathrm{empty} \mathrm{after} \mathrm{trimming}, \mathrm{and} \mathrm{not} \mathrm{a} \mathrm{recognised} \mathrm{placeholder},\\ 0,& \mathrm{otherwise}.\end{array}$$

(1)

For a record $r_i$ with selected fields $F$, the initial eligibility condition was defined as:

$$E_1(r_i)=\mathbb{I}(\sum _{f\in F}\mathrm{u}\mathrm{s}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}(r_{i,f})>0),$$

(2)

where $\mathbb{I}(\cdot )$ denotes the indicator function. Records containing no usable Kazakh-language information across the selected fields were excluded. This stage removed 7301 records.

The second stage required usable values in both essential textual fields:

$$E_2(r_i)=\mathrm{u}\mathrm{s}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}(r_{i,\mathrm{title}})\wedge \mathrm{u}\mathrm{s}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}(r_{i,\mathrm{description}}).$$

(3)

A further 55 records were removed because either title or description was missing, empty, or represented only by a recognized placeholder. The final inclusion rule was:

$$E(r_i)=E_1(r_i)\wedge E_2(r_i).$$

(4)

Starting from $N_0=\mathrm{223,245}$ source records, the two filtering stages produced $N=\mathrm{215,889}$ released records. The retention rate was calculated as:

$$R={\displaystyle \frac{N}{N_0}}\times 100={\displaystyle \frac{\mathrm{215,889}}{\mathrm{223,245}}}\times 100=96.705\mathrm{\%}.$$

(5)

The filtering strategy was deliberately conservative. Records were not excluded solely because they were old, marked as repealed, associated with sparse optional metadata, unusually long, or textually similar to another record. These characteristics may reflect valid properties of legislative data, including amendments, historical acts, repeated local decisions, or incomplete source-system coverage.

4.4. Source-Preserving Normalization

Two representations were distinguished during processing: the released source-oriented representation and an analytical representation used for validation and descriptive statistics. The source-oriented representation retained the original values wherever possible. The analytical representation applied reversible or derived normalization operations without replacing the original strings.

Text normalization included Unicode normalization to Normalization Form C, replacement of non-breaking spaces with standard spaces, removal of zero-width characters, trimming of leading and trailing whitespace, and reduction of repeated internal whitespace. Formally, for a textual value $v$, the analytical form was defined as:

$$v^{\mathrm{*}}=\mathrm{c}\mathrm{o}\mathrm{l}\mathrm{l}\mathrm{a}\mathrm{p}\mathrm{s}\mathrm{e}(\mathrm{t}\mathrm{r}\mathrm{i}\mathrm{m}(\mathrm{r}\mathrm{e}\mathrm{m}\mathrm{o}\mathrm{v}\mathrm{e}\mathrm{Z}\mathrm{W}(\mathrm{r}\mathrm{e}\mathrm{p}\mathrm{l}\mathrm{a}\mathrm{c}\mathrm{e}\mathrm{N}\mathrm{B}\mathrm{S}\mathrm{P}(\mathrm{N}\mathrm{F}\mathrm{C}(v))))).$$

(6)

Case-folded versions were created only for comparisons, duplicate detection, and diagnostic matching. The capitalization of the released source text was not modified.

Recognized placeholders were mapped to missing values only in the analytical representation. They remained unchanged in the released table to preserve provenance and allow users to reproduce alternative definitions of semantic missingness.

Multi-valued categorical fields were also normalized analytically. For the act_form field, comma-separated components were split, trimmed, deduplicated, and sorted. If $S(v)$ denotes the list of components extracted from a raw value $v$, the canonical analytical representation was:

$$canon(v)=join(\mathrm{s}\mathrm{o}\mathrm{r}\mathrm{t}(\mathrm{u}\mathrm{n}\mathrm{i}\mathrm{q}\mathrm{u}\mathrm{e}(trim(x):x\in S(v)))).$$

(7)

This procedure treated differently ordered strings, such as Шeшiм (Decision), Өзгepтy (Amendment) and Өзгepтy (Amendment), Шeшiм (Decision), as the same analytical combination. The canonical values were used for frequency analysis, while the original act_form strings remained unchanged in the released corpus.

4.5. Quality Assurance and Validation

Quality assurance combined mandatory structural checks with non-destructive diagnostic procedures. Mandatory checks determined whether the dataset could be released in its final form. Diagnostic checks identified records that may require task-specific review but did not automatically classify them as invalid.

Structural validation confirmed that the final table contained the expected 25 fields. The law_id field was tested for missing and duplicated values and was required to be unique across all released records. The essential title and description fields were also checked for null, empty, and placeholder-only values after analytical normalization.

Temporal fields were parsed into standard date representations where values were available. The validation process checked whether date_adopted was parseable and applied logical-order diagnostics to optional dates, including modification, publication, and registration dates. Records that violated a temporal-consistency condition were flagged for review rather than removed automatically because historical corrections and source-entry errors could not always be distinguished programmatically.

URL validation assessed the presence and structure of the source-link fields. The checks covered URL syntax, expected domains, path structure, duplicated links, and, where applicable, correspondence between URL components and the associated law_id. The absence of an Adilet URL was recorded as a limitation but was not used as a general exclusion criterion.

Potential duplicate records were detected using normalized combinations of title and description, supplemented by selected metadata attributes. Duplicate-group membership was treated as a diagnostic indicator because legislative databases may legitimately contain acts with identical or nearly identical titles, especially local decisions, amendments, and recurring administrative instruments.

Additional checks addressed common source-level anomalies. CAPTCHA and bot-verification artefacts were detected using multilingual regular-expression patterns. Unicode and encoding diagnostics searched for malformed strings, known technical artefacts, zero-width characters, and excessive character repetition. A conservative Kazakh-language heuristic checked whether either title or description contained Kazakh-specific Cyrillic characters. This heuristic was not treated as a definitive language classifier because valid records may contain names, abbreviations, numbers, borrowed terminology, or short expressions without Kazakh-specific characters.

Text lengths were measured in characters and whitespace-delimited words. Extremely long values were flagged for examination, but no record was removed solely because of its length.

For each record $r_i$, the combined diagnostic indicator was calculated as:

$$Q(r_i)=\mathbb{I}(\underset{j=1}{\stackrel{m}{\bigvee }{q}_j(r_i)),}$$

(8)

where $q_j$ represents an individual quality-control condition and $\bigvee$ denotes the logical OR operation. A record received a combined flag when at least one diagnostic condition was satisfied.

The final release passed all mandatory integrity checks. A total of 4635 records received at least one diagnostic flag and were retained with their identifiers and flag categories documented in machine-readable quality-control outputs. This approach preserved potentially valid legislative records while allowing users to apply stricter task-specific filters.

4.6. Descriptive Analysis

Descriptive analysis was performed on the final set of 215,889 records. Temporal coverage was examined using annual and decadal frequencies, cumulative counts, and a centered five-year moving average. For annual document count $n_y$ in year $y$, the centred moving average was calculated as:

$${\overline{n}}_y^{(5)}={\displaystyle \frac{1}{\left|W_y\right|}}\sum _{k\in W_y}{n}_k, W_y=\{y-2,y-1,y,y+1,y+2\},$$

(9)

where $\left|W_y\right|$ represents the number of available years in the window. The 2026 count was treated as partial because the source snapshot ended on 20 July 2026.

Textual fields were characterized using character counts, whitespace-delimited word counts, medians, means, selected percentiles, and maxima. These statistics were used primarily to identify distributional asymmetry and unusual values rather than to define exclusion thresholds.

Categorical composition was analyzed through absolute frequencies and proportions. For category $c$, its corpus share was calculated as:

$$p(c)={\displaystyle \frac{n(c)}{N}}\times 100,$$

(10)

where $n(c)$ is the number of records assigned to category $c$ and $N$ is the total number of records. Multi-valued fields were analysed using both their original source strings and their canonical analytical representations. Pareto analysis was used to describe concentration among the most frequent categories.

Metadata completeness was calculated in two ways. Raw completeness counted every non-null value as populated:

$$C_{\mathrm{r}\mathrm{a}\mathrm{w}}(f)={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}\mathbb{I}(r_{i,f}\ne \mathsf{\varnothing }).$$

(11)

Placeholder-adjusted completeness counted only analytically usable values:

$$C_{\mathrm{a}\mathrm{d}\mathrm{j}}(f)={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}\mathrm{u}\mathrm{s}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}(r_{i,f}).$$

(12)

The distinction between $C_{\mathrm{r}\mathrm{a}\mathrm{w}}$ and $C_{\mathrm{a}\mathrm{d}\mathrm{j}}$ was used to quantify the effect of literal source placeholders on apparent metadata availability. Legal-status distributions were calculated from the status values contained in the analysed source snapshot and were not interpreted as real-time assessments of legal validity.

The complete dataset construction and validation procedure is summarized in Algorithm 1 (in pseudocode form).

Algorithm 1. End-to-end construction and validation procedure
Input: Source table S; Kazakh field mapping M; eligibility field set U; essential fields R = {title, description}; placeholder dictionary P Output: Final dataset K; analytical representation A; exclusion report E; validation report V
1	begin
2	Load the PostgreSQL source table S.
3	Retain language-independent fields.
4	Select and rename Kazakh-language _kk fields.
5	Remove corresponding Russian and mixed-language fields.
6	Validate the expected 25-field schema.
7	for each record r in S do
8	if no field in U contains usable content then
9	Exclude r.
10	else
11	Retain r in K1.
12	end
13	end
14	Confirm that 7,301 records were excluded.
15	for each record r in K1 do
16	if title or description is unavailable then
17	Exclude r.
18	else
19	Add r to K.
20	end
21	end
22	Confirm that 55 additional records were excluded.
23	Confirm that |K| = 215,889.
24	Create analytical copy A.
25	Apply Unicode and whitespace normalization to A.
26	Map documented placeholders to missing values in A.
27	Create normalized act_form values.
28	Validate schema, identifiers, required fields, and dates.
29	Apply temporal, URL, duplicate, language, CAPTCHA, encoding, and text-length diagnostics.
30	Generate exclusion and validation reports.
31	Export K, A, E, and V.
32	end

5. User Notes

KazakhLawCorpus is distributed as a document-level legislative metadata corpus. Each row represents one legislative act and contains identifiers, Kazakh-language titles and descriptions, dates, legal-status indicators, legal and institutional categories, registry information, and links to source systems. The dataset does not systematically include the complete normative text of each act. Researchers should therefore distinguish between metadata-based document discovery and provision-level legal-text analysis.

The law_id field should be preserved as a string and treated as the principal record identifier. Registry numbers should not be used as universal primary keys because their interpretation may depend on the issuing authority, document type, administrative context, or historical period. Date fields should be parsed explicitly, while missing values and source placeholders should be handled separately.

The title and description fields are suitable for document identification, metadata-based retrieval, classification, clustering, temporal analysis, and candidate-document selection. However, the description field commonly contains bibliographic information, registration notes, details of the adopting authority, amendment statements, or status-related information. It should not be interpreted as the complete legal content of the corresponding act.

5.1. Locating Corresponding Full Legal Texts

For tasks requiring articles, clauses, subclauses, paragraphs, or other provision-level evidence, researchers should use the metadata to identify the relevant legislative acts and then obtain the corresponding full texts from authoritative legal-information sources.

The recommended workflow is as follows:

• Use law_id, title, date_adopted, act_form, adopting_body, and other metadata fields to identify candidate documents.
• Open the corresponding adilet_url where available. The ekb_url field may be used as an additional source link.
• Confirm that the document title, adoption date, issuing authority, registration number, and legal status correspond to the metadata record.
• Obtain the full text from the authoritative source and preserve the source URL, access date, document identifier, and version information.
• Store and process the full text separately from the KazakhLawCorpus metadata release.

A metadata record should not be treated as proof that a linked document remains current or legally effective. Source URLs may be missing, outdated, redirected, or associated with historical versions. The current wording, amendment history, and legal status of an act should therefore be verified through an official legal-information system before the text is used for legal interpretation or decision-making.

For reproducible full-text corpus construction, researchers should preserve the relationship between the metadata record and the retrieved document. At minimum, a derived full-text collection should retain:

• law_id;
• the original document title;
• the adoption date;
• the source URL;
• the date on which the text was accessed;
• the legal-status value observed at the time of collection; and
• any available version or amendment information.

Full texts may subsequently be segmented into document-, article-, clause-, or paragraph-level units according to the requirements of the downstream task. These derived texts and segments should not be described as part of the original KazakhLawCorpus release unless they are published and documented separately.

5.2. Analytical Use and Dataset Partitioning

The dataset is provided without predefined training, validation, or test partitions. The technical train label that may appear in some dataset-loading interfaces does not represent an official supervised-learning split.

Researchers should construct task-specific partitions while considering temporal and document-level leakage. Random row-level splitting may place closely related acts, repeated titles, amendments, or different versions of similar documents in separate subsets. For temporal evaluation, records should be divided according to date_adopted. For classification and retrieval experiments, related documents should be grouped using identifiers, normalized titles, registry information, source URLs, or other relevant metadata before partitioning.

The source-oriented fields should be retained for traceability. Normalized variants may be created for modelling and analysis, but they should be stored separately rather than replacing the original values. This is particularly important for institutional names, geographical categories, historical designations, and multi-valued legal categories, where apparently minor spelling or ordering differences may carry source-specific meaning.

The quality-control indicators should be interpreted as diagnostic information rather than as a universal exclusion list. Flagged records may contain valid historical names, unusual official titles, recurring administrative formulations, or incomplete optional metadata. Researchers should define exclusion criteria according to the requirements of the individual task and report those criteria transparently.

5.3. Previous Use in LexAI

An earlier working version of the underlying legal data was used in LexAI, a Kazakh-language legal information assistant available online [32], and in the experimental study of document segmentation for legal retrieval-augmented generation reported in [28]. At that stage, the data had not yet been formally curated, validated, documented, or released as a standalone research dataset.

Within LexAI, the underlying legal data supported document identification and source traceability, while the corresponding full legal texts were processed separately and segmented into provision-level units for retrieval-augmented answer generation. The metadata were therefore used primarily for document-level selection and provenance rather than as complete normative evidence.

The present Data Descriptor provides the first dedicated description and public release of KazakhLawCorpus as a curated and validated research dataset, including its reconstructed metadata schema, provenance, data-curation workflow, quality-control procedures, and documented limitations. Details of the LexAI document-segmentation methodology, retrieval architecture, generation pipeline, and experimental evaluation are reported separately in [28]. An example of the LexAI interface is provided in Supplementary Figure S1.

5.4. Legal Status and Responsible Use

KazakhLawCorpus is intended for research, information retrieval, corpus analysis, and the development of language technologies. It should not be treated as an authoritative legal database or as a substitute for professional legal advice.

The is_repealed field represents the status recorded in the source snapshot used to prepare the dataset. It does not provide a real-time guarantee that an act remains valid, has been amended, or has subsequently been repealed. Researchers developing legal search or question-answering systems should therefore incorporate version awareness, amendment tracking, and source verification into their downstream workflows.

Any system that presents generated legal information to users should clearly disclose that its responses are automatically generated, may contain errors, and are provided for informational purposes. Users should be directed to official legal sources and qualified legal professionals before making formal legal, administrative, or financial decisions.

6. Conclusions and Future Work

This study presented KazakhLawCorpus, a large-scale corpus containing 215,889 Kazakh-language legislative metadata records from the Republic of Kazakhstan. The dataset was derived from 223,245 source records through Kazakh-language field selection, essential-field filtering, source-preserving normalization, schema reconstruction, and quality validation, retaining 96.705% of the original legislative table. The final release contains 25 fields covering document identifiers, temporal attributes, legal status, registry information, Kazakh-language titles and descriptions, legal and institutional categories, geographical information, and links to source systems.

The principal contribution of KazakhLawCorpus is the provision of a structured and traceable document-level inventory of Kazakhstan’s legislative metadata. The corpus supports metadata-based document retrieval, classification, temporal analysis, institutional and geographical normalization, duplicate and version grouping, and candidate-document selection for downstream legal-language-processing applications. By retaining identifiers and official source URLs, the dataset can also serve as a discovery and provenance layer for separately constructed full-text collections and retrieval-augmented generation systems.

Several limitations should be considered when using the dataset. First, KazakhLawCorpus is a legislative metadata corpus rather than a complete full-text legal collection. The released records do not systematically contain the full articles, clauses, subclauses, or paragraphs of the corresponding legislative acts. The title and description fields are therefore appropriate for document identification and metadata-based analysis but should not be treated as complete normative evidence.

Second, the dataset represents a snapshot of a database supplied by NUBA Solutions LLP and assembled from publicly accessible legal-information resources. The authors did not independently reconstruct the source websites or perform direct web scraping during the present study. Consequently, source coverage, URL availability, amendment information, and legal-status values depend on the state of the underlying database at the time of export. Official legal-information systems remain authoritative for determining the current wording, validity, and amendment history of individual acts.

Third, the temporal distribution is strongly concentrated in recent decades, while comparatively few records predate 1990. This imbalance may reflect historical differences in digitization and source-system coverage as well as actual legislative activity. The corpus should therefore be used cautiously for long-term historical comparisons. The value for 2026 is also incomplete because the analyzed source snapshot ends on 20 July 2026.

Fourth, the categorical metadata preserve source-level spelling, ordering, naming, and historical variation. Although an analytical representation was created for selected multi-valued fields, institutional, geographical, and legal-domain categories were not fully canonicalized because automatic merging could remove legally or historically meaningful distinctions. Raw category counts should therefore not be interpreted as counts of fully standardized legal entities.

Fifth, some optional fields contain source-system placeholders, sparse values, residual Russian- or Latin-script fragments, unusual character sequences, duplicated formulations, and incomplete source links. Quality-control procedures identified 4635 records with at least one diagnostic flag. These records were retained because diagnostic conditions do not necessarily indicate invalid data and may reflect genuine historical or source-level variation. Users should apply task-specific filtering criteria and report them transparently.

Finally, KazakhLawCorpus does not provide predefined training, validation, or test partitions, manually assigned semantic labels, question–answer annotations, or provision-level relevance judgements. Researchers developing supervised or retrieval-based benchmarks must construct and document their own partitions while controlling for temporal, document-level, and version-related leakage.

Future work may extend the resource through periodic source updates, automated checking of official URLs, improved tracking of amendments and document versions, and the development of reviewed mappings for institutional, geographical, and legal-category variants. Further manual assessment of diagnostically flagged records could support the correction of encoding artefacts and the refinement of language and duplicate-detection procedures.

A complementary direction is the construction of a separately documented full-text legal corpus linked to KazakhLawCorpus through stable document identifiers and source URLs. Such a resource could preserve articles, clauses, document versions, retrieval units, and provenance information without changing the metadata-focused scope of the present release. It could subsequently support expert-validated benchmarks for legal retrieval, classification, document linking, summarization, and evidence-grounded question answering in Kazakh.

Overall, KazakhLawCorpus establishes a reusable metadata foundation for research on Kazakhstan’s legislation and Kazakh-language legal NLP. Its value lies not in replacing authoritative legal sources, but in providing a structured, transparent, and reproducible layer through which legislative documents can be identified, analyzed, organized, and connected to specialized downstream resources.