Quality engineer · ISO 13485 medical devices

I find the checks that pass when they shouldn’t.

A calibration sticker that disagrees with its certificate. A backup that reports success while saving one file. A score that can’t come out wrong. I’ve spent nine years in engineering and manufacturing quality, most recently in FDA-regulated medical-device manufacturing, and I validate the software and AI systems I build the same way.

Work: Quality systems, CAPA, calibration and supplier quality under ISO 13485 and ISO 9001
Looking for: Quality systems, software quality and validation roles
Based in: St. Louis, MO · open to remote (US)

Open the 90-second demo coinupbtc@gmail.com

Off the clock I build things you can play with: an arcade of fourteen phone-first games, a live Bitcoin block war, a falling-sand chemistry set, a lunar lander for your thumb. The lab

Start here · runs in your browser

Helix QMS Desk

A working quality desk for a fictional biomedical plant. In 90 seconds you walk a Monday morning:

a voltage standard whose calibration sticker disagrees with its certificate,
a CAPA 8D that repeats a closed one,
supplier SCARs and a training gap,
then IQ/OQ/PQ on the desk itself and on its AI assistant, where an empty answer counts as a failure.

Every record is synthetic. The failure it’s built around is real: a status label that stopped tracking the record it claims to show.

Open the desk · Source

Case files

Problems I found, and how I proved the fix

Each one is written the way a corrective action reads. Where there’s a public file, the evidence links to it.

Data integrity

A backup that passed for 15 days while saving one file

Found: A nightly backup reported success for 15 days in a row. Each archive held 1 file instead of the full configuration set.
Root cause: The check confirmed the archive existed. It never looked inside.
Fix: Replaced presence checks with entry-count verification on every backup tier.
Lesson: The same failure as a calibration sticker that no longer matches its certificate: the indicator kept saying "good" after it stopped measuring anything.

Evidence My home lab. I’ll walk through it in an interview.

Metrics

A score that could not come out wrong

Found: A reporting tool’s headline accuracy metric could never come out wrong, and its results board included 118 of 144 events that had already finished.
Root cause: The baseline was derived from the same data it graded, so the metric agreed with itself by construction.
Fix: Rebuilt it with leave-one-out baselines and an independent scoring harness.
Verified: The metric can now fail, which is the only way a passing score means anything.

Evidence Private project. I’ll walk through it in an interview.

Release gate

A release gate that rejected the better build

Found: A fine-tuned AI model scored better on its target task but failed 4 unrelated checks: 15/19 on the release gate.
Rule: A build ships only at 19/19. No exceptions for a better headline number.
Fix: Rejected it and rebuilt the training set: 2,883 pairs generated by two independent models and graded on their agreement.
Verified: 19/19 on the gate. On 104 held-out records: 96.2% field-level accuracy against 89.2% for the base model, and 71% fully correct against 34%.

Evidence The 19-check gate Training scripts

Performance

From 13 seconds to 7.5 milliseconds

Found: Selecting one row in a 516-record list took 13 seconds.
Root cause: Every filter pass rebuilt every row and parsed the same files again.
Fix: Stopped rebuilding rows that hadn’t changed and removed the repeated parsing.
Verified: A flat 7.5 ms, measured before and after.

Evidence The bug and the fix, timed in your browser

Study

Control charts against machine learning on real factory data

Question: Do machine-learning alarms catch failing production runs better than classic control charts?
Method: Public UCI SECOM data: 1,567 production runs, 590 sensors. Same 1% false-alarm budget for every method, tested on later runs only. I committed the analysis plan before scoring the test data.
Result: No method reliably beat chance. Control limits set on early runs over-alarmed 1.8–4.2× their 1% target on later runs.

Evidence Repo with plan, deviations log and results

How I work

Three rules I use on the floor and in code

Presence is not integrity

A file that exists, a 200 response, a sticker on a meter. None of them prove the contents are right, so I check the contents.

Baseline first

Record how a system behaves before changing it. Without a baseline, an improvement is just a claim.

One change at a time

Change one setting, measure again, and keep it only if the evidence says so.

The lab

Things I build at home, tested like parts

I build things people can play with: browser games, a live Bitcoin block war, a falling-sand chemistry set. Every game goes through the same public quality checklist before it reaches the shelf, and one that hasn’t passed yet says so on its card.

I also run AI models on two NVIDIA DGX Spark computers at home and tune them the way I’d qualify equipment: record a baseline, change one thing, measure again. Three of my fixes to the serving engine are now upstream. Speed isn’t the test: turning off the model’s step-by-step "thinking" made replies much faster, but a blind comparison on my own questions preferred thinking on 8 times out of 9, so it’s back on.

The Arcade
Fourteen browser games, phone-first, each held to the same public quality checklist. Every card says whether its game passed.
Play
Blockfield, falling sand, a lunar lander and a moiré bench. Browser toys, phone-first.
The bench
The 13-second render bug, speculative decoding, memory packing, context carry. Each one timed in your browser.
Lean AI
Lean manufacturing’s wastes, measured on an AI agent the way I’d measure a line. One idea from the day job, applied off the clock.
miaai35-tune
A setting-by-setting tuning study with a recorded baseline, plus the 19-check release gate.
spark-console
A read-only health dashboard for the machines. It only listens on the machine itself and has no start, stop or kill buttons.
All public code on GitHub
Each repo says how to run it.

Skills

What I work with

Quality systems: ISO 13485, ISO 9001:2015, CAPA, nonconformance and MRB, complaint investigation, 5-Why and fishbone, internal and third-party audit readiness, document and change control
Metrology and suppliers: ISO/IEC 17025 calibration vendors, NIST-traceable standards, calibration records, supplier certification, incoming and final inspection to drawing
Software quality: Validation of electronic quality records, risk-based test scoping, acceptance criteria before execution, requirements-to-test traceability, regression gates, data-integrity checks
Tools: Python, Linux, Git, FastAPI, Docker, llama.cpp, vLLM, Hermes Agent, AutoCAD, SolidWorks (working knowledge)

Contact

Hiring for quality or validation? Email me.

coinupbtc@gmail.com

GitHub X · @coinupbtc The lab