Project Audit 2 Update!

This audit reviews the project across four areas: outputs, governance, technical artefacts, and the plan to deliver value. Here's where we landed against each expectation:

• Repository & landing page — updated and accessible

• Systems engineering governance — requirements analysis, functional breakdown, risk register, and a decision log

• Technical artefacts — working UI, backend/API connection, Gemini image generation

• Progress against ConOps — scope narrowed, objectives tracked through requirements and prototype pathway determined

• Project management — PA4 roadmap developed, WHS remains unchanged, risks updated with project growth

Targets: Crash, Goal, Stretch

We set three tiers of ambition for PA2:

Crash : Updated ConOps and PMP, baseline requirements analysis, initial functional analysis, reviewed risk register, proof of concept finalised, and mentor/external feedback gathered.

Goal : Requirements matrix and QFD complete, baseline prototype running, MBSE incorporated.

Stretch : Funding and ethics approval, finalised prototype, test and evaluation metrics developed.

ConOps as a Control Document

The ConOps has shifted from a scoping document into an active control tool. The five phases it outlines are:

1. Research & problem definition — literature review guided scope narrowing

2. Stakeholder requirements & system definition — requirements analysis sets project boundaries

3. Requirements, functions & architecture — further analysis informs prototype generation

4. Concept implementation & performance evaluation — user and functional testing sets efficiency

5. Final analysis & recommendations — demonstrating project capacity and potential applications

Requirements Analysis

Requirements work is framed around extraction, traceability, and usability, flowing from:

A few example requirements we're working with:

• The system shall capture user input through natural language detection.

• The system may return the image within 30 seconds.

• The system may consider legal constraints and regulations.

Compared to PA1, we've made refinements: reframing around the system rather than the model, improving quantification, and reducing vague language.

Design Prioritisation with QFD

Quality Functional Deployment (QFD) is being used to convert stakeholder needs into ranked technical priorities. Some key takeaways.

Functional Breakdown

The prototype is decomposed into eight functions across input, processing, generation, display, and iteration:

#	Function	Description
1	User Interface	Capture input, display outputs, collect feedback
2	API Communication	Move requests between UI, backend and model
3	Prompt Processing	Validate, clean and structure requirements
4	Image Generation	Send structured prompt; receive generated image
5	Output Display	Show results; allow save, select or refine
6	Iterative Refinement	Combine prior prompt and feedback
7	Session Storage	Store prompts, images and feedback history
8	Error Handling	Detect invalid input and failed requests

Technical Artefact: Where the Prototype Is

What's working:

• User interface and API connection

• Error handling

• Rudimentary image generation

• Requirements used to create outputs

Current limitations:

• Free models limit output quality and speed

• No session storage

• Prior images aren't used as inputs

• Only requirements are accepted as inputs (no other input types yet)

The prototype demonstrates the basic input-to-generation pathway, but full iterative refinement isn't there yet.

Stakeholder Engagement

Our host engagement has shaped scope, documentation, prototype direction, and evidence. Here's a rough timeline:

• March 4 — Initial contact, workflow preferences discussed

• March 5–12 — Stuart provided notes, first meeting arranged

• March 20–23 — ConOps sent for review; audit update shared

• April 23 — ConOps signed by host

• April–May — Proof of concept and documentation updates shared

• May 13 — Prototype progress demonstrated; reports and funding pathway discussed

Positive outcomes: Funding and presentation opportunities identified, operational updates exchanged, signed ConOps.

Gaps we're aware of: Feedback isn't yet being converted into a formal action log, it's not consistently linked to requirements/risk/decisions, and overall engagement frequency has been low.

Decision Register

PA1 flagged decision traceability as a gap. PA2 addresses this with a formal decision register. Key decisions since implementation include:

• Core project direction — pursuing implementation-backed systems engineering (not a purely research-based feasibility study)

• Prototype architecture — modular design separating UI, request handling, prompt processing, image generation, output display, refinement, storage, and error handling

• Model selection — free Gemini image model chosen for accessibility and low cost at early POC stage (with acknowledged quality tradeoffs)

• Scope as a requirement discovery tool — deliberately avoiding overclaiming AI design authority

• Using existing AI tools — training a model is out of scope given team capabilities, timeframe, and resources

• Evaluating requirement quality, not image quality — success is whether the concept surfaces missing or conflicting requirements, not whether the image looks good

• Deferring session storage and image feedback — full session memory and image refinement reserved for PA3

Risk Management

Top risks and controls:

Risk	Control
Output misinterpretation (AI visuals treated as authoritative)	Improve prompt structure; allow user clarification and refinement
Requirements / scope creep	Clearly define technical boundaries
Integration & API limits	Support multiple providers; monitor API limits
Schedule delay	Break tasks into smaller milestones; track weekly; prioritise critical tasks
Over-reliance on AI	Keep humans in the feedback loop

Reflection: Responding to PA1 Feedback

PA1 pushed us to move from broad scoping toward clearer outputs and technical evidence. Here's how we responded to specific feedback:

• "No proof of concept" → Working POC now exists: UI, backend/API, image generation, error handling

• "No verification/testing plan" → Success reframed around requirement quality, traceability, and stakeholder review

• "No decision log" → Decision register added with rationale, risks, and links

• "No internal process for acting on feedback" → Communication log and feedback tracking folder added

• "Unclear project goal" → Scope clarified: Concept AI is a requirement-discovery tool, not a detailed design or compliance tool

Roadmap to PA4

Phase	Focus
PA2	Finalise prototype and PA2 deliverables
Break	Work on MVP; develop test and evaluation plan
PA3	Demonstrate MVP and discuss testing results
PA4	Present results, SWOT, and future recommendations