What is Legal Data?

Legal filings, case law, and statutory text, used for legal search, contract analysis, and legal question-answering models.

Rows of labelled paper case files standing on a records-office shelf

Legal data is filings, case law and statutory text. It is a jurisdiction-specific category: US case law and Chinese statutes are entirely different datasets with different structures, and a corpus that does not name its jurisdiction cannot be evaluated.

The structure is as important as the text. Legal documents have a hierarchy of parts, sections and paragraphs, and citations that link documents to each other. A corpus that flattens the hierarchy loses most of what makes legal text usable.

The uses are legal search, contract analysis, and legal question answering. Each needs a different subset: search needs citations and structure, contract analysis needs clause segmentation, and question answering needs outcome annotation.

What buyers get wrong

The jurisdiction has to be explicit. US case law and Chinese statutes are entirely different datasets, and mixing them is meaningless.

The specification detail that decides everything

Jurisdiction, time range, and whether outcome annotation is included.

This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.

How we source it

We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.

Scenarios this covers

Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.

  • Case law and judgments
  • Statutes and regulations
  • Contract clause libraries
  • Contract review pairs
  • Clause classification
  • Legal summarisation
  • Legal question answering
  • Citation and reference extraction
  • Named entity extraction in contracts
  • Party and obligation extraction
  • Due diligence document sets
  • Compliance policy documents
  • Regulatory filings
  • Court docket records
  • Intellectual property filings
  • Employment agreement clauses
  • M&A document sets
  • Real estate and lease documents
  • Terms of service corpora
  • Privacy policy corpora
  • Legal translation pairs
  • Multilingual legal corpora
  • Redaction and privilege review
  • Jurisdiction and date metadata
  • Public-domain and licensed sources only

What good Legal Data looks like

Legal data is judged on its jurisdiction, its document structure, and the completeness of its citation graph.

  • Jurisdiction named explicitly, per document

    Not implied by the language, because the same language covers multiple jurisdictions with different law.

  • Document structure preserved

    Hierarchy of parts, sections and paragraphs with the numbering intact, because legal citation depends on it.

  • Citation graph included where the use needs it

    Which documents cite which, because precedent-following is the structure of case law.

  • Time range stated, with the coverage of amendments

    Statutory text changes, and a corpus that does not say which version it contains cannot be relied on.

  • Outcome annotation where applicable

    For case law, the holding or the disposition, because a corpus of opinions without outcomes supports search and not prediction.

Public datasets in this category

These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.

  • CourtListener and RECAP

    A free legal research collection with court opinions and federal filings, with a citation network. The largest openly accessible US collection and its coverage of older material is uneven.

  • Caselaw Access Project

    Digitised US court opinions spanning centuries, released for research. Commercial use is restricted.

  • EUR-Lex

    European Union law with legislation, case law and treaties in all official languages. The parallel structure across languages is unique and the domain is EU law only.

  • Legislation portals by jurisdiction

    Most jurisdictions publish statutes through an official portal, usually without machine-readable structure. They are authoritative and they have to be parsed individually.

Questions to ask a supplier

Questions that establish the jurisdiction, the structure and the citation coverage.

  • Which jurisdictions are covered, named per document?
  • Is the document hierarchy preserved with numbering intact?
  • Is a citation graph included?
  • What is the time range, and how are amendments handled?
  • Is outcome or holding annotation included?

The vague answer in this category is about jurisdiction. A supplier who says the corpus is English legal text has described a language rather than a legal system. Common-law and civil-law material follows different rules, and a corpus that mixes them cannot be filtered on the dimension that determines the answer.

A verifiable answer names the jurisdictions, the document types, the versioning treatment for amended texts, and the citation format. Ask whether the document hierarchy was preserved, because flattened opinions and statutes lose the section numbering that citations depend on.

Technical attributes

The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.

JurisdictionNamed per document
Document structureHierarchy preserved with numbering
Citation graphIncluded or not, with direction
Time rangeStated, with amendment coverage described
Outcome annotationIncluded or not, for case law
Delivery formatStructured documents with a schema and a citation index

The document hierarchy column decides what the corpus can support, and it is the one most often lost in conversion. Statutes and opinions are structured by section, and citations refer to that structure. A corpus converted to plain text loses the numbering, and the loss is irreversible.

The values come from the task. Retrieval, summarisation and citation-aware question answering need different structures and different metadata. The specification should name the task, because a corpus built for retrieval is not sufficient for citation work.

A mistake here is discovered as a wrong answer that looks right. A corpus without versioning contains one version of a statute without saying which, and any date-sensitive question gets an answer that was correct at some point. For legal work that is worse than no answer, because it is confidently wrong.

How Legal Data is collected

The work is parsing structure and building the citation index.

  1. Jurisdiction and court-level scoping. The jurisdictions and court levels are fixed from the use case, because a corpus mixing trial and appellate courts behaves differently.
  2. Source acquisition and rights review. Where the text comes from and under what terms, including any restriction on redistribution.
  3. Structure parsing. The document hierarchy is parsed with numbering preserved, because citation depends on it and flattening is irreversible.
  4. Citation extraction and linking. Citations are extracted and resolved to documents within the corpus, producing the citation graph.
  5. Outcome annotation where required. Holdings or dispositions are annotated against a stated scheme, and a sample is checked for consistency.

After assembly, documents are parsed with their hierarchy preserved, amendments are versioned with effective dates, and the files are packaged with per-document metadata covering the jurisdiction and the document type. The versioning is the step that makes the corpus usable for anything date-sensitive.

The pilot for legal material is a slice from one jurisdiction parsed with its hierarchy preserved, run before the full assembly. Its purpose is to confirm that the section numbering and the citation format survive the conversion, because flattened text loses the structure that citations refer to and the loss is irreversible. One jurisdiction end to end shows what the rest will cost.

Acceptance is checked on the hierarchy as parsed and on the versioning of amended texts, both verified before the batch is accepted. The specification should name the jurisdictions and the document types before assembly starts. Where the pilot shows the structure was lost, the parsing is redone rather than the corpus accepted, since a legal corpus without hierarchy supports retrieval but not citation work.

How a delivery goes wrong

The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.

  • Jurisdiction was recorded as language

    A corpus labelled "English legal text" mixes US, UK, Australian and other common-law material. The rules differ, and the corpus cannot be filtered on the dimension that determines the answer.

  • Document hierarchy was flattened

    Converting opinions and statutes to plain text loses the section numbering that citations depend on. The loss is irreversible and it removes the ability to support citation-aware tasks.

  • Amendments were not versioned

    Statutory text changes over time. A corpus that contains one version without saying which cannot be relied on for anything date-sensitive, and consolidating versions afterwards is not possible.

Why this matters to buyers

Legal work is citation-driven. Finding the authority for a proposition means following the citation graph, and a corpus that contains the text without the graph does not support the task.

The second driver is jurisdiction specificity. A model trained across jurisdictions without labels learns a blend that matches none of them, and legal question answering is a task where a blended answer is worse than no answer.

A legal model built on a corpus without versioning gives confident answers that were true at an unstated time. The errors are not visible in evaluation, because the evaluation sets were drawn from the same corpus. In a legal product that failure mode is the one that ends the product.

The second cost is jurisdiction confusion. A corpus described by language rather than by legal system mixes material from several countries, and the model applies rules from one to questions about another. Fixing it requires per-jurisdiction collection, which means the original batch was partly wasted.

A legal corpus with hierarchy and versioning gives answers that can be traced to a section and a date. The team can build citation-aware products rather than search, and date-sensitive questions return the version that applied rather than the version that happens to be current.

The second gain is per-jurisdiction separation. Common-law and civil-law material follows different rules, and a delivery that records the jurisdiction per document can be extended to a new one without the two being mixed. That record is what makes a legal corpus defensible.

Specification at a glance

CategoryLegal Data
GroupNon-speech data
Critical specJurisdiction, time range, and whether outcome annotation is included.
Included by defaultPilot batch, metadata schema, source and consent documentation
PricingQuoted from specification. No published rates

See how a Legal Data delivery is structured →

Related categories

  • LLM Training Data

    Non-speech

    Text corpora for LLM pretraining and fine-tuning: instruction data, preference data, and multi-turn dialogue data.

  • Computer Vision Data

    Non-speech

    Annotated image and video data, with annotation types including classification, bounding boxes, segmentation masks, and keypoints.

  • NLP Data

    Non-speech

    Annotated text for NLP tasks: named entities, dependency syntax, sentiment polarity, and relation extraction.

  • Multilingual Language Data

    Non-speech

    Parallel or non-parallel text corpora spanning multiple languages, used for multilingual models and low-resource language research.

  • Translation Data

    Non-speech

    Parallel corpora pairing source and target language, used for machine translation training and evaluation.

  • Dictionary Data

    Non-speech

    Structured dictionary entries with definitions, parts of speech, pronunciation, and example sentences, used for dictionary products and lexical understanding tasks.

Questions about Legal Data

Why must jurisdiction be labelled per document?

Because the language does not determine the law. English-language documents come from many jurisdictions with different rules, and a corpus that records only the language cannot be filtered by the dimension that matters.

Can you flatten the documents into plain text?

We preserve the hierarchy. Flattening loses the numbering that citations depend on, and the loss is irreversible, so a flattened corpus cannot be used for citation-aware tasks.

Is outcome annotation necessary?

Only if the use requires it. Search and retrieval work without it; prediction and outcome analysis do not. It is a significant annotation effort and belongs in the specification as a separate item.

How are amendments handled?

By stating which version of the text the corpus contains and whether superseded versions are included. Statutory text changes, and a corpus that does not say which version it holds cannot be relied on.

Do you have Legal Data available now?

No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.

Can this be combined with other categories in one delivery?

Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.

What does the consent documentation cover?

Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.

Request Legal Data

Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.

  • Pilot batch before the full run, so problems surface early.
  • Consent documentation delivered with the data.
  • No medical or clinical data. No recorded telephone calls.

We reply within two business days. Your details are used only to answer this request. See our privacy policy.

  1. You send the spec Language, hours, recording conditions, and the deadline.
  2. We reply within two business days A real number and a real timeline, not a range.
  3. You approve a pilot batch A small run first, so problems surface before the full order.
  4. Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.
Contact

Talk to a human

Send a specification and we will come back with a real number and timeline.

Submit a sourcing request

Or use the contact form