ozimmi
How the knowledge base works

From published law to a cited, checkable knowledge base.

ozimmi never states a legal figure from memory. Every number traces to a saved primary source, shown with its version and as-at date. Here is how the law gets in, how coverage is extended, and how currency is tracked.

The pipeline

FetchExtractStructureVerifyRegisterIndexDetect change
  1. 1

    Fetch

    Download the official file from the primary publisher (legislation.gov.au for the Act, Regulations and instruments) and record its provenance: URL, retrieval date, SHA-256, and the exact compilation/version.

  2. 2

    Extract

    Pull the text and the Schedule tables out of the PDF (the website's text view omits the tables). The raw, layout-preserving text is kept as the machine-diffable substrate.

  3. 3

    Structure

    Map the extracted rows into a typed database — points items, English thresholds, per-subclass criteria, occupation lists — each row linked to the exact source version it came from.

  4. 4

    Verify

    Three automated gates must pass before a figure is trusted (below). This is what replaces a human proof-reader and makes “no uncited figure” an enforceable property, not a promise.

  5. 5

    Register

    Record the source in the provenance registry with its authority level and as-at date. Nothing is “known” until it is registered against a saved primary source.

  6. 6

    Index

    Make the corpus queryable — keyword/full-text search over the legislation plus direct structured lookups the assessment engine calls.

  7. 7

    Detect change

    Watch each source's version endpoint. When the law is amended, re-fetch, re-verify, and flag every downstream figure (and any past answer) that cited the changed provision.

Why you can trust a figure

Stage 4 is the heart of it. Three gates run automatically; a figure is only trusted if all three pass.

Verbatim back-check

Every stored number must appear verbatim in its source's raw text. A value that can't be found in the primary source fails.

Column guard

For multi-column tables, the value must sit under a header matching the expected label before it's bound — this kills adjacent-column transcription errors by construction (it caught a real PTE-vs-LANGUAGECERT mix-up).

Dual extraction

A deterministic parser and a second extraction must agree cell-by-cell; any disagreement is routed for review rather than trusted.

If the knowledge base can't verify something — for example the full grant criteria for a subclass — ozimmi declines rather than guesses, and flags it for a registered professional.

How coverage extends across pathways

Australia has 100+ visa subclasses, but they are not 100 separate documents. The grant criteria for each subclass live in one instrument — Schedule 2 of the Migration Regulations 1994, one Part per subclass (the schedule runs across a few compilation volumes). So extending coverage is a parsing job over a handful of documents, not a hundred manual efforts. The ingestion order, by leverage:

  1. Migration Act core sections (validity, grant, character, the points machinery).
  2. Schedule 2 criteria, split per subclass.
  3. Public Interest Criteria (Schedule 4, e.g. the integrity criterion).
  4. The occupation-list and regional instruments (these change most often — wired to change-detection first).
  5. Points and English instruments (already ingested), then policy guidance and tribunal decisions.

A subclass only counts as fully ingested when it has all four building blocks — points, English, Schedule 2 criteria, and its occupation list. We publish that as a live coverage metric so breadth is measured, never merely claimed.

How currency is tracked

Australian migration law changes often, so currency is treated as a property, not a hope:

Today's status, honestly

The engine is live; coverage is being built pathway-by-pathway, starting with skilled migration (189/190/491 points and English). The Sources page always shows exactly what is ingested and how current it is.