Ground Truth & Lovable Prototypes: Loon Conservation AI Progress | Weekly Update by Komal

Liam narrates a weekly progress update on the Madison Loon Conservation AI project, covering why the team annotated ground truth before writing model code.

5:48 video3 min readWatch on YouTube

This weekly update tracks the Madison Loon Conservation AI project as it moves from setup into real annotation work. Liam narrates the recap, covering what team members Sai and Sara Joshi shipped this week: three repositories, an architecture document grounded in current research, and the first hand-drawn bounding boxes on drone footage of loons on open water.

Ground truth before model code

The team made a deliberate choice about order: repositories first, then the architecture document, then hand-drawn labels, and only after that, model code. The reasoning is that a detector inherits whatever its training data believes about the world. Writing model code before the labeling standard is settled means training on data that may not reflect the rules you actually want the model to learn. So the project spent its first week on what looks like housekeeping, repository setup and documentation, precisely because that groundwork determines what the model can later be trusted to do.

The small target problem

Drawing bounding boxes on loons floating on open water turns out to be harder than it sounds. The bird is a small, dark shape on a surface that keeps moving, and most of each frame is water, not bird. Every box is a person deciding exactly where the animal ends and the lake begins. At roughly 10 percent into the annotation work, the team is still at the point where the labeling standard is cheap to change. Every box drawn after that standard hardens gets drawn against a fixed rule; every box drawn before it may need to be redone. That is why the team is treating early annotation decisions as high-stakes even though the dataset is still small.

Consistency rules in CVAT

Sara Joshi's annotation work in CVAT focused on consistency: how tightly a box should fit an object, how to handle loons that are partially hidden or only partly visible, and keeping those choices the same across the whole dataset. Inconsistent labels now produce a weaker model later, so the annotation standard is being written down as instructions another annotator could follow exactly, not left as an implicit judgment call.

The Lovable prototype

Alongside annotation, the team is refining a researcher-facing prototype built in Lovable. The design question that came up repeatedly was whether researchers should see how the machine learning works underneath. The answer the team settled on is no. The workflow stays simple: upload an image, select what to detect, analyze it, and review the AI's results, with a human verification step before results are saved as structured research data. No trained model exists yet, and the team says that is the plan rather than a delay, since the prototype's workflow is being built to match the real computer vision pipeline once more drone imagery is available for training.

Key takeaways

  • The team locked repositories, an architecture document, and hand-drawn labels before writing any model code, because a detector inherits whatever its dataset believes.
  • Small, partially visible targets like loons on open water make bounding-box consistency the hardest and most consequential early decision.
  • Labeling rules are being written as explicit instructions another annotator could follow, since inconsistent labels now mean a weaker model later.
  • The Lovable prototype deliberately hides the machine learning behind a simple upload, analyze, review, and save workflow for researchers.
  • No model has been trained yet; the current work is building the dataset and prototype workflow needed once more drone imagery arrives.

Who this is for

Anyone building a computer vision project from scratch, especially one with small or hard-to-see targets, will find a concrete example here of why annotation standards and dataset consistency come before model training, not after it.

Chapters

  1. 0:00Weekly Overview: From Foundations to Real Annotation
  2. 0:35Ground Truth First: Why the Order of Development Matters
  3. 1:15Drawing Bounding Boxes on Open Water: The Small Target Challenge
  4. 1:55Dataset Consistency: Tackling Small and Partially Visible Loons in CVAT
  5. 2:25Lovable Prototype Walkthrough: Upload, Analyze, Review, and Save
  6. 2:55Next Steps: Aligning the Tool with the Computer Vision Pipeline
Full transcript(auto-generated, with timestamps)

Weekly Overview: From Foundations to Real Annotation

[0:00]Hello, this is Liam in for KML LON project update for Madison. This week the team moved from foundations into real annotation work. Ground truth first, then the lab shipping CV at T- labels and a researcher prototype. Two clips, one recap. Here is the week in one breath. Sai locked the order. Repositories first, then the architecture document, then handdrawn labels, ground truth before model code. Sara moved into CVT annotation and a lovable prototype with upload, analyze, review, and save. No trained model yet. That is the plan, not a delay. First sigh on why ground truth comes first. Nothing in a detector runs until

Ground Truth First: Why the Order of Development Matters

[0:36]Somebody has told it what the thing looks like. Three repositories, one architecture document, and the first boxes drawn by hand. Nothing in a detector runs until somebody has told it what the thing looks like. This is sigh. This week was foundations and none of it was model code. Three repositories initialized. A guideline document started on the architecture written from the current research instead of from habit. And the first images annotated by hand. Three repositories went up this week. Two for the footage, one for the code that reads like housekeeping and it isn't. A detector inherits whatever its data set believes. So the order matters, the places first, then the reasons, then the labels. Model code is the last thing

Drawing Bounding Boxes on Open Water: The Small Target Challenge

[1:15]You write, not the first. Then the document the architecture for this detector is being chosen from the current research and the practices that actually hold up and the choosing is being written down while it happens. That second part is the whole discipline. A model whose architecture you can't explain is a model you can't defend and somebody will eventually ask. And this is the actual work. Two loons on open water. Two boxes drawn by hand. Look how much of this frame is not a loon. That's the real problem. The bird is a small dark shape on a surface that keeps moving. And every box like this one is a person deciding exactly where the bird ends and the lake begins. The project is about 10% in. That's small enough to feel like nothing. And it's

Dataset Consistency: Tackling Small and Partially Visible Loons in CVAT

[1:55]Exactly the moment that matters. Right now, the labeling standard is still cheap to change. Every box drawn after it hardens gets drawn against a fixed line. Every box drawn before it is a box somebody may have to draw again. So week one, three repositories, one architecture document, and the first image is annotated. No model has been trained yet. That's the plan, not the delay. You don't get a second chance to decide what your ground truth means. Your turn. If you're annotating anything right now, stop at the next hundred images and write your labeling rule down

Lovable Prototype Walkthrough: Upload, Analyze, Review, and Save

[2:25]As instructions another person could follow. What counts as one instance, what you do with a half-hidden one, where the box edge goes when the subject blurs into its background. Then ask which of those you'll regret. Ground truth first. The repositories, the document, and the first boxes drawn by hand. Next week, deeper into the annotation. Sigh. Next. Suare on what shipped in the lab this week. From planning into data set and annotation. See via t labels for consistency and a researcher prototype that hides the machine learning behind a simple

Next Steps: Aligning the Tool with the Computer Vision Pipeline

[2:56]Workflow. Hi, this is Sara Jooshi and this week on the LON conservation AI project, I moved from planning and setup into the actual data set and annotation stage. Annotating images in seat and refining the researcherfacing prototype in lovable. This week had a real throughine. Build the actual annotated data set in SEVAT and keep shaping how the eventual AI tool will work for researchers. Both sides move the project from planning into something real. In seat, the real focus was consistency. How tightly a box should fit an object, how to handle loons that are small or only partly visible, and keeping every choice consistent across the data set. These annotations become the model's training data. So inconsistent labels now mean a weaker model later. Alongside the annotation work, I kept thinking about the bigger workflow. Raw images go through annotation then validation before they become a data set that can actually be exported into a format suitable for training a real detection model.

One design question kept coming up while updating the prototype. Should researchers see how the machine learning works? The answer is no. The workflow stays simple. Upload an image, select what to detect, analyze it, and review the AI's results. Everything technical happens in the background. This week's prototype changes reflected the real workflow we're building toward, showing detection results, adding a human verification step, and saving verified results as structured research data, all wrapped in a simple upload, analyze, review, and save flow. So, the honest state is this. We don't have a trained model yet and we still need more loon specific data before we can train and properly evaluate one. But the annotation work in seat and the refined prototype are building the exact data set and workflow we'll need once more real drone imagery arrives. Next, I'll keep annotating and reviewing the data set, refine the annotation process based on what I'm learning, and keep improving the prototype so its workflow lines

Up with the real computer vision pipeline. If you want to help, here's one question. What's the clearest rule for how tightly a box should fit a partially visible loon? That is the update for this week. Thank you for watching and I will see you next week. Let's recap for Madison SA 3 repos architecture document first annotations. The labeling standard is still cheap to change at 10% in Sara CVT consistency rules and a lovable prototype with human verification. Honest state, no trained model yet. More loon specific drone imagery still needed next week. Keep annotating. Refine the box rules. Align the prototype with the real computer vision pipeline. Your turn. Paste this into Claude. For a wildlife detection project, write labeling rules another person could follow. What counts as one instance. What to do with a half-hidden bird where the box edge goes on open water. Then score your last 10 boxes against those rules. Madison Weekly AG 28. Lay them in for comal.

More from Madison

Humanitarians AI Lyrical Literacy Project