A GPS Logger on a Breeding Bird Is a Liability Until It's Back in Your Hand
Every tracking device deployed on a seabird exists in two states: on the bird, and recovered. The period between those two events is when things go wrong — batteries die mid-deployment, birds disappear, weights shift and devices detach prematurely, or a scheduled recovery visit turns up an empty nest site with no sign of the bird or the hardware. For hoiho and little penguin research along the New Zealand coast, where tracking devices represent months of grant-funded budget and irreplaceable foraging-at-sea data, losing sight of which devices are out and where they went is not a data management problem. It's a research program problem.
The Deployments template in the New Zealand Penguin Initiative's Memento stack was built to close that gap. Every deployment event is a record. Every recovery event updates that same record. Nothing goes unlogged.
What a Deployment Record Actually Holds
The structure is deliberately bilateral. The deployment side of each record captures species, DateTime (when the device went on), Site, GPS Location, Tagger identity, and then the two relational links that matter most: Nest ID and Bird ID. These are not typed fields — they're entries links connected directly to the companion nest library and bird ID database. That means when you pull a deployment record for Bird ID 4471-R, you're looking at the same individual whose bill morphometrics, sex determination, and full resighting history sit in the bird ID library. The deployment record doesn't exist in isolation; it inherits context from the rest of the database.
Device ID captures the hardware serial or label. Device start-time is a separate datetime field from the deployment timestamp — critical for biologgers and GPS units where the internal clock is offset from deploy time and you need the precise device-start epoch to align your downloaded data streams with the actual behavioral record. Weight at deployment is logged in grams, both to document the bird's pre-deployment body condition and to calculate the device-to-body-mass ratio, which for small penguins is a welfare and data-quality threshold that cannot be eyeballed.
The recovery side mirrors the deployment side with its own DateTime (R), Location (R), Weight (R), and a Recovered by field identifying which team member pulled the device. That personnel field is not a formality. When a device comes back with corrupt data or unusual wear patterns, knowing who handled the recovery and from which exact GPS location gives you the first investigative thread to pull.
When the Recovery Visit Goes Sideways
Breeding season, mid-January. You have fourteen active deployments across three sites. You arrive at site C to recover device DEP-0047 from a yellow-eyed penguin that should be guarding chicks at nest B-22. The nest is empty. The bird isn't there. No device on the ground. You pull the deployment record on your phone: last weight 3,140g at deployment, device start-time logged correctly, no recovery entry — which means the device is still counted as out in the field.
You cross-reference the bird ID record: last resighting was three weeks ago, status "Guarding chicks." You check the nest monitoring log for B-22: last visit shows one adult, one chick, eggs confirmed absent — consistent with the resighting. Nothing flags an uplifting event. The bird didn't get recovered to a rehabilitation center.
At that point you know the deployment record carries a gap that needs a Notes (R) entry, not a weight or coordinates. The structured distinction between a successful recovery and an unresolved disappearance is exactly why the template separates deployment and recovery into the same record rather than two independent entries. The absence of recovery data is itself a data point — and it stays attached to the device and the bird, permanently.