01
Legislation becomes a draft pack
AI reads the source clause by clause and extracts thresholds, rates, effective dates and conditions into a structured draft pack. It proposes the rules; it does not approve or execute them.
// Auxil Foundry
Cited legislation becomes a ratified rule pack
Auxil Foundry turns cited legislation into ratified rule packs. The packs run inside your environment, explain every answer back to the clause, and are re-ratified when the law changes. Cases the rules cannot settle go to a person with the unresolved question made explicit.
// Where it fits
This is designed for written rules that produce a number or a decision, especially when that result may later be challenged or audited.
- Employment and payroll rules An award or an employment agreement decides what someone is owed for the hours they worked.
- Professional licensing and certification Published requirements decide whether a candidate has met the standard, and by how much they fall short.
- Levies, duties and charges A rate table and a set of thresholds decide what a business owes for the period.
- Eligibility and entitlement schemes Criteria in regulation decide whether an applicant qualifies, and for how much.
- Sector safety rules Duty limits and rest requirements decide whether an operation is within the rules.
A pack is a ratified, signed, time-bounded rule set for one regime. A kernel is the small, closed evaluator for one shape of rule: quantities for payroll, conditions for licensing. One foundry drives every kernel, and one kernel runs any number of packs.
// The problem
A rule changes in March and takes effect in July. The usual process turns that change into a policy interpretation, a specification, a development queue and a software release. If the release arrives late, the organisation must identify and correct every affected decision.
Domain experts cannot easily verify application code, while developers often work from a summary of the source material. That gap makes changes slow and individual results difficult to explain.
// How it works
From the text to a running answer
02
The draft is checked automatically
Deterministic checks find gaps and contradictions, then compare the draft with published worked examples. A pack that fails verification cannot be signed; the failure is terminal, and a fresh draft is required.
03
Your expert ratifies it
Your subject-matter expert reviews each rule in plain English and signs the exact verified version. The pack records who signed, which documents by digest, and which clauses. Later amendments are shown as a focused, readable change set.
04
It runs, and shows its working
The ratified pack runs without AI. Every result includes its inputs and governing clause. If required data is missing, the system returns a clear refusal instead of guessing, and anything it has not looked at is reported as not looked at.
// Working examples
Two rule shapes, one foundry
-
Payroll
Working engine; New Zealand pack in development, not yet ratified
The calculation kernel, independent oracle, versioned clauses and evidence output run today against contrived jurisdiction packs. The New Zealand pack and validation against bureau data are the remaining steps before any claim about real payroll.
-
Professional licensing
Working engine; three draft maritime packs, none ratified
A condition kernel evaluates logged experience against published requirements and reports standing and shortfalls per stage. One unchanged kernel covers New Zealand Maritime Rule Part 90 and Australian Marine Order 54 with no kernel growth on the second regime, which is the evidence that the foundry is domain-blind.
// Under the surface
The checks a prompt does not give you
01
An independent oracle
The checker shares no evaluation code with the production engine. Both must agree on worked examples and test vectors, so the component producing an answer is never its only judge.
02
Judgement has an escape hatch
Missing evidence and genuinely undecidable cases travel through a separate refusal channel. The system identifies what prevents a decision and routes the case to a person instead of inventing certainty.
03
Rules keep their history
The system records when a rule applied and when the organisation learned about it. Historic results can be replayed correctly even when an amendment arrives late or takes effect retrospectively.
04
AI is sealed out of runtime
AI helps draft the formal artifact, then leaves the path. The runtime cannot depend on the generation package; the build fails if that boundary is crossed.
// Why this matters
What changes for you
// No release cycle
Update rules without rewriting application code
When an amendment arrives, your expert reviews the proposed change and approves its effective date. The rules can change without a new specification and application release.
// Defensible
Every answer can be defended
When a result is challenged, you can show its inputs, the clause used, the pack version and its effective date. The evidence is produced with the result, not reconstructed later.
// The past stays available
You can answer for periods that have closed
Old rules are kept alongside the new ones. Re-run March 2023 under the rules that applied in March 2023, and get the answer the system gave then.
// Who this is for
Teams responsible for the result
-
Government agencies and regulators
You publish the rules and you are expected to apply them the same way every time, across a large caseload and a rulebook that keeps moving.
One ratified pack behind every decision, with the clause and version attached, so a decision can be explained to the person it affects.
-
Compliance teams in regulated businesses
You maintain a rulebook that changes several times a year, and today that means a spreadsheet, a policy document and a queue with the development team.
You own the rules directly. Changes go live once you approve them, rather than in the next release.
-
Software teams whose product encodes someone else's rules
Your product covers payroll, tax, benefits, licensing or levies, and every amendment turns into weeks of reading legislation and regression testing.
The rules leave your codebase and become data your domain people maintain, so your engineers build product instead of re-encoding statute.
-
Professional bodies administering licensing
You track progress toward a qualification against published requirements, and the requirements have changed since half your candidates started.
Each candidate is assessed against the requirements that applied when they began, with any shortfall itemised.
Test it with one of your rules
Bring a representative rulebook and example case. We will show how the rules are drafted, checked and approved, then produce a result with its supporting evidence.