Palak Porwal — Applied AI Engineer

The problem When a shipping lane closes, procurement can name the suppliers who ship through it. The expensive ones are the suppliers nobody names, connected two steps away through a reroute and discovered when the material fails to arrive.

How I scoped it "Handle supply chain disruption" is unbuildable. I narrowed it to one answerable question — given a live news event, which suppliers are affected, including indirectly — and made the system defend its answer with an evidence chain a human signs off on.

What it does differently 8 of 8 affected suppliers found on a compound Red Sea and QatarEnergy disruption. A single-agent baseline, given identical information, found 3.

Five specialist agents reason over a live digital twin of the supply network in Neo4j: monitoring, risk, planning, finance, and an operations manager that arbitrates between them.

It ingests real news as it breaks and traces the disruption through the graph to indirect exposure. Nothing executes without human approval — the system stops and presents its evidence chain first.

LangGraph · Neo4j · FastMCP · Qwen · React · Alibaba Cloud

I've written up how the agent society was evaluated against a single-agent baseline, and where the gap actually opens.

Live demo Code Read the write-up

AeroOps

Live · knowledge graph · 2026

The problem A line engineer asks why exhaust gas temperature margin dropped after a turbine swap. Document search returns the page that mentions EGT. The answer lives across three documents, and nobody assembles it at 2am on a turnaround.

How I scoped it The useful question wasn't "can it search manuals" but "can it follow a cause." I built a 35-question benchmark from real maintenance reasoning first, then designed the system against it, so the weak categories were visible before anything shipped.

What it does differently Answers, or admits it can't Conventional retrieval declined 11 of 35 benchmark questions, including 3 of 5 real operational scenarios. This answered all 35, every claim traced to its source page.

A knowledge graph of 267 components, failure modes and procedures extracted from seven NASA, FAA and operator sources, so the system follows a causal chain instead of matching keywords.

Built for maintenance reality: every claim carries its document, chunk and page, because an engineer acting on it has to check it against the manual.

Neo4j · LangGraph · FAISS · BM25 · Groq · Streamlit

Live demo Code

MaintenancePilot

Live API · production ML · 2026

The problem Compressor maintenance runs on a calendar, so operators either service equipment that was fine or discover the failure when the line stops. On a metro fleet that is a service outage, not a maintenance ticket.

How I scoped it The modelling question was easy to get wrong. A missed failure and a false alarm are not equally bad, so the threshold is set by what each actually costs, and evaluation runs on time-ordered splits because random ones let the model see the future.

What it does differently Catches 99.5% of failures with the alert threshold set by what a miss actually costs rather than a default. Trained on 1.5 million rows of real compressor telemetry across four documented failures.

The failure signature turned out to be behavioural, not a threshold breach: the compressor stops cycling and begins running continuously, hours before anything reads as out of range.

Deployed as a live API with automated drift monitoring that fails the build rather than filing a report, because a maintenance model degrading silently is worse than none.

LightGBM · Optuna · MLflow · FastAPI · Docker · Evidently · GCP Cloud Run

Live API Code

Supplier Risk Assessment

Final year project · NTU · 2025

The problem Sourcing teams commit to suppliers on price and lead time, then absorb the country risk, disaster exposure and infrastructure fragility nobody priced in at signing.

How I scoped it Risk is only useful if a buyer can act on it, so the deliverable was a decision tool with scenario simulation rather than a score. This is the problem SentinelSCM returns to a year later, with agents and a live graph instead of a static model.

What it does differently R² 0.91 on supplier risk scoring, with scenario simulation so a buyer can test a decision before committing to it.

A stacked ensemble of Random Forest, Gradient Boosting and LSTM base learners with a Ridge meta-learner, delivered as a decision tool with country-level risk mapping and supplier scenario simulation rather than a score in a spreadsheet.

Random Forest · Gradient Boosting · LSTM · Ridge · Streamlit

Code

Lead research and outreach agent

AI Engineer · stealth AI startup · Jul – Dec 2025

The problem A mid-sized financial services firm needed prospect research and personalised outreach at volume. Done by hand it doesn't scale; done generically it stops working.

How I scoped it Alongside the build I ran pilot evaluations and discovery conversations with several companies, which is where the scoping actually happens: working out which parts of a workflow an agent handles well and which parts should stay with a person.

What it does differently 50-60% less manual effort on prospecting and analysis, measured against a timed baseline of the existing process rather than estimated.

A production lead-scraping and personalised-outreach agent, deployed for the client and built on LangChain and LangGraph over OpenAI models.

Also prototyped agentic and RAG systems across several other business workflows. My first production agent, and the reason the projects that followed were built around evaluation and human approval gates from the start rather than bolted on after.

LangChain · LangGraph · OpenAI · Python

Multimodal search evaluation

Associate Scientist Intern · P&G Data & Modelling Sciences · Jan – Jun 2025

The problem A text-to-image search engine over 50,000 images was built to give researchers a wide visual range for a theme. Ask it for a theme and it returned ten excellent results that all looked like the same photograph.

How I scoped it The standard metrics said the system was fine, and they were right about relevance and wrong about the product. Since the whole premise was personal interpretation, I defined three metrics around what a researcher would actually notice — relevance, diversity, and palette — and benchmarked four retrieval configurations against them.

What it does differently Framework, not a fix Shipped the evaluation framework alongside the recommendation, so the team could re-run the comparison as the image set grew. Roughly two seconds a query at 50,000 images.

Two more systems in the same six months: a colour correction pipeline for the VISIA CRP skin-imaging platform, with YOLO-NAS chip detection at mAP@0.5 of 90.4% and RGB to LAB modelling validated against spectrophotometer ground truth. And an auto-tagging pipeline that classified 10,000+ scalp images by clustering CLIP embeddings, cutting manual tagging effort by around 80%.

Presented results and design trade-offs in bi-weekly reviews to stakeholders across the US and China, where the job was turning technical findings into decisions.

CLIP · FAISS · HNSW · MMR · YOLO-NAS · NLLB · colour histograms

I've written up how the evaluation framework was designed, and why the obvious metrics pointed the wrong way.

Read the write-up

Ground station automation

ML Engineering Intern · NTU Satellite Research Centre · Jan – May 2024

The problem Satellite operations depend on tracking elements and space weather that live across three separate providers. Pulling them by hand every day is slow, error-prone, and has to happen before anyone can forecast anything.

How I scoped it The forecast was the visible ask, but it was useless without a reliable feed underneath it. So the work split into three: an API over the satellite data sources, a space weather database on a daily schedule, and the ensemble model on top of both.

What it does differently Pipeline, then model Automated ingestion from three providers into a maintained database, with forecasting on top. Normalized RMSE 0.15 on sunspot number across 50,000+ observations.

A FastAPI service that fetches and processes satellite tracking data and TLEs from Celestrak, SatNOGS and Space-Track, alongside scheduled collection of both observed and predicted space weather into a maintained database.

On top of that, an ensemble forecasting solar activity, combining LSTM, Prophet and gradient boosting models to predict F10.7 solar flux, the driver behind satellite drag and communication blackouts.

FastAPI · Kubernetes · LSTM · Prophet · Gradient Boosting · Celestrak / SatNOGS / Space-Track

Code

Telemetry and launch planning tooling

Engineering Intern · Rocket Factory Augsburg · Jan – Jun 2023

The problem The telemetry team monitored its systems by hand. Separately, the RFA One launch programme's test campaigns and milestones lived across several engineering teams with no single view.

How I scoped it Both problems were coordination rather than analysis, so the useful output was tooling people would open every day, not a report. My first experience of building software inside an engineering organisation rather than for a course.

What it does differently Replaced manual monitoring The visualisation tool took over workflows the telemetry team had been doing by hand, and stayed in daily use.

Built a telemetry visualisation tool in Dash, Plotly and Selenium for the avionics team at a European launch vehicle company.

Coordinated the RFA One integrated launch plan across multiple engineering teams, covering test campaigns and milestone tracking in Microsoft Project and GNC tooling.

Dash · Plotly · Selenium · Microsoft Project

Writing

Your AI feature has great metrics. It's still failing your users.

What to do when no standard metric measures the thing your product actually promises.

Building SentinelSCM

A multi-agent supply chain control tower, and how to prove five agents beat one.