Building China Coverage Into Your Legal AI: A Data Stack Walkthrough

"Add China" lands on the roadmap, and the engineering team inherits a deceptively large question. It sounds like a content problem — get the Chinese judgments, point the model at them, ship a China tab. In practice it's a data-infrastructure problem, and the teams that underestimate it spend two quarters discovering, layer by layer, that the model was never the hard part.

This walkthrough lays out the stack you actually have to stand up to ground a legal AI product in Chinese case law — six layers, bottom to top — what each one demands, where China-specific work hides, and which layers are worth building versus buying. It's written for the VP of Engineering or Head of Data who has to scope the project before committing a roadmap quarter to it.

The stack, bottom to top

Every layer depends on the ones beneath it. The output quality your users see at the top is capped by the weakest layer at the bottom — which is exactly why "just run RAG over it" fails when the corpus underneath is partial or messy.

Teams tend to budget generously for the top — the model, the prompt engineering, the UX — and almost nothing for layers 1 through 3. That allocation is backwards. Let's go up from the bottom.

Layer 1 — Corpus: coverage is the foundation, and it's not free-flowing

Everything rests on having the judgments. The trap is assuming they're freely available in bulk because they were once published openly. They were — and then the tap narrowed. Public availability peaked in 2020 at 19.2 million judgments in a single year and fell sharply through 2023; in 2024 the comprehensive database moved behind the courts' internal network, leaving a smaller public reference library. We cover the full availability curve separately, but the engineering consequence is blunt: there is no open, comprehensive feed to point a crawler at today. What you can reach is an uneven slice, thin in exactly the recent years many products care about. Your corpus layer either solves coverage deliberately or quietly biases everything above it.

Layer 2 — Ingestion & cleaning: the unglamorous 90%

Raw judgments are not training data. Chinese court documents vary in format across courts and years; the same judgment surfaces in multiple copies; encodings and boilerplate differ. Before anything upstream works you need parsing that reliably separates reasoning from operative ruling, deduplication that doesn't inflate your counts, and normalization that makes a 2014 document and a 2023 document look the same to your pipeline. This is ongoing engineering, not a one-time script — and it's the layer most likely to silently break when a source changes.

Layer 3 — Structure & normalization: fields are what make it queryable

To filter, cite, and retrieve, every record needs stable structured fields: case number, court, level, date, cause of action, parties, outcome. Deriving these reliably from free text across decades is a real NLP project in its own right — and it's the layer that makes or breaks everything above. Without a clean cause-of-action taxonomy your retrieval filters are noise; without stable case numbers your citations can't be verified. We go deep on the field model in our case law API and document structure walkthrough; the point here is that this layer is not optional polish, it's load-bearing.

Layer 4 — Retrieval: where your product finally starts

Now embeddings and metadata filtering earn their keep. Semantic retrieval finds judgments that are on point even when the wording differs; metadata filters (court level, year, cause of action) keep results relevant and citable. But note: every bit of retrieval quality here is inherited from layers 1–3. A perfect embedding model over a partial, unnormalized corpus still misses the precedent your user needed. This is the first layer where your engineering genuinely differentiates the product — which is the argument for not burning your best engineers on the three layers below it.

Layer 5 — Grounding & citation: the trust layer

Legal users don't accept answers; they accept answers they can verify. Grounding ties each model claim to a specific judgment a user can open and check, which is why stable citation identity from layer 3 matters so much. A China feature that surfaces the right reasoning but can't produce a checkable case number, court, and date is, to a lawyer, no different from a hallucination. Build this layer assuming every output will be scrutinized — because in legal it will be.

Layer 6 — Evaluation: you can't ship what you can't measure

Finally, you need a representative test set — queries spanning courts, years, and causes of action with known-good answers — to measure whether retrieval and grounding actually work, and to catch regressions. A lopsided eval set built only from the years and courts that were easy to obtain will tell you the system works while it fails on everything outside that slice. The quality of your evaluation is, once again, downstream of the coverage and structure at the bottom of the stack.

Build versus buy, by layer

The strategic question isn't "build or buy the whole thing" — it's which layers. The dividing line is differentiation: buy the layers that are pure cost and commodity for you, build the layers where your product competes.

The bottom three layers are where China projects stall, and they're also where you have zero differentiation to gain — every legal AI vendor parsing the same judgments produces the same fields. Spending a quarter building a Chinese-judgment ingestion pipeline buys you nothing a competitor can't replicate, while your actual product — retrieval quality, citation UX, eval rigor — waits. The teams that ship China coverage fastest start at layer 4, because they bought the foundation rather than rebuilt it. (For the deeper cost argument against scraping the corpus yourself, see license vs scrape.)

Where SinoVerdict fits

SinoVerdict is the bottom three layers, delivered solved. We license a structured, machine-readable corpus of more than 130 million Chinese court judgments, coverage through 2023 with incremental updates on request, already deduplicated, with stable fields — case number, court, date, cause of action, parties, outcome — on every record. It ships two ways that map directly onto the stack: a bulk dataset for training and for building your own index, and a REST API plus MCP server for live retrieval, with AI-use rights in writing. Your team integrates it at layer 4 and builds retrieval, grounding, and evaluation on top — the layers where your product actually competes — instead of spending the quarter on data plumbing nobody will ever see.