Legal intelligence for the people who need it most
RYTZ is a live Australian platform built for the people the legal system is hardest on: self-represented litigants in the family courts. It is not a chatbot bolted onto a marketing site — it is a full intelligence stack that grounds every answer in the actual legislation, reads and remembers a litigant's own documents, and turns their evidence into a drafted, accuracy-checked, adversarially stress-tested affidavit. Everything described here is verified against the running code, the production database, and live model calls — described as mechanisms, not promises.
In plain terms
A live tool that helps everyday people handle a family-law case on their own, grounded in the real law and their own documents.
Answers you can trust
Every reply is backed by the actual legislation and their own uploaded case, and it shows its working — instead of an AI that confidently makes things up.
Their whole case, remembered
It reads and remembers every document a person uploads, so it reasons about their specific matter — not family law in the abstract.
The client owns it outright
We built it and still maintain it, but the code, the data and the platform are theirs — if we walked away tomorrow it keeps running.
The problem
Roughly 200,000 Australian couples with children separate or divorce in a typical year, and a large share of those who reach the family courts do so without a lawyer — by various estimates around 40% of family-law litigants are self-represented, most often because representation is simply unaffordable. They walk into a system that assumes they know the Family Law Act, the difference between an affidavit and a parenting plan, the s60CC factors a court weighs, and how to say something so it survives cross-examination. The cost of getting it wrong isn't a refund — it's time with their children.
A general-purpose AI assistant can't close that gap. Ask it a family-law question and it starts from a blank page: no grounding in the actual legislation, no memory of your documents, no sense of which precedent treats your situation, and a strong tendency to confidently invent. RYTZ is built the opposite way — every answer grounded in retrieved authority, every document read and remembered, and the litigant's own case made the context the system reasons from. The hard engineering isn't the model; it's the scaffolding around it that makes the model safe, accurate, and accountable to a real case file.
What we built
RYTZ is organised in three layers. The data foundation is semantic search over the family-law corpus plus two knowledge graphs — a shared case-law graph and a private, per-user case graph rebuilt from each litigant's own documents. The intelligence engines read and synthesise: a two-pass document pipeline, a Master Case File compiler, and an affidavit engine. The guided workflows put that intelligence into plain-English surfaces — a two-gear chat, guided court forms, settlement and parenting planners, and an evidence portfolio. Threaded through all of it is a deliberate 'legal information, not legal advice' posture enforced in code, not just a footer.
Two-gear, retrieval-grounded chat
The chat lets a litigant choose, per question, between two gears. Brief — the default — runs Claude Sonnet 4.6 against the three most relevant statute sections for a fast, cited answer in around ten seconds. Memo runs at a much larger budget over the top seven sections plus similar decided cases and the precedent chain, reserving the most capable model — Opus 4.6 — for the heaviest analytical work. Both gears run the same retrieval before answering, so the difference is the depth of authority surfaced — not whether the system bothered to look.
The retrieval foundation: search plus a shared case-law graph
Before answering a substantive question, every non-crisis turn calls a dedicated retrieval engine. It embeds the question with OpenAI's text-embedding-3-large (3,072 dimensions) and runs semantic search over the indexed Australian family-law corpus in Pinecone with a five-signal re-ranking; it pulls similar decided cases from Postgres; and it queries a shared case-law graph in Neo4j for the precedent chain and binding authorities — walking from a statute to the cases that interpret it, and flagging when an authority has been overruled or distinguished, the citation-checking a paralegal does by hand. If the graph returns nothing it falls back to Postgres, and the whole step degrades gracefully on timeout.
The private per-user case graph — the moat
Separately, every litigant who uploads documents gets their own private knowledge graph in Postgres, built from those documents (not from chat). Across the platform it holds over 120,000 entities — parties, events, legal claims, court orders — linked by more than 80,000 document-to-entity references, deduplicated so the same person across several files collapses to one node with all the evidence attached, and embedded for semantic recall. This per-user memory is what lets RYTZ reason about a litigant's specific matter rather than family law in the abstract — a structural advantage a general-purpose assistant can't replicate, because it has no model of your case.
A deterministic crisis-safety gate
Before any AI model runs, the backend scans each message with a deterministic check for three categories — self-harm, active or imminent family violence, and child danger. On a hit it bypasses the model entirely and returns a vetted response with Australian helplines (Lifeline, 1800RESPECT, Kids Helpline, 000). The violence and child-danger patterns use recency markers so historical legal references don't false-trigger. It is a safety-first keyword gate, not a clinical risk model, and it does not replace emergency services — but it means the system never generates a legal answer when a message signals immediate danger.
The document-intelligence pipeline
Every uploaded document is read by Google's Gemini 2.5 Flash in two passes — a fast OCR/text pass that makes the file immediately answerable, and a deeper legal-analysis pass returning structured data, even on a 70-page scan. A four-stage classifier sorts each upload into one of dozens of family-law document types — filename and content-pattern rules first, with a Gemini classifier only as a last-resort rescue — and routes it to one of 61 document-type-specific extraction prompts. A tier-routed Claude step then synthesises the analysis, reserving the most capable model for filed court forms. The platform has read and analysed over 5,000 documents this way.
The Master Case File engine
The Master Case File compiles a litigant's entire corpus — documents, evidence, timeline, consultations and the applicable legislation — into one structured, barrister-style brief. It runs as a durable, multi-stage pipeline on Claude Sonnet 4.5: the file is split into four sections, each drafted by one pass and then independently reviewed by a second, adversarial critic pass that hunts for unsupported claims, missing citations, internal contradictions and any drift from legal information into legal advice. A quality floor withholds any result that fails basic completeness and citation checks. It has run to completion hundreds of times in production.
The affidavit engine
The affidavit wizard starts from the litigant's Master Case File and structured case facts rather than a blank page, so they confirm and edit instead of composing from nothing. Generation runs on Claude Sonnet 4.5 in a durable pipeline of bounded, independently-retried steps — core sections, then the facts batched per incident — with a non-AI quality floor that refuses to present an empty or degraded draft as finished. Then it stress-tests its own work: a temperature-zero grounding critic flags any date, place, person or quote it can't trace back to the deponent's own evidence — and by design it flags for review, never silently rewrites sworn words, because a 'helpful' edit to a sworn document could manufacture perjury. A separate pass plays opposing counsel, probing seven specific lines of courtroom attack — from missing annexures and hearsay-prone paraphrase to s60CC factor gaps and the cross-examination questions to prepare for.
A server-authoritative export gate
The last check before a draft becomes a filable document is a deterministic, server-side gate that owns the verdict and the audit record — the browser can't decide or forge the result. It promotes two findings into hard blocks: a critical claim the grounding critic couldn't support, and a high-severity reference to repealed family law (for example the equal-shared-parental-responsibility presumption repealed in 2024). A block is overridable only by an explicit, logged, per-finding attestation, and every authorised export writes a record including a SHA-256 hash of exactly what was exported. That hash is an integrity field on the record, not a court certification — we never claim the output is court-admissible. The gate is deliberately built to fail open: if it can't run, the export proceeds and is logged rather than trapping the user.
Guided court forms, settlement and parenting planners
A Postgres-backed forms system covers 63 Australian family-law forms with 1,490 mapped fields and 2,681 pre-generated guidance entries across three reading levels. Around ten of these — including the Form 11 Notice of Child Abuse, the Response to Divorce, the Reply and the Financial Statement — have a full split-screen, field-by-field experience that surfaces guidance live beside the official court PDF and fills that PDF for download; the rest present structured educational overviews. Alongside sit a Settlement Planner built on the s79 four-step and s75(2) frameworks, and a clause-based Parenting Planner with a readiness check, family-violence and cultural-safety flags, a Rice & Asplund pathway, and a server-generated s60CC best-interests briefing. These are educational structuring tools — never binding settlements or court orders.
The evidence portfolio and a safety posture enforced in code
Litigants upload documents into a private evidence vault — a storage bucket locked down by row-level security so each user can only ever reach their own files — with over 10,000 evidence items held to date. An auto-enrich pipeline reads each document with Claude and assembles the extracted dates into a single, source-linked chronology. Underneath everything runs a deliberate 'legal information, not legal advice' posture enforced at three independent layers: the chat system prompt hard-codes indirect, educational phrasing instead of directives; a deterministic validator scans every generated answer for advice-style language; and document analysis can't begin until the user clears an un-bypassable acknowledgement. These are engineering controls, not a regulatory clearance — and stored evidence is not content-hashed or court-admissible.
How it fits together
Three layers, one case file
Read it bottom to top: every answer starts from grounded authority plus the litigant's own case, the engines read and draft on top of that, and the guided workflows turn it into plain-English tools a non-lawyer can use.
Guided workflows (what the litigant sees)
Intelligence engines (read, compile, draft)
Data foundation (grounded memory)
Two guardrails bracket the stack: a crisis-safety gate runs before any model and returns vetted helplines, and a server-side export gate is the last check before a draft can become a filable document.
The outcome
RYTZ works because the model is the smallest part of it. The leverage is everything around the model: retrieval that grounds each answer in the actual legislation, two knowledge graphs that give the system both shared precedent and a private memory of each case, a document pipeline that reads what a litigant uploads, and an affidavit engine that drafts from their own case file, flags anything it can't ground, and stress-tests the draft as opposing counsel would before it can be exported. Every piece is deliberate engineering aimed at one outcome — that a self-represented parent walks into court better prepared and less alone, with information they can trust because the system shows its work. Throughout, we describe only what is built and running, mark what is nascent, and never claim a courtroom outcome the platform hasn't earned. For a tool built for people in the hardest moment of their lives, that honesty is the point. RYTZ runs live in production today — the platform, the code, and the data are the client's, not ours; we built it and we still maintain it, but if we walked away tomorrow it keeps serving litigants without us.
Built with
Next project