A Safe Work Method Statement is the smallest unit of testing for whether a compliance generator actually works. It has a defined purpose under the Model WHS Regulations (regulation 299, in case you ever need it). It has prescribed content. It has a real consequence — a tier-one builder won't let you on site without one — and the document is short enough that an experienced site supervisor can spot a fake within thirty seconds.
This post walks through what happens between the moment you tick "Working at heights" on the build flow and the moment a 6-page SWMS lands in your pack. We're going to be honest about what the system does and what it doesn't.
What a SWMS has to contain
Regulation 299 of the Model WHS Regulations requires a SWMS for every "high-risk construction work" activity. The list of activities is in regulation 291 — eighteen of them, including work at heights over two metres, demolition, excavation deeper than 1.5 metres, work near energised electrical installations, and work in confined spaces.
The SWMS itself must identify the work, the hazards arising from the work, the control measures, and how those control measures will be implemented, monitored, and reviewed. It must be in writing, and it must be developed in consultation with the workers carrying out the work.
That's the legal floor. A tier-one head contractor's expectation is materially higher: a numbered project reference, a competent person sign-off, dated revisions, a hierarchy-of-controls table, and explicit references back to the WHS Regulation and the relevant Code of Practice. PolicyPack writes to that higher bar by default.
The pipeline, end to end
There are four stages between input and output. Each one is independently testable, which is the part that matters.
Stage one — context assembly
When you select "Working at heights" on the build flow, the system isn't just appending a string to a prompt. It assembles a structured context object. That object includes:
- The activity (heights, including the regulation reference and the specific PCBU duties triggered).
- Your industry (construction → trade-specific control language, e.g. "edge protection" rather than "fall arrest harness" if you indicated "Tiling" rather than "Steel framing").
- Your state regulator (NSW → SafeWork NSW Code of Practice for Managing the risk of falls at workplaces; Victoria → the equivalent WorkSafe Victoria compliance code).
- Your headcount band (1, 2-5, 6-15, etc — affects whether the SWMS assumes a sole-trader scenario or a multi-worker crew).
- The other hazards you ticked — because heights work usually co-occurs with mobile plant, manual handling, and electrical exposure, and the SWMS should cross-reference those.
This object is built deterministically. The same inputs produce the same context every time. That's important because it lets us cache regulator citations, control-measure libraries, and clause skeletons rather than regenerating them from first principles on every run.
Stage two — generation
The model receives the context object plus a SWMS-specific system prompt. The system prompt is not a single string — it's a layered instruction set with five components:
- The SWMS template structure (project ref, hazards table, control table, sign-off panel).
- Hierarchy-of-controls discipline ("you must propose elimination first, then substitution, then engineering, then administrative, then PPE — never PPE alone").
- Citation discipline ("every control measure must reference either a WHS Regulation clause or a Code of Practice section; if you cannot cite, you must not state").
- Tone discipline ("plain English, no boilerplate, no exclamation marks, no marketing language").
- Validation hooks (instructions that tell the model what to put in machine-readable comments so the validator can pick out structured fields).
The model produces a draft SWMS. The output is markdown with embedded structured comments — not free-form prose. This matters for stage three.
Stage three — validation
Generation is non-deterministic. Validation is deterministic. We run a set of programmatic checks on the draft before it ever touches a PDF renderer:
- Does every control measure resolve to a citation that exists in our maintained register of WHS Regulations and Codes of Practice?
- Is there at least one elimination or substitution control proposed before any administrative control?
- Are all eighteen high-risk activity flags from regulation 291 cross-checked against the activity description?
- Is the responsible person field populated? Is the review interval field populated?
- Does the document include the project reference, the date, and the competent person panel?
If any check fails, the draft is rejected and a regeneration is triggered with a delta prompt that names the specific failure. We allow up to three regeneration cycles before the system flags the activity for human review and proceeds with a flagged-but-best-effort version. In production today, fewer than 0.4% of SWMS reach the third cycle.
Stage four — rendering
The validated markdown is rendered into a PDF using a templated layout that matches the rest of your pack — your business name, your colour, your jurisdiction footer, the consistent typography. The PDF is page-numbered, includes a footer with the document version and the regenerate-after date, and embeds a SHA hash of the source content so any subsequent edit is detectable.
What the system doesn't do
This is the honest part.
The system does not visit your site. It does not know whether you actually have edge protection installed on the job at 14 Carlisle Street. It does not know if the harness in your ute is in date. It assumes a competent person — usually the business owner or a nominated supervisor — has read the SWMS and can attest that the controls listed are the controls in use.
The system does not replace consultation. The Model WHS Regulations require the SWMS be developed in consultation with the workers carrying out the work. PolicyPack generates the document. You are still required to sit down with your crew, walk them through it, capture their input, and adjust the controls if they identify a gap. We give you the structure. You bring the people.
The system does not provide legal advice. It produces operational documents to a standard. If you have a fatality, a serious incident, a Provisional Improvement Notice, or a regulator-led investigation, you need a human lawyer. We say this in the disclaimer that ships in every pack and in the cover letter we email with the download link.
Why this matters
There is a school of thought that AI-generated compliance documentation is necessarily worse than human-generated, because the model can hallucinate and the lawyer cannot. The lawyer can. The lawyer who copies and pastes from a precedent bank without re-reading every clause does it constantly. The difference is that the lawyer's hallucinations are invisible to the buyer because they look like the rest of the document.
We invert the trust model. The model writes the prose. The deterministic validator gates the output. The citation register is maintained by humans against the live regulatory text. The renderer enforces the layout. Every step is independently verifiable. That's the engineering claim, and it's what gets a SWMS through a tier-one builder's gate without anyone noticing it wasn't produced by a $5,000 consultancy.
If you want to see what a real SWMS off the pipeline looks like, download the sample pack. Page 47 onwards.