Lex AU Explorer: Reading Commonwealth Legislation With the Definitions Built In

In January 2025 I wrote down an idea: help humans and computers better understand legislation and other large documents. Three problems kept coming up:

1. Technical language and terms that are not easy for the general public to understand.
2. Large documents that make it hard to see the big picture and the relationship between parts.
3. Content that needs to be rewritten for different human audiences and computer systems.

The first proof of concept was deliberately simple: extract key definitions from legislation PDF, generate a website where the use of each defined term is highlighted and show the extracted definition when the reader hovers over it.

Lex AU Explorer is that idea rebuilt on a proper foundation: structured, machine-readable Akoma Ntoso (AKN) XML converted from legislation.gov.au, and a build pipeline that turns it into a static reader at lex-au-explorer.netlify.app.

Here is the same provision, now section 296 of the enacted Aged Care Act 2024, in the live Explorer.

Image 2: Section 296 in the live Explorer. Hovering "accommodation payment" shows its definition from section 7.

Architecture

The Explorer is the application layer of a small stack: lex-au produces the corpus, lex-au-graph produces the definition graph and the Explorer renders both.

Image 3: From source DOCX to the published site. Currency checks run as a separate step before the build; the build itself never touches the network.

1. lex-au: crawls legislation.gov.au and converts each Act from DOCX to AKN 3.0 XML, the OASIS LegalDocML standard, with section-level identifiers. The corpus is published as a Hugging Face dataset.
2. lex-au-graph: builds a graph of defined terms and cross-references over that corpus, including which definition applies at which provision.
3. Build pipeline: parses AKN into a semantic intermediate representation (IR, a JSON tree of typed nodes such as section, provision, term and reference, with no HTML), renders it to HTML through a style map and writes one JSON bundle per Act (table of contents, sections, terms, resolved references and source status).
4. Vue 3 frontend: a static site that loads bundles on demand. There is no live backend.

The same XML that feeds the reader is the machine-readable starting point for problem 3. Anything that can parse AKN can use the corpus without going through the website.

Features

Definitions where terms are used

Terms are highlighted where they are used in operative provisions, not only where they are defined. This is the original proof of concept, now driven by the graph rather than extracted from a PDF.

• When an Act defines a term more than once, the definition nearest the use in the Act's structure wins.
• A short stoplist of generic terms (act, corporation and similar) is not highlighted.
• Pointer definitions ("has the same meaning as in the X Act") are followed one hop and inlined in the tooltip, with a "via X Act" line.
• Highlighting can be switched off with a reader toggle.

Structure you can navigate

Problem 2 is about the big picture. The reader shows the Act's table of contents alongside the text, renders a whole Part or Division at a time and scrolls to the section you pick.

• Cross-references resolve to the target provision inside the reader where the target is unambiguous.
• Schedules render in every shape the corpus uses, including amending Acts, where each amendment item is navigable on its own.
• Large Acts load schedules lazily so the first view stays fast.
• Part, Chapter and Division introductory text, the Act's long title and its enacting words are all shown.

Word-for-word text

Body text is rendered word-for-word. The exception is footnotes in the schedules of 6 Acts (international instruments), which are not extracted. Inline italics and bold, tables, lists, figures, examples and penalty blocks are preserved and hanging-indent numbering matches the original. A figure is either shown or marked as a placeholder, never silently dropped.

Source-fidelity panel

Each Act carries a panel stating whether the copy you are reading is the current compilation. A separate verification run checks every Act against the legislation.gov.au API and flags those with a newer compilation or a repeal. The build reads the result from a file, so publishing never depends on a live call to the government API.

Image 4: The source-fidelity panel, with links to legislation.gov.au and the raw AKN XML.

Swappable rendering

Parsing and rendering are separate steps. The semantic IR holds what the text means (a subsection, a defined term, a schedule item) and a style map decides how to show it. Replacing the style map produces a different rendering from the same IR. Only the HTML style map ships today; the split is what makes other renderings possible without re-parsing the corpus.

Known limits

• Some tooltips run on into neighbouring definitions where an Act lists several together.
• Some generic words (for example "and") still highlight, and terms that cannot be placed in scope are left plain.
• A cross-reference to a repeated section number resolves to the first one.

Connected projects

The Explorer links out to two other projects that build on the same corpus.

• Act Alike: where a term is defined in several Acts, its tooltip carries an "Open in Act Alike" link to a side-by-side comparison of those definitions.
• ClauseKit: converts legislation into evaluatable rules grounded back to the source clause.

Image 5: The tooltip for "rules" links through to Act Alike.

The Explorer is the reading surface. Act Alike answers "how is this term defined elsewhere?" and ClauseKit answers "can this clause be run as a rule?".

Code and Further Reading

• Live site
• lex-au-explorer: this project, MIT licensed.
• lex-au: the AKN XML corpus and converter, MIT licensed.
• lex-au-graph: the definition and cross-reference graph, MIT licensed.
• act-alike: compares how a term is defined across Acts, MIT licensed.
• clause-kit: rules extracted from legislation, grounded to source clauses, MIT licensed.

AI Tools

Claude Code was used to plan and build the Explorer, and Claude was used to draft this post.