Safe PerimeterBorn Between 2 Generals

Specification · Draft 1.0

A perimeter that answers in tiers,
not a siren that goes off at fifty feet.

A design document for a two-sided child proximity alert — the child-side device, the wearable form factor, and the tokenised matching layer. It is written to survive a hostile reading, so it leads with the parts that break.

What this is

This is a specification, not a product and not a pitch. It takes a concept — a child wears a band, a monitored adult carries a tracker, and the two notice each other — and works out what it would actually take to build, what the law would allow, and what it would and would not accomplish.

The core idea is sound, and a good deal of it already exists in statute. The work that remains is not the tracking. It is everything around the tracking: who is enrolled and by what process, what happens in the seconds after a threshold is crossed, who learns what, and how someone gets out.

The honest frame

Continuous GPS monitoring of people convicted of sex offences, with geofenced exclusion zones around schools and parks, is already law in a number of states. The tracking half of this concept is largely built. Three things here are genuinely new, and the document leads with those rather than re-pitching a solved problem.

The three new contributions

The child-side device

Existing law geofences the monitored adult. It draws a fixed boundary around a school and waits for someone to cross it. A device carried by the child makes the boundary move with the child — which is the only way to cover the shops, car parks, buses and streets where a child spends most of a day and no exclusion zone is drawn.

The wearable form factor

An ankle box is a court order. A band a child will actually keep on is a different engineering problem: weight, charge interval, water, the school’s policy on wearables, and a design that does not mark the wearer out to other children.

The tokenised matching layer

Two devices establishing that they are near each other without either one learning who the other is, and without a server learning where either of them was. This is achievable. It is also narrower protection than it sounds, for reasons on the threat model page.

Read these first

Four findings that change the design

Each of these was found by taking the concept seriously enough to try to break it. Three of them would have ended the programme in its first year.

Finding 1

Retroactive imposition is where this gets struck down

Courts have tolerated retroactive registration. They keep drawing the line at retroactive monitoring and geographic restriction. In 2016 the Sixth Circuit held Michigan’s retroactive registry amendments punitive, and so an ex post facto violation. In 2017 Pennsylvania’s Supreme Court reached the same conclusion about its own registration statute.

The version that survives is imposed prospectively at sentencing as part of the sentence, with an individualised-hearing path for existing registrants rather than a blanket sweep. Slower. It is the difference between a programme and a lawsuit.

The legal architecture, and a scorer for your own design →

Finding 2

The alarm identifies the person the tokens were protecting

A loud public alert is instantly de-anonymising. Everyone looks up, and the person walking away is the answer. Tokenisation prevents database browsing; it does nothing against situational identification, and people on registries have been murdered using registry data.

The privacy layer is real, but it covers a different threat from the one the alarm creates. The threat model carries a calculator that puts a number on it.

What the privacy layer actually covers →

Finding 3

Auto-dialling 911 on every ping ends the programme in month one

Fifty feet in a grocery store, on a transit platform, or in a shopping centre means constant triggers on people doing nothing wrong. Dispatchers desensitise quickly, and then the real alerts get ignored — which is worse than not having built it.

The answer is a graduated ladder: log silently, notify the guardian, and escalate to police only on sustained dwell, repeat contact, or an actual restricted zone. The audible alert belongs to the escalated tier alone.

The ladder, and the load model that shows why →

Finding 4

This closes a specific gap. It does not solve child abuse

34.2% of victims under 18 in sexual assaults reported to law enforcement were assaulted by a family member. 58.7% were assaulted by an acquaintance. Only 7.0% were assaulted by a stranger.

And 95.9% of sexual offence arrests over a 21-year period in New York were by people with no prior sex offence conviction. — so they are not in any system to be monitored. A proximity alert covers the known-monitored, physically-proximate slice. That slice is real and worth covering. If the pitch implies more, the first informed reader takes the whole thing apart.

The coverage model, with your own assumptions →

Snyder, BJS NCJ 182990 (2000)
This is the share of cases REPORTED TO LAW ENFORCEMENT, which is not the same as the share of cases that occur.

Sandler, Freeman & Socia, Does a Watched Pot Boil?, Psychology, Public Policy, and Law 14(4):284–302 (2008)
One state, one period. It is the most-cited figure of its kind, not a national constant.

The shape of the answer

Five tiers, and only one of them makes a noise

Nothing in this design dispatches on distance alone. Dwell time, repeat contact and legally designated zones are what separate an event from a coincidence.

Footage: generated (OpenAI Sora 2) — abstract, depicts nothing and no one

What is in this document

  • What is already law — the statutes and case law this would be built on top of, so nothing here re-pitches a solved problem.
  • Coverage — an explicit model of what share of harm this can touch, with every assumption exposed.
  • Threat model — assets, adversaries, and the de-anonymisation calculator.
  • Alert tiers — the response ladder as a running classifier, plus the dispatch load model.
  • Data flow — the token scheme, derived live in your browser.
  • Devices — tamper detection rather than tamper proofing, and the latency budget for it.
  • Legal architecture — the punitive-effect factors, as a scorer for a proposed design.
  • Due process — enrolment, appeal, audit, and the path off the programme.
  • Operations — charging, battery death, jamming, and false-alert handling.
  • The full specification — all of it in one printable document.
  • Check — every instrument on this site, run against its test vectors in your own browser.

On the instruments

Seven of the pages carry a working model rather than a diagram of one. They compute in your browser, make no network requests, and store nothing. Where a model rests on an assumption, the assumption is a control you can move. The check page runs them all against their vector tables so you can see them agree with what the pages claim.

What this document is for

To make the concept survive contact with a hostile reader — a defence lawyer, a civil-liberties litigator, a sceptical sheriff, a procurement officer — before a dollar is spent building it.