✍️ Petition Mode

Spec map

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

🎯 Goals

The Signature Record

Make every signature a structured, provenance-rich data event owned by Politogy and tied to a UVP. Sheet Types and Structural Recognition
Recognize and correctly structure every jurisdiction-specific sheet type with permanent immutable scans. Signature Ingestion Pipeline
Move every sheet through capture, OCR, verification, duplicate detection, and routing with full logging and replay. The Adjudication Workspace
Let trained reviewers resolve flagged signatures fast with coded reasons feeding AI training and circulator scoring. The Circulator System
Track, score, and reputation-rank circulators as first-class field actors with fraud monitoring. Petition Records
Maintain petitions as top-level containers with live threshold, distribution, and pace tracking. Submission Packet Generator
Assemble legally-defensible SOS filings only after all pre-submission validations pass. Cross-Mode Data Flow
Write signatures instantly to the single shared UVP so all modes see them without duplication. The Petition Drafting & Filing Workspace
Support the full pre-circulation lifecycle from drafting to filing milestones in one platform. The Public Transparency Portal
Offer an optional public dashboard that builds movement momentum while exposing zero PII. Sub-Modes Within Petition Mode
Support Initiative, Recall, and Candidate petition use cases on shared data structures via ruleset overlays. Permissions Summary
Scope petition capabilities by role from Politogy admins down to limited circulators. AI Capabilities Specific to Petition Mode
Apply petition-specific AI models for OCR, matching, forgery, risk, and SOS prediction with full provenance. Data Lifecycle in Petition Mode
Retain all core petition records permanently and govern customer-churn data handling.

This document defines the complete conceptual architecture for Politogy VRM’s Petition Mode. It establishes how Petition Mode operates as a feature surface, how it relates to the foundational data system, and how every component serves both campaign operations and Politogy’s data strategy.

When building from this spec: This document tells you HOW PETITION MODE THINKS. It assumes the foundational data system spec (UVP, two-tier architecture, field system, data exposure controls, AI infrastructure) is the bedrock. Petition Mode does not duplicate any of that — it extends it.

1. Core Identity: Petition Mode Is a Mass Voter Identification Engine Disguised as Campaign Software

Petition Mode is sold to customers as a turnkey signature-gathering operation. To Politogy, it is the largest voluntary self-identification event a campaign will ever run. Every signer is a voter who has personally written their name, address, and signature attesting to a position. That is the highest-quality voter intelligence in existence — and most petition operations throw it away the moment the sheets are submitted to the Secretary of State.

Petition Mode is built on a single principle: a signature is not a piece of paper, it is a structured data event tied to a real human voter, a real circulator, a real moment in time, and a real geographic point. Every feature in Petition Mode exists to capture, verify, structure, and enrich that event.

Petition Mode has two masters. It must be the best petition operations software in the country (because real campaigns will use it under legal pressure with real deadlines), and it must convert every signature into a permanent, structured record on the underlying UVP — owned by Politogy, enriching the foundational data asset.

2. The Signature Record

Everything in Petition Mode orbits the Signature Record — the canonical representation of one signature line on one petition sheet by one signer for one petition. Every feature, every workflow, every export reads from and writes to Signature Records.

A Signature Record is Politogy’s record, not the customer’s. Customers interact with Signature Records through the software, but the underlying record belongs to Politogy and links permanently to the signer’s UVP.

2.1 Signature Record Composition

A Signature Record is composed of seven data layers. Each has a defined source, update cadence, and visibility rules.

Layer	Contents	Source	Default Visibility
Sheet Context	Petition ID, sheet number, sheet type (10-line vs single-signature), line number on sheet, scan image hash	System on ingestion	All users
Captured Data	Printed name, signature image, address, city, ZIP, date signed, any optional fields (email, phone)	AI-OCR from scanned sheet	All users
Circulator Linkage	Circulator ID, circulator name, circulator signature image, circulator certification date	Sheet header parse + circulator registry	All users
Verification	UVP match status, match confidence, match method, voter file fields compared, mismatch reasons	System (verification engine)	All users
Adjudication	Status (pending/accepted/rejected/escalated), reviewer, reviewer notes, reason codes, override history	Customer input + Politogy review	Originating account + Politogy
Submission	Submitted to SOS (yes/no), submission packet ID, SOS response (accepted/rejected), SOS reason code	System + manual entry post-submission	Originating account + Politogy
Aggregate Intelligence	Circulator quality score input, fraud signals, geographic clustering signals, propensity model inputs	Politogy-computed	Politogy internal only (sellable asset)

The Aggregate Intelligence layer is what makes Petition Mode a data product. Patterns across all petitions, all circulators, all jurisdictions, all signers — computed only by Politogy, not replicable by any single customer.

2.2 Signature Record ↔ UVP Linkage

Every verified Signature Record writes to the Petition Data layer of the matched signer’s UVP. This is the integration point with the foundational data system.

A successful signature match auto-tags the UVP as “Signed [Petition Name]” with date.
The UVP’s Petition Data layer accumulates every petition the voter has ever signed across every customer account on the platform.
Cross-account visibility: if a voter signed three different petitions across three different campaigns, Politogy sees all three. Each customer sees only their own.
A voter who signs frequently across petitions becomes a high-propensity signer in Aggregate Intelligence — sellable as a model output.

2.3 Provenance Tracking

Every Signature Record carries the same provenance metadata as any UVP value:

Source: Scan image ID, OCR model + version, AI verifier model + version, or human reviewer ID
Timestamp: When captured, when verified, when adjudicated, when submitted
Confidence: OCR confidence per field, match confidence overall
Chain of custody: Every state transition logged with actor, timestamp, and (for field operations) geolocation

Provenance is what makes a Signature Record legally defensible if challenged. It is also what makes Petition Mode’s data sellable.

3. Sheet Types and Structural Recognition

Petition sheets vary by jurisdiction and petition type. Petition Mode must recognize and structure each correctly.

3.1 Recognized Sheet Types

Sheet Type	Structure	Circulator Block	Common Use
10-Line Sheet	10 numbered signature lines, one circulator per sheet	Required, signed at bottom	Oregon initiative petitions, most state ballot measures
Single-Signature Sheet	One signature per page	Required per sheet	Recall petitions in some jurisdictions, candidate filings
Variable-Line Sheet	5/15/20-line variants	Required	State-specific layouts
Cover/Certification Sheet	No signatures — circulator legal certification only	Signed	Submission packet component

Sheet type is detected automatically on ingestion based on layout recognition. If the AI cannot determine sheet type with high confidence, the sheet is flagged for adjudication before any data is extracted.

3.2 Sheet-Level Metadata

Every scanned sheet carries:

Sheet number (assigned by system, sequenced by petition)
Petition ID
Sheet type
Scan image (preserved permanently — never deleted, never overwritten)
Scan timestamp + uploader ID + (if mobile) geolocation
Circulator ID (extracted from circulator block)
Page integrity hash (detects post-scan modification)
Status (pending OCR, pending verification, pending adjudication, complete, submitted, rejected)

Sheets are first-class records. Every signature line inherits from its parent sheet. If a sheet is invalidated (forged circulator, chain-of-custody break, etc.), every signature on it inherits the invalidation status with full audit trail.

4. Signature Ingestion Pipeline

Data enters Petition Mode through a five-stage pipeline. Each stage is logged. Each stage can be replayed independently.

4.1 Stage One: Capture

Signature sheets enter the system via three channels:

Field Capture (Mobile): Circulator photographs completed sheet from the field. Image timestamped, geotagged, hashed at moment of capture. Chain of custody begins here.
HQ Scan (Bulk): Sheets batch-scanned at campaign HQ. Uploaded with batch ID, scanner ID, uploader ID.
Direct Upload: Pre-scanned PDFs/images uploaded via web. Lowest chain-of-custody confidence — flagged accordingly.

All three channels write to the same scan store. All scans are immutable from the moment of upload.

4.2 Stage Two: Recognition (AI-OCR)

The OCR engine processes each scan:

Detects sheet type and validates layout
Extracts circulator block (name, signature, certification date)
Extracts every signature line: printed name, signature image, address, city, ZIP, date
Extracts any optional fields configured for the petition (email, phone)
Scores per-field OCR confidence
Flags fields below confidence threshold for adjudication

The OCR engine is a Politogy-tier model. Customers do not configure it. Politogy continuously improves it using adjudication outcomes as training data — every human correction makes the model better. This is a feedback loop only Politogy can build because only Politogy sees adjudications across all customers.

4.3 Stage Three: Verification

Each captured signature is matched against the UVP database:

Primary match: Name + address + ZIP within jurisdiction → exact UVP match
Probable match: Fuzzy match on name + partial address → confidence-scored UVP match
No match: No UVP candidate within jurisdiction → flagged for adjudication
Ambiguous match: Multiple plausible UVPs → flagged for adjudication

Match results carry confidence scores. Verification draws from the foundational UVP database — Politogy’s master record — not customer-tier data.

4.4 Stage Four: Duplicate Detection

Three duplicate checks run on every Signature Record:

Within-petition duplicate: Same UVP signed this petition twice. Auto-flag both records, retain first occurrence by date.
Within-sheet duplicate: Same name appearing twice on one sheet (often a circulator filling in lines). Strong fraud signal.
Cross-circulator duplicate: Same UVP signed by two different circulators on different sheets. Often legitimate (signer encountered two circulators) but logged for pattern analysis.

4.5 Stage Five: Adjudication Queue Routing

Every Signature Record exits the pipeline into one of four states:

State	Meaning	Next Action
Auto-Verified	High OCR confidence, clean UVP match, no duplicate flags	Ready for submission
Adjudication Required	Some field needs human review	Routed to adjudication queue
Auto-Rejected	Hard fail (no UVP match in jurisdiction, signer ineligible, sheet invalidated)	Excluded from submission, retained in record
Hold	Sheet-level issue pending review	All signatures on sheet held

5. The Adjudication Workspace

Where humans resolve what AI cannot. Designed for speed — a trained reviewer should clear hundreds of signatures per hour.

5.1 Queue Design

Adjudication queues are filterable by:

Issue type (illegible field, no UVP match, address mismatch, low OCR confidence, duplicate flag, circulator issue)
Sheet
Circulator
Date received
Petition

Items can be batch-actioned (e.g., accept all “low OCR confidence” items where reviewer confirms reading).

5.2 The Adjudication View

For each Signature Record requiring review, the reviewer sees:

High-resolution crop of the original signature line
Full sheet image (in panel) for context
AI-extracted values, editable
Candidate UVP matches with confidence scores
Voter file data side-by-side with captured data, mismatches highlighted
Reason codes for the flag
One-click actions: Accept, Reject (with reason), Escalate to Politogy, Re-OCR

5.3 Reason Codes

Every adjudication outcome carries a coded reason. Codes are global (Politogy-defined) so cross-account analysis is possible. Examples:

ADDRESS_MISMATCH_MINOR — typo, abbreviation difference
ADDRESS_MISMATCH_MAJOR — different street
NAME_VARIANT — Bob vs. Robert
OCR_AMBIGUOUS — handwriting unclear, reviewer judgment call
OUT_OF_JURISDICTION — signer not in petition’s geographic scope
SUSPECTED_FORGERY — visual indicators of fraud
DECEASED — signer in deceased file
DUPLICATE_CONFIRMED — same signer signed twice
CIRCULATOR_INVALIDATED — entire sheet rejected at sheet level

Reason codes feed the AI training loop and the circulator quality scoring.

5.4 Politogy Escalation

Reviewers can escalate to Politogy for:

Suspected systematic fraud
Legal review on a sheet’s validity
Pattern they cannot resolve at the customer tier

Politogy review is logged separately and is binding.

6. The Circulator System

Circulators are the field-side actors who collect signatures. They are first-class records in Petition Mode and a primary unit of analysis.

6.1 Circulator Records

Every circulator has a record containing:

Identity (legal name, contact, registration jurisdiction)
Petition assignments
Legal training acknowledgment (digitally signed before circulating)
Signature exemplar (their own signature on file for verification against circulator blocks)
Performance metrics (rolling)
Compensation status (paid vs. volunteer, applicable in jurisdictions that regulate paid circulators)
Status (active, inactive, suspended, terminated)

Circulator records are customer-tier with Politogy visibility. Customers manage their own circulator rosters. Politogy sees every circulator across every petition across every customer.

6.2 Circulator Performance Metrics

Computed continuously:

Total signatures collected
Verified rate (% verified after pipeline)
Rejection rate by reason code
Duplicate rate
Illegibility rate (OCR confidence)
Sheet integrity rate (% of their sheets passing without sheet-level flags)
Geographic coverage (precincts worked)
Hours logged (if Circulator Mobile is in use)
Cost per valid signature (paid circulators)

These metrics surface in three views: customer-tier (their own circulators), aggregate (anonymized cross-petition baselines so customers can benchmark), and Politogy-tier (everything, named).

6.3 Circulator Quality Score

A computed Aggregate Intelligence value. Combines all metrics into a single score with confidence band. Stored on the circulator record with full provenance (model version, inputs, timestamp).

A circulator with a high quality score has portable reputation — if they later work for another customer’s petition on the platform, their score follows them. This is a network effect: the platform becomes more valuable to circulators as their reputation accumulates.

6.4 Circulator Mobile Mode

Field-side companion application. Functions:

Daily check-in / check-out (hours tracked)
Assigned turf map with progress overlay
Sheet capture (photograph completed sheets — chain of custody begins)
Real-time validity feedback (sheet processed within minutes; circulator sees their own validity rate update)
Daily quota and gamified leaderboard (opt-in)
In-app legal training, certification acknowledgment, compliance reminders
Offline mode with sync on reconnect

Circulator Mobile is a permission-gated subset of Petition Mode. Circulators only see their own data and their assigned turf.

6.5 Fraud Signals at Circulator Level

The system continuously monitors circulator behavior for fraud signals:

Spike in duplicate rate
Sheets where every line shares handwriting characteristics
Sheets completed unusually fast (timestamp deltas)
Geographic impossibilities (sheets supposedly collected in two distant locations within minutes)
Signatures matching deceased voters
Pattern of signers all from same precinct on a turf assignment elsewhere

Fraud signals raise a circulator’s risk flag. Risk flags trigger heightened adjudication scrutiny on their sheets and Politogy notification at threshold.

7. Petition Records

A Petition is a top-level container. Every Sheet, Signature Record, and Circulator assignment lives under a Petition.

7.1 Petition Composition

Every Petition record contains:

Identity (title, ballot caption, type, jurisdiction, petition number)
Legal parameters (signature threshold required, geographic distribution requirements, deadline, eligibility scope)
Filing metadata (chief petitioner, filed date, certification status)
Petition layout configuration (sheet types, fields captured, language)
Status (drafting, circulating, submitted, certified, rejected, withdrawn)
Configuration for OCR, verification, and adjudication thresholds

7.2 Petition Threshold Tracking

The most operationally critical view in Petition Mode. Live dashboard showing:

Raw count: Total signatures captured
Projected valid count: Raw count × historical validity rate (improves as adjudications complete)
Confirmed valid count: Auto-verified + adjudicated-accepted
Required threshold: Statutory minimum for the petition
Buffer: Recommended overage based on jurisdiction’s historical rejection patterns
Geographic distribution status: Per-county / per-district progress where required
Days remaining: To statutory deadline
Pace required: Signatures per day needed to hit threshold + buffer
Current pace: Signatures per day actual (rolling 7-day)
Projection: On track / behind / ahead, with confidence band

This is the Chief Petitioner Cockpit View. It is the single screen a chief petitioner should be able to leave open all day.

7.3 Geographic Distribution Engine

For petitions with geographic distribution requirements (e.g., minimum signatures per congressional district), the system tracks per-region progress in real time. Map view shows coverage by precinct, district, county, with color coding by status (under-target, on-target, over-target).

This tells the campaign where to deploy circulators today, not next week.

8. Submission Packet Generator

When the campaign is ready to turn in signatures to the Secretary of State, the Submission Packet Generator assembles the complete legal filing.

8.1 Packet Composition

Numbered sheets in legally-required order
Circulator certifications (one per circulator, generated from circulator records)
Required cover documents (jurisdiction-specific)
Internal validity report (for campaign records — not submitted)
Manifest of every sheet and signature included
Audit trail summary
Print-ready PDF and digital submission package

8.2 Pre-Submission Validation

Before generating a packet, the system runs final checks:

Every sheet has valid circulator certification
No sheets in “Hold” or “Adjudication Required” status (must be resolved first)
Geographic distribution requirements met
Threshold + buffer met
All deadlines current

Validation failures block packet generation with a remediation list.

8.3 Post-Submission Tracking

After the packet is submitted, the campaign logs the SOS response per signature as it comes back:

SOS-accepted
SOS-rejected with reason code (mapped to Politogy’s standard reason codes for cross-petition analysis)

Post-submission data is high-value Politogy training input. It tells the verification model what the SOS actually accepts vs. what the model predicted.

9. Cross-Mode Data Flow

Petition Mode is one of three modes (Relationship, Campaign, Petition) operating on the same UVP database. Data flow with the other modes is non-negotiable.

A signature on a petition writes to the Petition Data layer of the signer’s UVP, instantly. That fact is visible in Relationship Mode (signer can be tagged, contacted, scored) and Campaign Mode (signer enters the campaign universe immediately).

Reverse flow: A voter who is already in Relationship or Campaign mode being engaged by the campaign can be flagged in Petition Mode the moment they sign — no duplicate entry, no batch sync.

There is ONE voter profile. Modes are views, not copies. Petition Mode reads from and writes to the same UVP as every other mode.

10. The Petition Drafting & Filing Workspace

Pre-circulation phase. Built into Petition Mode so the entire petition lifecycle lives in one platform.

10.1 Drafting Tools

Library of past initiatives (historical petitions with outcomes, ballot titles, captions, vote results — sourced from Politogy’s database)
Ballot title and caption drafting workspace with version history
Co-petitioner assignment
Statutory deadline calculator (filing window, certification window, submission window — jurisdiction-aware)
Auto-generated filing forms (cover sheet, certifications, SOS-required forms)
Petition layout designer (sheet template, fields captured, language)

10.2 Filing Tracker

Pre-circulation milestones tracked: title filed, title approved, layout approved, circulation start authorized, circulator training complete. Each milestone has owner, due date, status.

11. The Public Transparency Portal (Optional Per-Petition)

A campaign can publish a public-facing dashboard for their petition. Configurable per petition.

11.1 What’s Public

Live signature count (with optional time delay)
Geographic spread (heat map, no PII)
Days remaining
Threshold progress
Ways to support / sign / volunteer

11.2 What’s Never Public

Any individual signer information
Circulator identities
Adjudication data
Internal metrics

The portal is a movement-building asset. Press uses it. Supporters watch the count climb. It also creates campaign content (count milestones generate social posts).

12. Sub-Modes Within Petition Mode

Petition Mode is structured to support related-but-distinct petition use cases.

12.1 Initiative / Referendum Mode

Default. Statewide or local ballot measures. The architecture described in this spec.

12.2 Recall Mode

Same engine, different ruleset overlay:

Target official as a record (not a measure)
Jurisdiction-specific thresholds (often based on prior vote counts in the official’s district)
Shorter circulation windows
Different circulator certification requirements in some jurisdictions

12.3 Candidate Petition Mode

For candidates qualifying for the ballot via signatures:

Lower volume, often higher per-signature standards
Tied to a candidate record (linkable to Campaign Mode)
Different geographic constraints

All sub-modes use the same Signature Record, Sheet, Circulator, and Petition data structures. Sub-mode configuration determines validation rules, threshold logic, and submission packet format.

13. Permissions Summary (Petition Mode-Specific)

Builds on the foundational permissions model. Petition Mode adds these role-specific capabilities:

Role	Tier	Petition Mode Capabilities
Politogy Super Admin	Politogy	Full access to all petitions across all accounts, all OCR/verification model controls, escalation queue, fraud review
Politogy Analyst	Politogy	Read all petition data across accounts, review adjudication outcomes, monitor circulator behavior
Chief Petitioner	Customer	Full control of own petition: configuration, circulator roster, adjudication, submission
Petition Manager	Customer	All adjudication and circulator management; cannot configure or submit
Adjudicator	Customer	Adjudication queue access only; no circulator management, no configuration
Circulator	Customer (limited)	Circulator Mobile only — own assignments, own performance, sheet capture
Viewer	Customer	Read-only on petition dashboards within scope

14. AI Capabilities Specific to Petition Mode

Built on the foundational AI infrastructure. Petition-specific models:

Handwriting OCR with confidence scoring — Continuously trained on adjudication outcomes. The training data moat is unmatchable.
Voter Match Disambiguation — Resolves ambiguous matches using context (geographic clustering, circulator turf, prior signatures by signer).
Forgery Detection — Visual analysis identifies sheets where multiple lines share handwriting characteristics, identifies signature lifts, detects unnatural pen pressure patterns.
Circulator Risk Scoring — Combines performance metrics + behavioral signals into a continuously updated risk score per circulator.
SOS Acceptance Prediction — Predicts per-signature probability of SOS acceptance based on features (OCR confidence, address match quality, signature visual quality, jurisdiction history). Lets campaigns submit only their strongest signatures, or strategically pad with marginal ones.
Petition Signer Propensity — Cross-petition model predicting which voters are likely to sign which kinds of petitions. A monetizable Aggregate Intelligence product.
Geographic Optimization — Recommends where to deploy circulators today based on coverage gaps and historical signing density.

All AI outputs follow the foundational rule: stored in Aggregate Intelligence layer with full provenance, never overwriting user or voter file data, subject to Data Exposure Control.

15. Data Lifecycle in Petition Mode

Record Retention

Scan images: Permanent. Never deleted. Required for legal challenges that may arise years after submission.
Signature Records: Permanent. Linked to UVP indefinitely.
Circulator records: Permanent.
Adjudication history: Permanent. Every state change logged.
Petitions: Permanent. Active for circulation period; archived but readable thereafter.

Customer Churn

If a customer churns, their Petition Mode data behaves identically to all other customer data per the foundational spec: retained by Politogy, continues feeding Aggregate Intelligence, no longer accessible to the customer.

16. Summary Mental Model

Petition Mode is mass voter identification disguised as petition operations software. Every scanned sheet becomes structured Signature Records. Every Signature Record matches to a UVP, writing to the voter’s Petition Data layer permanently. Every circulator becomes a tracked, scored, reputation-bearing actor. Every petition becomes a live dashboard tracking threshold, distribution, pace, and projection. AI handles handwriting recognition, voter matching, forgery detection, and acceptance prediction — improved continuously by every adjudication across every customer. The submission packet generator assembles legally-defensible filings. Post-submission outcomes train the next generation of models.

Customers see a tool that wins petitions. Politogy sees the largest voluntary self-identification dataset in the country, tied directly to UVPs, growing with every signature gathered on the platform.

One sheet. One signer. One UVP. Total intelligence. Every signature gathered on Politogy VRM is a permanent piece of the most comprehensive voter data asset in America.

🗳️ Politogy VRM — V2 Specs

Explorer