The structure is the work. The prose is the rendering.

From a distance, a Statement of Claim looks template-shaped: fill in parties, allege facts, cite statutes, request relief. Most legal-AI tools are built on this assumption. It is also what makes them unfileable in real litigation.

Every cause of action is a legal object with internal structure: elements that must be proven, evidence supporting each element, defenses available to the defendant, relief construction that depends on election and subsumption. A tool that produces legal-looking text without modeling this structure produces a document that falls apart on the first read by an experienced litigator.

Every statutory section governs a testable predicate. §15(4) of the Israeli Defamation Law governs expression of opinion on public action. §16(ב)(1) creates a bad-faith presumption when the defendant knew, or should have known, that the publication was false. §19(4) governs apology, correction, or cessation of distribution, a mitigating factor for defendants who did them.

A tool that matches sections by linguistic similarity can reach for §19(2) (defendant's subjective belief in truth) when the right anchor is §19(4) (corrective conduct). The sections sound similar. Their predicates are different. The result: a Statement of Claim with a doctrinal anchor that does not match the argument it carries. The court will see it. Opposing counsel will see it.

ORCA does not match sections by similarity. It evaluates predicates — what the section actually requires — against the facts you supplied. The section is named at the end, as a consequence of the evaluation, not at the start.

Instead of a clause library, ORCA holds full models of causes of action. Each model includes the elements that must be proven, the predicates for each element, the evidence requirements per element, the defenses available to the defendant, the relief construction — and the doctrinal anchors that link all of these to statutes and case law.

When ORCA assembles a Statement of Claim, it does not pick clauses and string them together. It evaluates which causes apply to the case, which elements are satisfied by the facts, decides election and subsumption between competing causes, derives the relief construction — and only then passes the assembled structure to a voice layer that renders it as prose.

The method is built broadly across dozens of civil-law areas, but depth is not uniform. It runs deepest on defamation, then contracts, consumer, lease and real estate - the areas taken end-to-end on a real case through the current validation stack. Other areas hold a modeled scaffold not yet run in full. In each area the same methodology is applied to new content; it is replicable and transferable - that is how depth and new jurisdictions are added. The corpus of cause models, and the validation apparatus that checks them, are what take years to build.

Many legal-AI tools ask the user to summarize the case: "my client was a victim of negligence," "they acted with intent to harm," "he breached the contract." These are not facts. They are legal conclusions. A system that accepts them as input becomes a renderer of the user's pre-existing beliefs, not a reasoning tool.

ORCA captures observable facts only: what was written, when, by whom, to which audience, in response to which documented events, with which supporting documents. The legal conclusions — negligence, intent, fraud, breach — it infers itself, by applying each cause's predicates to the facts. If the facts do not support, ORCA does not invent.

In ordinary software, a fix is validated at the code level: did the file change, does it compile, are the tests green? For a system that produces legal documents that is not enough - the code can pass while the document itself is still wrong. The only question that matters is whether the document itself, on an end-to-end run on a real case, looks as expected; so we built guards against the case where our own checking machinery 'advances' while the output does not.

ORCA validates output at the symptom surface: an end-to-end run on the actual case, and an inspection of the document that comes out the other end. An automated validation layer checks element coverage, citation integrity, and internal coherence, and flags the failures it can detect - with an explanation of what failed and why - before the document reaches you. The checks catch a great deal; what needs a legal eye, they surface for your review rather than silently pass.

ORCA is not a retrieval system (RAG). Retrieval is a search mechanism: "find me text similar to this question." Retrieval can support predicate evaluation, but it cannot substitute for a modeled predicate layer. We use retrieval where it is useful — citation verification, authority discovery — but not as the reasoning engine.

ORCA is not a clause library. A tool that assembles an NDA from a library of reusable clauses is excellent at what it does. A Statement of Claim demands something else: not clause concatenation, but reasoning about a cause as a structured object.

ORCA is not a single-purpose demand-letter tool. Some systems are built for one document type: demand letters in US personal-injury practice, contracts only from structured intake. They are excellent at their focus. ORCA's focus is Israeli civil litigation — Statement of Claim, Statement of Defense, strategy memos — at the same depth.

ORCA was built by a lawyer who learned the software work the system needed. Every cause-of-action model was authored by him. Every architectural decision was made by him.

This is not a biographical detail. It is structural. A legal-AI system built by engineers learns to render text that looks legal. A system built by a litigator learns what makes a document filable, and what makes a document one that will embarrass you in court.