The Victorian Schools AI Design Assistant is live — and it’s built for the documentation phase
There’s a moment on every Victorian school project when the design feels “resolved”… and then the real work starts.
Documentation is where you stop speaking in principles and start making hundreds of decisions that need to survive tendering, substitutions, RFIs, and (eventually) a school that gets used hard, cleaned often, and expected to last. That’s why we’ve launched the Victorian Schools AI Design Assistant — a specialist built to speed up the most repetitive (and risk-loaded) part of the job: checking requirements, interpreting them consistently, and documenting decisions clearly.
This assistant was built to make it faster and easier to work through the core guidance that shapes Victorian school projects when you’re moving quickly — especially when you’re deep in specs, schedules, and technical resolution.
BQSH is the baseline — and it’s written for documentation
At the centre of this tool is the Building Quality Standards Handbook (BQSH).
BQSH isn’t “nice to have” reading. It sets minimum quality criteria for Department of Education capital projects and is intended to assist architects and designers in creating high-quality school and early learning facilities across Victoria.
And crucially for documentation: BQSH is structured in a way that directly supports spec writing and decision-making. The handbook explains that its technical requirements are written in a performance/output format—specifically to encourage consultants to use their expertise while still meeting VSBA requirements.
That’s documentation language. It’s not a mood board. It’s a framework you can turn into enforceable requirements.
So the Victorian Schools AI Design Assistant is designed to help you:
locate the relevant BQSH clause quickly
summarise what it’s actually requiring (not what we think it’s requiring)
interpret “must” vs “should” consistently
and point you back to the source so you can record decisions with confidence
NCC compliance is necessary — but it’s not the whole test
Most of us have lived this scenario:
A product meets the National Construction Code. The datasheet looks fine. The supplier sounds confident. The builder says it’s “equivalent.”
But on VSBA projects, the question is rarely “is it code compliant?” It’s:
Is it appropriate for a school environment — and is it aligned with the minimum quality criteria set out in BQSH?
BQSH is explicit about its relationship to the NCC: it is intended to complement, rather than duplicate, NCC requirements. It also states that designs should be based on NCC Deemed-to-Satisfy provisions wherever possible.
And where you do need to go down the performance-solution path, BQSH is clear that a whole-of-life cost assessment must be prepared, and that this needs approval via VSBA Project Delivery Managers.
That is a very different mindset from “it passes the code, so it’s fine.”
This is exactly where documentation teams get squeezed: you can write a perfectly code-compliant specification and still end up with an outcome that doesn’t align with client expectations for durability, maintenance, cleaning, and lifecycle value.
BQSH even explains why it uses its “must” and “should” structure — because some products and design approaches simply do not work well in school environments.
That line is doing a lot of work. It’s the difference between “technically acceptable” and “suitable for schools.”
“Must” and “should” are not vibes — they’re a project controls system
In school projects, a huge amount of design risk arrives disguised as casual language.
BQSH removes some of that ambiguity by defining the meaning of “must” and “should,” and by explaining the approvals pathway when you want to vary them. It explicitly links departures to a justification that considers safety, design, operational and maintenance factors, with a formal process (Form 30) and costed justification.
In other words: this isn’t just a handbook, it’s a documentation control mechanism.
So the assistant is tuned to support the kind of questions that actually come up mid-documentation:
“Is this clause a must or a should?”
“If we can’t meet it, what’s the correct pathway?”
“How do we justify an alternative in a way that stands up to review?”
“What’s the intent behind this requirement, so we don’t accidentally comply in a way that undermines performance?”
Why we still layered in OVGA design guidance
BQSH gives you minimum quality criteria and performance requirements. But documentation isn’t just transcription — it’s interpretation. The quality of the outcome often depends on whether the team understands intent when there are multiple ways to meet a requirement.
That’s why we trained the assistant on an additional layer: OVGA’s “Good design + education : issue 06.”
Not because it replaces BQSH (it doesn’t), and not because it turns the assistant into a concept designer (it shouldn’t). It’s there because when you’re documenting, you’re constantly translating requirements into real materials, real assemblies, and real choices — and design intent helps you choose the right compliant path, not just any compliant path.
And if you’ve ever sat through a substitution conversation where the proposed alternative “meets the standard” but clearly degrades the learning environment… you already know why that matters.
Furniture: the documentation blind spot that keeps biting teams
We also trained this specialist on the Architects Guide to furniture specification by the AFA, because furniture is one of those areas that gets treated as “later” right up until it isn’t.
In schools, furniture affects:
circulation and supervision
storage and clutter pressure
flexibility and room use over time
durability and replacement cycles
the interface between FF&E, joinery, and builder’s scope
If you don’t document it clearly, you don’t just risk the wrong chair — you risk the wrong learning environment.
So this assistant is built to handle furniture questions with the same seriousness as finishes and assemblies: not as styling, but as performance and suitability.
Why this matters: public projects reward whole-of-life thinking
One of the enduring lessons in public investment is that the “cheapest” choice at documentation time often becomes the most expensive choice over the life of the building.
Michael Smith has made that point directly in the built-environment advocacy context: operational and maintenance costs are where buildings really “charge interest,” and early decisions drive long-term value.
That whole-of-life lens is also embedded in BQSH’s position on performance solutions and lifecycle assessment.
So the assistant isn’t just about speed. It’s about protecting outcomes by making it easier to document decisions that align with a school’s real operating context.
Where Spec Rep Help Desk fits
At Spec Rep Help Desk, we’re focused on the work that sits between design intent and contractual reality: specifications, compliance-heavy guidance, and the decisions that create (or reduce) downstream risk.
The Victorian Schools AI Design Assistant is one part of that—helping teams translate BQSH requirements into clear documentation, faster. And it works alongside our Design Risk specialist, which is designed to pressure-test decisions and surface the common traps before they turn into tender pain or site variation conversations.
The takeaway
If you’re working on VSBA projects, you don’t need a tool that confidently tells you what’s “probably fine.”
You need a tool that helps you answer, quickly and defensibly:
what BQSH actually requires (in performance/output terms)
how it complements NCC requirements without duplicating them
when Deemed-to-Satisfy is expected, and what’s required if you propose a performance solution
and how “must/should” decisions affect compliance, approvals, and maintainability over the life of the school
That’s what this assistant is built to support: documentation that’s faster, clearer, and more aligned with what works in real school environments.