Necessity/Proportionality Checklist¶
Screening checklist — instantiates Access-Conditioned Bundle Decoupling
For each condition attached to access, forces a documented answer to whether it is truly necessary and whether a narrower or separable alternative would do — with a higher bar when the access is essential.
When a package couples the thing someone needs to a condition they might not want, the whole package tends to be defended as a unit: "it all has to be there." The Necessity/Proportionality Checklist refuses that framing. It takes the conditions one at a time and asks of each: is this genuinely required for the desired access to work, or is it an opportunistic add-on riding along on the access handle? Its defining move is the per-condition standard — an add-on may stay only if the controller can show it is necessary, that the desired item cannot reasonably be delivered without it, and that no narrower or separable version would suffice. It is a screen applied before a condition is allowed to ride along, not a review of the deal as a whole.
Example¶
A ride-hailing app requires the user to grant access to their phone contacts before it will let them book a trip. A product-and-privacy review runs the checklist against that single condition. Is contacts-access necessary to deliver the ride? No — dispatch, routing, and payment all work without it. Can the ride be delivered without it? Plainly yes; it already is for users who decline on other platforms. Is there a narrower alternative? Yes — an optional "invite a friend" import, offered separately and consented to on its own. And because point-to-point transport is close to essential for some riders, the heightened-scrutiny trigger fires, raising the bar the condition must clear.
The outcome is not "ban contact-sharing" but a decoupling: booking proceeds with no contacts permission, and the referral import becomes an opt-in feature standing on its own. The checklist has converted a flat "you must allow contacts" into a documented finding that the condition failed necessity and had a less-restrictive alternative.
How it works¶
- One condition at a time. Each coupled condition is tested on its own, so a legitimate requirement can't be used as cover to smuggle an unrelated one through.
- The three questions. Necessary for the desired access? Deliverable without it? And is there a narrower or separable form that achieves the legitimate aim with less imposition (the least-restrictive-means test)?
- Essentiality escalation. When the access approaches essential — utilities, employment, healthcare, a dominant platform — the trigger raises the bar: the more the affected party depends on the access, the stronger the justification a condition must carry.
- Written finding. Each condition ends the pass marked keep, narrow, or drop, with the reasoning recorded so the decision can be challenged rather than merely asserted.
Tuning parameters¶
- Necessity bar height — whether "necessary" means required for safe, lawful delivery or merely convenient for the controller. Raising it strips more add-ons but can also catch borderline-legitimate safeguards.
- Essentiality escalation slope — how sharply the bar rises as the access becomes more essential. A steep slope protects dependent parties but slows routine, low-stakes bundling.
- Evidence demanded — whether a bare assertion of necessity passes or documented evidence and a less-restrictive-means analysis are required. More evidence resists rationalization but costs effort.
- Alternative scope — whether an acceptable narrower alternative must be one the controller itself offers, or may be an external substitute the affected party could reach.
- Sign-off independence — self-certification by the controller versus review by an independent party. Independence blunts rubber-stamping at the cost of speed.
When it helps, and when it misleads¶
Its strength is that it dissolves the "it's all required" defense into a set of separately defensible claims, exposing the opportunistic add-on that was hiding behind a genuine one — and it scales its own strictness to how much the affected party depends on the access.
Its classic failure is being run backwards: the conditions are chosen first and the checklist is filled in afterward to ratify them, so the justifications become theater. Necessity is also elastic — a motivated controller can define the "purpose" broadly enough that almost any condition looks necessary to it. The discipline that keeps it honest is holding to least-restrictive means rather than mere relevance,[n1] and routing contested items to an independent reviewer rather than letting the party that wants the condition also grade its necessity.
How it implements the components¶
The checklist realizes the testing side of the archetype — the gate that decides which conditions may stay attached, not the machinery that inventories, severs, or replaces them:
necessity_and_proportionality_test— its core: the per-condition necessity, deliverability, and least-restrictive-means questions, ending in a keep / narrow / drop finding.essential_access_heightened_scrutiny_trigger— the escalation rule that stiffens the test as the access approaches essential, so dependency raises the justification a condition must carry.
It does not compile the raw list of conditions (an Access-Condition Inventory Workshop / Rebundling Drift Audit does), provide the remedy when a condition is contested (Severability Clause and Review Rule), or stand up the unconditioned alternative it recommends (Standalone Base-Service Path).
Related¶
- Instantiates: Access-Conditioned Bundle Decoupling — the checklist supplies the necessity finding the rest of the decoupling hangs on.
- Consumes: an inventory of the coupled conditions to be tested (from an Access-Condition Inventory Workshop).
- Sibling mechanisms: Severability Clause and Review Rule · Take-It-or-Leave-It Term Audit · Purpose-Bound Security Condition Record · Standalone Base-Service Path · Rebundling Drift Audit · Bundle/Unbundle Menu · Coercion Safeguard Review
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The checklist evaluates each access condition against necessity, separability, and least-restrictive-means evidence and produces a documented legitimacy finding.
Nearest alternative: Decision, Gate & Allocation — The finding can permit or reject a condition, but that gate is the result of criteria-based review.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The checklist directly operationalizes legal proportionality doctrine: legitimate aim, necessity, least-restrictive means, and a burden calibrated to the right or access at stake.
Related originating lineages:
- Philosophy — Normative ethics contributes the underlying least-restrictive-means and proportional-burden reasoning.
Review resolution: Both independent reviews agree on primary origin law_governance; reconciliation resolves alternate_origin_disagreement, encyclopedia_synthesis_disagreement. Formative alternate lineages retained: philosophy. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=single_lineage describes the historical relationship among lineages. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=true preserves the reviewers' boundary judgment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The checklist decides whether a condition may stay, not how to remove it or whether anyone will collect the reasons it stays. A condition that passes on security grounds still needs a durable record — that is Purpose-Bound Security Condition Record; a condition that fails but is contested still needs a clean way out — that is the Severability Clause and Review Rule. Keeping the test separate from the remedy is what lets a controller tighten the standard without renegotiating every contract at once.
[n1] In the proportionality doctrine of many legal systems — including EU law and human-rights jurisprudence — a measure that restricts a right is permissible only if it is necessary and uses the least restrictive means to achieve a legitimate aim. The checklist borrows that necessary-and-least-restrictive standard; it is why "is there a narrower alternative?" is a load-bearing question rather than an afterthought. ↩