Resolution

Two halves, a court between them, and a record that is written first

The operator holds observations and no keys. The custodian holds keys and no observations. Neither one can answer the question alone, and that is the only version of this guarantee that does not depend on everyone behaving well.

Footage: José Lizardo / Pexels

The ballot analogy is close and it breaks at one specific point. A ballot can be perfectly anonymous because nobody ever needs to act on an individual ballot. This system must be able to send an officer to a particular person at a particular place. There must therefore be some path from an identifier to an identity - which means the honest design is not "no database" but no standing database, and a controlled, logged, judicially authorized resolution path.

Everything on this page is part of a design document. It describes a path that has not been built, and it is written to be argued with by people who would have to authorize it, run it, or be subject to it.

The authorization boundary

Everything left of the dashed line happens on the anchor in real time, with no server contact and no identity: the alarm can fire and a guardian can be notified while the system still does not know who was detected. Crossing the line - learning which person an identifier belongs to - requires both a judicial order and the independent key custodian, and unconditionally writes an audit record. Neither half can resolve an identity alone.

Notice what is on the left-hand side and what is not. Detection is local and anonymous; attribution is authorized and logged. That sentence is the whole architecture, and it is the honest version of the ambition that started this project - that the system should not let anyone zero in on a particular individual.

Split custody

Splitting custody is what makes the guarantee structural rather than a policy promise. It is the same argument the isolation page makes about trust domains, applied to the one join that would undo all of them: an insider at either organization, acting alone, cannot produce an identity, because neither organization holds the other half of the answer.

The operator holds observations without keys

Zone events, times, dwell durations, tier states, dispatch queues.
Every one of them keyed by a rotating identifier that changes several times an hour.
No enrollment key, no roster, no route to either. There is no query the operator can write, no report it can run, and no configuration change it can make that turns an identifier into a person.
A full breach of the operator yields a pseudonymous movement corpus and no names.

The custodian holds keys without observations

The deposited public halves of every device enrollment key, and the roster binding them to people.
No observation feed of any kind - not filtered, not aggregated, not for debugging.
It answers a single, signed, single-use order and initiates nothing. It cannot ask the operator anything, and it has nowhere to ask.
A full breach of the custodian yields a list of who is enrolled, which for a supervised population is largely a public registry fact, and nothing about where anyone has been.

A court authorizes joining them. That is the only join, it happens one subject at a time, and it leaves a record whether or not anybody wanted one.

The custodian does not trust the operator's assertion that an order exists. It verifies the court's signature itself, against a key it holds in its own hardware module, in its own building, under its own administration.

What a resolution actually looks like

An escalation reaches tier 3. Below that, no petition may be filed. The tiers are the volume control on this whole mechanism: a design that resolves identity on every proximity event has no resolution policy, it has a lookup service.
A named officer files a petition for one identifier, one interval, one case, signed under their own credential, stating the facts relied on. The petition itself is written to the audit chain when it is filed, not when it succeeds - refused petitions are part of the record and are frequently the more interesting half of it.
A judge issues or refuses an order. The order is single-use, bound to a nonce, and expires. An order without those three properties is a reusable credential wearing the word "order".
The custodian verifies the signature itself and resolves exactly what the order names. It does not accept a range, a bulk list, or a standing instruction, because none of those can be reviewed by the judge who signed them.
The audit record is written before the answer is returned. A resolution that cannot be logged does not happen. This ordering is the difference between an audit trail and a courtesy.
The identity goes to the named requester and to nobody else - not into the console's database, not into a case management field, not into an email. The system's standing state after a resolution is unchanged; the knowledge lives with the person the court authorized to have it, which is what a warrant has always meant.

The exigency exception

A narrow exception is unavoidable and pretending otherwise would be dishonest: a child is missing, and seconds matter. But an exception is where architectures go to die, so it has to be specified as tightly as the rule it interrupts. Four elements, all of them required together.

A named class of circumstances. Not "an emergency". A closed list, written into the statute and not into the operator's runbook: a report of an abduction in progress; a missing child under a stated age with a tier-3 or tier-4 encounter in the preceding interval; a credible threat to life. If a circumstance is not on the list, the ordinary path applies however urgent it feels - and the list is amended by the legislature, in public, not by an operations team at speed.
A defined official who may invoke it. One role, identified by name and rank in the authorizing instrument, personally accountable, whose credential is what the custodian checks. Not "a supervisor". Not a shift duty holder. Not a service account. The point of naming a person is that a person can be asked afterwards why they did it, and can be removed.
Automatic notification to the reviewing court within 24 hours. Automatic - not on request, not on the official remembering, not conditional on the resolution having produced anything. The clock starts at invocation and the notification fires whether or not the case is still open. The court can then do what courts do with warrantless action reviewed after the fact: approve it, or not, and the second outcome has to have consequences that exist in the statute.
The same audit record. Byte for byte the same fields as a court-ordered resolution, in the same chain, distinguished only by the authority field. An exigency path that writes a different, thinner record is an exigency path designed to be used.

An exigency path with no time limit and no review is the whole architecture defeated by its own exception.

It is worth being blunt about how this fails in practice. Nobody removes the court. What happens is that the exigency path is fast and the ordinary path is slow, the exception is invoked because a case is urgent and everything feels urgent, the 24-hour notification becomes a form that nobody reads, and within two years the ordinary path is the exception. The countermeasure is not exhortation: it is publishing the ratio of exigent to ordered resolutions every quarter, next to the count of exigency invocations the reviewing court subsequently declined to approve. If that ratio is not published, assume it is bad.

The same warning applies to review generally. An audit record that nobody reads is not oversight; it is storage. In one state audit of electronic monitoring, 80% of alerts were never checked by officers in a Tennessee audit.Karsten & West, Brookings (2017) A resolution log reviewed at that rate would be a compliance artefact, not a control - which is why this design puts the store with an oversight body that has a statutory duty to read it and to publish what it found.

The limits, not softened

Everything above describes what the design protects. What follows is what it does not, stated in the same voice - because these limits are structural, they cannot be engineered away inside this architecture, and a document that lists the protections without them is marketing.

The enrollment set reveals how many devices are enrolled

Anchors must hold the set of identifiers valid for the current interval in order to match locally and offline. The size of that set is therefore observable to anyone who obtains it - and it is distributed to every anchor in the deployment, including anchors sitting in public buildings that can be physically reached. The count of enrolled devices in a jurisdiction is not a secret this design can keep. It can be argued that the count is not sensitive; it should not be argued that the count is hidden.

An observer with eyes defeats the cryptography

An anchor operator who observes a person and simultaneously captures their identifier has bound that identifier to that human by direct observation. This is the "paparazzi" attack from the DP-3T analysis [28] and no cryptography prevents it: the scheme protects an identifier from being linked to a name in a database, and it has nothing at all to say about somebody standing in a doorway with a radio and a pair of eyes. Once that binding is made, every subsequent appearance of that identifier - until it rotates, and by extension across an interval - is attributable to that person by the observer who made it.

This is not a marginal concern in this system, because the adversary the design most needs to worry about is precisely an adversary who can physically observe the person whose identifier they captured. It is the reason the legal architecture forbids public identity disclosure from an alert, and the reason an audible alarm is heavily gated: a loud alarm de-anonymizes instantly, because everybody in earshot looks around and the person walking away is the answer.

Publishing a long-window key links everything derived from it

Identifiers are derived from a daily key, and the daily key is what makes them unlinkable to an observer who does not have it. Publish any long-window key and every identifier derived from it links retroactively into a single trail. That is not a bug in the derivation; it is the derivation working as designed, and it means the disclosure rules around key material are as load-bearing as the cryptography. A resolution that hands over a daily key rather than an answer converts a warrant for one moment into a warrant for that whole window, and the design must therefore return an identity, never a key.

This is a pseudonymous system with a trusted matching party, not an anonymous one.

Say so in plain language rather than borrowing privacy vocabulary the architecture does not support. Calling this system anonymous would be a failure of the document, not a marketing choice - it would set an expectation the design cannot meet, and every reviewer who found the paparazzi attack on their own would be right to distrust everything else on the site. The correct claim is narrower and still worth making: there is no standing database that binds identity to location; the join requires two organizations and a court; and every time it happens, it is written down before it is answered.

What this leaves open

Who is the custodian, in law? Naming an independent body is easy in a design document and hard in a statute. It needs its own funding line, or it will be funded by the operator and independent on paper.
What happens to a refused petition? The record says it was refused. Whether the officer who filed it may file again on the same facts is a policy question this design does not answer, and the answer determines whether refusal means anything.
How is a wrongly resolved person told? A person whose identity was resolved on an alert that turned out to be sensor drift has a strong claim to be told it happened. Notification of the subject after the fact is standard in some warrant regimes and absent in others, and it should be decided in the statute rather than discovered in litigation.
What is the retention period for the audit chain? It has to outlive the program to be reviewable, and it is the one dataset that binds names to places. Those two facts pull in opposite directions and the tension is real.

How this works

1:07 · 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	Set membership is local and real time. Identity is remote, authorized and logged. That single sentence is the architecture this page describes.
0:12	Two halves	The operator holds observations and no keys. The custodian holds keys and no observations. Neither one can answer the question alone.
0:22	The join	A court authorizes the join, one subject at a time. The custodian verifies the signature itself, and the audit record is written before the answer is returned.
0:32	The exception	A narrow exigency path is unavoidable. It needs a named class of circumstances, a named official, automatic notice to the court, and the very same record.
0:42	The honest limit	This is pseudonymous, not anonymous. Anyone who watches a person while capturing their identifier has bound the two by eye, and no cryptography prevents that.
0:53	What to claim	So claim the narrower thing. No standing database binds identity to location, the join takes two organizations and a court, and it is written down every time.