Justinian

ChatGPT is a general-purpose language model that generates plausible-sounding text. Justinian is a legal AI engine: before any general model is called, it establishes what you are actually asking, which jurisdiction applies, what language the governing law is in, and what the request needs. The general model then runs on a question that has already been framed. It applies legal rules to facts, respects jurisdictional boundaries, cites retrieved sources, and produces structured, client-ready deliverables.

Yes. Justinian searches verified legal databases and authoritative sources before answering. Every citation is traceable and verifiable. When sources conflict or the law is ambiguous, Justinian flags the uncertainty rather than presenting a confident but wrong answer.

Yes. Justinian drafts natively in Arabic, English, French, and other languages with full RTL support. It understands legal nuance in each language and can produce bilingual contracts while maintaining legal precision across both versions.

Justinian reasons across MENA, Europe, the US and international arbitration frameworks including ICC and UNCITRAL, and it drafts in English, Arabic and French. Depth varies by jurisdiction, because it depends on how well the source law is digitised and how much of it is public. Rather than quote a single global number, we would rather answer the question for the specific jurisdiction you work in.

Yes. Every Justinian output includes a transparent reasoning chain - you can see which rules were applied, which sources were consulted, and how the conclusion was reached. This auditability is critical for professional accountability and client trust.

Your question does not go straight to a general-purpose model. It first passes through a step we own and control, which establishes what you are actually asking, what kind of legal work it is, which jurisdiction is in play, what language the governing law is written in, and the facts inside your request as structured data. Only then does the general model run, and it arrives with the question already framed rather than guessing at it.

Two reasons. A model's context window is finite, so anything loaded unnecessarily competes for attention with your actual document. And a model handed structured facts instead of a wall of prose spends its budget on legal reasoning rather than on parsing what it was given. The second effect is larger than most people expect, and it is why the same general-purpose model produces better legal work inside Justinian than inside a simple wrapper.

We deliberately do not build on a single vendor. A third-party frontier model performs the final generation, but every layer that carries our value runs independently of any particular one: orchestration, tooling, retrieval, memory and safety. Justinian is architected to route different kinds of legal work to different models, so if a better or cheaper model appears, adopting it is a configuration change rather than a rebuild.

Yes. We treat document intake as a first-class engineering problem rather than a preprocessing afterthought, because a large share of legal work arrives as a scan, a photograph of a stamped page, or a PDF that was printed and re-scanned crooked. An error introduced at that stage cannot be recovered later: the system would reason impeccably about the wrong clause number.

Yes. Justinian holds the relationships between your matters over time and draws on them when a question calls for it, rather than simply replaying recent messages back into the prompt. That is what lets it recognise that the counterparty in a contract you are reviewing today is the same one from a dispute two months ago.

Any system built on a language model can produce a wrong answer, and any vendor who tells you otherwise is not being careful with words. What good architecture does is make wrongness rarer and detectable: legal claims are generated against retrieved sources, every claim carries a citation you can open, and where sources conflict or the law is genuinely ambiguous Justinian flags the uncertainty instead of resolving it for you. It is built to be reviewed by a professional, not to replace one.

Four questions in a demo, and they work on any vendor including us. Ask it something outside law: a wrapped general model will usually answer a medical question. Ask the same legal question in two languages: if the substance changes, language is handled after the reasoning rather than before it. Upload a badly photographed document. And push it toward an unsettled area of law, where a system built for professional work will tell you the ground is uncertain instead of producing a confident answer.

Against legal-specific benchmarks rather than general ones, because a model that scores well on general reasoning can still be useless on a clause. Clause-level validation, jurisdictional accuracy and continuous feedback from practising lawyers drive what the engine does before and around every model call: what gets retrieved, which capabilities run, and what gets flagged for human review. The results are published rather than described, including the ones where a frontier model beats us.

Every figure we publish declares how we know it. Measured means it comes from our own usage data or our own benchmark run. Cited means it is a third-party finding, linked to its source. Illustrative means it is a directional scenario, and it carries a badge saying so, including on the worked examples further up this page. If a number does not say which of the three it is, treat that as a defect and tell us.

Yes, and you should be suspicious of any legal AI vendor who does not. A benchmark that its author always wins is marketing, not evaluation. Our published runs include tasks and categories where a frontier model scores above us, because a buyer needs to know where the tool is strong and where it is not before they rely on it in front of a client.