Turn complex awards and EAs into usable payroll guides.

Retrieve the award from FWO, or use the supplied PDF. Parse the text into headings, clauses and subclauses, then write the snapshot to structured JSON.

N/A. This stage uses code to construct the award structure before interpretation begins.

Confirm the source can be accessed, construct the award structure using code, and ensure the outputs can be serialised and written.

Only payment-related clauses are relevant for this interpretation. Each clause is therefore classified as payment-relevant, definition-relevant or not relevant. Clauses that are not related to payment are omitted, with the classification and reason available for review. Relevant payment clauses are classified by payment type, including overtime, penalties, allowances, breaks and leave. Subclauses that are not relevant for payment purposes are excluded from downstream calculations.

An LLM reviews each top-level clause and records whether it is payment- and/or definition-relevant. It reviews each top-level subclause to classify the type of payment.

Check that every top-level clause group supplied to the classifier appears in the output. Check that each direct subclause is classified, marked not relevant or excluded by a documented filtering rule (i.e. nothing is silently excluded). Perform a deterministic sweep to identify clauses with wording that may make them relevant but were excluded by the AI. Detect duplicates, and record classifications, exclusions, corrections and edits.

The model currently creates rulesets for hours worked and therefore focuses on overtime and penalties. Clauses that are not related to overtime or penalties are omitted. For each overtime clause, distinguish clauses that create overtime (i.e. determine when worked time becomes overtime) from clauses that describe what happens when overtime is worked (overtime consequences). Identify the employee cohort and work arrangement where the award text supports it.

For overtime clauses, an LLM classifies each shortlisted clause into Overtime Creation or Overtime Consequence. All penalty clauses are kept together and classified as penalties. For each clause, the LLM proposes the relevant employee cohort (FT/PT/Casual/All) and work arrangement (day/shift workers or all).

Confirm every shortlisted clause is classified into an applicable category. Reject duplicate or invented references, validate classification and scope fields, check that cohort and work arrangement are supported by the clause text, and normalise unsupported scope to all. For penalties, apply predefined code rules to select clauses, assign the penalty classification and set the scope.

Convert selected clauses into explicit payroll rules designed to be read by a payroll officer. For accuracy, two independent drafts are prepared by two separate LLM calls, then compared and combined into one combined draft ruleset.

An LLM runs two independent expert interpretations. Expert A and Expert B each produce a structured ruleset from Step 2.2. A further LLM comparison call proposes how the drafts should be reconciled.

Validate both expert rule lists and the comparison output. Confirm that every rule from either expert is accounted for in the comparison and combined ruleset. Highlight any clauses in the Step 2.2 output that are not in either expert ruleset, along with any employee-cohort mismatches.

Review the Step 3.1 combined ruleset against the clause evidence and classifications from Steps 2.1 and 2.2. The evaluator records rule-by-rule recommendations, including proposed new rules. The creator records decisions and rebuilds the revised ruleset component.

An LLM evaluator reviews the combined ruleset against clause evidence. A separate LLM creator records keep, modify, remove and add decisions and produces the revised ruleset.

Require every original rule to be addressed. Prevent silent removals and additions (any excluded rules are highlighted for human review), require tracked evaluator and creator records for additions, rebuild from structured decisions, and surface reductions in clause coverage. Any rules in the combined Step 3.1 ruleset that are not in the revised Step 3.2 ruleset are highlighted for user review.

We want the expert review to add or remove rules as applicable, but we do not want rules removed without the creator being aware of and agreeing to the removal.

Select the revised ruleset component and transform it into a cleaner, reviewer-facing Interpretation Matrix using the appropriate ruleset headings and formatting template.

An LLM reorganises and rewrites the reviewed component into the required Interpretation Matrix format. This is a formatting activity, not a new interpretation.

Compare the reviewed component with the formatted output and highlight rules that appear to have been omitted during formatting. Produce warnings for human review rather than proceeding with automatic repairs.

Provide the formatted Interpretation Matrix for optional human review, allowing the reviewer to make any required changes. This can be read alongside the evolving drafts and any warnings produced through the process. A reviewer-edited version becomes the preferred source for the pseudocode and machine-readable ruleset file where additional assurance is required.

Select the best available reviewed Interpretation Matrix, build an inventory of its rulesets, and generate implementation-oriented pseudocode for technical teams.

An LLM translates the reviewed Interpretation Matrix and ruleset inventory into pseudocode, required inputs, decision logic and outputs.

Compare the pseudocode against the source-rule inventory. Identify missing rule coverage and check required inputs, exclusions, reasons and clause references. Write validation JSON and Markdown reports.

Load the three reviewed rulesets contained in the Interpretation Matrix—overtime creation, overtime consequence and penalties. Answer a fixed calculator questionnaire and generate a Python draft for the PayGuide calculator.

An LLM interprets the three reviewed rulesets to answer the structured questionnaire with supporting evidence, then generates a Python draft from that questionnaire.

Validate questionnaire values, normalise the response, retain evidence, identify unsupported or missing fields, and generate Python from the structured questionnaire.

Convert the Interpretation Matrix and its rulesets into the machine-readable schema required by payroll software. Where a reviewer has made edits, use that reviewer-edited version.

The Interpretation Matrix ruleset data is structured into the required machine-readable format. This output is generated from the current Matrix, including any reviewer edits, rather than from an earlier draft.

Validate the schema, required fields, rule references, employee scope and supported input values before the file is made available to downstream payroll software.