🚪 Field Canvassing

Spec map

Home: All V2 Specs · Foundation: Data System (UVP) Mode(s): Campaign Mode, Petition Mode Related specs: Data System (UVP), Phone Banking, Polling Engine, Voter Contact

🎯 Goals

Product Philosophy and User Model

Serve distinct Manager, Canvasser, and Politogy roles with surfaces tuned to strategy, field speed, and oversight respectively. Mode Architecture and Product Positioning
Position Field Canvassing as the highest-value Campaign Mode intelligence channel integrated with the Polling Engine and peer to Phone Banking. Foundational Architecture
Establish the two-tier IP boundary, portable Canvasser entity, first-class walk lists, and immutable Door Visit Events as the data backbone. Walk List Creation and Optimization
Produce methodologically defensible, optimized, fielding-ready walk lists with consultative AI and auditable overrides. The Mobile Canvasser Experience
Give canvassers a fast, offline-first field assistant that handles routing, capture, safety, and polling at the door. Polling Engine Integration
Make canvassing a full fielding mode of the Polling Engine with door-administered, scored, provenance-stamped poll responses. Heavy-Prescription Walk List Next Moves
Autonomously generate fully-specified follow-up canvass campaigns from poll or canvas findings. The Canvasser Performance Profile
Score every canvasser continuously and portably across accounts as a calibrated, sellable data asset. Capture Mode and Intelligence Routing
Distinguish what the voter said from what the canvasser inferred so Aggregate Intelligence is honestly weighted. Reporting, Analytics, and Strategic Memo
Turn captured canvass data into operational reports, strategic memos, and longitudinal voter trajectories. Compliance, Safety, and Consent Architecture
Make canvasser physical safety, consent, and per-state compliance foundational architecture rather than features. Offline Architecture
Guarantee end-to-end offline field operation with mandatory pre-shift sync, opportunistic post-shift sync, and lossless conflict resolution. Donor and Volunteer Canvassing Variants
Support Donor and Volunteer canvassing on the shared substrate while routing intelligence to their respective pipelines. Service Boundaries and Integration Points
Organize the implementation into clear services and integration contracts with the UVP, Polling Engine, and peer features.

Conceptual Specification

Module: Campaign Mode → Voter Contact → Field Canvassing Document type: Conceptual specification (architecture, behavior, and integration) Audience: Politogy VRM development team Status: Draft for development team review (substrate-aligned) Author: Ben Edtl (Politogy LLC) Substrate dependency: VRM Voter Contact Substrate (foundational entities, Posture distinction, Cross-Channel Contact Ledger, VWPP framework, Next Moves contract, Capture Mode taxonomy, two-tier boundary) Companion documents: VRM Foundational Data System; VRM Polling Engine; VRM Voter Contact — Phone Banking; VRM Mode Architecture; Message Lane Taxonomy

1. Executive Summary

Field Canvassing is the highest-value voter intelligence channel in Politogy VRM. It is not a walk list app, not a door-to-door logistics tool, and not a volunteer task manager. It is a distributed intelligence extraction system, disguised as a canvassing product, that turns every door knock into structured, scored, longitudinally tracked input for the Unified Voter Profile and the Aggregate Intelligence layer.

The product thesis is that direct in-person contact is the single most reliable channel for capturing voter intelligence. A trained canvasser standing on a voter’s porch produces signal that no SMS, no email, no automated call, and no third-party enrichment provider can replicate. This signal is also the most expensive to collect — which is precisely why it deserves a software architecture that extracts maximum structured value from every interaction. Field Canvassing is built around that premise.

The product is built on five foundational principles:

Every door is a fielding instrument. A canvasser is not delivering a message; the canvasser is fielding a methodologically validated instrument that produces structured output. Walk lists, scripts, optional polling questionnaires, and custom note schemas are all part of the instrument design.
Every canvasser is a measurable instrument. Canvassers are scored on door quality, response rate, data quality, sentiment capture reliability, polling fidelity, geographic coverage efficiency, and safety discipline. This scoring is Politogy IP and constitutes one of the core data assets of the platform.
Every captured datum carries a Capture Mode. Self-Report, Observation, and Verified are first-class field-level attributes that distinguish what the voter said from what the canvasser inferred. This produces honestly weighted training signal for Aggregate Intelligence.
Walk lists are methodology, not transient lists. Walk lists are first-class queryable longitudinal entities with explicit states, methodology abstracts, version history, and comparability across time, geography, and canvasser team. This makes canvassing data defensible and longitudinally analyzable.
Safety is architecture, not a feature. Cross-account unsafe-property warnings, mandatory pre-shift sync, panic-button hot-path delivery, pair canvassing routing, and per-state compliance enforcement are foundational to the product. Canvasser physical safety is an explicit categorical exception to standard data isolation rules.

Field Canvassing differentiates Politogy VRM in five structural ways: (1) tight integration with the Polling Engine, making canvassing a fielding mode that produces full four-dimensional scoring on door-administered polls; (2) the Canvasser Performance Profile (CPP), a Politogy-IP scoring layer that turns canvasser quality into a portable, sellable data asset; (3) the Capture Mode taxonomy, which lets the system honestly weight self-reported voter positions versus canvasser observations in Aggregate Intelligence; (4) Heavy-Prescription Walk List Next Moves, where the Strategic Analyst autonomously generates fully-specified canvass campaigns following a poll’s findings; and (5) cross-account safety intelligence, where unsafe-property warnings flow across the platform to protect canvassers in the field.

This specification defines the V1 MVP scope. V2 features are flagged where relevant but not detailed.

Substrate alignment. Field Canvassing is one of two V1 channels of the VRM Voter Contact substrate. It honors every substrate contract — the Volunteer Worker entity, the Posture distinction (Poll-Fielding vs Contact Operation, locked at Session creation), the Cross-Channel Contact Ledger, the VWPP framework with four substrate-defined shared dimensions, the Heavy-Prescription Next Moves contract, the Capture Mode taxonomy, the two-tier IP boundary, and the substrate-shared campaign type taxonomy. Where this spec describes a concept that is substrate-defined, the concept is reproduced here for context and a substrate-note flags the reference. Channel-specific elements (walk lists, GPS, offline-first, physical safety, canvasser-specific VWPP dimensions) diverge from the peer Phone Banking channel per substrate’s permission to do so.

See the VRM Voter Contact — Phone Banking specification for the peer voice channel.

2. Product Philosophy and User Model

2.1 The User

Field Canvassing serves three user roles, each with distinct needs:

Manager / Coordinator (PC-tier user)

Campaign managers, field directors, ballot initiative coordinators
Plans canvasses, builds walk lists, assigns territory, monitors execution, reviews captured intelligence
Operates primarily on desktop/laptop, with occasional mobile oversight

Canvasser (Mobile-tier user)

Volunteers, field organizers, paid canvassers, candidate-supporter walkers
Receives assigned routes, knocks doors, captures interactions, administers structured instruments at the door
Operates exclusively on mobile

Politogy Internal (Cross-account oversight)

Politogy admins reviewing safety flags, moderating Do Not Approach designations, managing the cross-account Canvasser entity, observing CPP calibration

The Manager and Canvasser experiences are deliberately distinct surfaces with different design priorities. Manager surfaces emphasize strategic planning, oversight, and intelligence review. Canvasser surfaces emphasize speed, clarity, offline reliability, and physical safety in the field.

2.2 The Manager Experience

The manager surface should feel like a strategic field operations console. Walk list creation is a methodology negotiation — the user defines target population, geographic scope, optimization parameters, and the system produces a defensible, optimized walk list with full methodology abstract. Assignment is structured and auditable. Live oversight provides real-time progress without micromanagement of canvassers in the field. Captured intelligence flows through the Strategic Analyst into actionable Next Moves rather than sitting as raw outcome data.

Specifically:

Walk list optimization is consultative, not opaque. The user sees the optimization function being applied, can adjust parameters, and overrides are logged with audit trail.
Live progress dashboards show coverage, contact rate, outcome distribution, and canvasser performance in aggregate without exposing raw GPS traces by default.
Strategic memos arrive when canvasses complete. Heavy-Prescription Next Moves arrive as fully-specified follow-up campaigns.
Cross-feature integration with the Polling Engine and Phone Banking is visible at the campaign level — managers see contact mix and channel coordination across all features.

2.3 The Canvasser Experience

The canvasser surface should feel like a confident field assistant that handles every operational concern so the canvasser can focus on the conversation at the door. Routing is turn-by-turn or sequential at the canvasser’s preference. Voter cards arrive pre-populated with everything the canvasser needs to have an intelligent conversation. Outcome logging is two taps. Notes capture is fast and tagged by Capture Mode. Polling instruments administered at the door are scriptable, branched, and frozen at pre-shift sync. Safety infrastructure is unobtrusive but always present.

Specifically:

The mobile app works offline-first, not offline-capable. Once the shift is started, the entire field operation runs without network.
Door cards display only canvassing-relevant UVP fields, sized for fast in-the-moment reading.
Custom note fields defined by the manager appear as distinct capture surfaces alongside Community Notes and System Notes.
Polling Engine instruments fielded at the door appear as a clearly delineated module within the door card — distinct from outcome logging and free-form notes.
Panic / safety button is persistent. Geofence and check-in alerts are non-disruptive but reliable.

2.4 What This Product Is Not

To avoid scope drift:

This is not a generic walk list tool. Conventional canvassing tools (Reach, MiniVAN, others) are operationally adequate but treat canvassing as logistics, not intelligence. Field Canvassing is positioned as the platform’s highest-value intelligence channel, with a data architecture and IP layer that other tools do not provide.
This is not a Phone Banking product. Phone Banking is the peer voice channel of the VRM Voter Contact substrate, with its own specification. Both channels build against the same substrate; integration points are substrate-defined and noted throughout this spec.
This is not a stand-alone product. Field Canvassing is integrated with the Polling Engine (canvassing as a fielding mode), the broader UVP and Aggregate Intelligence layers, the message lane taxonomy, and the Strategic Analyst’s Next Moves system.
This is not exclusive to door-to-door operations. Door-to-door is the primary fielding mode in V1. Event canvassing, public-space canvassing, and parking-lot canvassing are V2+ fielding modes that share the substrate. The product is “Field Canvassing,” not “Street Canvassing,” to accommodate this future scope.

3. Mode Architecture and Product Positioning

3.1 Where Field Canvassing Lives

Field Canvassing lives exclusively inside Campaign Mode. This is foundational and non-negotiable.

The reason is structural: meaningful canvassing requires access to the voter roll. A canvasser without geocoded voter data is walking blind — they don’t know who lives at which door, what their party affiliation is, what their vote history is, or whether they’ve requested do-not-knock. Because Campaign Mode is the mode that grants voter-roll access, Field Canvassing must live there.

Petition Mode subscribers automatically receive Campaign Mode entitlement (per existing architecture) and therefore receive Field Canvassing. This is operationally important: petition signature drives are field operations that benefit directly from walk list optimization, canvasser scoring, and cross-account safety intelligence.

3.2 Relationship Mode

Relationship Mode does not include Field Canvassing. Relationship Mode is built around opt-in customer-supplied contacts (donors, volunteers, supporters) and does not have voter-roll access. Without voter-roll access, the optimization, geofencing, do-not-knock enforcement, and intelligence routing that define Field Canvassing cannot operate.

If a Relationship Mode user wants to coordinate in-person outreach to opt-in contacts (e.g., visiting major donors at home), this is supported through Relationship Mode’s existing contact and event infrastructure — not through Field Canvassing.

3.3 Field Canvassing and the Polling Engine

Field Canvassing and the Polling Engine are peer Campaign Mode features that share infrastructure where it is right to share and stay distinct where they solve different problems. The integration is tight at the fielding layer and loose elsewhere.

Tight integration:

Canvassing is a fielding mode of the Polling Engine. Canvasser-administered polls are full Polling Engine polls — same Methodology Agent, same four-dimensional scoring, same Fielding Scorecard, same Strategic Analyst output, same Aggregate Intelligence telemetry.
The Methodology Agent’s headless mode generates canvass scripts and walk list specifications alongside its existing poll questionnaire generation. One agent, broader domain.
Heavy-Prescription Next Moves include canvass campaigns as a Next Move type alongside follow-up polls.
A unified Strategic Next Moves queue surfaces both poll and canvass Next Moves at the campaign level.

Loose integration:

A canvass without polling is a full canvass. Outcome logging, free-form notes, and the rest of the canvassing-specific infrastructure operate independently.
A poll without canvassing is a full poll. SMS, email, and tokenized web link fielding modes operate independently.
Field Canvassing carries its own intelligence layer — the Canvasser Performance Profile, Capture Mode, walk list optimization, cross-account safety intelligence — that is not subsumed by the Polling Engine.

3.4 Field Canvassing and Phone Banking

Substrate note: Shared substrate elements below are defined in the VRM Voter Contact substrate spec. Reproduced here for context.

Phone Banking is a peer Campaign Mode feature of the VRM Voter Contact substrate. Both channels build against the substrate; Field Canvassing defines its channel-specific implementation; Phone Banking defines its own. See the VRM Voter Contact — Phone Banking specification for the peer voice channel.

Shared substrate (architectural contract — substrate-defined):

Volunteer Worker entity (Canvasser is the Field Canvassing specialization; Caller is the Phone Banking specialization; one continuous VWPP across both)
Posture distinction (Poll-Fielding Session vs Contact Operation Session, locked at creation)
Session lifecycle (Draft → Staged → Live → Closed → Archived)
Cross-Channel Contact Ledger (every door visit and every call attempt writes a Ledger entry)
Shared campaign type taxonomy (all 8 substrate campaign types apply to both channels)
VWPP framework with four substrate-defined shared dimensions (Data Quality, Sentiment Capture Reliability, Polling Fidelity, Channel-Specific Quality)
Polling Engine integration: both are fielding modes for the Polling Engine when in Posture A
Methodology Agent and ScriptBuilder script contracts
Heavy-Prescription Next Moves contract (Walk List Next Move type for canvass; Call List Next Move type for phone; unified Strategic Next Moves queue)
Capture Mode taxonomy (Self-Report / Observation / Verified — Observation rare on phone, common on door)
Two-tier IP boundary as applied to Voter Contact
Message lane assignment taxonomy
Aggregate Intelligence routing: both feed cross-account intelligence
Do-not-contact propagation across channels (a voter who opts out on phone cannot be door-knocked by the same campaign)

Divergent elements (defined per channel):

Fielding instrument: walk list (canvass) vs. call list (phone bank)
Optimization function: walking distance + elevation + time-of-day vs. time-zone + preferred-contact-time + do-not-call
Capture environment: in-person vs. remote/voice
Channel-specific VWPP dimensions: Response Rate, Geographic Coverage Efficiency, Safety Discipline (Field Canvassing) vs. Connect Rate, Compliance Discipline (Phone Banking)
Channel-Specific Quality dimension: Door Quality (Field Canvassing) vs. Call Quality (Phone Banking)
Safety architecture: physical canvasser safety vs. caller anonymity / harassment protection
Offline architecture: offline-first (canvass) vs. online-first (phone)
Compliance regime: state-by-state canvassing rules vs. TCPA / DNC registries / calling hours / recording consent

Nothing in Field Canvassing V1 depends on Phone Banking shipping. The two integrate cleanly when both are present.

3.5 Field Canvassing and the UVP

Field Canvassing writes to multiple UVP layers as defined in the VRM Foundational Data System:

Campaign Data layer: Walk list assignments, door visit events, outcomes, contact log entries, free-form notes (Community / System / custom), captured polling responses (originating from Field Canvassing fielding)
Relationship Data layer: Voter-requested do-not-knock flags (account-scoped portion), voter-stated preferences captured during canvass conversation
Aggregate Intelligence layer: Canvasser performance scoring inputs, Capture Mode-weighted training signal, sentiment extraction outputs from notes, cross-account safety intelligence, walk list methodology effectiveness telemetry
Identity Core / Contact Info / Vote History / Geographic / Enrichment: Read-only consumers; canvassing displays these through the door card but does not write to them

User-generated data priority rules apply per the data system spec — canvasser-captured data takes priority over voter file values when in conflict, with full provenance preservation.

4. Foundational Architecture

4.1 The Two-Tier Boundary

Substrate note: The two-tier IP boundary (Customer-tier vs Politogy-tier) is substrate-defined and applies uniformly across all VRM Voter Contact channels. The lists below show the Field Canvassing-specific application of the substrate boundary.

The two-tier boundary established in the VRM Foundational Data System and the Polling Engine specification applies to Field Canvassing in full, as required by the VRM Voter Contact substrate. This is non-negotiable architecture, enforced at the data-write and query layer rather than the UI layer.

Customer-tier (visible to the originating account):

Walk list as instrument: segmentation rules, geographic scope, target sample, methodology abstract
Scripts: AI-drafted, user-edited, user-authored
Custom note field schemas defined by the manager
Outcome enum customizations within allowed bounds
Polling instruments fielded at the door (campaign work product, per Polling Engine spec)
Captured raw data: door visit events, free-form notes, polling responses, audio/photo media (V2), Capture Mode tags, GPS traces (consented)
Operational reporting: volunteer stats, coverage reports, outcome distribution, aggregate progress dashboards
Strategic outputs: strategic memos, lane assignments, AI-drafted Next Move artifacts before activation
Audit trails of all of the above

Politogy-tier (Politogy IP, never customer-visible directly):

Walk list optimization algorithm: routing engine, TSP heuristics, elevation weighting models, time-of-day weighting models
Canvasser Performance Profile (CPP) scoring model: full algorithm, weights, calibration logic
Sentiment Capture Reliability calibration model: how the system learns to weight a canvasser’s tags against ground truth
Capture Mode disambiguation model: internal logic for routing Self-Report vs. Observation vs. Verified into Aggregate Intelligence
AI sentiment extraction pipeline applied to free-form notes
AI script generation models: prompts, fine-tunes, evaluation rubrics
Optimization Intelligence model: cross-account canvassing telemetry → routing recommendations
Cross-account aggregate intelligence: contact rate patterns, script effectiveness benchmarks, canvasser portability data, door-level cross-canvass intelligence, walk list methodology effectiveness
The unified Canvasser entity itself
AI artifact telemetry, override decisions, cross-account override patterns
Cross-account unsafe-property warning aggregation (free-text observations are Politogy-only; structured aggregates surface to the field per safety architecture)

4.2 Tier-Gated Customer Exposure

Three tiers, mirroring the Polling Engine pattern:

Tier	Exposed Capabilities
Free / Basic	Walk list generation (algorithm hidden, output shown). Basic operational reporting. Aggregate volunteer stats. AI sentiment extraction running on notes — customer sees classifications and tags only, no underlying scores. Polling Engine integration follows Polling tier rules — Free tier sees classifications and tags only on canvasser-administered poll responses.
Premium	CPP scores exposed on canvassers within the customer’s account: Door Quality, Response Rate, Data Quality, Sentiment Capture Reliability, Polling Fidelity. Four-dimensional scoring exposed on canvasser-administered poll respondents (per Polling Engine Premium tier). AI sentiment extraction with underlying scores on customer’s own notes. Optimization Intelligence applied to own data (e.g., shift-window performance patterns, territory-type effectiveness).
Enterprise	Cross-account canvasser intelligence: benchmarking, predictive canvasser-effectiveness modeling, portable canvasser scoring (aggregated, anonymized). Cross-account contactability intelligence. Cross-account script effectiveness benchmarks. Predicted contactability scoring on individual doors at walk list generation. Walk list methodology benchmarks. Aggregate Intelligence layer access for canvassing-derived signals.

4.3 The Canvasser Entity

Substrate note: The Volunteer Worker entity (with account-portable identity, cross-account/cross-channel VWPP accumulation, customer-tier slice view, and Politogy-tier full view) is substrate-defined. The Canvasser is the Field Canvassing specialization of the substrate Volunteer Worker. Reproduced here for context.

The Canvasser is a Politogy-owned, account-portable entity distinct from the User entity. A Canvasser is a role-playing instance of a User. Architecturally, a Canvasser is the Field Canvassing specialization of the substrate’s Volunteer Worker entity. A User who has also worked Phone Banking Sessions has both a Canvasser and a Caller specialization on the same Volunteer Worker entity, with one unified VWPP accumulating across both channels.

Architectural properties:

A canvasser working for Account A in 2026 and Account B in 2028 is the same Canvasser entity with one continuous CPP across both accounts.
The CPP accumulates continuously across all door visits, all campaigns, all accounts.
Customers see only the slice relevant to their account. Politogy sees the unified profile.
Cross-account scoring at the Enterprise tier is aggregated and anonymized — the customer sees a canvasser’s overall reliability score, not specific account-by-account performance breakdowns.

V1 scope:

Canvasser entity created on first canvass assignment
Continuous CPP accumulation across accounts
Customer-tier slice view per account
Politogy-tier full view
Enterprise-tier aggregated cross-account access

V2 scope (flagged for legal review):

Canvasser opt-out of cross-account scoring (labor-law implications around scoring workers across multiple employers may apply in some jurisdictions)
Canvasser-facing visibility into their own CPP (transparency feature)

4.4 The Walk List as First-Class Entity

Walk lists are first-class queryable longitudinal entities — not transient lists of addresses.

Architectural properties:

Each walk list carries a Methodology Abstract describing target population, sample, geographic scope, optimization function, instrument, and assignment methodology
States: Draft → Ready → Assigned → Live → Complete → Analyzed → (Activated / Archived)
Immutable once Live; edits during Draft / Ready are versioned with full history
Doors can be added or removed during Live state via explicit, audited operations; historical state at any point is reconstructible
Comparable across time, geography, canvasser team, and methodology
Each walk list emits state-transition events to the Aggregate Intelligence event stream

This parallel with the Polling Engine’s poll-as-living-record principle is intentional. Walk lists are not activities; they are research instruments.

4.5 The Door Visit Event

The atomic unit of canvassing data is the Door Visit Event. Every door knock — successful or not — produces exactly one Door Visit Event written to the UVP’s Campaign Data layer.

A Door Visit Event carries:

UVP reference (the voter at this door)
Walk list reference (which walk list this visit was part of)
Canvasser reference
Timestamp (server time + device-claimed time + reconciliation flag)
GPS (if consented; verification mode or continuous mode per Section 12)
Outcome (typed by campaign type — Voter / Donor / Volunteer enum sets)
Outcome Capture Mode (Self-Report / Observation / Verified)
Free-form notes (Community / System / custom fields), each with field-level Capture Mode
Polling response reference (if a Polling Engine instrument was administered; full response data lives in Polling Engine data model and is referenced)
Media references (V2: audio, photo, video, transcript)
Safety flag (if any: Caution / Warning / Do Not Approach with structured reason and free-text observation)
Voter-requested do-not-knock flag (if set)
Incident report reference (if any)
Audit metadata: client UUID, sync timestamp, idempotency key

Door Visit Events are immutable. Re-knocks at the same door produce a new Door Visit Event. The voter’s full canvass history is the ordered sequence of all Door Visit Events on the UVP.

4.6 Event Stream and Downstream Processing

Every Door Visit Event sync-write triggers downstream pipeline execution:

ScoringService scores any associated polling responses (per Polling Engine spec)
ClassificationService runs on scored responses
LatentStateDetectionService scans for latent state signals
AI sentiment extraction runs on free-form notes (per Section 11 of the data system spec)
CPP updates compute new scores for the canvasser
Aggregate Intelligence event stream emits the captured event for downstream consumers
Optimization Intelligence telemetry feeds the routing model
Strategic Analyst receives the event for memo generation when the parent walk list reaches Complete
Cross-account safety aggregation runs if a safety flag was set

These run asynchronously on the backend, not blocking the canvasser’s sync. The canvasser sees their data as “synced” once it reaches the backend; downstream processing happens in the event stream.

4.7 The Continuous Lifecycle

Substrate note: The Session lifecycle (Draft → Staged → Live → Closed → Archived) and the substrate’s continuous lifecycle phases (Plan → Build List → Build Script → Stage Session → Field → Disposition → Aggregate → Activate Next) are substrate-defined. The Field Canvassing lifecycle below is the channel-specific elaboration of that substrate lifecycle, with phases named for the canvassing operational reality. Phase names differ but the underlying state machine is the same.

Field Canvassing follows a continuous lifecycle parallel to the Polling Engine’s:

Define → Generate → Optimize → Assign → Field → Capture → Sync → Score → Analyze → Recommend → Deploy → Track Longitudinally → Recommend Next Moves

Each phase flows into the next. Data captured at any phase remains queryable at every subsequent phase. The system is stateful, not transactional. A campaign’s tenth canvass is dramatically more powerful than its first because every prior canvass has contributed to UVP enrichment, CPP calibration, and Aggregate Intelligence accumulation.

5. Walk List Creation and Optimization

5.1 The Walk List Creation Workflow

Walk list creation is a structured workflow that produces a methodologically defensible, optimized, fielding-ready walk list. The user proceeds through five phases:

Campaign Type Selection — Voter Canvassing (primary), Donor Canvassing (variant), or Volunteer Canvassing (variant). The selection determines available outcome enums, intelligence routing, and downstream features.
Target Population Definition — segmentation rules applied against the voter roll within the customer’s geographic scope. Filters include voting history, party, demographics, prior contact status, prior outcome, custom tags, polling-derived classifications, and (Premium/Enterprise) Aggregate Intelligence-derived attributes.
Geographic Scoping — precinct, district, ward, or custom polygon boundaries. Geofence is a hard constraint at optimization and assignment.
Optimization Configuration — walking distance minimization (default), elevation weighting (configurable strength), time-of-day weighting, canvasser starting location, do-not-knock and unsafe-property exclusions.
Instrument Configuration — script (AI-drafted, user-edited, or user-authored), optional Polling Engine instrument to be administered at the door, custom note field schema, outcome enum configuration.

The walk list is generated in Ready state when all phases are complete. The user reviews on an interactive map preview, can edit the route, can override individual door inclusions, and can adjust optimization parameters. Each adjustment is recorded in the walk list’s audit trail.

5.2 The AI Methodology Layer in Walk List Creation

Walk list creation invokes the Methodology Agent (per Polling Engine spec) for two purposes:

Script generation. The agent produces an AI-drafted script tailored to the campaign type, target population, and selected optimization. Each script element carries a rationale: why this opening, why this question sequence, why this close. The user can accept, modify, or override — same consultative pattern as poll questionnaire negotiation in the Polling Engine. Override is logged with audit trail and surfaces on the resulting strategic memo.

Polling instrument generation. If the user opts to field a Polling Engine instrument at the door, the Methodology Agent generates the questionnaire under canvass-mode constraints — different from SMS-mode constraints. Specifically:

Question length budget is shorter (canvasser delivery time at door)
Branching depth is shallower (canvasser cognitive load at door)
Voice register is conversational, not formal
Scriptability is required (the canvasser has to read it aloud naturally)

The questionnaire is locked when the walk list reaches Live state. Mid-shift questionnaire updates do not propagate to active walk lists. New walk lists generated after an update use the new version.

5.3 Walk List Optimization

Walk list optimization is a Politogy-IP server-side computation. The customer sees the output (the optimized route) and can adjust parameters (elevation penalty strength, time-of-day weights), but the algorithm itself is not exposed.

V1 optimization inputs:

Walking distance (primary minimization target — TSP-approximate routing using nearest-neighbor with 2-opt refinement)
Elevation (edge weighting: penalize segments above 5% grade, configurable per campaign)
Time-of-day (residential vs. commercial vs. mixed-use weighted by shift start time)
Geofence boundaries (hard constraint)
Do-not-knock flags (hard constraint)
Unsafe-property flags at “Do Not Approach” severity (hard constraint)
Canvasser starting location (origin point)

V2 optimization inputs:

Address density / cluster optimization (smarter than nearest-neighbor for dense urban grids)
Weather-adaptive routing (live weather API integration)
Daylight constraints (auto-shorten near sunset, prioritize lit-street segments after dark)
Shift length / canvasser fatigue (personalized to each canvasser’s CPP)
Multi-canvasser territory balancing (AI-balanced partition across N canvassers)
Predicted contactability (drop low-probability-of-contact doors at generation time — Aggregate Intelligence-driven, Premium/Enterprise tier)
Mid-shift re-routing (reshuffling based on field conditions)

5.4 The Methodology Abstract

Every walk list carries a Methodology Abstract — a short structured document describing:

Target population definition (segmentation rules in plain English plus structured form)
Sample size and target sample
Geographic scope and boundary definitions
Optimization function used (parameters, weights, version of the optimization model)
Script / instrument fielded
Assignment methodology (volunteer count, doors per volunteer, territory split logic)
Known limitations (uncovered doors, opt-outs, geographic gaps, do-not-approach exclusions)

The Methodology Abstract is attached to the strategic memo when the walk list reaches Analyzed state. It is how a campaign defends “here is what we knocked, here is what we found” months or years later. It is also how the Strategic Analyst compares walk lists longitudinally — same target population, different scripts, different outcomes.

5.5 Optimization Override

The user can override optimization decisions at the parameter level (adjusting elevation penalty, time-of-day weights) or at the route level (manually reordering doors, removing doors, adding doors back that the optimizer excluded).

Overrides follow the Methodology Agent’s behavioral pattern:

The system explains its current optimization reasoning when the user attempts an override
The system can decline routing that would create operational problems (e.g., manual reordering that crosses the geofence; adding back a door flagged Do Not Approach)
For overrides the system permits but disagrees with, it logs the override and may flag the resulting walk list with a methodology note
The user always has authority to override; friction is calibrated to severity

5.6 Walk List Assignment

Once the walk list reaches Ready state, the manager assigns territory to canvassers. Three assignment modes:

Percentage split — divide the list into equal-size or proportional shares across N canvassers. System suggests cuts that minimize cross-canvasser travel and respect geographic clustering.

Manual territory split — manager draws or selects sub-regions of the walk list and assigns to specific canvassers.

AI-balanced split (V2) — AI partitions the walk list across N canvassers to equalize estimated effort, accounting for terrain, density, and canvasser CPP profiles.

Each canvasser receives an assignment in their mobile app inbox (or the existing notification surface; Inbox is a separate forthcoming feature). Assignment includes: walk list reference, assigned door subset, route order, script, optional polling instrument, custom note schema, and shift parameters (start time, expected duration).

The walk list transitions to Assigned state when at least one canvasser has been assigned and notified. It transitions to Live state when at least one canvasser has started their shift.

6. The Mobile Canvasser Experience

6.1 Pre-Shift

The canvasser opens the mobile app and sees their assigned shift. Pre-shift sync is mandatory:

Canvasser taps “Start Shift”
App requires connectivity to proceed
App pulls the latest cache: walk list version, script version, polling instrument version, do-not-knock flags, unsafe-property warnings, custom note schema, map tiles for assigned territory + buffer
App requests GPS consent (if not already on file) per consent mode (Off / Verification only / Continuous)
App captures shift origin location
Shift transitions to Active

If pre-shift sync fails (no connectivity, server error), the shift cannot start. The app surfaces a clear message: “You need to connect to start your shift. Your assignment will load when you’re online.”

This is non-negotiable architecture. Pre-shift sync is the moment the system enforces current safety data, current do-not-knock flags, current polling instrument, and current script. Bypassing it would compromise data integrity and canvasser safety.

6.2 In-Shift: The Door Card

At each assigned door, the canvasser sees a Door Card. The Door Card is the canvasser’s primary interaction surface and is designed for fast in-the-moment use.

Door Card sections:

Section	Contents
Address & Voter	Display name, address, party, registration status, last contact date and outcome from this account, key UVP-derived tags relevant to script
Script	The locked script for this walk list. Scrollable, scriptable, with branching logic indicators if applicable
Outcome	Tap-to-log outcome buttons: campaign-type-appropriate enum (Voter / Donor / Volunteer). Each outcome captures Capture Mode (Self-Report / Observation / Verified) via a secondary tap.
Polling (if applicable)	“Conduct Poll” button. Launches the locked Polling Engine instrument as an inline module. Branched, scoring-instrumented, response-captured. Returns to Door Card on completion.
Notes	Tabs for Community Notes (global to Politogy), System Notes (campaign-private), and any manager-defined custom note fields. Each note tagged with field-level Capture Mode.
Safety / Flags	Buttons for: voter-requested do-not-knock, safety flag (Caution / Warning / Do Not Approach with structured reason), incident report.
Media (V2)	Audio capture, photo capture (with consent flow).
Navigation	Auto-advance to next door on outcome log; manual override; “Skip for now” with reason capture.

The Door Card is offline-first. All operations work without network. Captured data is queued for sync; the canvasser sees their captures as “captured locally” until sync confirms server receipt.

6.3 Outcome Logging

Outcome logging is two taps minimum: one to select the outcome, one to confirm Capture Mode.

Voter Canvassing outcomes:

Supportive (Self-Report / Observation / Verified)
Undecided (Self-Report / Observation / Verified)
Opposed (Self-Report / Observation / Verified)
Refused (Self-Report / Observation)
Not Home (Observation only — there’s no voter to self-report)
Do Not Knock (per voter request — Self-Report)
Unable to Contact (operational — Observation only)

Donor Canvassing outcomes:

Pledged (Self-Report / Verified) — captures pledge amount and cadence
Considering (Self-Report)
Declined (Self-Report)
Not Home (Observation only)
Already Donor (Self-Report / Verified — captures status check)

Volunteer Canvassing outcomes:

Signed Up (Self-Report / Verified) — captures sign-up details (skills, availability)
Interested (Self-Report)
Declined (Self-Report)
Not Home (Observation only)
Already Volunteer (Self-Report / Verified)

Capture Mode selection is required. The default selection is the most likely Capture Mode for the outcome (e.g., “Not Home” defaults to Observation; “Supportive” defaults to Self-Report) but the canvasser confirms.

6.4 Free-Form Notes Capture

Three note types, accessible via tabs on the Door Card:

Community Notes — written for the global Politogy community. The canvasser is told these are visible across the platform (anonymized, aggregated). Higher-quality observations, not gossip. AI sentiment extraction runs across all Community Notes for Aggregate Intelligence.

System Notes — campaign-private. Only visible within the originating account. Tactical observations, internal context, follow-up notes for other canvassers in the same account.

Custom Note Fields — manager-defined for this walk list. Examples: “Issue Focus” (free text or enum), “Urgency Level” (Low / Medium / High), “Follow-Up Action” (callback / mail / other). Custom fields are part of the walk list’s instrument.

Each note carries a field-level Capture Mode. The canvasser tags whether the note represents something the voter said (Self-Report), something the canvasser observed about the situation (Observation), or something the voter said and the canvasser cross-confirmed (Verified).

6.5 In-Shift: Polling Engine Administration

When the walk list includes a Polling Engine instrument, the canvasser sees a “Conduct Poll” button on the Door Card. Tap launches the polling module as an inline experience:

Token verification (the pre-issued token bound to canvasser + door + walk list is validated)
Questionnaire administered with full Polling Engine logic (branching, validation, response capture)
Each response carries Capture Mode at the question level
Completion writes a polling response back to the Polling Engine data model with full provenance (source: canvass-fielded; canvasser: ID; door: UVP reference; walk list: reference)
Returns to the Door Card with poll status indicated

Polling responses fielded by canvass are first-class poll responses. They flow through the same scoring, classification, latent state detection, segmentation, and message lane assignment pipelines as SMS, email, and tokenized web link responses. The Fielding Scorecard reflects them as canvass-mode samples.

6.6 Safety Surfaces in the Field

Do-Not-Knock Enforcement at Door Display. Even though the walk list excludes flagged addresses at generation time, the Door Card re-checks flag status when it loads. If a flag was added after walk list generation (via online sync), the Door Card displays a Do-Not-Knock indicator and the canvasser is prevented from logging an outcome other than “Do Not Knock — voter request” or skip.

Unsafe-Property Warnings. When the Door Card loads for a property with cross-account safety flags, the canvasser sees a warning indicator before approaching:

Caution (yellow) — informational. “Caution: aggressive resident reports.” Canvasser exercises judgment.
Warning (orange) — explicit pre-knock confirmation required. Canvasser must tap “I have reviewed the safety note and choose to approach” before the Door Card unlocks.
Do Not Approach (red) — the door is excluded entirely. The canvasser is routed past it. (This severity should not appear at the Door Card because such doors are removed at walk list generation; the safeguard exists in case of late flagging.)

The reason category is shown (e.g., “aggressive resident,” “weapons displayed”). Free-text observations are not shown — they remain at the Politogy tier.

Geofence Boundary Alerts. If the canvasser strays outside the assigned territory by more than a brief threshold, the app prompts: “You appear to have left your assigned area — confirm or return to territory.” Repeated boundary violations flag for manager review.

Periodic Check-In. Configurable per campaign (e.g., every 60 minutes). Non-disruptive prompt; tap to confirm safe. Missed check-in triggers escalation per the safety architecture in Section 12.

Panic / Safety Button. Persistent on every screen during shift. One tap silently flags shift as in-distress, alerts manager and configured escalation contact, shares last known GPS, and (V2) captures audio context. Operates over every available channel including SMS fallback.

6.7 Post-Shift

The canvasser ends the shift via the app:

Tap “End Shift”
App captures shift end location and timestamp
App displays shift summary: doors knocked, outcomes captured, polling responses, time spent, distance walked
App attempts final sync; remaining queued data continues to push opportunistically afterward
Shift transitions to Complete

If the canvasser does not end the shift within the expected window plus grace period, the safety architecture escalates per Section 12.

6.8 Offline Reliability

Once the shift has started, the entire field operation runs offline. This includes door display, outcome logging, free-form notes, Capture Mode tagging, polling instrument administration, photo capture (V2), audio capture (V2), GPS capture, safety flagging, voter-requested do-not-knock logging, incident reporting, panic button, route navigation, auto-advance, and pair canvasser proximity.

Sync runs continuously and opportunistically once started. The canvasser does not trigger sync; it just happens. Push order prioritizes safety events, incident reports, do-not-knock flags, then door events, GPS, and media.

Every captured event has a client-generated UUID and is fully idempotent. The backend deduplicates on UUID. The same event can be pushed multiple times without producing duplicates.

(Detailed offline architecture is described in Section 13.)

7. Polling Engine Integration

7.1 Canvassing as a Fielding Mode

Field Canvassing is a fielding mode for the Polling Engine. Canvasser-administered polls are full Polling Engine polls — same Methodology Agent, same four-dimensional scoring, same Fielding Scorecard, same Strategic Analyst output, same Aggregate Intelligence telemetry.

The Polling Engine’s FieldingService extends to handle canvas fielding. Tokenized respondent linkage at fielding time still applies — except the token is bound to the canvasser’s session at the door, not delivered as an SMS link.

7.2 Three Distinct Door Interactions

At any given door, three interaction types are available, and they are stackable rather than exclusive:

Interaction	What It Is	Where It Lives
Outcome logging	Canvasser records what happened: campaign-type outcome enum with Capture Mode	Native to Field Canvassing
Free-form notes	Canvasser captures observations: Community / System / custom fields with field-level Capture Mode	Native to Field Canvassing
Structured polling	Canvasser administers a Polling Engine instrument: methodologically validated questionnaire, full four-dimensional scoring	Polling Engine, fielded via canvass

A single door visit can produce all three: an outcome, free-form notes, and a fielded poll response. They are stored as distinct artifacts on the UVP — the Door Visit Event references the polling response — both linked to the same UVP and same shift.

7.3 Methodology Agent Awareness of Canvas Mode

The Methodology Agent gains canvas-mode awareness during questionnaire generation. A poll fielded by canvass has different methodological constraints than a poll fielded by SMS:

Question length budget — canvasser delivery time at the door is short; questions must be readable in seconds
Branching depth — canvasser cognitive load at the door is high; deep branching is impractical
Voice register — conversational, not formal; the canvasser reads it aloud
Scriptability — natural sentence flow; the canvasser must be able to deliver it without sounding scripted

When the user opts to field a canvass poll, the Methodology Agent generates the instrument under these constraints. The agent’s behavioral standard (consultant-grade pushback) applies. If a user wants to field a 40-question poll by canvass, the agent declines and explains why, offering an alternative path.

7.4 Token Architecture for Canvas Fielding

Tokens for canvas-fielded polls are batch-issued at pre-shift sync, scoped tightly:

Bound to (canvasser, walk list, door)
Expire on shift end
Stored in the offline cache for use without network

When the canvasser administers the poll at the door, the response is captured against the pre-issued token. If the canvasser administers a poll at a door that wasn’t on their assigned list (rare — e.g., door added mid-shift via walk list edit), the response is captured locally with a deferred-token marker; the token is issued at sync time and the response is reconciled.

This batch-issuance pattern is distinct from the just-in-time issuance used for SMS fielding. The Polling Engine’s FieldingService supports both modes.

7.5 Polling Fidelity as a CPP Dimension

The Canvasser Performance Profile includes Polling Fidelity as a scoring dimension. This measures:

Completion rate of administered polls (canvasser launches the instrument and completes it vs. abandons mid-poll)
Branch logic adherence (canvasser follows the questionnaire flow vs. skips or volunteers answers)
Response distribution patterns (canvasser-collected response distributions vs. SMS-collected response distributions on comparable polls — large divergences flag for review)

Polling Fidelity feeds Sentiment Capture Reliability calibration: a canvasser with high Polling Fidelity who tags a voter “Supportive” in free-form notes has high credibility on that tag; a canvasser with low Polling Fidelity does not.

7.6 Strategic Analyst Output

When a walk list reaches Complete state, the Strategic Analyst runs on the captured data. The walk list transitions to Analyzed state when the analyst’s output is ready.

Strategic Analyst outputs from a canvas walk list include:

Strategic memo with classifications, latent state tags, segments, lane assignments, and AI-drafted messaging content (per Polling Engine memo structure — the format is shared)
Heavy-Prescription Next Moves (per Section 8)
Methodology abstract attached to the memo
Override / credibility flags if the walk list had user overrides during creation
Cross-feature observations: how the canvas data complements polling data captured on the same UVPs

For walk lists that included a polling instrument, the Strategic Analyst integrates the polling output with the canvas-specific data. A voter who responded to the door-administered poll AND was tagged in free-form notes provides richer signal than either alone, and the memo treats them accordingly.

8. Heavy-Prescription Walk List Next Moves

Substrate note: The Heavy-Prescription Next Moves contract — including the unified Strategic Next Moves queue that aggregates Walk List Next Moves, Call List Next Moves (from Phone Banking), and Follow-Up Poll Next Moves (from the Polling Engine) at the Campaign level — is substrate-defined. The Walk List Next Move type below is Field Canvassing’s channel-specific implementation of the substrate Next Moves contract.

8.1 Walk Lists as a Next Move Type

Heavy-Prescription Walk Lists are first-class Next Move types alongside Heavy-Prescription Polls (per Polling Engine spec). The Strategic Analyst can autonomously generate them following analysis of any poll or canvas.

A Heavy-Prescription Walk List is a complete, fielding-ready follow-up canvas campaign — not a recommendation. It contains:

Target segment (derived from the source poll’s classification migrations or latent state findings)
Walk list (fully generated, optimized, geofenced, ready to assign)
Script (drafted by AI, lane-tagged, voiced for canvasser delivery)
Optional structured polling instrument (a follow-up poll the canvasser administers at the door, fully drafted by the Methodology Agent in headless mode)
Custom note schema (manager-defined fields the canvasser captures)
Suggested team size and time budget (derived from territory difficulty and canvasser CPP estimates)
Cost estimate (volunteer-hours estimate, paid-canvasser cost if applicable)
Strategic rationale (why this canvas move follows from the source’s findings)

User actions: Accept and assign (one click), Modify and assign, Save for later, or Dismiss.

8.2 Methodology Agent Headless Mode

The Methodology Agent’s headless mode (established in the Polling Engine spec for autonomous follow-up poll generation) extends to canvas artifact generation.

In headless mode, the agent:

Selects the target segment based on source’s strategic findings
Generates an optimized walk list against the target segment
Drafts a canvas script with per-element rationale, voiced for the canvas-mode constraints in Section 7.3
(Optionally) generates a follow-up polling instrument under canvas-mode constraints
Produces the methodology abstract
Assigns lane tags to script elements
Produces the strategic rationale

The agent operates without a user in the loop. The output is fully formed; the user reviews and accepts, modifies, or dismisses.

8.3 Cross-Feature Next Move Surfaces

The Polling Engine’s Next Moves tab surfaces a mix of follow-up polls AND follow-up canvasses. Field Canvassing’s analogous tab surfaces a mix of follow-up canvasses AND follow-up polls (the inverse — a canvas might recommend a poll as the next move when sentiment data needs broader sampling).

Eventually this becomes a unified Strategic Next Moves queue at the campaign level — every poll and canvas feeds it, every Next Move is a queryable entity, the user works through them in priority order. This unified queue is substrate-defined and accepts Walk List Next Moves (Field Canvassing), Call List Next Moves (Phone Banking), and Follow-Up Poll Next Moves (Polling Engine) as the three V1 Next Move types.

8.4 The Closed-Loop Intelligence Flow

The strategic flow Field Canvassing enables:

Poll reveals Persuadable-Property-Tax segment in Precinct 12 → Strategic Analyst generates Heavy-Prescription Walk List Next Move → Manager accepts, assigns to canvasser team → Canvas produces sentiment data, observation tags, optional structured polling responses → Data flows into UVP, classification migration events, Aggregate Intelligence → Strategic Analyst generates the next Next Move (could be another canvas, could be a follow-up poll, could be a targeted SMS push)

This is the closed-loop learning system the Polling Engine spec described as V2. Field Canvassing’s V1 brings it forward by being the highest-yield input into that loop.

9. The Canvasser Performance Profile (CPP)

Substrate note: The Volunteer Worker Performance Profile (VWPP) framework, including the requirement that every channel populate four substrate-defined shared dimensions (Data Quality, Sentiment Capture Reliability, Polling Fidelity, Channel-Specific Quality) plus channel-specific dimensions, is substrate-defined. The CPP below is Field Canvassing’s channel-specific implementation of the substrate VWPP framework — naming the substrate-shared dimensions explicitly and adding three Canvasser-specific dimensions on top.

9.1 What the CPP Is

The Canvasser Performance Profile is the Field Canvassing channel implementation of the substrate’s VWPP framework. It is a Politogy-IP scoring layer attached to every Canvasser specialization of the substrate Volunteer Worker entity. It accumulates continuously across all door visits, all campaigns, all accounts the canvasser works for — and where the canvasser has also worked Phone Banking Sessions, the same Volunteer Worker carries a Caller specialization with its own channel-specific dimensions on the same unified profile.

The four substrate-defined shared dimensions (Data Quality, Sentiment Capture Reliability, Polling Fidelity, Channel-Specific Quality) accumulate across all channels the Volunteer Worker has worked. The three Canvasser-specific dimensions (Response Rate, Geographic Coverage Efficiency, Safety Discipline) accumulate only on Field Canvassing evidence.

This is structurally parallel to the Polling Engine’s four-dimensional respondent scoring: a measurable instrument scored on multiple dimensions, exposed to customers in tiered fashion, and used internally to calibrate Aggregate Intelligence.

9.2 CPP Dimensions

The CPP contains seven dimensions: four substrate-defined shared dimensions and three Field-Canvassing-specific dimensions.

Substrate-defined shared dimensions (every channel’s VWPP must populate these; they are directly comparable across phone, door, and future channels):

Dimension	Substrate Slot	What It Measures
Door Quality Score	Channel-Specific Quality (substrate-named slot; Field Canvassing names it Door Quality)	Average completion depth per door — capture rate of full notes, complete poll administration, custom field fill rate, vs. minimal-effort outcomes
Data Quality Score	Substrate-shared	Internal consistency of captured data, divergence from cross-canvasser patterns, free-text richness, frequency of “default” outcome selection without engagement
Sentiment Capture Reliability	Substrate-shared	Calibration backbone. When this canvasser tags a voter “Supportive,” how often does that voter actually behave as Supportive in subsequent polls / elections / cross-canvasser contacts?
Polling Fidelity	Substrate-shared	When administering Polling Engine instruments at the door: completion rate, branch logic adherence, response distribution patterns vs. SMS-fielded comparable polls

Field-Canvassing-specific dimensions (these accumulate only on canvassing evidence; they are not comparable to Phone Banking’s channel-specific dimensions):

Dimension	What It Measures
Response Rate	Percentage of doors knocked that produced a meaningful interaction (any outcome other than Not Home / Refused / Unable to Contact)
Geographic Coverage Efficiency	Doors per hour adjusted for territory difficulty (elevation, density, walking distance)
Safety Discipline	Adherence to do-not-knock flags, geofence boundaries, check-in protocols, panic-button false-positive rate, safety flag accuracy (corroborated vs. uncorroborated flags)

The Caller specialization (Phone Banking) adds its own channel-specific dimensions (Connect Rate, Compliance Discipline) plus the same four substrate-shared dimensions, with Call Quality as its Channel-Specific Quality slot. Substrate-shared dimensions accumulate evidence from both channels on a Volunteer Worker who has worked both.

9.3 CPP Calibration

Sentiment Capture Reliability is the calibration backbone of the entire CPP system and one of the highest-value training signals in the Aggregate Intelligence layer.

Calibration works longitudinally. Every time a voter the canvasser tagged “Supportive” in free-form notes:

Responds to a Polling Engine poll (any fielding mode)
Votes (per state file)
Is contacted by a different canvasser with a different outcome
Donates / volunteers / takes some action consistent or inconsistent with the tag

That outcome is signal. Over hundreds of doors, the system learns whether this canvasser’s “Supportive” really means Hard Support, Soft Support, or wishful thinking.

This is the closest thing to ground truth Politogy will ever capture on a canvasser. Other dimensions can be measured operationally; Sentiment Capture Reliability requires longitudinal cross-validation.

9.4 Tier-Gated CPP Exposure

Per Section 4.2:

Free / Basic: Aggregate volunteer stats only (doors knocked, hours worked, contact rate). No CPP scoring exposed.
Premium: CPP scores exposed on canvassers within the customer’s account. Door Quality, Response Rate, Data Quality, Sentiment Capture Reliability, Polling Fidelity, Geographic Coverage Efficiency, Safety Discipline. Enables rebalancing assignments, identifying training needs, recognizing high performers.
Enterprise: Cross-account canvasser intelligence — aggregated, anonymized scoring across the platform. Benchmarking, predictive canvasser-effectiveness modeling, portable canvasser scoring for hiring decisions.

Customers cannot configure how canvassers are scored. The CPP scoring model is Politogy IP, calibrated cross-account, non-negotiable.

9.5 The Canvasser as Portable Asset

A canvasser working for Account A in 2026 and Account B in 2028 is the same Canvasser entity with one continuous CPP across both accounts. This is intentional and commercially significant.

Customers in V1 see only their slice — Account A sees the canvasser’s performance on Account A’s campaigns; Account B sees Account B’s slice.
Enterprise customers see aggregated cross-account scoring — a national-level customer can query “this canvasser’s overall reliability score across the platform” without seeing specific account-by-account breakdowns.
Politogy retains full visibility regardless.
A future canvasser-effectiveness data product is possible: campaigns hiring field staff in 2028 paying Politogy for canvasser-effectiveness data the way they pay for voter propensity data.

9.6 V2: Canvasser Opt-Out

Cross-account CPP accumulation is V1 default behavior. V2 adds canvasser-side consent and visibility controls:

Canvasser can opt out of cross-account scoring (with implications: Enterprise customers no longer see their aggregated profile)
Canvasser can view their own CPP (transparency feature)
Canvasser can dispute specific scoring decisions (with structured workflow)

These features are flagged for legal review. Labor-law implications around scoring workers across multiple employers may apply in some jurisdictions.

10. Capture Mode and Intelligence Routing

Substrate note: The Capture Mode taxonomy (Self-Report / Observation / Verified) is substrate-defined and applies across all VRM Voter Contact channels. Field Canvassing surfaces all three modes in the field; Phone Banking surfaces Self-Report and Verified commonly, with Observation rare due to the absence of visual context. Capture Mode application in Field Canvassing is described below.

10.1 The Capture Mode Taxonomy

Every captured intelligence point at a door carries a Capture Mode field with three values:

Capture Mode	Meaning
Self-Report	The voter directly stated this. (E.g., voter said “I’m voting for Ben.“)
Observation	The canvasser inferred this from the conversation, body language, environment. (E.g., canvasser tagged “Hostile” because voter slammed the door.)
Verified	Self-report that the canvasser cross-confirmed in conversation. (E.g., voter said yes, canvasser asked “so we can count on your vote?”, voter said yes again.)

Capture Mode applies to:

Outcome logging (the outcome enum carries a Capture Mode)
Free-form notes (each note tagged at the field level)
Polling Engine responses fielded by canvas (every response carries a Capture Mode)

10.2 Why Capture Mode Matters

Capture Mode separates two distinct uncertainties:

The voter’s confidence in their position is captured by the Polling Engine’s Confidence dimension. This measures how certain the voter is about what they think.

The system’s confidence in whether the captured value reflects the voter’s actual position is captured by Capture Mode. This measures the reliability of the data path from voter through canvasser to UVP.

These are different uncertainties. Modeling them separately lets Sentiment Capture Reliability calibration work properly — the system can learn that Canvasser X’s Self-Reports are 94% accurate while their Observations are 67% accurate, and weight each accordingly when feeding Aggregate Intelligence.

10.3 Intelligence Routing by Capture Mode

Captured intelligence flows into Aggregate Intelligence with weighting based on Capture Mode:

Verified data — highest weight. Gold-standard training signal. Voter said it, canvasser cross-confirmed it.
Self-Report data — high weight, modulated by canvasser Sentiment Capture Reliability.
Observation data — lower weight, modulated by canvasser Sentiment Capture Reliability calibrated on observations specifically.

Sentiment Capture Reliability is computed separately for Self-Report and Observation. A canvasser may be highly reliable on Self-Report (accurate transcription of what voters tell them) but less reliable on Observation (over-interpreting context). The weighting respects that distinction.

10.4 Customer-Tier vs. Politogy-Tier Use

At the customer tier, Capture Mode is visible on each captured value. Customers can filter their own data by Capture Mode — e.g., “show me all Verified Supportive tags in Precinct 12.” This is operational utility.

At the Politogy tier, Capture Mode drives training-signal weighting in the Aggregate Intelligence pipeline. The weighting algorithm itself is Politogy IP and not exposed.

11. Reporting, Analytics, and Strategic Memo

11.1 Operational Reporting (Customer-Tier)

Operational reporting answers the question “what is happening in my canvas operation right now and what has happened?” These reports are available at all tiers.

Live progress (during Live state):

Doors knocked / total assigned (overall and per canvasser)
Outcome distribution running tally
Coverage map: completed doors, in-progress, not yet visited
Canvasser locations (if continuous GPS consented)
Pace: doors per hour, projected completion time
Anomaly indicators: canvasser falling behind pace, unusual outcome distributions, sync delays

Walk list summary (Complete state):

Total doors knocked / contact rate / outcome distribution
Coverage percentage
Volunteer stats: doors per hour by canvasser, total hours, distance walked
Average door visit duration
Polling response rate (if instrument fielded)

Rolling reports (any time):

Cross-walk-list summary across the campaign
Precinct-level coverage and contact rates
Volunteer leaderboard (configurable visibility)
Outcome trend over time

11.2 Strategic Memo (Walk List Analyzed State)

When a walk list reaches Analyzed state, the Strategic Analyst produces a Strategic Memo following the Polling Engine memo structure (the format is shared across features). For canvas walk lists, the memo includes:

Methodology summary

Target population and segmentation rules
Geographic scope and sample
Optimization function used
Script and instrument
Override / credibility flags if applicable

Findings

Outcome distribution (campaign-type specific)
Sentiment extraction summary from free-form notes (Premium+: with underlying scores)
Polling response analysis if instrument was fielded (full Polling Engine memo treatment)
Classification migrations observed on UVPs (which voters moved between Hard Support / Soft Support / Persuadable / Opposed)
Latent state tags and notable patterns
Capture Mode distribution and weighted findings

Segmentation

Auto-generated segments based on captured data
Lane assignments per segment
Segment-level Capture Mode reliability indicators

Strategic narrative

AI-drafted interpretive narrative tying findings to campaign strategy
Notable canvasser observations (Community Notes that surfaced patterns)
Cross-canvasser convergence patterns (multiple canvassers tagging similar patterns)
Anomalies flagged for manager review

Heavy-Prescription Next Moves

Fully-specified follow-up walk lists (Section 8)
Fully-specified follow-up polls (Polling Engine pattern)
Cross-channel recommendations: when SMS / email / phone bank Next Moves are appropriate

Methodology abstract (attached for longitudinal defense)

11.3 Aggregate Intelligence Reporting (Premium / Enterprise)

Higher-tier reporting exposes Aggregate Intelligence-derived insights:

Premium:

CPP-driven canvasser performance reporting
Sentiment extraction with underlying scores on own captured notes
Optimization Intelligence applied to own data: best shift windows, best territory types, most effective scripts within own account

Enterprise:

Cross-account contactability benchmarks: “doors in this profile have X% contact rate across the platform; your account is at Y%”
Cross-account script effectiveness benchmarks
Predicted contactability scoring on individual doors at walk list generation
Walk list methodology benchmarks: “walk lists with this profile produce Z% higher Sentiment Capture Reliability across accounts”
Territory risk scoring (cross-account safety intelligence-driven)

11.4 Unified GOTV Analytics (Cross-Feature)

Field Canvassing produces contact data that contributes to a unified contact view per UVP and per geographic unit. This view is not owned by Field Canvassing — it lives in a Reporting Service layer above all Campaign Mode features.

The unified view includes:

Contact attempts (any channel: canvas, phone, SMS, email)
Contact successes (any channel)
Outcome distribution (cross-channel)
Coverage % (any channel) per precinct, district, segment
Channel mix (precinct heatmaps showing which channels touched which voters)

Phone bank data flows into the same unified view via the Cross-Channel Contact Ledger and the substrate’s unified reporting contract. The Reporting Service accepts multiple Campaign Mode contact channels.

For this spec: Field Canvassing produces the data. The Reporting Service surfacing the unified view is owned by a future analytics specification.

11.5 Voter Trajectory View

The Polling Engine spec established Voter Trajectory View as the V1 user-facing surface for longitudinal voter intelligence. Field Canvassing extends this surface.

For any UVP, the trajectory view shows:

All polling responses and scores over time (Polling Engine)
All canvas door visits with outcomes, Capture Mode, notes (Field Canvassing)
All contact log entries across channels
Classification migrations and timing
Score evolution over time per issue per dimension

A voter who’s been canvassed three times, polled twice, and texted once has a rich trajectory. The trajectory view shows it integrated. Conflicting captures coexist with full context (the Polling Engine spec’s “preserve all, do not average” principle applies).

11.6 Canvasser-Facing Reporting

Canvassers see limited reporting in the mobile app:

Their own shift summary at end of shift
Their own historical totals (doors knocked, hours, contact rate)
(V2) Their own CPP if opt-in transparency feature is enabled

They do not see other canvassers’ performance, full walk list-level reporting, or strategic memos. These are manager-tier surfaces.

Canvassing is one of the few political activities where physical safety is genuinely on the line. Field Canvassing treats compliance, safety, and consent as foundational architecture rather than a footer. The infrastructure described in this section ships V1.

12.1 Cross-Account Unsafe-Property Intelligence

When a canvasser flags a property as unsafe, the flag accumulates at the Politogy tier on the property’s record (linked to the UVP and the geocoded address). The flag carries:

Severity tier (Caution / Warning / Do Not Approach)
Reason category (aggressive resident, dog off-leash, threatening signage, weapons displayed, verbal/physical threat, other)
Free-text observation (Politogy-tier only)
Canvasser ID, timestamp, GPS verification
Capture Mode (almost always Observation)

When any canvasser from any account is generating or executing a walk list that includes that property, the system surfaces the warning. Severity tier determines treatment per Section 6.6.

IP boundary preservation:

Canvassers see aggregated reason categories, not raw cross-account observations
Free-text observations stay at Politogy tier
Customer-facing reporting shows only the customer’s own canvassers’ safety flags
The exception is justified by safety — canvasser physical safety is a categorical exception to data isolation, made explicit in this spec

Aggregate Intelligence implications:

Unsafe-property data feeds Aggregate Intelligence as a high-value safety signal
Patterns emerge: neighborhoods with elevated incident rates, time-of-day risk profiles, household-type risk associations
This becomes Optimization Intelligence input (routes auto-deprioritize high-incident windows), canvasser briefing data (pre-shift safety summary based on territory profile), and Premium/Enterprise products (territory risk scoring)

12.2 False-Flag and Bias Mitigation

Canvassers may flag properties based on bias rather than genuine threat. Three-layer mitigation:

Severity gradient. Most flags will be Caution, which surfaces information without excluding the door. Do Not Approach (full exclusion) requires structured justification.

Politogy-tier moderation. All Do Not Approach flags route to a Politogy review queue for manual review. Patterns of over-flagging by individual canvassers feed the CPP Safety Discipline dimension.

Decay. Flags carry timestamps and decay in salience over time absent corroboration. A single 2024 flag with no further reports by 2027 surfaces as low-priority Caution; multiple flags within 90 days reinforce severity.

V1 ships manual Politogy moderation. AI-assisted moderation is V2.

12.3 Do-Not-Knock Enforcement

Do-not-knock enforcement is layered (belt-and-suspenders):

At walk list generation time — flagged addresses excluded from the list before optimization runs
At assignment time — second pass before list dispatched to canvassers
At door display time — mobile app re-checks flag status when door card loads (handles flags added after walk list generation, including offline-resolved updates that arrive on next sync)

Sources of do-not-knock flags:

Voter file (where states maintain such registries)
Customer-set flags (campaign-specific exclusions)
Voter-requested flags (set by canvasser during door visit when voter requests no further contact)
Political party list management (where applicable)
Cross-account “Do Not Approach” safety flags

Voter-requested flags propagate to the UVP and are enforced across all accounts going forward. This is cross-account propagation in service of the voter’s expressed wishes — it’s writing to the UVP, which is Politogy’s record. Customers honor it.

12.4 Canvasser Safety Workflow

Shift check-in / check-out:

Canvasser starts shift via mobile app (sets origin, expected duration, assigned territory)
Canvasser ends shift via app (confirms safe completion)
If no check-out within expected window plus grace period, system escalates: notification to manager → escalation contact → emergency escalation per campaign policy

Periodic check-in (during shift):

Configurable per campaign (e.g., every 60 minutes during shift)
Non-disruptive prompt; tap to confirm safe
Missed check-in escalation parallel to missed check-out

Panic / safety button:

Persistent on every screen during shift
One tap silently flags shift as in-distress, alerts manager and configured escalation contact, shares last known GPS, captures any audio context (V2)
Operates as a hot path: uses every available channel (cellular data, WiFi, SMS fallback to manager’s number), retries continuously until transmission confirmed
Visual indicator on canvasser’s screen confirms whether escalation has been transmitted
V1 covers manager + designated emergency contact; V2 expands to local emergency services integration where legally and practically feasible

Geofence boundary alerts:

If canvasser strays outside assigned territory by more than a brief threshold, mobile app prompts (“You appear to have left your assigned area — confirm or return to territory”)
Pattern of repeated boundary violations flags for manager review and feeds CPP Safety Discipline

Pair canvassing support:

Canvasses can be assigned in pairs at manager’s discretion
Mobile app coordinates pair routing (paired canvassers’ lists synchronized for proximity)
Pair check-ins covered jointly
Operationally important in higher-risk territories; V1 ships the assignment and routing support

12.5 GPS / Tracking Modes

Three modes, customer-configurable per campaign:

Mode	Behavior
Off	No GPS captured. Walk list generation uses geocoded addresses only. Canvasser reports outcomes without location verification.
Verification only (V1 default)	GPS captured at door visit confirmation, used to verify canvasser was actually at the door. Not stored as continuous trail.
Continuous	GPS captured as track during shift (per consent). Used for live oversight, post-canvas analysis, safety monitoring.

Default V1 is Verification only. Strikes the balance between data integrity and privacy. Continuous tracking is an explicit opt-in escalation by both canvasser (consent) and manager (campaign configuration).

Consent Type	V1 Requirement
GPS tracking consent	Explicit opt-in per canvasser, granular by mode, revocable at any time, historical data purged on revocation with audit trail
Voter media consent (V2 capture, V1 architecture)	Per-state consent regime mapping (one-party vs. two-party) wired in V1 even without capture surface
Canvasser identity disclosure	Canvassers carry digital ID through mobile app, field-displayable on demand (required for some jurisdictions)
Recording disclosure (V2)	Two-party consent enforcement with voter signature/tap-confirmation flow when audio capture ships

GPS consent shapes everything downstream — assignment, safety, oversight. Voter media consent architecture is V1 even though the capture surface is V2 because the consent regime mapping informs the data model and the future capture surface depends on it being right from the start.

12.7 Per-State Compliance Engine

V1 includes a compliance engine that maps customer geography to applicable rules and constrains walk list generation accordingly:

Per-state political activity rules (canvassing hours, signage, do-not-disturb registries)
HOA / private property restrictions (database of restricted territories maintained by Politogy, fed by customer reports and public records)
Campaign finance reportability (canvasser hours, expenses, assignments captured for FEC / state ethics commission reporting; V2 ships reportability features)

Audit trail: every door visit, every consent capture, every safety flag, every override is auditable end-to-end, retained per retention policy.

12.8 Incident Reporting

Canvasser injuries, property damage claims, voter complaints, and other incidents are captured through a structured incident reporting workflow. V1 ships the workflow:

Canvasser logs incident through app (offline-capable)
Manager notified via push and dashboard
Structured record created: incident type, description, parties involved, GPS, timestamp, media (V2)
Record available for downstream legal / insurance use

Insurance integration is out of scope for V1. The incident record is the foundation; integrations build on it later.

12.9 Labor-Law Considerations (Flagged)

Canvassers are typically volunteers or W-9 contractors. CPP scoring and cross-account data sharing have potential FLSA and state labor-law implications, particularly:

Cross-account scoring of workers across multiple employers
Performance scoring that influences hiring / assignment decisions
Data captured about volunteers vs. paid canvassers (different rules apply)

These implications are flagged for legal review prior to V1 launch. V2 introduces canvasser opt-out and visibility controls partially in response.

13. Offline Architecture

Canvassing is offline-first, not offline-capable. The entire field operation is designed to work end-to-end without network. This section defines the principles. Detailed mobile implementation lives in a separate Mobile App Architecture document.

13.1 The Three-Phase Sync Model

Pre-shift sync (mandatory) → Offline-resilient shift → Post-shift sync (continuous and opportunistic)

This three-phase model is load-bearing for the architecture. Pre-shift sync establishes integrity for the shift. The shift operates offline. Post-shift sync flushes the queue and triggers downstream processing.

13.2 The Canvassing Cache

The mobile app caches a canvassing-specific UVP subset, not the full UVP. The cache is sized for the assigned route plus reasonable buffer (~50% headroom for mid-shift territory expansion).

Per assigned door, the cache contains:

Identity Core (display name, party, registration status)
Contact Info (address, residential details)
Geographic (precinct, district indicators relevant to script)
Vote History (summary indicator only, not full ballot history)
Relationship Data (script-relevant tags, prior canvas outcomes from this account)
Campaign Data (last contact date and outcome from this account)
Aggregate Intelligence (tier-appropriate exposed values only)

Not cached: cross-account data, full enrichment, full longitudinal score evolution, other canvassers’ captured data on the same voter.

13.3 Pre-Shift Sync (Mandatory)

When the canvasser starts a shift:

App requires connectivity to proceed
App pulls the latest cache: walk list version, script version, polling instrument version (with batch-issued tokens), do-not-knock flags, unsafe-property warnings, custom note schema, map tiles for assigned territory + buffer
App requests GPS consent if not already on file
App captures shift origin location
Shift transitions to Active

Pre-shift sync is the moment the system enforces:

Most recent do-not-knock flags
Most recent safety warnings (cross-account)
Most recent assignment changes
Latest version of the script
Latest version of any structured polling instrument
Tokens for canvas-fielded polls

If pre-shift sync fails, the shift cannot start. The app displays a clear message: “You need to connect to start your shift. Your assignment will load when you’re online.” This is non-negotiable architecture.

13.4 Offline-Resilient Shift

Once the shift has started, the entire field operation runs offline:

Door card display
Outcome logging (campaign-type-appropriate enums)
Capture Mode tagging
Free-form note capture (Community / System / custom)
Polling Engine instrument administration (full questionnaire, branching, response capture)
Photo capture (V2)
Audio capture (V2)
GPS capture (continuous if consented, even without network)
Safety flagging
Voter-requested do-not-knock logging
Incident reporting
Panic / safety button (special handling per Section 13.7)
Route navigation (cached map tiles)
Auto-advance to next door
Pair canvasser proximity (cached last-known positions)

Only the strategic intelligence layer — Strategic Analyst output, longitudinal queries, Aggregate Intelligence-derived insights — requires connectivity. None of these run during canvassing; they run after.

13.5 Post-Shift Sync (Continuous and Opportunistic)

Sync runs continuously and opportunistically once the shift has started. The canvasser does not trigger sync; it just happens whenever connectivity is available.

Push priority order:

Panic / safety events (if any pending)
Incident reports
Do-not-knock flags (voter-requested)
Door visit events (outcomes, notes, polling responses)
GPS traces
Media (V2 — photos, audio)

Higher-priority items push first so the most safety-critical and operationally important data reaches the backend even if connectivity is intermittent.

13.6 Idempotency and Conflict Resolution

Every captured event has a client-generated UUID and is fully idempotent. The same event can be pushed multiple times (e.g., partial network failure causing a retry) without producing duplicates. The backend deduplicates on UUID.

Conflict scenarios:

Scenario	Policy
Two canvassers log same door, same outcome	Both events preserved as separate Door Visit Events on the UVP. Aggregate Intelligence treats them as corroborating evidence.
Two canvassers log same door, conflicting outcomes	Both events preserved. Most recent timestamp is the displayed default for customer view. Voter Trajectory View shows both with full context.
Same canvasser logs same door twice (e.g., re-knock)	Both events preserved as separate door visits. Sequence is part of the canvasser’s interaction history with the voter.
Two canvassers from different accounts log same door	Each account sees only its own canvasser’s event. Politogy sees both, uses convergence/divergence for Aggregate Intelligence calibration.

Principle: never delete captured field data. Every Door Visit Event is preserved in full, immutable. Conflicting captures coexist; the Strategic Analyst and Aggregate Intelligence layer handle interpretation.

13.7 Panic / Safety Button — Hot Path

The panic button is the one operation where “sync later” is unacceptable. Architecture:

Records the panic event locally with timestamp, GPS, audio context (V2), shift state
Attempts immediate transmission via every available channel (cellular data, WiFi, SMS fallback to manager’s number)
If transmission fails, retries continuously in background until successful
Visual indicator on canvasser’s screen confirms whether escalation has been transmitted

V1 supports SMS-based panic escalation as a fallback channel — even without data, basic SMS often works. The canvasser doesn’t see the difference; the system uses whatever channel succeeds first.

13.8 Polling Engine Token Architecture Offline

Tokens for canvas-fielded polls are batch-issued at pre-shift sync, scoped to (canvasser, walk list, door), expiring at shift end. Stored in offline cache for use without network.

When the canvasser administers a poll at a door, the response is captured against the pre-issued token. If the canvasser administers a poll at an unassigned door (rare — e.g., door added mid-shift), the response is captured locally with a deferred-token marker; the token is issued at sync time and the response is reconciled.

The Methodology Agent does not run on the device. The questionnaire is locked at walk list generation time and shipped to cache as a frozen instrument. Mid-shift questionnaire updates do not propagate to active walk lists. New walk lists generated after the update use the new version.

13.9 Sync Failure Handling

If an event fails to push after extended retry (e.g., 7 days of failed sync), it remains in the device queue indefinitely. The mobile app surfaces a “Pending sync” indicator with count. There is no auto-purge of unsynced data.

Conservative by design. Field-captured data is too valuable to silently drop.

13.10 Sync-Triggered Downstream Processing

When data syncs to the backend, downstream pipelines fire (per Section 4.6). These run asynchronously on the backend, not blocking the canvasser’s sync. The canvasser sees their data as “synced” once it reaches the backend; downstream processing happens in the event stream.

13.11 What This Section Does Not Cover

Detailed mobile implementation is deferred to a separate Mobile App Architecture document:

Specific local storage technology (Realm, SQLite, async storage)
Map tile caching strategy and storage budget
Battery optimization
Background sync scheduling
Encryption-at-rest specifics
Push notification delivery and fallback channels
Cross-platform parity strategy (iOS / Android)
Security model for compromised devices
Cache invalidation logic
Bandwidth-adaptive sync (defer media on cellular, push on WiFi)

These are real engineering decisions but they are implementation details, not conceptual architecture.

14. Donor and Volunteer Canvassing Variants

Voter Canvassing is the primary product and the focus of this specification. Donor Canvassing and Volunteer Canvassing are deliberate variants that share the canvassing substrate (walk list generation, mobile app, assignment, GPS, offline sync, outcome logging, AI sentiment extraction on notes) but route their intelligence outputs to different destinations.

14.1 Shared Substrate

All three campaign types share, in V1:

Walk list generation, optimization, geofencing, elevation weighting
Assignment workflow, mobile app delivery, offline sync
GPS / safety / consent infrastructure
Free-form note capture (Community / System / custom fields)
Door Visit Event model and audit trail
Canvasser scoring (Door Quality, Response Rate, Data Quality, Sentiment Capture Reliability, Geographic Coverage Efficiency, Safety Discipline)
Compliance engine, cross-account safety intelligence

The same canvasser can work all three campaign types in the same shift if the manager assigns mixed-type territory. The CPP accumulates across all types.

14.2 Type-Specific Routing

	Voter (Primary)	Donor (Variant)	Volunteer (Variant)
Goal	Persuasion + GOTV intelligence	Pledge / contribution capture	Volunteer recruitment / commitment
Outcome enums	Supportive / Undecided / Opposed / Refused / Not Home / Do Not Knock / Unable to Contact	Pledged / Considering / Declined / Not Home / Already Donor	Signed Up / Interested / Declined / Not Home / Already Volunteer
Polling Engine integration	Yes — full instrument administration with four-dimensional scoring	No (V1) — donation conversation is not survey methodology	No (V1) — recruitment conversation is not survey methodology
Primary intelligence output	UVP scoring, classification migration, sentiment extraction, Aggregate Intelligence	Donor pipeline entity (commitment record, amount, cadence)	Volunteer roster entity (sign-up record, skills, availability)
Lane assignment	`mobilize.turnout`, `mobilize.activate`, `persuade.`, `reinforce.` (full taxonomy)	`mobilize.donate` (single lane)	`mobilize.activate` (single lane)
AI sentiment extraction	Full pipeline — feeds UVP, Aggregate Intelligence, score evolution	Lighter (V1) — flags fundraising-relevant signals (capacity, urgency, objections)	Lighter (V1) — flags recruitment signals (interest level, skills, availability)
CPP scoring inputs	Outcome accuracy, response rate, sentiment quality, polling response completeness	Pledge conversion rate, average commitment size	Sign-up conversion rate, retention of recruited volunteers

14.3 Donor Pipeline and Volunteer Roster Integration

The Donor Pipeline and Volunteer Roster are separate VRM features with their own forthcoming conceptual specifications. Field Canvassing defines the integration contract here; those specs will define their internal architecture.

Donor Pipeline integration contract:

Donor Canvassing produces commitment records: pledge amount, cadence, in-person captured signature (V2), follow-up plan
Records flow to the Donor Pipeline entity attached to the UVP
Pledged outcomes trigger Donor Pipeline downstream workflows (acknowledgement, fulfillment tracking)
Donor Pipeline owns the intelligence layer for donor data; this spec writes to it

Volunteer Roster integration contract:

Volunteer Canvassing produces sign-up records: skills, availability, role interests, contact preferences
Records flow to the Volunteer Roster entity attached to the UVP
Signed-Up outcomes trigger Volunteer Roster downstream workflows (welcome, role assignment)
Volunteer Roster owns the intelligence layer for volunteer data; this spec writes to it

14.4 V1 Scope

Voter Canvassing ships V1 with full functionality: walk list optimization, Polling Engine integration, AI sentiment extraction, canvasser scoring, Aggregate Intelligence telemetry, Heavy-Prescription Walk List Next Moves.

Donor and Volunteer Canvassing in V1 ship operational parity, intelligence parity deferred. Walk list generation, assignment, mobile app delivery, outcome logging, free-form notes, basic reporting all work for all three types in V1. Polling Engine integration, full sentiment extraction, and Aggregate Intelligence routing are voter-only in V1. Donor and volunteer get those treatments when the receiving entities (Donor Pipeline, Volunteer Roster) are spec’d and built.

This phasing parallels the Polling Engine spec’s pattern with Longitudinal Tracking: full data architecture in V1, surfaces phased.

15. Service Boundaries and Integration Points

15.1 Service Boundaries

The implementation should be organized around these services. Most are new; some extend existing Polling Engine services.

New services for Field Canvassing:

WalkListService — CRUD on walk lists, versions, methodology abstracts, state transitions
WalkListOptimizationService — TSP routing, elevation weighting, time-of-day weighting, geofence enforcement, do-not-knock and unsafe-property exclusion
CanvasserService — Canvasser entity management, account-scoped slice views, cross-account aggregation
CPPScoringService — CPP dimension computation, Sentiment Capture Reliability calibration, tier-gated exposure
DoorVisitEventService — Door Visit Event CRUD, idempotent intake, conflict resolution
AssignmentService — territory split, canvasser assignment, mobile app dispatch
CapMobileSyncService — pre-shift sync, opportunistic sync, push priority, idempotency
CapMobileCacheService — canvasing cache provisioning, cache invalidation
SafetyIntelligenceService — cross-account unsafe-property aggregation, severity computation, decay, moderation queue
ShiftLifecycleService — shift state, check-in / check-out, periodic check-in, panic events, escalation
ComplianceEngineService — per-state rule mapping, HOA / private property restriction enforcement, audit trail
IncidentReportingService — incident capture, manager notification, structured record management
CanvassFieldingService — token batch issuance, response collection coordination with Polling Engine FieldingService

Extended services from Polling Engine:

MethodologyAgentService — extended with canvass-mode questionnaire generation, canvass script generation, headless mode for Heavy-Prescription Walk List Next Moves
FieldingService — extended with canvas fielding mode, batch token issuance for canvas
StrategicAnalystService — extended to produce strategic memos for canvas walk lists, generate Heavy-Prescription Walk List Next Moves
VRMIntegrationService — extended to push canvas-derived segments and messaging into Campaign Mode workflows

All AI services share the common orchestration layer established in the Polling Engine spec: prompt construction, model version tracking, output validation, retry/fallback, Aggregate Intelligence telemetry.

15.2 Integration Points

With UVP / Foundational Data System:

Reads: Identity Core, Contact Info, Geographic, Vote History, Enrichment, Aggregate Intelligence (tier-gated)
Writes: Campaign Data layer (Door Visit Events), Relationship Data layer (voter-requested do-not-knock), Aggregate Intelligence (CPP inputs, Capture Mode-weighted training signal, sentiment extraction outputs, cross-account safety)

With Polling Engine:

Walk lists may include Polling Engine instruments
Tokens batch-issued via FieldingService for canvas fielding
Responses written via ResponseCollectionService through Polling Engine pipeline
Strategic Analyst produces canvas walk list memos using shared format
Heavy-Prescription Walk List Next Moves generated via Methodology Agent headless mode
Strategic Next Moves queue at campaign level surfaces canvas + poll Next Moves

With Phone Banking (peer channel of VRM Voter Contact substrate):

Shared Volunteer Worker entity (Canvasser specialization + Caller specialization on the same Worker)
Shared Cross-Channel Contact Ledger on UVP
Shared campaign type taxonomy
Shared lane taxonomy
Shared VWPP framework with four substrate-defined dimensions accumulating across both channels
Strategic Next Moves queue accepts both Walk List Next Moves and Call List Next Moves
Unified GOTV analytics layer accepts both feeds

With Donor Pipeline (forthcoming):

Donor Canvassing writes commitment records via integration contract
Pledged outcomes trigger Donor Pipeline workflows

With Volunteer Roster (forthcoming):

Volunteer Canvassing writes sign-up records via integration contract
Signed-Up outcomes trigger Volunteer Roster workflows

With Reporting Service (forthcoming):

Operational reports surface inside Field Canvassing
Cross-feature unified GOTV analytics surface inside the Reporting Service layer above Field Canvassing
Field Canvassing produces the contact data; Reporting Service aggregates across channels

With Inbox (forthcoming):

Walk list assignments delivered via Inbox to canvassers’ mobile apps
Notifications for shift start, missed check-in, panic events, manager alerts

With Maps API (third-party):

Mapbox / Google Maps or equivalent for routing, geocoding, terrain elevation
OSM / USGS for elevation tiles (alternative source)
Map tile caching for offline use

15.3 Data Ownership Summary

Entity	Owner	Notes
UVP	Politogy	Field Canvassing reads and writes per data system spec
Walk List	Customer (instrument); Politogy (optimization algorithm)	Customer owns work product; Politogy owns infrastructure
Canvasser	Politogy	Customer sees account slice; Politogy holds unified profile
CPP	Politogy	Tier-gated customer exposure
Door Visit Event	Customer (raw data); Politogy (Aggregate Intelligence routing)	Customer owns the captured data; Politogy uses it for cross-account intelligence
Polling Response (canvas-fielded)	Per Polling Engine spec	Customer owns instrument and raw responses; Politogy owns scoring model
Cross-account safety flags	Politogy (with structured customer-tier visibility)	Free-text observations stay at Politogy tier; structured aggregates flow to field
Strategic Memo	Customer (with Politogy audit trail)	Customer’s strategic asset; Politogy retains audit
Heavy-Prescription Walk List	Customer (post-acceptance)	Politogy generates; customer owns once accepted

16. V1 MVP Scope and V2 Roadmap

16.1 V1 MVP Headline

A campaign on Field Canvassing V1 can:

Create a canvas campaign by type (Voter / Donor / Volunteer)
Filter and sort raw lists from voter data using segmentation rules
Generate AI-optimized walk lists with elevation, time-of-day, and geofence-aware routing
Preview walk lists on interactive map with editable route and override capability
Configure canvass scripts (AI-drafted with rationale, user-editable)
Optionally include a Polling Engine instrument fielded at the door
Define custom note field schemas
Assign territory to canvassers via percentage split or manual territory selection
Dispatch assignments to mobile app
Canvassers conduct door-to-door fieldwork with offline-first reliability
Capture outcomes with Capture Mode tagging
Capture free-form notes (Community / System / custom) with field-level Capture Mode
Administer Polling Engine instruments at the door
Flag unsafe properties (cross-account aggregation) and respect cross-account safety warnings
Use panic / safety button with hot-path delivery
Operate fully offline once shift is started; sync continuously and opportunistically
Receive a strategic memo per walk list with classifications, latent state tags, segments, lane assignments, AI-drafted messaging content, and Heavy-Prescription Next Moves
Receive Heavy-Prescription Walk List Next Moves (fully-specified follow-up canvasses) following any poll or canvas analysis
View canvasser performance through CPP scoring (Premium tier+)
Push captured segments and messaging into Campaign Mode workflows
Build longitudinal voter intelligence — every door visit accumulating across walks on the Voter Trajectory View

Donor and Volunteer Canvassing V1 ship operational parity. Polling Engine integration, full sentiment extraction, and Aggregate Intelligence routing for these types arrive when their receiving entities (Donor Pipeline, Volunteer Roster) are spec’d.

Audio and photo capture are V2. Data architecture, consent regime mapping, and AI processing pipeline ship V1.

16.2 V2 Expansion

Audio and photo capture surface

Mobile app gains audio capture at the door with two-screen consent flow
Jurisdiction-aware consent enforcement (one-party vs. two-party state law)
Photo capture for property condition, signage, etc.
Auto-transcription on sync
AI sentiment extraction from transcripts (richer source material than free-form notes)
Polling response capture from audio (AI extracts structured responses for canvasser confirmation)

Advanced walk list optimization

Address density / cluster optimization
Weather-adaptive routing
Daylight constraints
Shift length / canvasser fatigue (CPP-personalized)
Multi-canvasser AI-balanced territory partitioning
Predicted contactability scoring (Aggregate Intelligence-driven, drop low-probability doors at generation)
Mid-shift re-routing

Canvasser-facing CPP transparency

Canvassers can view their own CPP
Cross-account scoring opt-out (with Enterprise-tier implications)
Dispute workflow for specific scoring decisions
Flagged for legal review prior to V2

Additional fielding modes (Field Canvassing scope expansion)

Event canvassing (rallies, town halls, county fairs)
Public-space canvassing (parking lots, pedestrian areas)
Same substrate, different optimization, different safety architecture

Closed-loop learning

Active learning from acceptance / rejection / outcome of Heavy-Prescription Walk List Next Moves
Cross-canvasser script effectiveness telemetry feeding script generation
Optimization Intelligence model improvement from observed canvas performance

Reporting expansion

AI-assisted moderation of Do Not Approach safety flags
Campaign finance reportability features
Insurance integration on incident reports
Cross-feature unified GOTV analytics surface (owned by Reporting Service spec when it arrives)

Cross-channel Phone Banking integration (Phone Banking ships V1 as peer channel)

Unified Volunteer Worker entity already consolidates Canvasser and Caller specializations from V1 per substrate
V2 adds cross-channel canvasser intelligence (worker effectiveness routing across channels)
V2 adds Strategic Analyst channel-recommendation logic (optimal channel per segment)
V2 adds cross-channel orchestration primitives (e.g., failed phone attempts auto-queue door knock in next canvas)

16.3 Deferred Items (Out of V1 and V2)

Insurance integration on incident reports beyond record creation
Predictive dialing-style optimization (does not apply to canvas; flagged as a Phone Banking concern)
Voter-side mobile app integration (canvassed voters opening app to confirm interactions)
International expansion (compliance regime varies dramatically; V1 + V2 are US-only)

17. Critical Architectural Principles

When making implementation decisions, return to these principles:

Every door is a fielding instrument, every canvasser is a measurable instrument. The product is not walk list logistics; it is distributed intelligence extraction. Every architectural decision should serve maximum structured value extraction from each interaction.
Capture Mode is foundational, not optional. Self-Report, Observation, and Verified are first-class field-level attributes. They distinguish what the voter said from what the canvasser inferred. Modeling them separately produces honestly weighted training signal.
Walk lists are methodology, not transient lists. First-class queryable longitudinal entities with explicit states, methodology abstracts, and version history. Walk lists are how a campaign defends “here is what we knocked, here is what we found” months or years later.
Canvasser scoring is calibrated longitudinally, not operationally. Sentiment Capture Reliability is the calibration backbone. Operational metrics (doors per hour, completion rate) are inputs; the product is honestly calibrated reliability scoring against ground truth.
Safety is architecture, not a feature. Cross-account unsafe-property warnings, mandatory pre-shift sync, panic-button hot-path delivery, pair canvassing, per-state compliance enforcement. Canvasser physical safety is a categorical exception to data isolation rules, made explicit.
Offline-first, not offline-capable. Pre-shift sync is mandatory; the entire field operation runs offline; sync runs opportunistically; conflict resolution preserves all field data. Field-captured data is too valuable to silently drop.
Polling Engine integration is tight at fielding, loose elsewhere. Canvas-fielded polls are full Polling Engine polls. The canvas-specific intelligence layer (CPP, Capture Mode, walk list optimization, safety) lives in Field Canvassing and is not subsumed.
The IP boundary is enforced at the data-write layer, not the UI. Tier-gated CPP exposure, customer-tier vs. Politogy-tier visibility, cross-account data isolation, and safety-exception data flow are enforced where data is written and queried.
Aggregate Intelligence is the moat. Every door visit, every Capture Mode tag, every CPP recalibration, every Next Move outcome feeds Politogy’s cross-account intelligence layer. This is the long-term commercial asset. Capture telemetry from V1 even where active learning is deferred.
The user always owns their canvas. Override mechanisms are always available, always friction-laden, always logged, always flagged on the memo. The user exercises judgment; the system’s defensibility record stays honest.
The substrate is the architectural contract, not the channel. Field Canvassing is one of two V1 channels of the VRM Voter Contact substrate. Substrate-defined entities, contracts, and primitives are honored uniformly; channel-specific concerns (walk lists, GPS, offline-first, physical safety) diverge from Phone Banking only where the operational reality demands it. Cross-channel features (Cross-Channel Contact Ledger, unified VWPP, unified Strategic Next Moves queue) are substrate-owned, not Field Canvassing-owned.
The product feels like a strategist, not a logistics tool. Every surface communicates strategic seriousness. The Methodology Agent’s pushback on canvas script and walk list decisions is a feature, not friction.

18. Developer Open Questions

The following are open questions for the development team. These are decisions that should be made during implementation planning rather than pre-decided in the conceptual spec.

18.1 Walk List Optimization

What is the V1 acceptable performance budget for walk list generation (e.g., <30 seconds for 500-door list)? Does the optimization run synchronously at user request or asynchronously with notification on completion?
For elevation data, OSM, USGS, or commercial provider (Mapbox terrain tiles)? What is the cost / accuracy / latency trade-off?
How is the elevation penalty parameter exposed to the user? Single slider (mild / moderate / aggressive)? Numerical threshold? Rule-based (“avoid grades above X%”)?
What is the V1 minimum walk list size below which optimization is bypassed (e.g., 20 doors)?

18.2 Canvasser Performance Profile

What is the warm-up threshold for CPP scoring? How many door visits before a Canvasser entity has a meaningful CPP?
How are CPP scores normalized across territories of vastly different difficulty? Is there a difficulty-adjusted score visible to the customer alongside the raw score?
What is the Sentiment Capture Reliability calibration window? Lifetime? Last 12 months? Issue-specific?
How does the CPP handle canvassers who only work for one account vs. canvassers who work across many? Is the cross-account aggregation explicit in the customer’s view (e.g., “based on N accounts”) or hidden?

18.3 Capture Mode

What is the default Capture Mode when the canvasser does not explicitly tag? Should the system require an explicit tap, or default based on outcome type?
How granular is Capture Mode within a single free-form note? Per-paragraph? Per-sentence? Note-level only?
Should Capture Mode be editable post-sync if the canvasser realizes they tagged incorrectly?

18.4 Cross-Account Safety

What is the V1 moderation SLA for Do Not Approach flag review? Same-day? Next-day? Per-tier?
How does flag decay work mathematically? Linear? Exponential? Reset on new corroboration?
Should canvassers see who flagged a property (anonymized “another canvasser”) or no source attribution at all?
How is the false-flag rate calibrated into CPP Safety Discipline? What threshold triggers manager / Politogy review?

18.5 Polling Engine Integration

When a walk list is in Live state and a manager wants to update the polling instrument, what is the user experience? Hard rejection (“you cannot edit a Live instrument”)? Soft warning (“changes will not propagate to active shifts”)?
For canvas-administered polls, what is the V1 maximum question count? Is this enforced by the Methodology Agent at canvas-mode generation time?
How are deferred-token responses (canvasser administered poll at unassigned door) reconciled? Auto-issue token? Manager review queue?

18.6 Mobile App Architecture

What is the storage budget for the canvasing cache per shift? Per assigned door target?
What is the cellular bandwidth budget for sync during shift? Should media (V2) defer to WiFi?
What is the device security model when a canvasser device is lost / compromised mid-shift? Remote wipe? Cache encryption-at-rest with periodic key rotation?
iOS and Android parity targets for V1 — features identical, or Android-first / iOS-first?

18.7 Next Moves

When the Strategic Analyst generates Heavy-Prescription Walk List Next Moves, who pays for the underlying compute (especially in headless Methodology Agent operation)? Per-customer billing? Tier-included?
How are Next Moves prioritized in the unified queue when polls and canvasses both produce them? Score-based? Time-based? User-configurable?
What is the V1 limit on how many Heavy-Prescription Next Moves can be generated per source poll / canvas?

18.8 Donor and Volunteer Variants

For Donor Canvassing, how is pledge amount captured at the door? Free numeric input? Bracketed selection ($25 / $50 / $100 / Other)?
For Volunteer Canvassing, what is the V1 set of skills / availability / role-interest fields? Standardized across accounts or per-account custom?
When the Donor Pipeline / Volunteer Roster specs ship, what is the migration path for Donor / Volunteer Canvassing data captured under V1 contracts?

18.9 Substrate Alignment and Phone Banking Cross-Channel

The Canvasser entity is now defined as a specialization of the substrate’s Volunteer Worker entity. What is the migration plan for any V1 Field Canvassing data captured before substrate alignment? Existing Canvasser records — do they need a Volunteer Worker entity backfill, or is the relationship inferred at runtime?
The Strategic Next Moves queue is now substrate-owned and accepts Walk List Next Moves, Call List Next Moves, and Follow-Up Poll Next Moves. What is the substrate-defined prioritization logic? Is it flat (one priority signal) or hierarchical (Next Move type → priority bucket → within-bucket ordering)?
Substrate-shared VWPP dimensions (Data Quality, Sentiment Capture Reliability, Polling Fidelity) need cross-channel calibration commitments. What does “Data Quality 0.85 on phone” mean relative to “Data Quality 0.85 on door”? Substrate flags this as an open question; Field Canvassing V1 needs to commit to its calibration outputs being substrate-comparable.

18.10 Compliance and Labor Law

Cross-account CPP scoring: legal review required prior to V1 launch on FLSA / state labor-law implications. What is the trigger date for that review?
Per-state canvassing rule database: who maintains it? Politogy internal team? Third-party compliance vendor? Customer-contributed with Politogy moderation?
HOA / private property restriction database: same question as above. Politogy-maintained, third-party, or customer-contributed?

18.11 Aggregate Intelligence

What is the V1 emission rate of Aggregate Intelligence events from canvas operations? Per Door Visit Event? Batched? Tiered?
Cross-account convergence detection (multiple canvassers tagging same voter consistently) — at what threshold does this fire as Aggregate Intelligence signal?
Optimization Intelligence model training cadence — continuous? Weekly? On-demand per customer?

End of Conceptual Specification.

This document defines how the Field Canvassing system thinks. Implementation decisions referenced in Section 18 are deferred to development team review. Companion specifications (Polling Engine, VRM Foundational Data System, Mobile App Architecture, Phone Banking, Donor Pipeline, Volunteer Roster, Reporting Service, Inbox) are referenced where integration points exist; their internal architecture is owned by their respective specs.

🗳️ Politogy VRM — V2 Specs

Explorer