English-Language Access to Chinese Court Judgments: API, MCP and Translation Boundaries

SinoVerdict offers access to Chinese court judgment records through structured interfaces. An English interface, English query understanding, an English summary, and a complete English translation are separate deliverables. The public labor-dispute demo accepts Chinese search terms. Its response to the English query “overtime pay”, checked on 17 October 2026, explicitly says that this beta search index is Chinese-language only. That observation does not establish the capabilities of a separately scoped enterprise implementation.

For an English-speaking legal AI team, the practical question is therefore which layer has been demonstrated on the endpoint you will actually use. This guide separates those layers, describes the current public access surfaces, and gives a concrete acceptance plan. It does not represent the 160M+ record corpus as a fully translated English collection or promise that every record includes complete text.

What can a buyer verify today?

The table distinguishes a documented interface from an unverified language capability. “Not verified” means that this page supplies no successful demonstration of that capability; it is not a finding that every enterprise configuration lacks it. Before a purchase, request a test against your exact endpoint, scope, language pair, and document slice.

Start with the Chinese record, then specify the English layer

A judgment record can contain a title, case number, court, decision date, category labels and stored Chinese text. These elements are useful for retrieval even when no English rendition exists. They also let a bilingual reviewer check whether an English answer is attached to the intended proceeding. The case number identifies a proceeding; one proceeding can have several documents, so it should not automatically become your unique document key.

SinoVerdict uses 160M+ records as its corpus-size description. That is a record count, not a count of distinct disputes, translated documents, or records with complete bodies. Procurement should ask for those quantities separately. The metadata census and year-coverage analysis explain why a single headline does not describe every slice.

For each sample result, retain the delivered identifier, available case number, court and date, plus the length and availability of the stored body. Keep missing values explicit. If the record provides only an excerpt, do not label the excerpt “full judgment”. If it provides a nonpublication explanation instead of a judgment body, do not ask a translator to manufacture the absent decision.

English queries require a retrieval test, not an English label

An English-speaking team might ask for “overtime pay”, “unfair competition”, or “shareholder inspection rights”. Translating those expressions into Chinese is only the first step. The translated query must retrieve the intended legal issue under the endpoint's actual matching rules. A title search, a body search and an exact category filter can each produce different sets even when their labels sound interchangeable.

Prepare a small bilingual test list with a Chinese reviewer. For every English question, record the intended issue, an agreed Chinese expression, any date or region constraints, and examples of relevant and irrelevant results. Submit both the English expression and the Chinese control to the same endpoint. A zero-result English query alongside a successful Chinese control indicates a language-access boundary, not absence of Chinese cases on that issue.

Record what your own application translated before sending the request. If your assistant supplies the Chinese search term, describe the workflow as assistant-assisted translation over a Chinese retrieval service. Do not attribute that translation to the API. This separation makes failures diagnosable: a poor translation needs a different fix from a missing body, an unsupported filter, or a service error.

English summaries and full translations need different acceptance criteria

A summary supports triage: what kind of dispute this is, which court decided it, and what portions deserve closer reading. A full translation attempts to render the delivered document in another language. Neither should silently fill gaps in the source. If the Chinese body stops before the operative section, a fluent English disposition is not evidence that the missing section was recovered.

Ask the supplier to identify whether a summary is stored, generated on request, or produced entirely by your own model. For generated text, record the source record, available source span, generation date and review status. Keep the Chinese text next to the English result during review. Distinguish a party's requested remedy, the court's reasoning and the final order; these can disagree within a single judgment.

For a translation deliverable, specify whether headings, tables, monetary amounts, citations and procedural notices are included. Agree how omitted or unreadable passages appear. Test with the actual document types you need: a short enforcement ruling and a long civil judgment impose different demands. A polished example from one type is not a corpus-wide acceptance result.

REST and MCP are access methods, not language guarantees

REST is convenient when your application controls pagination, caching, logging and response validation. The public demo documents a labor-dispute slice; use its displayed request shape rather than assuming that every endpoint accepts the same filters. For enterprise use, request current documentation for the exact API base, schema, permitted parameters, response limits and credentials you will receive.

MCP lets an assistant discover callable tools. The current remote four-tool service separates finding records, retrieving stored text, checking a case number and checking a quotation against stored text. That tool list does not contain a dedicated general translation or English-summary tool. An assistant can still translate as part of its own reasoning, but that remains a separate model operation with separate quality and data-handling considerations.

Do not mix the remote service with an older local adapter simply because both use the SinoVerdict or Wenshucha name. Tool names, corpus slices, output fields and identifiers can differ. Save the advertised tool schema at integration time, validate the actual response, and keep a small regression set when changing clients or endpoints. A successful transport connection proves connectivity, not retrieval quality or contractual permission.

Source citations need an explicit boundary

The full-corpus source-link limitation matters: current full-corpus interfaces do not provide usable original judgment URLs as a general field guarantee. Do not construct a court URL from a case number or treat a field called source_url as evidence that a working source link exists. A separate sample endpoint can have different link coverage; that does not transfer to the full corpus.

For review, retain the identifiers and the available court, date and case number, then perform any required official-source check separately. A match inside this corpus verifies what this corpus contains. It does not certify authenticity, prove that no other document exists, establish current appeal status, or make an extracted passage admissible evidence. The official endpoint inventory describes several distinct publication surfaces.

A practical pilot for an English-speaking legal AI team

1. Choose the job. State whether you need bilingual search, English triage, full translation, extraction, or bulk ingestion. Include the intended users and output destination.
2. Fix the slice. Name document types, years, regions and any exclusions. Ask for raw record counts, distinct-case methodology and body availability separately.
3. Run paired queries. Keep English prompts and Chinese controls together. Preserve empty responses and errors rather than quietly replacing unsuccessful questions.
4. Review returned evidence. Check relevance and source text with a bilingual reviewer. Mark metadata-only records, excerpts and truncated bodies distinctly.
5. Evaluate the English output. Separate retrieval errors from mistranslation, unsupported summaries and invented conclusions. Ask for corrections on the same examples.
6. Confirm permitted use. Review evaluation, storage, end-user display, model training and redistribution separately under the proposed agreement.

Define acceptance before running the pilot. For example, your team can specify which legal issues must be found and what counts as a material translation error, then agree the sample size and review method. These are project criteria, not performance claims made by this article. Keep the failed examples as part of the handover so a later demonstration cannot quietly change the test.

Finally, ask how a delivered snapshot will be identified and updated. Record count changes can come from new ingestion, duplicate handling, re-extraction or removal. A running service does not prove a daily publication lag for every slice. Agree the update artifact and the notification process your application needs, rather than inferring a service-level commitment from a marketing phrase.

What to include in an access request

Send your target issue, date range, region, desired interface and two or three representative queries. Say whether you need Chinese source text, an English summary or full translation. For bulk evaluation, also describe the fields and storage environment. This gives the data team enough information to propose a demonstrable scope without treating every use as the same product.

Then review the licensing acceptance guide alongside the technical results. API functionality, document completeness, language quality and permitted use should each have their own written answer. A trial is useful because it lets you test those answers; receiving access alone does not establish them.