AI product · MLOps · Full-stack
AECAI: from inspection models to a working product
An AI-assisted structural inspection platform. Inspectors upload photos; crack, spalling and exposed-rebar models run in parallel; engineers review annotated findings and issue reports.
- Context
- AECAI Ltd (Belfast): co-founder & CTO
- Period
- Dec 2025 – present
- My role
- CTO: CV pipeline design, model evaluation, and the full web console (Next.js)
- 3
- Production defect models
- crack · spalling · exposed rebar
- 0.901
- Rebar U-Net F1 (IoU 0.820)
- 1,500 validation patches · P 0.903 · R 0.899
- 58 → 19
- Spurious regions removed
- hardest test photo · rule validated on 23 images
- 2
- Models run in parallel per photo
- non-fatal: one failing never blocks the inspection
Chapter 01
The engineering challenge
Research models only become useful when they sit inside the inspector's workflow: capture, detection, engineer review, report.
Models trained on close-up benchmark photos behave differently on real uploads, which vary in scale, surface finish and lighting.
Chapter 02
Input data
Inspection photos
Uploaded per location and element by inspectors
Structured forms
Floors, elements and condition fields from the form builder
Model weights
Crack, spalling and exposed-rebar U-Nets on a model hub
Chapter 03
The AI & engineering workflow
Stage 1 of 5
Capture
Inspector creates an inspection and uploads photos per location
What I did
- Built the entire web console (`apps/console`, Next.js): dashboards, structures and assets, inspection forms with a form builder, photo review and reports.
- Designed the spalling and exposed-rebar pipeline: 224 px patches at 50% overlap, Gaussian-weighted stitching, flip test-time augmentation, thresholding and morphological clean-up.
- Dispatched crack and spalling detection in parallel from the app to serverless GPU workers. Each finding is stored with geometry and confidence for engineer review.
- Audited model quality myself. The rebar model looked broken on user photos, but I traced the cause to a training-metric artefact and a scale gap, not the weights.
Production architecture
One photo, two GPU workers, one engineer's decision.
01 · App
Inspection consoleNext.js · VercelInspector uploads photos per location; one action dispatches both models in parallel● Built by me02 · Orchestration
Edge functionsSupabasecv-detect · cv-detect-spalling: submit jobs, poll, store results03 · Inference
Crack U-Net workerRunPod serverless GPUScales from zero; weights pulled from Hugging Face at cold startSpalling + rebar workerRunPod serverless GPU224 px patches, Gaussian stitching, flip TTA, post-processing● Built by me04 · Data
Runs, findings, imagesSupabase Postgres + StorageOne run per model; one finding per defect region, with geometry and confidence05 · Decision
Engineer review & reportConsoleFindings are checked by an engineer before a report is issued● Built by me
Chapter 04
Technical result
- Delivered a working product loop: capture, AI detection, human review and reporting.
- Replaced a hard-coded confidence with the mean predicted probability, and fixed stitching so probabilities are accumulated before thresholding.
- Swept thresholds across 23 test images and 260 candidate regions. This produced a scale-invariant false-positive rule that removed speckle noise without losing any real spalling.
- Diagnosed the remaining failures (peeling paint and whitewash) as a gap in the training data, not something to tune away. That points to the next data-collection priority.
Exposed-rebar U-Net on its validation split
Computed with pixel-aggregated metrics after I found that the notebook's per-image averaging had reported F1 = 0.14.
View data table
| Category | Rebar U-Net (VGG-19) |
|---|---|
| Precision | 0.903 |
| Recall | 0.899 |
| F1 | 0.901 |
| IoU | 0.820 |
Source: AECAI model-evaluation log (v0.6, 2026-09-18)
Limitations, stated plainly
- Spalling over-detection on painted brickwork is only partly mitigated. The fix is new negative training data, which is planned.
- Edge functions, migrations and infrastructure secrets are owned by my co-founder. My ownership is the console and the CV pipeline design.
Outputs & artefacts
Chapter 05
Practical impact & relevance
- Takes computer vision from notebook to production: serverless GPU inference, cold starts, schema design and an engineer-in-the-loop review step.
- Shows disciplined evaluation. I disproved my own overfitted rule, and fixed a misleading metric before it drove a decision.
EvidenceWhere every figure on this page comes from
Each metric is taken from a primary record, not from a CV. Hover a metric to see its source. The underlying files are available for review at interview.
- AECAI engineering knowledge base
- AECAI model-evaluation log
- AECAI product screenshots (identifiers blurred)
Commercial details, credentials and customer data are excluded. The screenshots come from the founders' own workspace, with addresses and coordinates blurred.
Next case study
CAD-to-BIM AI: structural drawing understanding