Selected work

A small number of projects, explained as problems.

Each one is written the same way: what was wrong, what was built, how it was engineered, and what changed. Technology lists come last, if at all.

Week planPLAN VALIDATED
Protein targetWITHIN RANGE
Allergen rulesPASSED
Weekly budgetWITHIN LIMIT

Conceptual visual based on the project's engineering approach.

CASE STUDYConsumer product · AI application

AI-powered meal planning product

Generating a week of meals is straightforward to demonstrate and much harder to make dependable. Each plan has to satisfy nutrition targets, dietary restrictions, budget and available ingredients before it can be shown.

  • Model output constrained to a validated schema before it reaches the product interface
  • Hard nutrition, dietary and budget rules checked outside the model
  • Repeatable evaluation cases used to catch quality regressions
Detection reviewTHRESHOLD REVIEW
Above thresholdACCEPTED
Below thresholdDEFERRED

Conceptual visual based on the project's evaluation approach.

CASE STUDYResearch · Computer vision

Applied computer-vision research

A model that is usually right is only useful in a controlled system if uncertainty changes what happens next. This work focused on measuring that boundary and deciding when the system should defer to a person.

  • Confidence checked against labelled examples rather than accepted as a probability
  • An explicit threshold separates automated handling from human review
  • A reproducible benchmark keeps later comparisons meaningful

HOW EVERY CASE STUDY IS WRITTEN

01

Problem

What was slow or unreliable, in the business’s own words.

02

Solution

The workflow that replaced it, drawn as a flow rather than described.

03

Engineering

The parts that make it survive contact with production.

04

Outcome

What measurably changed — stated only where it can be stated accurately.

Your process probably looks like one of these.

Tell me how it works today — where it starts, who touches it, and where it slows down.