Every Turkish competition decision, and the fields a lawyer adds

The complete published decision history of the Turkish Competition Authority is now one file you can download: emirms/turkish-competition-authority-decisions on the Hugging Face Hub. 10,367 decisions from November 1997 to June 2026 — around 113,000 pages and 323 million characters of full text, plus 35 columns of structure, in a single 107 MB parquet file. The count matches the total the Authority itself publishes, which is the only coverage claim worth making: not comprehensive, but the same number they have.

A paragraph of background, for anyone who does not work in Turkish competition law. The Rekabet Kurumu is the national competition regulator; its decision-making organ, the Rekabet Kurulu or Competition Board, clears or blocks mergers, opens and closes cartel and abuse-of-dominance investigations, grants exemptions, and imposes fines. It does that under Law No. 4054 on the Protection of Competition — Article 4 on restrictive agreements, Article 5 on exemptions, Article 6 on abuse of a dominant position, Article 7 on merger control, Article 16 on fines.

Turkish legal NLP already has court-decision corpora; the competition regulator was missing from them. But scraping 10,367 PDFs is a weekend of patience, not an idea. The part worth writing about is what came after, which is deciding what to record about each decision — because a corpus is nothing but the sum of those decisions. I am a lawyer who writes software rather than an engineer who reads law, and that shows up in the schema in ways I did not plan and noticed only afterwards.

the field that gives it away

Each decision carries an appeal_status: whether it was challenged before the administrative courts or the Danıştay, and whether it survived. 933 of the 10,367 decisions were challenged, across 2,118 separate court cases. 547 were upheld. 225 were annulled. Sixty-four of those 225 had originally found a violation.

That field is the tell. An engineer building a competition-law corpus would extract the text, the parties, the date, the outcome, the fine — everything the document says about itself — and stop there, because the document is the artefact and the document is complete. It would not occur to them to go and ask a second source whether the document is still good law.

To a practising lawyer that is not an enrichment. It is the first question. Citing an annulled decision in a submission is not a data-quality curiosity; it is a professional failure, the kind that is noticed by the other side. So the field exists, and it is derived from the Authority's own published judicial-review records rather than from the decision text — because the decision cannot know its own fate.

Getting it right meant refusing some tempting shortcuts. A stay of execution (yürütmenin durdurulması) is interim relief, not an annulment — and stay rulings are about a third of the procedural stages in this data, so reading them as merits outcomes would corrupt the field wholesale. A reversal and remand resets the status to unresolved rather than resolving it, because a remand means the question is open. And the label never comes from the prose on the page, which routinely contains the word iptal because it is quoting the title of the decision under challenge. Each of those is a legal judgement rather than a parsing decision, and each one changes the number.

the gaps are in the file, on purpose

Here is the thing I would most want a reader to take away, and it is not a feature the dataset card can make sound impressive.

The outcome field — what the Board actually held — is populated for 81.2% of decisions. The precedent graph, the list of other Board decisions each decision cites, covers 24.6%. appeal_status covers 9.0%, because 91% of decisions were simply never challenged. Every field that could not be parsed confidently is null or empty, with a machine-readable code recording why in an enrichment_issues column, and the fourteen records where I corrected something carry a repairs label saying what I changed.

None of that is a shortfall I am admitting to. It is the product.

A dataset that tells you where it is thin can be used. You can restrict a study to the 8,415 decisions that carry an outcome, report that denominator, and know what your finding is about. A dataset that implies uniform quality cannot be used for anything careful, because the errors are invisible and they do not announce themselves at the point where they matter — they announce themselves in your conclusion, months later, as a number that is wrong in a direction nobody can reconstruct.

The 18.8% of decisions with no outcome label are there because the operative section could not be located, or because its wording was not one the extractor recognised. I could have closed that gap by guessing from language elsewhere in the document. The gap is the honest answer, so the gap is what is published.

what the Board held, not what it discussed

outcome is derived from the operative section — the SONUÇ, the part that actually holds — and from nothing else.

This sounds pedantic until you see what the alternative does. A Board decision is a long piece of reasoning. It can spend twenty pages considering whether conduct falls within Article 4, rehearsing the parties' argument that it should be cleared, quoting earlier decisions that cleared comparable conduct — and then decline to clear it. A keyword classifier reading the whole document sees cleared everywhere. It is not wrong about the text. It is wrong about the law, which is a different and worse kind of wrong, because the label looks fine and sits in a column called outcome.

The same rule applies to fines. fine_imposed is true only where the Board actually imposed one, so a decision that discusses a penalty and then declines to impose it — time-barred, say — reads false. 795 decisions imposed a fine. Matching on phrase presence would have produced roughly twice that, most of them wrong.

A lawyer knows the operative section is the decision and the rest is reasons, because that distinction is what they are trained on. It is not obvious from the outside, and it is invisible to a model that has only ever seen the document as a bag of sentences.

panels, without the names

Every decision records the panel that decided it: the presiding member, the other members who sat, and the rapporteurs who worked the file — all as stable pseudonymous identifiers of the form kisi_1a2b3c4d, never as names. The same names have been removed from the decision text as well. 1,190 distinct people sat on panels or worked files across the corpus.

The identifiers are stable, so the analytically interesting question survives: you can still ask which other decisions a given member sat on, how a panel's composition tracks its outcomes, whether particular combinations recur. What does not survive is using this file to assemble a dossier on a named public servant, which is not necessary to any of those questions.

This is a deliberate choice and not an oversight, and I want to be precise about what it is: pseudonymisation, not anonymisation. The salt is held locally and is not distributed, so the mapping cannot be reconstructed from the dataset. But the original PDFs remain publicly available from the Authority, and the decision texts still name party representatives and occasionally carry addresses — those were never extracted as fields and are not redacted. Anyone processing the full text should assume other personal data is in there and handle it accordingly.

two things you could actually build

Two things the fields genuinely support. I am not going to speculate past them.

A precedent graph. 2,555 decisions cite at least one other Board decision, giving 8,212 edges, every one validated against the corpus's own set of real decision numbers rather than harvested from any number-shaped string. That is a citation network you can walk: which decisions the Board keeps returning to, which lines of reasoning propagate, where a doctrine enters the case law and how far it spreads.

Survival analysis on judicial review. You have the outcome, the articles relied on, the panel, the fine, and whether the decision was annulled. You can ask which of those correlate with a decision being struck down. I have not run it, and I am not going to imply a finding I do not have — but the columns needed to ask the question are all in one file, which they were not before.

what it does not do

Nine decisions, all from 2022 to 2024, have no text at all: the source PDFs are images with no text layer, flagged suspected_scan, and I applied no OCR.

Publication lags the decision itself by a median of three months and often much longer, so the most recent months are always thinner than they will eventually be. Anything keyed on decision date keeps changing under you.

And the important one: every derived field is extraction, not ground truth. outcome, appeal_status, cited_law_articles and the rest are my reading of the document, produced by rules I wrote, and they are wrong somewhere. They are a way to find the decisions you need and to describe a corpus in aggregate. They are not a substitute for reading the decision, and nothing here is legal advice. Where appeal_status says unknown — 93 decisions — the classifier declined to label rather than guess, and some of those are probably recoverable.

The dataset is published under a custom licence, turkish-public-sector-information, covering material the Authority publishes freely. If the terms matter to what you intend to do, read the licence on the dataset page rather than taking my summary of it, and note that responsibility for compliance with KVKK and, where relevant, the GDPR sits with whoever processes the data.

why bother

Turkish legal material is badly served by the tooling that exists, and the gap is not model quality — it is that the primary sources are PDFs behind search forms, one document at a time, with no structure a program can hold. I have been working the same problem from the other end with yargi-mcp, an MCP server for Turkish legal databases.

The argument of this post is narrower, though. Building a legal dataset is not a text-processing problem with some domain vocabulary attached. The schema is the legal work: what counts as an outcome, when a decision stops being authority, which distinctions you are allowed to collapse. Get those wrong and you have a clean, well-formatted, quietly misleading file — and nobody downstream will catch it, because it will look exactly like a good one.

The dataset is here. It is refreshed from the source rather than frozen. If you find something wrong in it, I would like to know.