I’ve been building an open-source case study around a smart water bottle’s liquid-level telemetry, and Gemini was part of the process from early on — so I wanted to post it here honestly, including the parts that needed correcting, not just the parts that worked.
The real story: an earlier version of the accuracy-validation pipeline had a filter that rescaled a reported error metric without touching the actual measurement — it made the QA report say “100% accurate” while the real reading was exactly as noisy as before. Found it, fixed it properly (multi-sample laser averaging, validated across 200 independent trials rather than trusting one lucky run), and kept the flawed version in the repo as a documented “before” case study rather than deleting the evidence.
Where Gemini fit in: drafting and ideation on an early structural-engineering write-up (vessel wall-thickness sizing using Barlow’s Formula and Timoshenko buckling). One term in that early draft — a “universal specific-strength coefficient” — sounded authoritative but was never actually defined anywhere in the math or the code. Caught it, documented exactly what was wrong and why, and replaced it with two real, derived, tested material indices. That correction is written up in the repo too, not swept under the rug.
Everything’s MIT licensed, three language ports (JS/Python/C++) checked against the same 24 test vectors, and every formula/constant is either derived or cited to a real source (a 1992 Boeing fuel-quantity patent, ISO/NIST metrology standards, Ashby’s materials-selection textbook).
Curious what people think, especially anyone who’s hit the same “the metric improved but the thing it measures didn’t” trap in their own sensor/QA pipelines.