The Question to Ask Before Anything
One question that resolves most disagreements in this field, and what to do with each answer.
Most arguments about location tracking are arguments about purposes that were never stated. One question surfaces them.
The question
What decision would this data inform, and who makes it?
Ask it of every feature, every report, every request.
What the answers reveal
"It tells dispatch which van is nearest." A decision, made by a named role, needing current position only. Proceed.
"It proves we attended." A decision — whether to write off an invoice — needing two events per visit. Proceed, with geofences.
"It tells us if someone needs help." A decision needing position on alarm. Proceed, designed as a safety system.
"It shows how far the van went." A payment decision needing a number. Proceed, without routes.
"It shows us who's working hard." No decision that this data can inform, and the note on what it cannot tell you explains why. Stop.
"We'd know what people are doing." Ask what would be done differently. Usually nothing, which means the request is about reassurance rather than about a decision.
Why it works
It separates the operational from the anxious without anyone having to say which they are.
It is neutral. Nobody has to be accused of wanting surveillance; they simply cannot name the decision.
And where a decision does exist, it usually needs far less data than was proposed, which moves the conversation to design rather than to principle.
Using it in the impact assessment
The proportionality section asks exactly this in more formal language.
A feature that cannot name its decision cannot justify its collection, and writing that down is what makes an assessment real rather than decorative.
Using it when declining
"What would you do differently?" is a better opening than "we can't do that", because it is a genuine question and it frequently answers itself.
Where the answer is a real decision, help with it — usually with less data than was asked for.
Where it is not, the conversation has resolved itself without anyone defending a position.
The whole collection in one line
Collect the least data that informs the decision you can name, stop collecting when the decision does not exist, and say plainly which is which.
Everything else in these notes is the detail of doing that.
Apply it to features, not just requests
The question works at procurement as well as in an argument.
For every feature on the demonstration: what decision does this inform?
Driver league table: none that this data supports.
Live map for managers: dispatch already has one, and a manager's version informs nothing.
Geofence events: a billing dispute decision.
Run it down the feature list and the specification shortens considerably, which is the cheapest reduction available.
Turn the principle into a test
For an example that can make this requirement testable, consult see how the workflow works. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, failures and permissions.