The reasoning is the work. The wording is its 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. Section 15(4) (§15(4)) of the Israeli Defamation Law governs expression of opinion on the injured party's conduct in a judicial, official or public role, in public service, or in connection with a public matter. §16(b) creates a bad-faith presumption: where the publication was untrue and the defendant did not believe it was true (§16(b)(1)), or took no reasonable steps to check (§16(b)(2)). Section 19 lists mitigating circumstances the court may weigh; §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.

ORCA is built on complete, detailed models of each cause 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. In each area the same methodology is applied to new content; it is replicable and transferable - that is how new jurisdictions are added. The models themselves are encoded as structured knowledge, data rather than code - so they are checked, corrected and extended without touching the engine. 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 a full end-to-end run, is right; so we built the checking layer against the case where our own checking machinery 'advances' while the output does not.

ORCA validates the document itself: 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.

A test that passes proves nothing until it has been shown to fail on the defect it guards against. So every check in ORCA is proven that way before we rely on it. Separately from that discipline, more than 200 automated checks run on every draft.

ORCA is not a retrieval system. 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 bank of reusable contract clauses). A tool that assembles an NDA (non-disclosure agreement) 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), where every document it produces stays consistent with the others in law and in logic, not written independently from a template.