The cover is an AI-generated editorial concept, not a photograph of a completed project or evidence of a regulatory decision.
What ministers actually agreed
On 16 October 2026, Commonwealth, State and Territory ministers responsible for housing, homelessness, planning and building met for the second Joint Ministerial Meeting on Housing Supply and Affordability. The communiqué records a commitment to modernise the National Construction Code and an agreement to pursue reforms that support the uptake of modern methods of construction through "a more nationally consistent building system".
The attached shared statement of reform commitment goes further in one specific place. Under the heading "Enable innovation and products", jurisdictions agree:
to work together to establish clear, nationally consistent and scalable pathways to accelerate uptake of safe, innovative products and methods, ensuring alignment with existing National Competition Policy reforms, including efforts to support the adoption of modular and prefabricated construction.
That sentence is the reason this article exists. It is also the reason to read it carefully. The commitment is to work together to establish pathways. It is not a pathway. The statement also commits jurisdictions to support a single national market through a national code, to a process analysing NCC variations "with a view to identify inconsistencies and understand reasons for NCC variations", and to "risk-based proportionate ways of demonstrating compliance".
Each of those is a reform direction with preliminary work attached. None of them is a published instrument that a project can submit against today. A roundtable with investors, modular housing manufacturers, unions and construction companies followed the meeting, which signals intent to keep industry involved. It does not create an approval route.
National ambition, state approval
The structural fact that survives all of the reform language is that building approval remains a state and territory function, exercised through their own legislation, regulators and processes.
The communiqué itself reflects this. Ministers "agreed to pursue reforms". They "committed to modernise" the code. They agreed to "work together" on a process to analyse variations. The verbs are consistently about cooperation between jurisdictions that retain their own instruments.
For a modular project, this produces a specific planning consequence. The question "is my building approved?" is never answered nationally. It is answered by a particular authority, for a particular site, under a particular set of requirements, at a particular time. A national direction can reduce the number of differences over years; it cannot answer that question for a project in the room today.
The practical response is not cynicism about the reform. It is to separate two workstreams that are often blurred: the project's own approval path, which is local and specific, and the industry-level evidence base that may eventually make future paths easier. Both are worth doing. They have different owners, different timelines and different tests of completion.
Design one evidence pack, not one approval
The most useful thing a manufacturer or developer can build while pathways are being developed is a single technical evidence pack that is not organised around any one jurisdiction's submission form.
The pack should be organised around the building and its systems: the design basis, the structural system, the enclosure, the services interfaces, the installation method, the inspection regime and the records that prove each of them. A reviewer in any jurisdiction should be able to find the same seven things in the same seven places.
This structure has a practical benefit beyond tidiness. When a new jurisdiction is added, the work is to map its requirements onto the existing pack and record the gaps, rather than to rebuild the file from a blank page. When a requirement changes, the change lands in one place and its consequences are visible across all jurisdictions at once.
The pack should also state what it does not cover. A file that claims completeness invites a reviewer to find the missing element; a file that declares its boundaries invites a reviewer to test them. The second conversation is shorter.
Register the differences instead of hiding them
Australian jurisdictions differ on climate loading, seismic and wind provisions, energy performance, fire performance, termite and durability requirements, planning controls, and the administrative form of submission. Those differences are real, and a nationally consistent direction does not make them disappear on the day it is agreed.
The tool for managing them is a variation register: a table with one row per requirement area and one column per jurisdiction the project might touch. Each cell records whether the requirement is materially the same, materially different, or not yet assessed, and each difference gets a short note on what it changes in the design or the evidence.
The register's value is that it converts an unbounded research problem into a bounded list. A team that knows it has fourteen differences across three jurisdictions can plan for fourteen. A team that knows only that "the states are different" tends to plan for none and discover them late.
The register should also record who assessed each cell and when. A difference recorded from a summary is weaker evidence than a difference recorded from the instrument itself, and the register should make that distinction visible rather than flattening both into the same confidence.
Keep product evidence and project evidence separate
Two kinds of evidence meet in every modular project, and confusing them is one of the most common sources of delay.
Product evidence addresses a system, component or assembly against a defined basis: a test report, an assessment, a certificate, a declared performance. It travels reasonably well because it is about the thing rather than the place. Project evidence addresses this building, on this site, with these connections, under these requirements: design decisions, site conditions, interface resolutions, installation method, inspection records.
A certificate does not resolve a project question, and a project file does not replace a certificate. An authority reviewing a submission generally wants both, and wants to see how they connect: which product claim supports which project element, and what remains to be demonstrated locally.
The pack should therefore carry a linking column, not just two folders. For each significant project element, record the product evidence relied on, the project decision it supports, and the local verification that remains. That column is also the fastest way to find a gap when a jurisdiction asks a question the pack has not yet been asked.
Plan for change while the pathway is being written
Reform directions create a specific planning risk: a project can be designed, documented and submitted against a requirement that is later superseded, and the rework lands at the worst possible time.
The mitigation is not to freeze the design until the reform settles, which may take years. It is to identify which decisions are expensive to reverse and which are cheap, and to manage the former with a deliberate hold while the latter proceed.
A structural system, a facade module, a production jig or a factory tooling investment are expensive to reverse. A paint specification, a signage package or an interior finish schedule are cheap. The pack should carry a short list of the expensive-to-reverse decisions, each with an owner and a review trigger, so that a change in the national direction is caught before it becomes a factory change.
The trigger matters more than the review date. "We will review in March" is weaker than "we will review when the ABCB publishes its preliminary work on digital delivery, or on 31 March, whichever comes first".
Structure the technical file for review
A reviewer's time is the scarcest resource in any approval process, and a file that respects it gets better decisions.
The technical file should open with a one-page project statement: what is being built, where, by whom, in what configuration, and what is being sought. It should then present the design basis and the system description before the detailed drawings, because a reviewer who understands the system reads the drawings differently.
Drawings should be organised by interface rather than by discipline alone, because modular problems cluster at interfaces. The module-to-module joint, the module-to-foundation connection, the service entry and the facade termination are where questions concentrate. A drawing set organised only by architectural, structural and services packages tends to require the reviewer to reconstruct those interfaces.
Calculations, test reports and assessments should each be referenced from the element they support, with an edition and a date. An unreferenced report in an appendix is a document, not evidence.
Make factory records legible to a local reviewer
A factory's quality system may be mature and still be unreadable to a local authority that has never seen it.
Legibility has three components. The first is identification: every record should identify the unit, the project, the revision and the date, in a way that a reviewer can match to the drawings in the pack. The second is traceability: a record should show what was checked, against what requirement, by whom, and with what result. The third is control: superseded records should be visibly superseded rather than quietly replaced.
The practical test is a sample retrieval. Ask a reviewer to take one module from the drawing set and find its fabrication records, its inspection records and its release-to-site record within a defined time. If that takes an afternoon, the system is not yet legible, and no amount of additional certification will fix the experience.
Factory records should also distinguish between records the project holds and records the factory holds. An authority may ask for either, and the pack should say where each lives and who can produce it.
Brief the local team on interface ownership
The local design and construction team carries responsibilities that a supplier cannot absorb, and the boundary between them should be written down before work starts.
Typically the local team owns the site investigation, the foundation design, the connection design at the module interface, the site services up to the module connection point, the crane and access plan, the local planning and building submission, and the site inspection regime. The supplier owns the module design within its scope, factory fabrication, factory inspection, factory records and the installation method statement it proposes.
The failures happen in the overlaps. Who designs the connection between a module and a foundation designed by someone else? Who confirms that the crane position assumed by the factory is achievable on the actual site? Who signs off a deviation discovered during installation?
Naming those questions in a short interface schedule, with an owner for each, is more valuable than a longer document that describes responsibilities in general terms. The related discussion of factory and site interface commissioning develops the services side of the same boundary.
Work through a hypothetical two-state project
Consider a hypothetical developer planning a three-storey modular apartment building, with a factory in one state and a site in another. The details here are illustrative.
The developer's first assumption is that because the building system is the same, the submission will be the same. The variation register quickly shows otherwise. The two jurisdictions differ on the wind region applied to the site, on the energy performance pathway accepted for the building class, and on the documentation expected for the off-site fabrication inspection.
None of those differences invalidates the system. Each of them changes something specific. The wind difference affects the connection design and possibly the bracing. The energy difference affects the glazing specification and the services design. The inspection difference affects what the factory must record and who must witness it.
The developer's response is not to redesign. It is to keep one core pack, add a jurisdiction tab for each location, and record the three differences with their design consequences and owners. The factory is briefed on the inspection difference only, because that is the only one that changes factory work. The local design team is briefed on all three.
The submission then proceeds in the site jurisdiction, using the site jurisdiction's requirements, with the core pack unchanged. The other tab remains in the file as evidence that the difference was assessed rather than missed.
Use a proceed, condition, dual-track or wait matrix
Each significant decision in the pack should end in one of four positions.
Proceed means the evidence is sufficient and the decision can be taken now. Condition means the decision can be taken with a defined allowance or hold point. Dual-track means two options are maintained for a defined period because the cost of choosing wrong is high. Wait means the decision is postponed until a specific event occurs.
The matrix should record, for each row, the evidence held, the evidence missing, the owner, the trigger and the review date. It should also record what would move the row between positions, so that the matrix is a live instrument rather than a snapshot.
The most common failure is a row that sits in "proceed" because nobody has tested it. A short review in which each row is challenged once is usually enough to move the genuinely uncertain rows into condition or dual-track, where they can be managed.
What to do in the next 90 days
The communiqué does not give implementation dates for the pathways work, so a project cannot schedule against it. It can, however, do the work that will be useful regardless of the timeline.
In the first thirty days, assemble the core pack structure and populate the sections that do not depend on jurisdiction: design basis, system description, installation method, factory quality system, and the evidence linking table. In the second thirty days, build the variation register for the jurisdictions the project could realistically use, and mark each cell as same, different or unassessed. In the third thirty days, test the pack against one real submission requirement and record what the test exposed.
That sequence produces something a project can use now and a manufacturer can reuse later. It also produces a record of what was assessed, which is the only durable defence if a requirement changes after a decision has been made.
Sources
- Australian Government Treasury, "Meeting communiqué: Joint Ministerial Meeting on Housing Supply and Affordability, October 2026", 16 October 2026. https://treasury.gov.au/media-release/meeting-communique-building-ministers-october-2026
Source note: the communiqué was read on 22 October 2026. It records the second joint ministerial meeting, the commitment to modernise the National Construction Code, agreement to pursue reforms supporting modern methods of construction through a more nationally consistent building system, and the attached shared statement whose "Enable innovation and products" section commits jurisdictions to work together on nationally consistent and scalable pathways including efforts to support modular and prefabricated construction. It gives no implementation date, no published pathway, no mutual recognition arrangement and no change to current approval requirements. The variation register, evidence pack structure, hypothetical project and decision matrix are original editorial analysis. Commentary published after 22 October 2026 was excluded deliberately to respect this article's date.
