Vote-to-Border Mechanics (Optional)
Some variants of Freeze–Vote–Rebuild include a “vote-to-border” component: a published method that maps vote outcomes to territorial or administrative lines.
In this GitBook, vote-to-border is treated as an optional module. If used, it must be designed to be:
- transparent (published rules),
- version-locked (no midstream changes),
- simulatable (public sandbox before the vote),
- auditable (inputs/outputs and edge cases are inspectable),
- resistant to manipulation (especially via strategic displacement or gerrymandering).
Why Include Vote-to-Border at All?
Potential Benefits:
- Reduces arbitrariness by committing to rules in advance.
- Narrows post-vote bargaining space (fewer “interpretation wars”).
- Makes tradeoffs visible before voting, not after.
Potential Risks:
- Creates strong incentives to manipulate turnout or eligibility.
- Hard edge cases (mixed areas, security constraints, minority protections).
- May be viewed as legitimizing outcomes that should be negotiated separately.
Core Design Requirements
1. Define the Mapping Unit
Specify the unit that maps votes to outcomes, e.g.:
- Municipality / district / precinct.
- Contiguous geographic cells (grid-based).
- Administrative units with defined boundaries.
Avoid ad hoc redrawing during or after the vote.
2. Define the Decision Rule
Examples (illustrative only):
- Simple majority by unit.
- Supermajority thresholds for boundary changes.
- Turnout-adjusted rules (high risk; can be gamed).
- Multi-option outcomes with runoff rules.
3. Define Contiguity and Coherence Constraints
If borders are produced, specify constraints such as:
- Contiguity: No isolated enclaves unless explicitly allowed.
- Corridor rules: For access.
- Treatment of mixed units: Subdivision rules or shared administration options.
4. Define Minority Protections and Human Rights Constraints
Vote-to-border must not be a “license” for rights violations. Specify:
- Protections for minorities in any resultant zones.
- Policing/security constraints under Freeze conditions.
- Mechanisms for monitoring rights compliance post-result.
Before the vote:
- Publish the full mapping algorithm and parameters.
- Publish the data inputs that will be used (boundaries, units, registries).
- Establish a version-lock and governance process for any emergency changes.
- Define how disputes about inputs are handled.
The Simulation/Sandbox Requirement
A public simulation platform should allow stakeholders to:
- Test hypothetical vote distributions.
- Explore edge cases (mixed units, low turnout, displaced participation).
- Verify that the published rules behave as advertised.
- Detect incentives for gaming.
Publish:
- Code (or at minimum a deterministic spec).
- Sample datasets.
- Documented examples and edge-case handling.
- A changelog and cryptographic hashes (if applicable) to support version-locking.
Fraud and Manipulation Risks (and Mitigations)
Risk: Strategic Exclusion or Displacement
Mitigate via:
- Electorate inclusion rules with cutoffs.
- Independent audits of registration and participation.
- Transparency on participation by category (resident/IDP/refugee).
(See: Electorate Definition)
Risk: Gerrymandering via Unit Choice
Mitigate via:
- Choosing stable, pre-existing administrative units where possible.
- Publishing boundaries and forbidding midstream changes.
- Independent review of unit design.
Risk: Low-Turnout Gaming
Mitigate via:
- Cautious use of turnout thresholds (can be exploited).
- Robust anti-coercion measures and access support.
- Explicit rules for inconclusive units (e.g., rerun, runoff, negotiated fallback).
When Not to Use Vote-to-Border
Consider excluding this module if:
- Security conditions make free participation implausible in key areas.
- Displaced inclusion cannot be operationalized credibly.
- Boundary consequences would create unacceptable rights risks.
- Parties cannot pre-commit to rules and accept the outputs.
