Operations

Connection to server failed. Retrying.

Every monitoring program lives or dies in this room, on an ordinary Tuesday, when a third of the fleet is offline and somebody has to decide which of those outages means anything.

Footage: Kiwi and Camera / Pexels

The specification so far describes a system working. This page describes it not working, which is the condition it will spend most of its life in.

Device states an operator will actually see

State	What it looks like	What it means	Response
Healthy	Reporting, strap intact, fix good	Normal	None
Fix lost	Reporting, no position	Indoors, underground, urban canyon. Extremely common.	None automatically. The tier engine already refuses to alert on it.
Silent	No contact for > 15 min	Network gap, or a device off. Indistinguishable at first.	Automatic query. Escalate on duration, not on the fact.
Low power	Battery under threshold	Charge due, or a charging pattern being avoided	Subject notified; repeated instances are a supervision matter, not a device matter.
Power dead	Orderly shutdown, then nothing	Defined in the conditions as a violation	Written response per the order. Not an emergency call.
Strap breach	Continuity broken, device may still report	Removal. The one hardware event that is unambiguous.	Immediate, per the latency budget on the devices page.
Signal denial	All radios lost at once, in a place with prior coverage	Jamming, a shielded enclosure, or a dead antenna	Recorded as an event in its own right; investigated on pattern.
Late batch	A burst of buffered events arriving at once	Reconnection after an outage	Every event in the batch is labeled with its true age. Presenting buffered events as live is how a monitoring system produces a wrong arrest.

False alerts

There will be a lot of them, and how they are handled is the program's reputation.

Classify before you count. A false alert is not one thing: a bad fix, a legitimate encounter with an innocent explanation, a device fault, and a data error each need a different fix and each should be counted separately.
An overturned alert leaves the pattern count. Repeats feed the ladder. An uncorrected false positive permanently raises a subject's escalation risk, and the error compounds.
Publish the rate. Quarterly, broken down by classification. A program that will not publish its own false-positive rate has no standing to ask anyone to trust its true ones.
Watch for the desensitization curve. Track the time between an alert arriving and a human acting on it. When that number starts to rise, the ladder is mis-tuned - and rising response time is the leading indicator of the failure that gets programs canceled.

The unglamorous list

Charging

Named in the conditions with a specific window and a specific duration. "Keep it charged" is not an enforceable condition and will not survive a violation hearing. The child's band targets five to seven days precisely so charging never becomes the reason it is not worn.

Fleet health

A daily figure for devices reporting, devices silent over 24 hours, and strap events. Any program where this number is not on somebody's desk each morning is already failing and does not know it.

Firmware

Staged rollout, never fleet-wide at once, with the version recorded against every encounter so a defect can be scoped to the events it touched. A silent fleet update that changes classifier behavior is a change to the evidence.

Key list distribution

The daily pseudonymous key list has to reach every band. A band that has not fetched today's list is matching against yesterday's and is quietly less capable, so staleness is a monitored condition - not a silent degradation.

Lost and found bands

A found band carries no identity, so it cannot be returned by looking at it. Revocation must be immediate from the guardian side, and the pairing secret wiped on the next power cycle.

Handover between agencies

Subjects move. Enrollment, tier, term and audit history have to move with them, and the receiving jurisdiction has to be one where the order is enforceable. Where it is not, the program ends for that subject - and says so, rather than pretending to a coverage it no longer has.

The metric that actually predicts failure

Not uptime, not alert volume, not enrollment. Median time from alert to human action, tracked weekly. It captures dispatcher desensitization, understaffing, and a mis-tuned ladder in a single number, and it starts moving months before anything visible goes wrong.

All of it, in one document

The full specification collects every requirement on this site into a single printable page.

Footage: Tima Miroshnichenko / Pexels

How this works

0:59 · narrated · captioned · nothing here is sent anywhere when you press play. Prefer to read it? The transcript is below.

Transcript

At	Section	What it says
0:02	What it is	The specification so far describes the system working. This page describes it not working, which is the condition it will spend most of its life in.
0:11	The board	What an operator actually sees is a list of device states on an ordinary Tuesday. Reporting and healthy. Fix lost indoors. Silent. Low power. Strap broken.
0:23	Loss of signal	Loss of signal is ambiguous. A flat battery, a basement and a person walking away look the same at first. Duration escalates it, and the bare fact never does.
0:35	False alerts	There will be many. Classify them before counting them, and publish the rate. An overturned alert has to leave the pattern count, or the error compounds.
0:44	The metric	Median time from alert to human action is the number that predicts failure. It captures desensitisation, understaffing and a mis-tuned ladder, and it moves early.