Why AI monitoring of livestock farming does not reach results
Typical picture at a complex: cameras in alleys and above the feed table record around the clock, animals wear activity sensors, the milking parlor provides a log for each milking, and the livestock specialist keeps records of treatments.
Data exists, volume grows, but herd decisions are made the old way — walking the barn twice a day and visual estimation. A signal about lameness, mastitis, or injury reaches a person when the animal already refuses feed or milk yield drops.
The reason is not a lack of observations, but fragmented data from the farm. The video stream lives in one system, sensor readings in another, the milking log in a third, and they have different recording frequencies, different animal identifiers, and different timestamps.
It is impossible to bring this into a single time scale for a specific cow manually: while an analyst compares the exports, the case has either passed or become chronic.
The cost of late disease detection is not calculated from a single episode.
Treatment begins on the second or third day after the real onset, so the share of repeat treatments grows, some animals are culled, and productivity losses accumulate across the group for weeks — in our projects this is 5–12% of milk yield in the affected area.
A separate problem is noise. If a system without labeling and threshold calibration produces dozens of alerts per shift, staff stop responding even to valid ones, and herd control becomes a formality.
We explain how this is addressed — from a unified time scale for each animal to thresholds that a shift can actually work with.
Measurable effects: what changes on the farm after implementation
The effect is measured by response times, shares of closed scenarios, and failure classes that have been eliminated. We record metrics before launch and repeat the measurement a month later — then it is clear what has changed.
Early disease detection and mortality
Detection from the video stream of the feed alley runs on a model of the YOLO family: reduced activity, refusal of the feeder, lameness, atypical body position.
The signal arrives 12–36 hours before clinical signs, and treatment begins while the animal has not yet been removed from the group. The failure class “found during a routine walk when it was too late” is eliminated.
Feeding control by groups
The system calculates how much feed actually reaches each group and compares it with the ration.
The discrepancy is visible on the same day, not at the end of the month: overfeeding of one group and underfeeding of another are leveled out, and the share of uneaten leftovers on the feed table decreases.
Productivity forecast
Based on consumption and behavior, a forecast of milk yield or weight gain for the group is built 7–14 days ahead. The livestock specialist sees the deviation before it turns into a drop in total output and has time to adjust the ration.
Workload on livestock handlers
Walking the entire herd is replaced by a targeted list: 10–15 tasks arrive per shift instead of inspecting all animals one after another. Time goes to those who actually need help, not to visual control for its own sake.
Deployment options: cloud, local loop, hybrid
The processing placement scheme is chosen not by the model but by the site: communication channel bandwidth on the farm, power stability, the required archive retention depth, and who sees the alarm first.
Where there is a single mobile channel, uploading the entire video stream to the cloud causes frame loss at every interruption — some events never reach processing at all.
The opposite case is distributed sites without an on-duty specialist: there is no one to maintain the local node, and it is more reliable to compute in the cloud, leaving only a few hours of recording buffer on site.
Between these extremes fits a hybrid scheme: critical events are processed on site, and the archive is uploaded during low-load hours.
| Scheme | When it fits | Limitations |
|---|---|---|
| Cloud processing | Many sites, predictable channel, no in-house engineer on site | Depends on connectivity: frames are lost during an interruption; upload grows with the number of cameras |
| Local loop | Weak or expensive channel, strict privacy requirements, response needed within seconds | Requires a node with thermal and power headroom, a maintenance procedure, and spare equipment |
| Hybrid scheme | Sites with different connection quality, long-term archive | Two support environments, model versions on site and in the cloud must match, archive reconciliation is required |
At the start we calculate three values: the share of frames that cannot be lost, the required archive depth, and the acceptable event response time. These numbers determine where to place processing — the rest follows.
Implementation stages: from farm survey to operation
Implementing AI monitoring of livestock farming is a sequence of engineering works, not camera installation. The order is fixed: understand the site, design the coverage, train the model on local data, and only then put the system into operation.
- Farm survey. We walk the barns at different times of day: record lighting and backlight from gates, elevation changes, areas of dense animal concentration, power and communication points, herd and staff routes. The result is a map of site constraints that cannot be bypassed by installation.
- Camera placement plan. We calculate angles and overlaps, mounting height, tilt, and distance to the movement line. The animal must fit fully in frame at the entrance and exit of the milking parlor, and frames from adjacent cameras must join without “blind” segments.
- Model tuning for the breed. We label frames with local body type, coat color, and spot pattern, and fine-tune the model on a local sample. Separately, we select sensitivity thresholds so that group behavior does not cause a spike in false alerts.
- Processing loop assembly. Computation runs on site — shorter response and less traffic. Events are written with timestamps, buffered during a communication outage, and sent to the log after recovery, so there are no gaps in the history.
- Testing on the real stream. For several weeks the system runs in parallel with manual observation: we compare alerts, analyze discrepancies, and adjust thresholds and zones of interest. Calving, fights, and lameness are also worked through here.
- Procedure and staff training. We agree on what to do when an alert occurs, who receives the notification, and how to mark false events so they go into retraining.
- Handover to operation. We hand over accesses, diagrams, configurations, the model change log, and its update plan for changes in herd or barn layout.
Handover package: models, diagrams, procedures, and accesses
After launch, the customer retains not only a working loop but also a package by which the system lives and evolves without us.
We hand it over to the customer’s private repository and as printed appendices for the operations service — so that when an engineer changes, the logic does not have to be reconstructed from memory.
- System passport — purpose, scope of applicability, module composition, list of connected cameras and sensors, integration points with the farm’s record-keeping systems.
- Placement diagrams — binding of cameras and sensors to sections, feeding and milking zones, viewing angles and overlaps, areas where animal behavior is visible reliably and where the model operates with a caveat.
- System documentation — description of data flows, export formats, thresholds, and settings; instructions for typical operations: add a camera, mark a zone, restart a node.
- Response procedure — which events are considered significant, with what delay they go to the responsible person, who closes the alert and within what time, and what goes into the log.
- Data access rights — role matrix: who has access to raw recordings, who only to aggregates, who exports data, retention periods, and anonymization rules when transferring to third parties.
- Model card — what data they were trained on, metrics on a holdout sample, known limitations, and classes of situations where operator confirmation is required.
- Update procedure — how quality degradation is tracked, who decides on retraining, and how rollback to the previous version is performed.
Case study: dairy complex, monitoring metrics before and after
What the site had before implementation
The complex already had milking parlors and herd records in DairyComp, but the data lived separately: milk yields in the parlor controllers, activity in collars, veterinary treatments in a paper log.
The operator learned about a problem after the fact: the cow was already refusing feed, the calf had stopped drinking.
Quarterly measurements gave this picture: young stock mortality held at 8–9%, less than half of behavioral deviations were detected on the first day, and the average delay before examination was two to three days.
What was changed
We brought the streams into a single storage and trained models on two years of history: for each head, an individual norm of milk yield, activity, feed and water intake is calculated, and a signal is raised only when there is a sustained excursion outside the corridor.
The veterinarian receives not a stream of alarms but a priority list indicating exactly what deviated and how long ago — the examination has time to happen before the condition turns into loss.
Metrics before and after
| Indicator | Before launch | After launch |
|---|---|---|
| Young stock mortality | 8–9% | 3–4% |
| Deviations found on the first day | less than half | about 90% |
| Delay before examination | 2–3 days | several hours |
The effect on herd records is visible separately: discrepancies between the log and the actual number of head decreased because the system daily reconciles animal movements with records instead of relying on manual reconciliation at the end of the month.
What to do if cameras and sensors are already installed on the farm?
We start with an inventory, not a purchase: angles, coverage zones, stream quality, archive depth. Cameras that are already installed are usually suitable — the question is whether feeding zones, alleys, and lying areas are in frame.
The result is a coverage map: where existing equipment is enough, where an angle adjustment is needed, and where we add a point.
We do not build a second record-keeping system: the module pulls the animal and group directory from your system. If records are kept in Afimilk or a similar platform, video events are mapped to the same identifiers — tag, number, group.
Exchange is via exports or through a software interface, and discrepancies go into the log and are resolved manually.
History is not lost: we run the archive in batches, and the model returns a retrospective of behavior for past periods — charts do not start from zero on the launch day.
Frames where the animal cannot be recognized confidently are marked as missing data; otherwise a poor recording would turn into a false “zero activity.”
We carry out replacement in stages, by zone, in windows between feedings and milkings. The new loop initially runs in parallel: it reads the same streams and switches nothing until accuracy is confirmed on your animals and lighting. Rollback means returning the stream to the previous recorder.
We check stream compatibility before installation: cameras output video via open standards, analytics connects as an additional consumer and does not take the stream away from the recorder.
We calculate network load and retention depth in advance so that expansion does not break the working archive.
Technical concerns: connectivity, data quality, staff
Concerns on such projects rarely relate to the model itself — they relate to operation: connectivity in remote barns, light in the stall, people’s response to an alarm. Below are four questions that the customer’s engineers ask first, and how we address them on site.
What happens if communication with the site is lost?
Processing does not stop: frames are buffered on a local node next to the cameras, analytics runs there too, and when the channel appears, events go into a queue and are sent without loss. The interruption is visible in the interface as a status, but the chronology is not broken.
Will image quality be sufficient at night and in backlight?
We select cameras for the actual lighting: infrared illumination, operation at dusk, separate exposure adjustment for zones where light from alleys falls. If the scene is objectively unreadable, we will say so during the pre-start measurement, not after.
How are false alerts filtered out?
The scheme is two-stage: the detector identifies the object and class, and the second step checks trajectory and time — whether the animal is standing, lying, or moving.
We calibrate the confidence threshold on recordings from the specific barn, so sensitivity is tuned to your herd rather than left at the factory setting.
Will staff actually use it?
Training takes two or three short sessions: working with the interface, reviewing disputed alerts, and the procedure for responding to an alarm.
The instruction remains on site, and for the first weeks we analyze mistakes using operators’ recordings — this is how settings are brought to a working mode.
How does the system behave in winter?
Domes are installed with heating, mounts are outside icing zones, and the maintenance procedure includes cleaning the optics. We review thresholds based on winter recordings: frost and low sun change the picture more than it seems.
Let’s discuss the task: what we need from you to start work
So that the timeline estimate is based on facts rather than assumptions, we need a set of initial data about the site. Below is what we request in the first conversation: you already know some of it, and we will clarify the rest together.
- List of sites and barns: livestock population, sections, how they are connected — this determines the data collection scheme and the number of control points.
- What is already installed: cameras, sensors, weighing and milking equipment, animal identification means — models, angles, coverage zones.
- How events are recorded now: walk logs, spreadsheets, paper records — what should go into the system and what remains manual.
- What decisions the system should support and in what priority: activity and feeding control, records, early detection of deviations, reporting.
- Who uses the result and from which device: operator in the barn, livestock specialist, manager — this determines the output and notification format.
- Site constraints: network and power, room for equipment, sanitary procedure, and staff access rules.
- Acceptance criteria: what we consider the result — completeness of event recording, signal delay, share of correctly recognized animals.
With this set, we return with a timeline estimate, solution design, and work plan. We discuss the launch order separately: first we deploy the loop at one site, compare indicators with expectations, then transfer it to the others. Describe the task — we will clarify what is missing and fix the stages.
