Luke's Relevance

The legal engine · Luke's Relevance

The robot lawyer, on paper

This room holds the design for a legal engine that would read all nine of Australia's statute books without tiring the way a person does, built so every answer can be checked against the exact section it came from. "Doesn't get things wrong" is the bar the engineering has to clear, not a promise being made. The first working parts are now public code; most of what follows is still a drawing.

First parts built Cited or silent Human checked

The bar to clear

In 2013 the read-through was done by one person, on paper, over a summer. The method shows how you can run your own version today with a general AI assistant and the authorised sources. The engine is the third step: a purpose-built system, designed so the checking is not left to luck.

The design starts from a hard rule: an answer about the law is only worth having if you can trace it back to the words of the act. So the engine would not be allowed to answer from memory or vibes. It would answer only from sections it has just retrieved, name each one, and show the date the law was current to. Where it cannot find the section, the design calls for it to say so rather than guess.

None of this would make it a lawyer. It would be legal information with receipts: a map to the source, never advice about your situation. For advice about your situation, a qualified lawyer. What "getting it right" has to mean in practice is unpacked further in the limits page.

The pipeline, end to end

Nine parliaments and assemblies publish Australia's statute law, each through its own register; below them sits a council tier of local laws and planning schemes. The design would take all of that in at one end and hand out grounded, cited answers at the other. Every stage below is conditional: this is what the design calls for, not what exists.

IN: NINE STATUTE REGISTERS Cth NSW Vic Qld WA SA Tas ACT NT plus the council tier: local laws and planning schemes 1 · Acquire engagement first: sanctioned access from each register, not scraping 2 · Parse PDFs and register pages into clean text that keeps the act's own structure 3 · Chunk by part, section, subsection never arbitrary fixed-size blocks 4 · Embed with embeddings trained on Australian legal text 5 · Index semantic vectors plus exact keyword, side by side 6 · Retrieve hybrid search, filters by jurisdiction, act, section and date, then re-rank 7 · Answer only from retrieved sections, every claim cited, "as at" date shown 8 · Human check expert review for anything high-stakes, and a standing golden question set OUT: a grounded answer every claim tied to an act and section you can open, dated, and never dressed up as legal advice Where a section cannot be retrieved, the design calls for "I cannot find that" rather than a confident guess. Silence beats invention.
The designed pipeline. Nine registers and the council tier in; acquire, parse, chunk, embed, index, retrieve, answer, human check; a cited answer out. A design drawing, not a screenshot.

Two stages deserve a plain-words note. Acquire is deliberately engagement first: most registers publish no public interface for bulk access, terms of use vary, and Crown copyright applies to reprints (the official consolidated copies of acts), so the path is to ask each Parliamentary Counsel's office for sanctioned access rather than scrape around them. Embed uses embeddings (text turned into numbers so meaning can be compared, not just words matched), and embeddings trained on Australian legal text already exist publicly, which matters because Australian statute reads nothing like everyday prose.

One scope note the design has to carry: "in force" law means assented (formally approved into law) principal and amending acts, including ones made but not yet commenced; bills and repealed law sit outside it; and regulations, the subordinate legislation made under acts, are a second layer the design also needs. The full tour of where all this law lives is next door in nine registers.

Why structure matters

Legislation is a tree. An act divides into chapters and parts, parts into sections, sections into subsections and paragraphs, and the meaning hangs off that shape: subsection (3) often only makes sense under the heading of section 12, inside Part 2. Most document systems cut text into fixed-size blocks because it is easy. Do that to an act and you sever a definition from the term it defines, or an exception from the rule it softens.

So the design chunks by structure: split at part, section and subsection boundaries, keep each piece whole, and carry its address (act, part, section, date) with it as metadata. The address is what makes citation possible later.

Cut by size Block 1 (1,000 characters) ...Part 2, s 12 Meaning of supplier (1) ... (2) ... (3) A person is not the cut Block 2 (next 1,000) a supplier if... [rule now separated from its own heading and subject] The exception in s 12(3) is split mid-sentence. Retrieved alone, it can read as the opposite rule. Cut by structure Chunk: Act X · Part 2 · s 12 s 12 Meaning of supplier (1) the general rule (2) the extension (3) the exception, kept whole metadata: jurisdiction, act, part, section, "as at" date one section, one whole piece, one address The section travels with its heading, its context and its address, so an answer can cite it exactly.
A worked illustration with an invented section number, not a real act. The point is the shape: fixed-size cuts sever meaning; structural cuts preserve it.

What already exists, and what is designed

This page keeps the two piles separate on purpose. Overclaiming is exactly the failure the whole design is built against.

Exists

Built, and running

The first working parts of the engine are now code you can read and run: australian-legal-engine. It reads acts you already hold, rebuilds the tree the drafter wrote, indexes it offline in a plain file you own, and answers a question by handing back the provisions themselves, quoted exactly, addressed precisely, and dated to the source. It makes no network calls and needs no account, key or subscription.

Stages 2 to 7 of the pipeline above exist: parse, chunk by structure, index, retrieve, answer, and a check step that prints what the index cannot support. Indexing three acts from the 2012 cabinet produced 6,756 addressable provisions. The rule the code holds to is the one this page argues for: it retrieves and cites, and it never writes prose about the law. Where a question needs plain language, the engine writes a prompt that hands the retrieved provisions to an assistant and forbids it from naming any section that is not in front of it.

Still designed only

The acquisition agreements with each Parliamentary Counsel's office, semantic search using embeddings trained on Australian legal text, the knowledge graph of amendments and cross-references, amendment awareness beyond a compilation's printed date, and the maintenance loop across nine registers. The engine also does no fetching of its own by design, so what it knows is whatever you have indexed.

The audit pattern

A grounded legal engine would enable one pattern worth naming plainly, in neutral terms. Rules and records are both public. Today they are rarely read against each other, because doing so takes a person weeks per question. An engine that has already parsed the rules would change the cost of looking.

  1. Extract the rules

    The engine would pull the checkable requirements out of the law: for example, a threshold above which a contract must go to open tender, or a deadline by which a gift must be declared.

  2. Line up the public records

    Tender databases, donation registers, published contracts and disclosures: records that already sit in public, jurisdiction by jurisdiction.

  3. Compare, mechanically

    Each record would be checked against the rule that governs it. Most would match. Matching is the expected, boring result.

  4. Where they disagree, look closer

    A mismatch is not an accusation; it is a place to look. Some mismatches would be data errors, some lawful exceptions, some worth a question to the body involved. The engine's job would end at the pointing.

The same pattern, run on your own life instead of public records, is the sorting bench; run toward reform, it feeds change the law.

Threads, and time

Tracing the threads

The 2013 read worked by following threads: one act defines a term, another borrows it, a third amends them both. The cabinet in the filing cabinet is the trail of that thread-following, done by hand. The design's future layer is a knowledge graph: a map of acts and sections joined by named links such as amends references defines. It would do mechanically what the summer of 2013 did on paper: start anywhere, follow every thread, and see the web whole. That web, followed far enough, is the raw material of the cyber republic room.

The maintenance truth

Laws change constantly, across all nine jurisdictions at once: new acts, amending acts, commencements, repeals, reprints. Any engine that ingests the law once and stops would drift out of date, and a stale legal database is worse than none, because it answers with yesterday's law in today's confident voice. So the design treats maintenance as part of the machine, not an afterthought: a standing update loop per register, and an "as at" date stamped on every answer so you can see how fresh the law behind it is. Like a use-by date on milk: the carton does not stop you drinking it, it just makes sure you know.

The bar, as a ledger

"Doesn't get things wrong" only means something once it is broken into parts you can test. Here is the bar the design sets, and how each part would be checked before anyone should trust it.

The bar What it means How it would be tested
Grounded Every answer built only from retrieved sections of the law, never from the model's general memory. No section found, no answer given. A golden question set: questions with expert-checked answers, run against the engine on every change, with failures blocking release.
Cited Every claim tied to a named act and section, so the reader can open the source and read the words themselves. Citation accuracy measured against the source texts, with a near-perfect target; a wrong citation counts as a failure, not a rounding error.
Current Answers drawn from in-force law, with the "as at" date shown, and made-but-uncommenced changes flagged. The update loop monitored per register; the shown date checked against the register's own consolidation date, the date up to which amendments have been folded into the published text.
Checkable High-stakes answers routed to human review before anyone relies on them, and every answer traceable end to end. Human review as a designed stage of the pipeline, not a disclaimer; reviewers able to follow any answer back through retrieval to the source section.

Why the bar is set this high

Australian courts have already dealt with lawyers filing citations invented by AI tools, and in 2025 an Australian lawyer was penalised for exactly that. The failure mode is not hypothetical; it has a case file. That is why grounding and citation are non-negotiable in this design, and why the engine would rather say "I cannot find that" than produce a confident sentence with no section behind it. The full engineering bar lives in the limits page.

Where to next

The engine's raw material comes first: nine registers walks the actual shelves, Commonwealth to council, where Australian law lives today. And before trusting any machine with the law, read the limits page: what "gets it right" has to mean, and what this site does and does not claim.