An operating system for the place. And one animal to show it holds together.

The thread: one number, everything on it

Every animal has an NLIS number, and in LPOS that number is the key. The yard scan, the weight, the pen it stands in, the treatment it got, the line on the kill sheet — all of it hangs on the same record, because all of it came in carrying the same EID.

• One number per animal per place. The database will not hold two animals with the same NLIS number on the same feedlot.
• A new tag does not start a new animal. When a tag is lost and replaced, the change is recorded — old number, until when, in which yard session. The history runs straight through the re-tag instead of breaking in two.
• The kill sheet finds its own animals. The works reports by NLIS number, and that is how every carcase is matched back to the beast it came from.

One animal, from purchase to kill sheet

This is what the thread holds. One page per head, filled in by the work — nobody keeps it.

• Where it came from. The purchase price and the vendor sit on the animal. The purchase register holds the rest — the NVD, the vendor’s PIC, the sale, the lot.
• How it grew. Every weighing, the gain per day, the days on feed, and the date it came onto feed.
• Where it stood and what it ate. Every pen it was placed in, from when to when, on which ration and why it moved. Below that, day by day: the pen, the ration, its share of the feed in kilos, and what that feed cost.
• What it was given. Every treatment with the product, the batch, the dose and the date — and the day its withholding runs out, in green, amber or red. While that date is ahead, the animal cannot be put on a truck: the dispatch is refused.
• When it left, and what it was worth. The day it shipped or died. Then the works: kill date, body number, carcase weight, dressing percentage against the weight you last took, MSA index, P8 fat, pH, dentition, price per kilo, the grid and the deductions, and what the carcase came to.
• Who it was bought for. The buyer, and the target weight and days on feed they asked for, next to the ones the animal actually has.

Every number here was written by a job, not by a clerk. The weight came from the crush, the ration from the feeding plan, the carcase from the kill sheet. LPOS only puts them in one place, under one number.

Notes that stay where they belong

What a person notices does not go into a notebook in the ute. It goes onto the thing it is about. “1234 is lame, give it another shot of Draxxin on Monday” is one note, linked to the animal, the pen and the product at once — and it turns up on all three.

• Linked to what it is about. A note can point at any number of pens, animals, mobs, machines and treatment products. The links are checked by the database, so a note never points at something that is not there.
• A date, if it needs one. With a due date it is a job and turns up on the day. Without one it is information and stays with the object.
• It closes itself when it is overtaken. Once every animal or pen a note points at has gone, the note is marked as overtaken, with the reason written on it. Nobody has to clean up after cattle that have left.
• Written where the work is. From the phone in the yards, with no signal — it waits on the device and goes up when there is a bar.

How the data gets in, without typing

A record like that is only worth having if nobody has to type it. So LPOS reads what your place already produces. Whatever your scale head, your crush software or the works sends you, it comes in the same way: the share sheet on the phone.

The NVD is the one document a model reads, because it is the one with handwriting on it. It comes back with the serial, the vendor and their PIC, the head count, the dates and the declaration questions, and flags by name the fields it was unsure of. You correct what needs correcting and record the lot. Weights come across as a file after the crush run, not live from the scale.

Nothing is written until you say so. Every file opens as a preview first. The kill sheet goes furthest: the preview is the real run — every animal exited, every result written, the consignment costed — and then rolled back. What you see is what will happen, not an estimate of it. A kill sheet that was already applied cannot be applied twice.

Feeding: the work that writes what they ate

One loop from the bunk at first light to the last pen fed. Each step hands the next one its numbers, and at the end of it every pen — and so every animal in it — has its kilos, its ration and its cost for the day.

• Every change keeps its reason. When someone overrides what a pen gets, LPOS stores what was recommended, what was chosen and why, with the name and the time. Those entries cannot be edited afterwards — the database refuses, not just the screen.
• It brings them up slowly, so they keep gaining. A pen that cleans up its bunk tempts you to give it a lot more tomorrow. Push too hard and they go off feed and sit on a plateau — days of gain lost. The steady climb is what pays, but doing it by hand means working out every pen again every day, so people end up taking bigger jumps. LPOS does that sum for you. It reads the bunk over the last few days, steps a pen up only once the pattern says it is ready, and otherwise holds it where it is so it can settle.
• It has a guard against overfeeding. Built on the pen’s own records, it will not let a pen be pushed faster than it can take — and when a pen moves onto a new ration, it takes it across in steps instead of all at once. Every recommendation says why on the same line.

Where it runs

Same data, three screens, cut to who is holding the phone. The office has the whole place. The phone in the cab has the day’s work and runs without signal. The laptop at the crush has the sessions, the kill sheets and the NVDs.

• Nine roles, each a set of permissions. A feeder gets the run, the plan and the troughs; the drafting is not theirs to see. The server checks on every request, and again when an offline entry syncs.
• No signal is the normal case. Bunk checks, mix steps, deliveries, notes, hours — they queue on the phone and go up when there is a bar. The aerial map of your place is stored on the device too. A signed-in phone works up to three days without a connection; the queue is never lost.
• A shared handset needs no password. The office pairs a phone once with a six-digit code, and can revoke it with a tap. A terminal tied to a mixer only sees that mixer’s work.