Deepthi's Reading

Quality

038

The clabsi-audit-insights Story

Photo-first CLABSI audits

Lovable · React · Hugging Face Transformers · Recharts

Edition #038 · 6 chapters · 6 min read

The clabsi-audit-insights Story

Photo-first CLABSI audits

Photo-based compliance monitoring with weekly trends and line-type performance.

An ebook edition of the clabsi-audit-insights build journey: how it started, what actually happened, the conversations that changed the build, what broke, and what I learned. Written in plain English for readers with no technical background. Tools covered: Lovable, React, Charts.

Start reading Back to the library

Start here

What you'll understand by the end

Not mastery — understanding. By the last page you'll be able to explain these in your own words, even with no technical background.

•what Charts really is, and what it cannot do
•what Lovable really is, and what it cannot do
•what React really is, and what it cannot do
•the difference between what the AI does, what the tool does, and what I do
•why permissions and privacy matter once AI can act on your behalf
•where a real person's judgement is still necessary

The concept ladder — the order I actually learned things

I had an idea worth building

↓

I asked an AI to help me shape it

↓

I learned the AI could explain things but could not act outside the chat by itself

↓

I met the tools that actually do the work

↓

I learned how those tools are connected and permitted

↓

I built something real and watched it break

↓

I learned where my own judgement is still required

Chapter 01

Why CLABSI Audit Insights had to exist

Track 1 · My journey

Dressing audits were happening by eye and ending up on paper. I wanted to know a narrow, testable thing: could a phone camera and a browser do any part of the looking, and would I be allowed to trust the answer?

Learning checkpoint

Before this chapter

I had a problem I could describe in a corridor conversation, but nothing I could hand to anyone.

After this chapter

I still did not know which tools to use, but I knew exactly who I was building for.

What changed my mind

The problem stopped being a complaint and became a specification.

Can you answer these?

?Can you state the problem in one sentence, without naming a solution?
?Do you know who is holding the screen when your product is used?

Chapter 02

Three questions, not one product

Track 1 · My journey

The build split into three: can I chart compliance in a way that separates a bad week from a real change, can non-clinical risk factors sit alongside clinical ones, and can an image model run on the device without a photo of a patient leaving it. Each was answerable separately, which is why the app has tabs rather than a single flow.

Learning checkpoint

Before this chapter

A blank project and a chat window.

After this chapter

The shape of the product was decided before a single deliberate design decision was made.

What changed my mind

I learned to treat conversation as a design tool, not as preparation for design.

Can you answer these?

?What is the one sentence in your own notes that decided the architecture?
?Are you describing outcomes, or dictating implementation?

Chapter 03

Building it: browser inference and control charts

Track 1 · My journey

The photo tool loads onnx-community/mobilenetv4_conv_small through the Hugging Face transformers library and runs it locally, preprocessing the image on a canvas first. The compliance side implements proper P-chart logic with upper and lower control limits, so an out-of-range week is judged statistically instead of by feel. TanStack Query and Recharts do the fetching and drawing.

Track 2 · Learn with Deepthi

Running a model in the browser

USED — evidence shows I used it

What did I just discover?: That a real image model can run on the phone itself, with the photo never leaving the device.
What is it, really?: Machine learning inference executed in the browser, using the device's own processor or GPU, instead of a server.
Think of it like this (analogy): Doing the maths on your own paper instead of posting the question away.
How does it actually work?: The model file is downloaded once, the image is preprocessed on a canvas, and the model returns scores for its categories.
Why did it matter to my project?: Because a photo of a patient's dressing is exactly the kind of thing that should not travel.
Where I used it: The photo audit tool, using mobilenetv4 through the Hugging Face transformers library.
What this tool cannot do: It classifies images against generic categories. Clinical judgement about a dressing is not something this model was trained for.

Track 2 · Learn with Deepthi

ONNX

USED — evidence shows I used it

What did I just discover?: That models are shipped in an interchange format so they can run outside the framework they were trained in.
What is it, really?: An open file format for trained models, letting one model run across many runtimes including the browser.
Think of it like this (analogy): A PDF for neural networks — written once, opened anywhere.
How does it actually work?: The trained model is exported to ONNX; a runtime in the browser loads the file and executes it.
Why did it matter to my project?: Because it is the reason browser inference is possible at all.
Where I used it: The onnx-community model loaded by the audit tool.
What this tool cannot do: Format portability says nothing about whether the model is right for your task.

Track 2 · Learn with Deepthi

P-charts and control limits

USED — evidence shows I used it

What did I just discover?: That there is a proper statistical way to tell a bad week apart from a real deterioration.
What is it, really?: A control chart for proportions, with limits calculated from the data that mark the boundary of normal variation.
Think of it like this (analogy): Lane markings on a road. Drifting inside them is normal; crossing one means something changed.
How does it actually work?: The average proportion and sample size give upper and lower control limits; points outside them signal a genuine shift.
Why did it matter to my project?: Because reacting to every dip in compliance wastes the reaction you need for a real one.
Where I used it: The statistical process control charts in the compliance tab.
What this tool cannot do: Control limits assume the process is otherwise stable, and they need enough data points to be meaningful.

Learning checkpoint

Before this chapter

I had screens in my head and a stack I had not yet justified.

After this chapter

A working product, and a much shorter list of things I believed without evidence.

What changed my mind

The stack became a means, not an identity.

Can you answer these?

?Could you rebuild your first screen in an afternoon if you had to?
?Which tool are you using out of habit rather than fit?

Chapter 04

Where I stopped, and why

Track 1 · My journey

The model runs. The clinical verdict on top of it does not: inside performMedicalAnalysis the dressing assessment is simulated logic written to prove the pipeline, not a validated medical classifier. There is also no database in this project at all — no migrations, no tables — so nothing audited is stored. Both facts belong on the front page of any honest description of this build.

Learning checkpoint

Before this chapter

Something that worked in the demo and failed in real life.

After this chapter

A smaller, blunter, considerably more useful product.

What changed my mind

I stopped defending the first version and started measuring it.

Can you answer these?

?What in your build is complete but unused?
?What would you cut if you had to halve the time it takes to use?

Chapter 05

What actually changed

Track 1 · My journey

My understanding of the boundary. Running a model became the easy half; deciding what a model is permitted to conclude about a patient became the real work, and it is not a coding problem.

Learning checkpoint

Before this chapter

A product that worked, and no clear evidence that it mattered.

After this chapter

A clear-eyed view of what the product does and does not fix.

What changed my mind

Success stopped meaning "it is built" and started meaning "it is used".

Can you answer these?

?What behaviour changed because your product exists?
?Would anyone notice if it disappeared tomorrow?

Chapter 06

What I would tell you before you start

Track 1 · My journey

Build the pipeline and label the judgement as unvalidated in the code itself. A comment that says simulated is the difference between a prototype and a claim.

Learning checkpoint

Before this chapter

You have read what happened. Here is what to take with you.

After this chapter

A method you can reuse on a completely different problem.

What changed my mind

The build became repeatable rather than lucky.

Can you answer these?

?What is your version of the short loop?
?What will you ship this week, even if it is embarrassing?

Appendix

Deepthi's Dictionary

Short loop: Describe, build, use, correct — repeated in hours rather than weeks. The core working method behind this build.
Second use: Whether someone opens the product a second time without being asked. The simplest honest measure of whether it works.
Conversation beat: A single line in a build conversation that changed a decision. Collected, these form the real design document.
Worst day design: Designing for the tired, rushed, distracted user rather than the ideal one in a demo.
Lovable: Lovable — part of the stack used to build clabsi-audit-insights.
React: React — part of the stack used to build clabsi-audit-insights.
Charts: Charts — part of the stack used to build clabsi-audit-insights.