🪧 Sign Mapping

Spec map

Home: All V2 Specs · Foundation: Data System (UVP) Mode(s): Campaign Mode, Petition Mode Related specs: Data System (UVP), Field Canvassing

🎯 Goals

Executive Summary

Track campaign sign assets geospatially while capturing supporter signal to the UVP from the same pin drop. Product Thesis
Replace spreadsheets and memory with a shared visual database that also preserves supporter intelligence across cycles. Mode Architecture
Confine Sign Mapping to Campaign Mode where district geofence and voter-roll matching exist. The Two-Tier IP Boundary
Tier sign asset data and supporter event data distinctly while anonymizing cross-account host history. The Continuous Lifecycle (SignPlacement)
Model each sign as a stateful, auditable entity whose lifecycle never invalidates the supporter signal. The SignPlacement Entity
Define the canonical asset-tracking entity that links to but stays separate from any supporter event. The Three Sign Types
Treat Yard, Field, and Billboard signs as operationally, analytically, and supporter-relationally distinct. Pin Drop Workflow (Mobile)
Provide a fast, forgiving, offline-safe pin drop that captures supporter signal invisibly server-side. Map Visualization (Manager & Mobile Views)
Render placements on a filterable district map with role-appropriate supporter and UVP detail. Analytics & Reporting
Produce operational, supporter-signal, strategic, and aggregate-intelligence outputs with tiered exposure. Recovery Workflow
Make post-election sign recovery a first-class routed workflow that preserves supporter events. Permissions
Scope placement, editing, deletion, export, and match-confirmation rights appropriately by role. Integration Points
Integrate with VRM geographic, supporter-layer, geocoding, voter-file, and aggregate-intelligence systems. AI & Aggregate Intelligence Hooks
Emit full event telemetry from V1 to feed supporter scoring and future AI capabilities. Critical Architectural Principles
Keep sign assets and supporter signals distinct, offline-first, frictionless, and anonymized at the write layer.

Module: Sign Mapping Mode: Campaign Mode (inherited by Petition Mode) Version: V1 Conceptual Spec — Rev 2 (Supporter Layer integration) Document Owner: Politogy LLC

1. Executive Summary

Sign Mapping is a geolocated asset-tracking module inside Campaign Mode that does two architecturally distinct jobs at once.

Job 1: Asset tracking. Field volunteers drop pins where they install campaign signs. Managers see, filter, and act on the resulting district-wide picture. Three sign types — Yard, Field, and Billboard — each with distinct visual treatment, lifecycle expectations, and analytical weight. Recovery is a first-class workflow.

Job 2: Supporter signal capture. When a yard or field sign is placed on a property where a voter is identifiable via GPS reverse-geocode and voter file match, the placement automatically writes a supporter event to that voter’s UVP via the Supporter Layer. This is high-value behavioral signal — a voter who hosts a sign is among the most reliable supporters a campaign has — and it must accumulate across cycles, modes, and features.

The two jobs share a data capture surface (the pin drop) but write to architecturally distinct destinations: the SignPlacement entity tree for asset tracking, and the UVP Supporter Layer for supporter signal. The pin drop is one volunteer action that produces two data writes.

At the Politogy tier, cross-account sign placement density is an Aggregate Intelligence input. Cross-cycle sign host history is a monetized Intelligence Product (see vrm-data-system Section 4.3). Both are anonymized at the campaign level to protect customer trust in the primary-competitive Republican ecosystem Politogy exclusively serves.

2. Product Thesis

Campaigns spend tens of thousands of dollars on signs and lose track of most of them. They also collect priceless supporter intelligence in the process and almost universally discard it. The volunteer who placed a sign on a supporter’s lawn last cycle knows that household supports the cause. That knowledge dies in a group text thread the day after the election.

Sign Mapping replaces the spreadsheet, the text thread, and the manager’s memory with a single shared visual database — AND it captures the supporter signal as canonical UVP data that persists across cycles and travels with the voter regardless of which campaign or mode encounters them next.

The mobile app is the input. The district map is the output. The voter’s UVP is the long-term beneficiary. The volunteer doesn’t need training — they tap a button and the GPS does the rest. The manager doesn’t need to ask anyone where things are — the map shows them. The next cycle’s campaign doesn’t need to start cold — the Supporter Layer remembers.

This is deliberately a simple module on the surface. Underneath, it is the first production writer to the Supporter Layer, and it sets the architectural pattern that the Politogy donation system, event RSVP, and future supporter-signal features will inherit.

3. Mode Architecture

Sign Mapping lives exclusively inside Campaign Mode.

Mode	Sign Mapping Access	Rationale
Relationship Mode	No	No district scope, no geofence, no voter-roll for UVP matching
Campaign Mode	Yes	District geofence, precinct overlay, voter-roll geography, UVP matching all live here
Petition Mode	Yes (inherited)	Petition Mode auto-grants Campaign Mode entitlement

Sign Mapping requires Campaign Mode’s geographic scope to enforce district geofence validation, overlay placements on precinct boundaries, AND to perform GPS-to-UVP matching against the state voter file. A campaign without a defined district cannot use Sign Mapping in a meaningful way.

4. The Two-Tier IP Boundary

Sign placement data and supporter event data tier differently. Both must be respected.

4.1 SignPlacement (asset data)

Customer-tier (visible to the originating account):

All sign placements within the account’s district and time scope
Pin coordinates, type, lifecycle state, notes, photos, placer identity, timestamps
Density heatmaps and per-precinct counts derived from the account’s own data
Recovery lists and exports

Politogy-tier (Politogy IP):

Cross-account sign placement density patterns
Correlation of sign density with turnout, voter contact rates, and result outcomes
Aggregate Intelligence layer inputs derived from sign data
Sign placement behavioral patterns across accounts

4.2 Supporter Events (UVP-canonical data)

Supporter events written by Sign Mapping (hosted_yard_sign, hosted_field_sign) follow the Supporter Layer rules defined in vrm-data-system Section 2.4.

Within-account visibility: The customer that placed the sign sees the supporter event on the matched UVP. The event appears in the UVP’s supporter history, contributes to the customer’s view of the supporter score, and is available in segmentation.

Cross-account visibility: Other accounts’ supporter events on the same UVP are NOT visible at the standard subscription tier. They are accessible only through the Cross-Cycle Sign Host History Intelligence Product per Section 4.3 — and only in anonymized form.

4.3 Tiered exposure summary

Tier	Sign Asset Data	Own-Account Supporter Events	Cross-Account Supporter Events
Free / Basic	Core placement, map view, simple counts	Event written + visible on UVP	Not available
Premium	Density heatmap, density rankings, recovery dashboard, CSV export	Event written + visible + contributes to supporter score	Not available
Enterprise	Anonymized district-level benchmarks vs comparable races	All Premium + Enterprise analytics	Not available at subscription level
Intelligence Product: Cross-Cycle Sign Host History	N/A	N/A	Anonymized event count + cycle list (no campaign attribution)

The Intelligence Product never reveals which Republican campaign a voter previously hosted for. This anonymization is enforced at the data-write layer per vrm-data-system Section 4.3.

5. The Continuous Lifecycle (SignPlacement)

Every sign placement is a stateful entity with a defined lifecycle, not a static record.

Placed → (optional) Verified → (in-life) Active → Recovered / Lost / Stolen / Damaged / Removed-by-Authority → Archived

State	Meaning	Who Sets It
Placed	Pin dropped, sign installed	Volunteer (default on creation)
Verified	Manager or second user has confirmed the placement	Manager (optional gate)
Active	Live and in service (default in-life state)	System (computed)
Recovered	Sign retrieved post-election or earlier	Volunteer or Manager
Lost	Believed gone, not recovered	Manager
Stolen	Confirmed taken without permission	Manager
Damaged	Found but unusable	Volunteer or Manager
Removed-by-Authority	Pulled by ROW agent, city, or property owner	Manager
Archived	Closed out of active rotation (post-election housekeeping)	Manager or System

Every state transition is timestamped, attributed to a user, and auditable. Photos can attach to any state transition.

Note on lifecycle and supporter events: The supporter event is written when the placement is created (state = Placed). Subsequent lifecycle transitions do NOT invalidate the supporter event. A sign that was placed and later stolen still represents a homeowner who consented to host it. The supporter signal stands regardless of asset outcome.

The only exception: if the placement is hard-deleted (Account Admin action) on grounds that it was placed in error (wrong location, fraudulent entry), the linked supporter event is also superseded by a corrective event flipping verified = false and noting the deletion reason.

6. The SignPlacement Entity

A SignPlacement is the canonical asset-tracking entity. It is not a UVP and not a Supporter Layer event. It lives in its own table tree and references geographic and user entities. It is linked to but architecturally separate from any supporter event it generates.

6.1 Core fields

Field	Type	Notes
`placement_id`	UUID	Primary key
`account_id`	UUID	Customer account scope
`district_id`	UUID	Campaign Mode geographic scope
`precinct_id`	UUID	Computed from coordinates at write time
`sign_type`	enum	`yard_sign` / `field_sign` / `billboard`
`lifecycle_state`	enum	Per Section 5
`lat`	decimal	Captured from device GPS or manual adjust
`lng`	decimal	Captured from device GPS or manual adjust
`gps_accuracy_meters`	int	Device-reported precision at capture
`placed_by_user_id`	UUID	Originating volunteer
`placed_at`	timestamp	Server timestamp on sync
`device_placed_at`	timestamp	Local device timestamp at capture (preserves offline truth)
`notes`	text	Free-form, optional
`photos`	array	Photo references, lifecycle-tagged
`is_within_geofence`	bool	Computed at write
`manual_adjust_applied`	bool	Did user move the pin off auto-GPS
`resolved_address`	text	Reverse-geocoded address (if available)
`resolved_uvp_id`	UUID nullable	Matched UVP via voter file (if match succeeded)
`match_confidence`	decimal nullable	0.0–1.0 confidence of UVP match
`supporter_event_id`	UUID nullable	Foreign key to the Supporter Layer event written, if any
`supporter_match_status`	enum	`no_attempt` / `no_match` / `low_confidence` / `matched` / `confirmed` / `rejected`

6.2 Lifecycle history

Each SignPlacement carries an append-only lifecycle_history log:

state (the state transitioned into)
transitioned_at
transitioned_by_user_id
reason (free-text, optional)
photo_ref (optional)

This makes the entity a living record. Every sign carries its own history.

6.3 Relationship to Supporter Layer

A SignPlacement of type yard_sign or field_sign attempts to resolve a UVP at the placement coordinates per the workflow in Section 8. The result of that resolution is recorded on the SignPlacement (in resolved_uvp_id, match_confidence, supporter_event_id, supporter_match_status) AND written as a separate Supporter Layer event on the matched UVP.

Billboards do NOT attempt UVP matching. Commercial structures are typically owned by LLCs or media companies (Lamar, Clear Channel) — not voters. The matching attempt would produce noise. Billboards remain pure asset tracking with no supporter event write. V2 may revisit this if a meaningful subset of billboard placements turn out to be on voter-owned commercial parcels.

7. The Three Sign Types

The three types are operationally distinct, analytically distinct, AND distinct in their relationship to the Supporter Layer.

Type	Typical Cost	Surface	Recovery Priority	Analytical Weight	Supporter Event Written
Yard Sign	$3–$8 each	Private residential lawn (consent required)	Medium — high volume, low individual value	High — proxy for supporter density	Yes — `hosted_yard_sign`
Field Sign	$30–$150 each	Roadside, open lots, intersections	High — higher per-unit value	Medium — proxy for visibility coverage	Yes — `hosted_field_sign` (when match succeeds)
Billboard	$500–$5,000+	Commercial structure, highway, paid placement	High — contract-bound asset	Low for density, High for spend tracking	No — commercial structures rarely voter-owned

The system treats each type as a distinct icon and distinct analytical input. Icon treatment per the politogy-vrm-brand skill.

8. Pin Drop Workflow (Mobile)

The mobile pin drop is the most important interaction in the module. It must be fast, forgiving, offline-safe, AND it must capture supporter signal without adding friction.

8.1 Entry points

Persistent “Place Sign” quick action in Campaign Mode bottom nav
Sign Mapping section landing page primary CTA
Optional shortcut from a Walk List screen (when a volunteer is on the doors anyway)

8.2 Capture flow

Tap “Place Sign.”
GPS auto-captures. Device current location populates lat/lng. Accuracy radius shown visually.
Manual adjust available. Drag pin if GPS is wrong (common in dense neighborhoods or near tall buildings).
Select sign type. Three large tappable cards — Yard / Field / Billboard.
Optional details. Notes field, photo capture/upload, custom timestamp override.
Geofence check. If the pin sits outside the campaign’s district boundary, the system warns the user (“This pin is outside [District 37]”) and requires explicit confirmation to save. It does not block. The placement is saved with is_within_geofence = false flagged.
Save. Pin commits to local store, queues for sync if offline.
(Server-side, post-sync) UVP resolution. If sign type is yard_sign or field_sign, the server attempts GPS-to-UVP matching per Section 8.5. This is asynchronous and does not block save confirmation to the volunteer.

The volunteer’s experience is unchanged from a non-supporter-signal world: tap, select, optional details, save. The supporter event happens invisibly on the server. The volunteer doesn’t need to know it exists.

8.3 Offline behavior

Field placement happens in cell-dead zones constantly. The mobile client must:

Persist placement records locally on capture
Queue for server sync
Surface a clear sync indicator (“3 pins waiting to upload”)
Sync automatically when connectivity returns
Handle conflict resolution if the same pin was somehow re-edited offline

Offline pins display on the user’s own map with a “pending sync” visual treatment. They do not appear to other users until synced. UVP resolution and supporter event writes happen server-side after sync.

8.4 Validation

District geofence: warn, do not block (per 8.2)
Duplicate detection: if a new pin is dropped within 10 meters of an existing pin of the same type within the same account within 24 hours, the system surfaces a soft warning (“A Yard Sign was placed near here yesterday — is this a duplicate?”) with a “Place anyway” option
Sign type: required
Photo: optional but encouraged for Field Signs and required for Billboards (contract documentation)

8.5 UVP Resolution (server-side, post-sync)

For SignPlacements of type yard_sign or field_sign, the server runs the following resolution pipeline:

Reverse geocode. Maps API converts (lat, lng) to a structured address.
Voter file address lookup. The structured address is matched against the Geographic and Contact Info layers of the UVP database, scoped to the campaign’s district.
Match outcome:
- Single high-confidence match (confidence ≥ defined threshold, e.g., 0.85): write to resolved_uvp_id, set supporter_match_status = matched, generate Supporter Layer event with verified = true.
- Multiple possible matches (e.g., apartment building with multiple registered voters): write to resolved_uvp_id as primary candidate, set supporter_match_status = low_confidence, generate Supporter Layer event with verified = false, surface in manager review queue.
- No match (commercial address, vacant lot, unregistered address): set supporter_match_status = no_match, do NOT write a supporter event. SignPlacement is still saved normally; only the supporter linkage is skipped.
Confidence threshold tuning is a Politogy-tier configuration. The threshold can be adjusted based on observed match quality without requiring code changes.

No county assessor data is used in V1. Reverse geocoding via Maps API + voter file lookup is the entire resolution mechanism. This means:

Yard signs on residential addresses match well (the resident owner-or-tenant is typically a voter on the voter file at that address)
Field signs on commercial / freeway parcels often produce no_match because there’s no voter registered at a roadside parcel address — and that’s acceptable. The asset tracking still works; the supporter linkage is just absent.
V2 may introduce county assessor data ingestion to resolve commercial property owners back to their residential UVPs, but this is a meaningful new ingestion pipeline and is deferred.

8.6 Manager Review Queue

Low-confidence supporter event matches surface in a dedicated Supporter Event Review Queue at the customer tier (Account Manager and Account Admin roles).

Queue entry contents:

The SignPlacement (with photo, address, type, placer, timestamp)
The candidate UVP match (name, address, party, registration status)
Other possible UVP matches at the same address, if any
Match confidence score
Action buttons: Confirm match / Choose alternate UVP / Reject (no UVP) / Defer

Manager action updates the Supporter Layer event’s verified flag and supersedes prior values as needed. Confirmation triggers a recompute of the affected UVP’s supporter score.

The queue is the customer-tier safety valve for the auto-match pipeline. It is not a blocker — the supporter event is written immediately at low confidence — but it lets human judgment correct the auto-match where the auto-match was wrong.

9. Map Visualization (Manager & Mobile Views)

The map is the central surface for asset tracking. It is the same underlying map data on mobile and desktop, with surface adaptations.

9.1 Base map

Maps API integration (provider TBD — Google Maps or Mapbox)
District boundary always overlaid
Precinct boundaries toggleable
Standard pan/zoom

9.2 Pin rendering

Three distinct icon styles per sign type (per Section 7)
Lifecycle state affects pin appearance:
- Active / Placed: full color
- Recovered: muted / checkmark badge
- Lost / Stolen / Damaged: outlined with warning badge
- Archived: hidden by default, toggleable
Supporter match status badge: A small secondary indicator on the pin showing whether the placement generated a confirmed supporter event, a low-confidence event awaiting review, or no event. Visible only to Manager and Admin roles; hidden from volunteers to avoid information overload at the field surface.
Pin clustering at zoom-out levels. Cluster shows count and a mini-breakdown by type if zoomed close enough.

9.3 Layers and filters

Layer / Filter	Purpose
Sign type toggle	Show/hide Yard / Field / Billboard independently
Lifecycle state filter	Default: Placed + Active + Verified. Toggle to include Recovered, Lost, etc.
Date range	Placements within a window
Placer filter	Filter to placements by a specific user (manager use)
Precinct overlay	Show precinct boundaries with placement count per precinct
Density heatmap	Color intensity by sign concentration. Premium-tier feature.
GOTV crossfade	Overlay sign density alongside voter contact heatmap (Premium-tier integration)
Supporter match filter	Show only placements with confirmed / low-confidence / no-match supporter status (Manager+ only)

9.4 Pin details

Tap or hover on a pin reveals a details card:

Sign type and lifecycle state
Placer name and timestamp (placed_at)
Notes
Photo(s) with lifecycle tag
Resolved address (if available)
Linked UVP (if matched) — name, party, supporter score; clickable to UVP record (Manager+ only)
Match confidence and review status
“Edit” / “Mark Recovered” / “Mark Lost/Stolen” / “Delete” actions (permission-gated)
“Confirm Match” / “Change Match” / “Reject Match” actions for unverified events (Manager+ only)
Full lifecycle history (expandable)

9.5 List/table view

Companion view to the map. Searchable and sortable by all SignPlacement fields including supporter match status. Bulk select for bulk lifecycle updates and bulk supporter event confirmations.

10. Analytics & Reporting

Sign Mapping produces four categories of analytical output.

10.1 Operational metrics (all tiers)

Total signs placed, by type, by lifecycle state
Placement rate over time (daily / weekly trend)
Coverage: precincts with at least one sign, precincts with zero signs
Top placers (volunteer leaderboard, if account opts in)

10.2 Supporter signal metrics (all tiers, own-account only)

Total supporter events written from sign placements
Confirmed vs unverified match counts
Manager review queue depth
New UVPs entered into the Supporter Layer this cycle (via sign hosting)
Cross-reference: sign hosts that are also donors / volunteers / event attendees (Premium+, requires multi-feature data)

10.3 Strategic metrics (Premium tier)

Sign density per precinct (signs per square mile, or per registered voter)
Sign density heatmap
Sign placement vs voter contact rate cross-overlay (uses Campaign Mode contact data)
Recovery rate per cycle (recovered / placed)
Loss/theft rate per precinct
Supporter conversion rate: % of placements that generated confirmed supporter events

10.4 Aggregate Intelligence inputs and Intelligence Products (Politogy-tier; tier/product exposure to customers)

Cross-account sign density distribution at district / county / state level (Enterprise benchmark)
Correlation between sign density and turnout (Politogy-side)
Volunteer placement patterns as inputs to ground-game scoring
Cross-Cycle Sign Host History Intelligence Product: per-UVP cross-account host event count and cycle list (anonymized at campaign level)

10.5 Exports

CSV: full placement list with lat/long, type, lifecycle state, notes, placer, resolved UVP (own account only), match status
Recovery list export: filtered to active placements within a geographic scope, sorted to optimize a recovery route
Photo bundle export: ZIP of all photos with metadata
Supporter events export: own-account supporter events generated by Sign Mapping, with UVP linkage (subject to standard customer-tier export rules)

11. Recovery Workflow

Post-election sign recovery is the under-built half of sign management at most campaigns. Sign Mapping treats it as a first-class workflow.

11.1 Recovery mode

A toggle on the map view that:

Filters to placements in Active, Placed, or Verified state
Sorts a route based on geographic clustering (nearest-neighbor walk)
Lets a volunteer mark pins as Recovered (or Lost / Stolen / Damaged) with a single tap
Photo capture for Recovered state is optional
Updates the map in real time as the volunteer works through the route

11.2 Recovery assignment

Managers can assign recovery sub-regions to specific volunteers. Each volunteer sees their assigned pins; managers see the global picture.

11.3 Recovery analytics

Recovery completion percentage by region
Time-to-recovery (days from election to recovery)
Per-volunteer recovery counts
Loss rate analysis: “23% of yard signs in Precinct 17 were never recovered — investigate”

11.4 Recovery does not invalidate supporter events

When a sign is recovered, lost, stolen, or damaged, the original supporter event on the matched UVP remains intact. The voter consented to host the sign; that signal stands regardless of the asset’s downstream lifecycle. Only a hard-delete of the SignPlacement (Account Admin action) supersedes the supporter event.

12. Permissions

Role	Place	View Pins	Edit/Move	Delete	Bulk	Export	Confirm Supporter Matches
Field Volunteer	Yes (own)	Own + account-shared	Own only	Own only (soft)	No	No	No
Account Manager	Yes	All within account	All within account	All within account (soft)	Yes	Yes	Yes
Account Admin	Yes	All within account	All within account	All (hard-delete possible)	Yes	Yes	Yes
Politogy Analyst	No	All across all accounts (read-only)	No	No	No	Politogy-tier extraction	No
Politogy Super Admin	No	All across all accounts	Override capable	Override capable	Yes	Full	Override capable

Notes:

Field Volunteers can place but cannot move, hard-delete, or confirm supporter matches. Supporter match confirmation is a Manager-and-above action because it writes to UVP-canonical data.
Soft-delete is the default delete mechanism. Records persist with deleted_at flag set. Hard-delete is reserved for Account Admin and Politogy roles and supersedes any linked supporter event.

13. Integration Points

Integration	Nature	Priority
VRM Data System — Geographic Layer	District and precinct boundaries consumed from the Geographic layer of UVP / Voter Data infrastructure	Critical
VRM Data System — Supporter Layer	Sign Mapping is the first production writer to the Supporter Layer. Writes `hosted_yard_sign` and `hosted_field_sign` events.	Critical
VRM Data System — Reverse Geocoding Service	Politogy-tier service that converts GPS coordinates to structured addresses	Critical
VRM Data System — Voter File Address Lookup	Politogy-tier service that matches a structured address to a UVP	Critical
Campaign Mode geographic scope	Geofence validation reads the campaign’s defined district	Critical
Maps API provider	Tiles, routing, geocoding	Critical
Supporter Score computation	Supporter Layer events from Sign Mapping feed the supporter score model	Critical
GOTV / Voter Contact Heatmap	Sign density heatmap can overlay with voter contact density (Premium)	Important
Polling Engine	Polls can reference geographic segments where sign density is high or low	Future
Walk Lists	Quick-action to drop a Yard Sign pin while on a walk list	V1 nice-to-have
Aggregate Intelligence telemetry stream	Every placement, lifecycle transition, supporter event, and recovery emits an event to the AI-ready event stream	V1 — build the tracks
Intelligence Product entitlement system	Cross-Cycle Sign Host History product access is gated by entitlement system	V1
Politogy Donation System (future)	Both systems write to the Supporter Layer; their data combines on the UVP	Roadmap
Notifications	Optional push/email when new pins are added in subscribed precincts and when supporter review queue grows	V1

14. AI & Aggregate Intelligence Hooks

Sign Mapping is not an AI-heavy feature in its own UX, but the data it produces feeds multiple AI capabilities through the Supporter Layer and Aggregate Intelligence.

14.1 Capture telemetry from V1

Every placement, every lifecycle transition, every supporter event (verified and unverified), every manager review queue action, every recovery is emitted to the event stream with:

Source attribution (volunteer, manager, system)
Geographic context (precinct, district, county)
Timing (calendar day, days-to-election, time-of-day)
Type and lifecycle state
Supporter match outcome (matched / low_confidence / no_match)
Reviewer action (confirmed / corrected / rejected / deferred)

14.2 Future AI capabilities (V2+)

Optimal placement recommendations. Recommend placement priority based on historical density-vs-turnout correlation.
Loss / theft pattern detection. Identify precincts with anomalously high loss rates.
Recovery route optimization. Model traffic, time-of-day, volunteer load capacity.
Supporter score model improvement. Sign host events are a primary input to the supporter score; the model evolves as more events accumulate across cycles.
Supporter propensity for sign hosting. Predict which voters are most likely to host a sign if asked, based on cross-account behavioral patterns. Feeds canvass targeting.
Volunteer engagement scoring. A volunteer who places signs and returns to recover them is a Tier-1 reliable. Ground-game scoring input.
Match confidence model improvement. Manager review queue confirmations and corrections train the auto-match confidence model.

14.3 Aggregate Intelligence layer writes

Politogy-tier aggregations write to the Aggregate Intelligence layer with full provenance (model + version, inputs, confidence, timestamp). Customer-tier exposure of these aggregations is gated by tier and by Intelligence Product entitlement.

15. V1 MVP Scope vs V2

V1 MVP must deliver

Mobile pin drop with GPS capture, manual adjust, sign type select, notes, photo, offline queue
District geofence validation (warn, not block)
Duplicate detection soft warning
Three sign types with distinct icons
Manager map view with all pins, clustering, type/state/date/precinct filters
List/table view, searchable and sortable
Pin detail card with full lifecycle history
Lifecycle state management (all states per Section 5)
Recovery mode with route ordering and bulk marking
CSV export
Volunteer + Manager + Admin role permissions
Notifications (push + email) on new pins in subscribed precincts and on supporter review queue activity
Density heatmap (Premium tier)
Aggregate Intelligence event telemetry from day one
GPS-to-UVP auto-match pipeline for yard signs and field signs (reverse geocode → voter file lookup)
Supporter Layer event writes (hosted_yard_sign, hosted_field_sign) with full provenance and confidence flagging
Manager Review Queue for low-confidence supporter event matches
Cross-Cycle Sign Host History Intelligence Product access gating (anonymized at campaign level)
UVP linkage display in pin detail card (Manager+ only)

V2 expansion

Sign density vs voter contact crossfade
Cross-account benchmark exposure (Enterprise tier)
AI-driven placement recommendations
Loss-pattern anomaly detection
Recovery route optimization beyond nearest-neighbor
Volunteer engagement scoring integration
Walk-list / canvass workflow tighter integration
Photo recognition for sign condition assessment
County assessor data ingestion for commercial parcel owner resolution (closes the field-sign no-match gap)
Supporter propensity model for predictive canvass targeting
Attributed cross-account sign history as a higher-tier Intelligence Product (requires Politogy executive approval and contractual terms; default remains anonymized)

16. Critical Architectural Principles

When making implementation decisions for Sign Mapping, return to these principles:

Sign assets and supporter signals are architecturally distinct but operationally linked. The SignPlacement entity tracks the physical asset. The Supporter Layer event captures the supporter signal. They share a creation moment (the pin drop) but live in separate data structures and follow separate lifecycle rules. Maintain this distinction at the data-write layer.
The pin drop must feel free. Three taps maximum from app open to pin saved. Friction kills field data quality. Supporter matching happens invisibly server-side after sync — the volunteer never sees it, never confirms it, never thinks about it. The volunteer’s experience is identical to a non-Supporter-Layer world.
Offline-first is non-negotiable. A pin captured offline is exactly as valid as one captured online. Supporter event resolution waits for sync. The architecture must treat sync as inevitable, not exceptional.
Geofence warns, never blocks. Field reality is messier than boundary lines.
Recovery is a first-class workflow, not a footnote. Half the value of the asset side of Sign Mapping is post-election asset recovery.
Lifecycle state is the spine of asset tracking. Every state transition is data. Recovery, loss, theft are all data points.
Supporter events stand regardless of asset outcome. A sign that’s stolen or lost still represents a voter who consented to host it. Only a hard-delete of the placement (admin action on grounds of error) supersedes the supporter event.
Auto-match writes immediately; humans confirm asynchronously. Low-confidence matches still write to the UVP at the time of placement, flagged unverified. The manager review queue is a confirmation surface, not a blocker. Never silently drop signal because the auto-match wasn’t confident enough.
No assessor data in V1. The reverse-geocode-to-voter-file pipeline is sufficient for yard signs and many field signs. Commercial parcels that produce no match are an acceptable V1 gap. V2 closes it.
Billboards skip supporter matching entirely. Commercial structures rarely have voter owners. The matching noise isn’t worth the rare hit.
Cross-account supporter history is an Intelligence Product, anonymized at the campaign level. Politogy serves Republican campaigns exclusively, and Republicans run primaries against each other. Exposing attributed cross-cycle host history inside the platform creates a customer-trust crisis. Anonymization is enforced at the data-write layer, not the UI.
Aggregate Intelligence captures from day one. Build event telemetry into V1 even where analytics surfaces are deferred to V2.
Three sign types stay three. Yard / Field / Billboard covers >95% of campaign sign reality.
The map is the product for asset tracking. The Supporter Layer is the product for cross-cycle value. Build the map experience first; the supporter linkage rides quietly underneath. Over multiple cycles, the Supporter Layer becomes the more valuable half.

End of conceptual specification.

🗳️ Politogy VRM — V2 Specs

Explorer