Project Audit 1 Update!

Our goal is to make it easier for teams to see and discuss possible solutions while a project is still being planned — turning verbal and written requirements into visual concepts so stakeholders and consultants can better understand proposals and refine needs earlier in the design process.

This post is a snapshot of where the project stands at our first audit.

What's in scope (and what isn't)

It's tempting to chase every interesting idea on a project like this, so we spent time early on drawing clear lines around what we're actually doing.

In scope is early-stage conceptual design: eliciting requirements from stakeholders, interpreting those requirements in a form an AI can work with, generating visual concepts, and rating those concepts so users can compare options. Sitting near scope are minimal blueprint generation, additional sensory outputs (beyond visuals), and the possibility of building out a complete, commercial-grade AI product. Firmly out of scope is anything that takes us into detailed downstream engineering work: dimensional design, full 3D or BIM models, regulatory compliance assurance, and construction planning.

Two possible paths forward

One of the biggest decisions we are facing is what direction the project should take. We've identified two:

Path 1 — AI Development. We build an AI agent ourselves, working through initial scoping, an early design stage where we prepare and tune a base model, a detailed design stage covering regulations and the user interface, then internal and external testing rounds.

Path 2 — Research Analysis. Rather than building, we deeply evaluate the current AI landscape: demand and requirements, current capabilities, image and schematic generation, viability, and obstacles to feasibility, culminating in a SWOT analysis and viability report.

Assumptions and constraints

Every project rests on assumptions.

We're assuming that:

• regulations can be represented in a machine-readable form

• current AI tools are capable enough to support what we're proposing

• stakeholders will be able to engage meaningfully with the outputs

• the project may legitimately fork down one of the two paths above

On the constraint side:

• real-time latency limits

• strict regulatory bounds

• complex input dependencies

• bounded scope of what we can deliver in the time available

  
  

Who we're building for

1. Our primary stakeholder is Frazer Nash — high interest, high influence, with the most at stake in terms of money and time. Communication runs through our project host, Stuart Taylor, via weekly email updates with ad-hoc contact for queries.

2. The ANU sits behind that, tracking progress through graded assignments and audits.

3. Legal and regulatory bodies enter the picture only at specific touchpoints — contract signing, queries about legality, and gathering relevant standards.

4. Product users are high-interest but lower-influence at this stage, and we'll engage them mainly to gather information or share results.

   
   

Timeline and work breakdown

The project runs across four audits before a final showcase in Week 12 of Semester 2, with a SWOT analysis in late Semester 2.

Because of the path decision, we've built two parallel work breakdown structures. The development WBS moves through six phases: initial scoping, early design, detailed design, finishing the model and UI, internal testing, and external usability and applicability testing. The research WBS moves through management setup, early research and scoping, demand and requirement assessment, current capability research, viability assessment, and a final report. Each WBS aligns its deliverables to the audit checkpoints so we have a clear picture of what "done" looks like at each milestone regardless of which path we follow.

Managing risk

We're maintaining a relevant risk register. As an example: technical and approval delays are flagged as a "Possible / Moderate" project risk, mitigated by identifying required tools and approvals early and submitting paperwork immediately.

Reviews happen on four triggers: scheduled reviews per the register, incident reviews after something goes wrong, control reviews whenever a new risk is added, and team approval at weekly meetings whenever risks or controls change.

How the team is organised

We've assigned overlapping leadership roles so coverage doesn't depend on any one person.

For tooling: Messenger and Microsoft Teams handle day-to-day team chat, email handles supervisor communication, Google Drive holds our documents, GitLab holds our code, and Wix hosts our landing page.

What's next

The headline question heading into Audit 2 is the path decision — develop or research. Resolving that depends on our literature review, and most of our near-term effort goes there.

For more information please look at our repository. To see Project Audit 1 Slides please look here.