I'm a Bachelor of Computer Science (Professional) student at Swinburne University of Technology, specialising in machine learning, cloud architecture, and enterprise data systems.

- 🔭 Extracurriculars: Brains, Minds, and Machines Club
- 📚 Currently learning: Advanced Computer Vision, Cloud Architecture, and Enterprise Data Systems
- ⚡ Outside of code: Cooking, Working out, and Travelling
- 🎯 Status: Seeking a 6–12 month professional placement

Also proficient in: Scikit-learn, Keras, d3rlpy, REST APIs

Also proficient in: CI/CD, Hugging Face, KNIME, Confluence, Slurm, HPC environments, MuJoCo, Office365, Kinetica

Projects listed in reverse chronological order — most recent and most complex first.

2026 · Capstone Research Project (COS40005) · Industry Partner: Atlassian

The Problem

Offline reinforcement learning (Offline RL) is increasingly used to train robotic agents from pre-collected datasets — but what happens when that data has been tampered with? And once a model has learned something harmful, can you surgically remove it without rebuilding the model from scratch? These are open research questions with real consequences for AI safety, data privacy legislation ("right to be forgotten"), and the security of autonomous systems deployed in manufacturing and logistics.

Who We're Building This For

• Industry partner (Atlassian / Swinburne): A Senior Full-Stack Developer and PhD candidate who need a reproducible research platform validating trajectory unlearning on robotic benchmarks.
• AI Security Analysts: Who need to understand the exact poisoning threshold before an offline RL agent catastrophically fails.
• AI Compliance Auditors: Who need cryptographic proof that specific training data has been permanently erased from a deployed model, in line with Australian Privacy Act (APP 11) and SOCI Act mandates.

What We Built

Working as Project Lead and ML Architect across a 6-person Agile team, I led the end-to-end engineering of a research pipeline deployed on the OzSTAR supercomputer (Swinburne's HPC cluster) that:

• Established offline RL baselines on the FrankaKitchen manipulation benchmark (6 tasks: microwave, burner, light switch, slide cabinet, hinge cabinet), training IQL and CQL agents using the D4RL dataset suite and achieving a stable ≥ 0.85 Mean Reward across all tasks.
• Implemented TrajDeleter (NDSS '25) — a trajectory-level machine unlearning algorithm — ported into our pipeline and validated against a "retrain-without-deleted-data" baseline. Post-unlearning agents retained >95% utility across all FrankaKitchen scenarios.
• Engineered a BAFFLE-style backdoor attack pipeline, injecting Gaussian noise and targeted label swaps into the kitchen-mixed-v0 HDF5 dataset at 5%, 10%, and 20% corruption levels. Identified the ≥20% poisoning threshold as the point of catastrophic policy collapse across all three dataset variants (partial, mixed, complete).
• Deployed Membership Inference Attack (MIA) shadow models to mathematically prove trajectory erasure, capturing Temporal Difference (TD) Error spikes as cryptographic proof that backdoor-influenced trajectories were permanently removed — not merely suppressed.
• Containerised the entire research stack using Apptainer (.sif), bypassing OzSTAR's strict read-only filesystem and legacy Python 3.7 constraints. Resolved 40+ documented HPC bugs including GPU memory mapping errors, Slurm permission stripping, Lustre I/O bottlenecks, and headless MuJoCo rendering crashes.

My Specific Contributions

• Architected the immutable p37_env.sif Apptainer container and all Slurm execution scripts.
• Engineered an in-memory PyTorch monkey patch to resolve a hardcoded d3rlpy CPU/GPU index mapping bug — without rebuilding the container.
• Used sed for JIT source-code patching to override hardcoded training horizons at runtime, scaling from 1k to 500k steps while leaving the original research repository untouched.
• Implemented CPU pinning (taskset -c) to eliminate cache-miss penalties during parallel training, yielding a 3× training throughput improvement.
• Led all three client demonstrations (Microsoft Teams) to stakeholders from Atlassian, presenting live OzSTAR telemetry, MIA validation results, and robot simulation video evidence.

Collaboration & Process

• Managed 6 engineers across ML, DevOps, Data Engineering, Security, and QA streams using Agile Matrix Management (Trello sprint boards, async stand-ups, mandatory RSVP protocols for client demos).
• Enforced a centralised Git policy with PR-based code review; responsible for 100% of Alpha/Beta branch commits and final codebase synchronisation.
• Conducted formal sprint retrospectives after each client demo and translated client feedback directly into updated backlogs.

Tech Stack

Python · PyTorch · d3rlpy · MuJoCo · ManiSkill2 · D4RL · HDF5 · Apptainer · Slurm · OzSTAR HPC · Matplotlib · NumPy · Bash · Git

Key Outcomes

What I Learned

This project fundamentally changed how I think about the gap between research and production. Deploying academic ML pipelines onto shared HPC infrastructure with strict permission hierarchies, legacy dependencies, and no internet access forces a level of systems thinking that no coursework fully prepares you for. I learned to treat infrastructure as a first-class engineering problem, not an afterthought — and to communicate deeply technical blockers to non-technical stakeholders without losing their trust.

🔗 View Repository · Semester 2 ongoing

2026 · Artificial Intelligence Engineering (COS40007) · Industry-Inspired: Heidi Health

The Problem

GP clinic admin staff are buried in voicemails — many urgent, some routine, all requiring manual listening before any action can be taken. Missed or delayed callbacks on high-priority calls carry genuine patient safety risks. The challenge was building a production-grade AI pipeline that could automatically transcribe, classify, and triage incoming clinic voicemails by urgency and intent, freeing staff to act rather than listen.

Who We're Building This For

• Clinic admin staff at Harbour to Sunset GP who need incoming voicemails surfaced as a structured priority queue — urgency-sorted, intent-labelled, and actionable without replaying each recording.
• Practice managers who need auditability: every voicemail item tracked through its full lifecycle (new → in progress → resolved) with assigned ownership.
• ML engineers who need a fully observable, version-controlled system with automated performance monitoring and a documented retraining trigger strategy.

What We Built

A two-person Agile team built a full-stack intelligent voicemail triage system across 3 sprints (11 weeks), following the MLOps lifecycle end-to-end. The system ingests raw clinic voicemail audio, transcribes it via Whisper, classifies urgency and intent using a trained ML classifier (SVM / Random Forest with TF-IDF vectorisation), and surfaces results to admin staff through a React priority-queue dashboard backed by a FastAPI inference endpoint.

• Designed and documented a complete system blueprint covering all ML and non-ML components, data flow, system boundaries, and environment layers — including a Feature Server, ML Pipeline, Model Registry, Monitoring stack, and Admin Actions interface.
• Engineered a full MLOps data pipeline: Kaggle dataset download and validation → Whisper audio transcription → text normalisation and edge case handling → TF-IDF feature engineering → stratified 70/15/15 train/val/test splits with class-balance validation.
• Trained and evaluated multiple classification models (SVM, Random Forest) with full hyperparameter sweeps across learning rate, batch size, and regularisation configurations, targeting macro F1 ≥ 0.80 on held-out test data.
• Built a FastAPI inference service with Pydantic input validation, singleton model loading at startup, and structured JSON output (intent class + urgency level + confidence score).
• Developed a React triage dashboard with a priority queue sorted by urgency, intent classification badges, and one-click admin actions (assign / callback / flag / resolve).
• Deployed to Google Cloud Run via Docker containerisation, verified endpoint accessibility and response latency end-to-end.
• Implemented a GitHub Actions CI/CD pipeline that triggers on every merge to main: runs unit tests, re-evaluates the model on the held-out test set, commits a timestamped classification report to /reports, and raises a GitHub issue automatically if F1 drops ≥5% from baseline.

DevOps & MLOps Highlights

The project was deliberately structured around production-grade engineering discipline, not just model accuracy:

• Drift detection: Token frequency histograms from the training corpus are used as a baseline; KL divergence against new inputs flags data drift. Sustained drops in model confidence scores signal concept drift (e.g. new medical terminology or seasonal call pattern shifts) and trigger a documented retraining review.
• Model versioning: All model weights follow a timestamp-based naming convention (model_v1_20260420.pt) stored in a dedicated /models directory. Each version is accompanied by a JSON config recording exact hyperparameters, dataset split sizes, and achieved metrics — ensuring any prior model state is fully reproducible.
• Branch protection & PR review: Main branch protected; all changes submitted via pull request with mandatory peer review before merge.
• Experiment tracking: Git sprint tags mark each submission milestone as a permanent, recoverable snapshot of the codebase and model state.
• Retraining strategy: A performance-based 5% F1 drop threshold was chosen specifically because a 5% recall drop on the "urgent symptom" class means roughly one in twenty urgent patient calls is miscategorised as routine — a direct patient safety implication, not just a model quality metric.

Collaboration & Process

• Used the full Atlassian suite: Jira for sprint planning and 20-ticket backlog management across 3 sprints, Confluence for all documentation (ADRs, system overview, sprint retrospectives, dataset cards), Loom for async video updates and demo recordings.
• Maintained a conventional commit message format across the shared GitHub repository, with Alpha (development) and Beta (stable) branch strategy.
• All architectural decisions documented as Architecture Decision Records (ADRs) in Confluence, including model selection rationale, retraining trigger choice, and CI/CD pipeline design.

Tech Stack

Python · Whisper · Scikit-learn (SVM / Random Forest) · TF-IDF · FastAPI · Pydantic · React · Docker · Google Cloud Run · GitHub Actions · Jira · Confluence · Draw.io

Key Outcomes

What I Learned

This project sharpened my understanding of the gap between training a model and operating one. Building the CI/CD evaluation pipeline — so that every code merge automatically re-evaluates the model and flags performance regressions — made the system genuinely observable in a way that a standalone notebook never is. Designing the retraining trigger around a patient safety threshold rather than an arbitrary accuracy number was a forcing function to think like an engineer deploying into a regulated domain, not just a researcher chasing metrics.

🔗 View Repository

2025 · Applied Machine Learning (COS30082) · 6-Person Team

The Problem

Enterprise attendance systems that rely solely on face identity are vulnerable on two fronts: spoofing attacks (printed photos, screen replays) can fool the recogniser, and static systems can't register new employees without retraining the entire network. The challenge was building a production-ready, multi-modal attendance pipeline that handles identity verification, liveness detection, and emotion recognition concurrently in real time — with zero retraining required for new employee enrolment.

Who We're Building This For

• Enterprise HR and security teams who need a contactless, spoof-resistant attendance system that surfaces identity, liveness status, and emotional state in a single live dashboard.
• ML engineers who need a modular, independently testable architecture where each neural network component can be swapped or retrained without disrupting the rest of the system.

What We Built

A 6-person team built a fully integrated, real-time facial recognition attendance system in Python, combining four neural network pipelines — face verification, liveness detection, emotion recognition, and an individual innovation module — behind a single FreeSimpleGUI desktop interface and a live MJPEG webcam feed. The system architecture was organised into five discrete layers: UI and request management, Haarcascade face segmentation, model-specific preprocessing, parallel deep learning inference, and a state-machine event logger that commits verified attendance records to a secure CSV database.

Face Verification

Two architectures were trained and compared on the 24-identity RAVDESS dataset:

• FNN (Feedforward Neural Network): Three dense layers (512 → 512 → 256 units) with LeakyReLU, BatchNorm, and Dropout. Lower closed-set accuracy (61%) but significantly superior open-set verification — 79.34% ROC-AUC — because it learns spatially invariant, generalisable embeddings rather than memorised identity boundaries.
• MLP (Multilayer Perceptron): Deeper five-stage architecture achieving 80% closed-set accuracy but degrading sharply on open-set verification (65.89% ROC-AUC) due to overfitting to the 24 training identities.

The FNN was selected for production. At inference time, a 128-dimensional cosine similarity comparison against a cached embedding database identifies registered users. Faces with no match above a 0.85 threshold trigger automatic enrolment — no model retraining required.

Liveness Detection (Anti-Spoofing)

Trained on the CelebA-Spoof dataset (600K+ images, 10,177 subjects) covering print attacks, screen replay, and cut-out attacks. Two architectures compared:

• Custom baseline CNN: Fast but limited — struggled on high-resolution digital replay attacks.
• MobileNetV2 (transfer learning): Two-phase training — frozen backbone (15 epochs, lr=1e-4) followed by fine-tuning layers 100+ (lr=1e-5). Achieves 94.74% test accuracy and 0.9979 AUC on low-quality device generalisation. Zero real faces missed (live recall = 1.00). Only 388 fake faces out of 4,411 incorrectly passed.

Emotion Detection

Four architectures evaluated on the AffectNet dataset (8 classes: anger, contempt, disgust, fear, happy, neutral, sad, surprise):

• Vanilla CNN (96×96 RGB, 4 conv blocks): 67.14% accuracy, macro F1 0.63
• Residual CNN (128×128 RGB, residual blocks + squeeze-and-excitation): 68% accuracy, macro F1 0.63, lowest test loss (1.13) — selected for production
• EfficientNetB0 (224×224, two-phase fine-tuning): 66% accuracy — strong on contempt, weak on fear/surprise confusion
• Hybrid CNN-Transformer (96×96, conv stem + 2-block transformer encoder): 56% accuracy — struggled on subtle negative emotions where convolutional inductive bias outperforms global attention at this scale

The Residual CNN was chosen for its consistently lower loss, more stable predictions across emotion classes, and best real-world webcam performance.

My Specific Contributions

• Architected the hybrid_attendance.py orchestration script — the central hub managing data flow between webcam feed, four model wrappers, the state-machine logger, and the GUI thread.
• Designed and implemented the Lip Reading Module (individual innovation): a CNN-LSTM processing 15-frame mouth-movement sequences to classify spoken passphrases, adding a behavioural biometric layer against presentation attacks.
• Implemented process forking to decouple TensorFlow .fit() retraining calls from the FreeSimpleGUI event loop — eliminating frame-freeze bugs that blocked the webcam feed during background retraining.
• Engineered the face verification preprocessing pipeline: Haarcascade ROI extraction → greyscale conversion → bilinear resize → normalisation → augmentation (flips, rotations, contrast shifts).
• Built the dynamic model gating system allowing individual neural network modules (verification, emotion, liveness) to be toggled live from the admin panel without restarting the application.

Tech Stack

Python · TensorFlow / Keras · OpenCV (Haarcascade) · MobileNetV2 · EfficientNetB0 · Residual CNN · CNN-LSTM · FreeSimpleGUI · RAVDESS · AffectNet · CelebA-Spoof

Key Outcomes

What I Learned

Building four concurrent deep learning pipelines into a single real-time application exposed infrastructure constraints that model training alone never does. Thermal throttling on consumer hardware when running MobileNetV2 + Residual CNN + CNN-LSTM simultaneously forced a rethink of inference scheduling. The most important lesson was that GPU concurrency and Python threading interact badly with GUI event loops — the fix wasn't clever synchronisation, it was process isolation. The lip reading module also underscored something non-obvious: a behavioural biometric (what you say, not just who you are) is a fundamentally stronger anti-spoofing primitive than pixel-level texture analysis alone.

🔗 View Repository

2025 · Computing Technology Innovation Project (COS30049) · Grade: 95% High Distinction

The Problem

Security Operations Centre (SOC) analysts are overwhelmed by alert fatigue — existing rule-based intrusion detection systems generate massive false-positive rates while missing novel attack patterns. The challenge was building an ML-driven system that could classify known attack types reliably while also detecting anomalies it had never seen before.

Stakeholders

Network security teams and SOC analysts at mid-to-large enterprises who need both a classification engine for known threats and an anomaly detection layer for zero-day-style traffic.

What We Built

A dual-mode Intrusion Detection System (IDS) combining supervised multi-class classification with unsupervised anomaly detection, served through a real-time FastAPI backend and a D3.js/Plotly dashboard.

Tech & Architecture

Random Forest · MLP · Custom PyTorch DNN · Isolation Forest · Autoencoder · FastAPI · D3.js · Plotly

Key Outcomes

• ~95% classification accuracy across attack categories
• Detection latency under 200ms per inference
• 95% reduction in undetected DDoS exposure in simulated test environments

What I Learned

Combining supervised and unsupervised approaches in a single pipeline required careful threshold calibration — the anomaly detector had to be sensitive enough to flag genuine outliers without drowning the dashboard in noise. Building the FastAPI layer also pushed me to think about model serving as a distinct engineering discipline from model training.

🔗 View Repository

2025 · Introduction to AI (COS30018)

The Problem

Urban traffic management authorities need short-term traffic condition forecasts to dynamically adjust signal timing. Raw SCATS sensor data from VicRoads is noisy, high-frequency, and arrives in inconsistent formats — making it a poor fit for off-the-shelf time-series models.

Stakeholders

VicRoads and urban traffic management operators who need accurate sub-5-minute traffic condition forecasts to inform adaptive signal control strategies.

What We Built

A real-time ML forecasting system comparing LSTM, GRU, and TCN architectures on VicRoads SCATS sensor data, integrated into a live Dash/Plotly dashboard with geospatial mapping.

Tech & Architecture

LSTM · GRU · TCN · Dash · Flask · Plotly · Custom data engineering pipeline for cleaning, resampling, and sequence windowing.

Key Outcomes

• ~30% model performance improvement following pipeline optimisation (sequence windowing, outlier handling, feature normalisation)
• Real-time dashboard with geospatial sensor mapping and live prediction overlays

What I Learned

The majority of value in this project came from the data engineering pipeline, not the model architecture. A well-windowed, clean sequence dataset made a modest GRU outperform a more complex TCN trained on raw data — a lesson about where ML effort is actually best spent.

🔗 View Repository

2025 · Intelligent Systems Team Project (COS30018)

The Problem

Digitising handwritten documents at scale requires OCR systems that go beyond printed digits — but most open-source systems either depend on cloud APIs or are limited to numeric recognition. The challenge was building a fully self-contained, containerised OCR system capable of recognising the full alphanumeric character set.

Stakeholders

Any organisation digitising handwritten records (healthcare, education, government) who need a deployable, self-hosted OCR solution without external API dependencies.

What We Built

A custom CNN trained first on MNIST (digits), then extended to EMNIST (letters + digits), served through a Flask API with an HTML5 canvas frontend allowing users to draw characters in-browser for live inference. The entire application was containerised with Docker for reproducible deployment.

Tech & Architecture

Custom CNN · Flask · HTML5 Canvas · JavaScript · Docker

Key Outcomes

• 98% accuracy on MNIST digit recognition
• Real-time inference under 200ms
• Full Docker containerisation for production-style reproducible deployment

What I Learned

Extending from MNIST to EMNIST surfaced how sensitive CNNs are to class imbalance — letter frequencies in natural writing vary enormously. Addressing this through augmentation and class weighting was more impactful than any architectural change.

🔗 View Repository

2024 · Cloud Computing Architecture (COS20019)

The Problem

Enterprise recruitment platforms need fault-tolerant infrastructure that maintains availability and data consistency even when individual compute nodes fail. Building this from scratch on AWS requires careful architectural decisions around load balancing, database failover, and network isolation.

Stakeholders

A simulated enterprise HR department requiring 99%+ uptime for a public-facing job posting portal, with audit requirements around data consistency under concurrent writes.

What We Built

A fault-tolerant, multi-tier web application deployed entirely within a custom AWS VPC, using Auto Scaling Groups, an Application Load Balancer, RDS with Multi-AZ failover, and S3 for static asset delivery.

Tech & Architecture

AWS VPC · ALB · EC2 Auto Scaling · RDS (Multi-AZ) · S3 · IAM · CloudWatch

Key Outcomes

• Validated 99% uptime under simulated load testing and manual EC2 instance termination
• Zero orphaned records under concurrent write stress testing
• Full IAM role separation between compute, database, and storage tiers

What I Learned

Designing for failure rather than designing to avoid failure is a fundamentally different mindset. The most useful part of this project was deliberately breaking things — terminating instances mid-request — and watching the ALB route traffic seamlessly to healthy nodes.

🔗 View Repository

2025 · COS20031 Database Design Project

The Problem

A fictional archery enterprise was managing athlete performance and competition data across a fragmented set of spreadsheets, resulting in duplicate records, update anomalies, and no scalable path to analytics reporting.

Stakeholders

Club administrators needing reliable operational data, and a management team requiring an analytical layer for performance trend reporting via Power BI.

What We Built

A fully normalised operational relational database (3NF) and a separate analytical schema (Snowflake model) designed for read-optimised reporting, with a complete ETL pipeline connecting the two layers.

Tech & Concepts

SQL · 3NF Normalisation · Snowflake Schema · Referential Integrity · Indexing Strategy · ETL · Window Functions · Power BI

Key Outcomes

• ~35% reduction in redundant data storage through full 3NF normalisation
• Eliminated insert, update, and deletion anomalies
• Built a scalable Snowflake analytical schema as the foundation for Power BI dashboards

What I Learned

Schema design decisions made early are extraordinarily expensive to reverse later. Spending time on entity-relationship modelling before writing a single line of SQL saved hours of migration work and produced a far more maintainable system.

🔗 View Repository

2025 · COS20007 Object Oriented Programming

The Problem

Traditional game controllers require dedicated hardware. The goal was to explore whether real-time computer vision could replace a physical controller entirely, mapping physical object movement captured by a standard webcam to in-game actions.

What We Built

A real-time game engine with procedurally generated platforms where a physical ball tracked via webcam acts as the player controller. The system involved a cross-language pipeline: OpenCV (Python) handling vision and coordinate mapping, and Unity 3D (C#) handling physics simulation and procedural generation.

Tech & Architecture

OpenCV (Python) · Unity 3D (C#) · Physics-based Rigidbody Logic · Procedural Platform Generation

Key Outcomes

• Solved real-time signal mapping between webcam coordinates and Unity's physics space
• Implemented smoothing algorithms to eliminate coordinate jitter for responsive gameplay
• Built a stable cross-language data pipeline between the Python vision layer and the C# game engine

What I Learned

Latency is the enemy of game feel. Even a 30ms delay between physical movement and on-screen response is perceptible. This project taught me to profile every step of a real-time pipeline and to think carefully about where smoothing helps versus where it introduces lag.

🔗 View Repository

Thanks for visiting — feel free to reach out via email or LinkedIn.