🎙️ Voter Contact

Spec map

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

🎯 Goals

Substrate Philosophy and Scope

Define one channel-agnostic contact architecture where Posture locks behavior and captured signal is honestly tagged. Mode Architecture and Product Positioning
Confine governed Voter Contact to Campaign Mode and enforce correct UVP layer routing and data priority. Foundational Entities
Define the six channel-agnostic substrate entities that channel specs reference but cannot redefine. Continuous Lifecycle
Standardize a shared Plan-to-Activate-Next session lifecycle with auditable state transitions across channels. Two-Tier Boundary
Enforce the customer/Politogy tier boundary at the data layer to protect IP and gate exposure by tier. Shared Campaign Type Taxonomy
Maintain a stable substrate-defined campaign type enum that all channels honor. Volunteer Worker Performance Profile
Score every worker on four shared dimensions plus channel-specific dimensions in one portable cross-account profile. Cross-Channel Contact Ledger
Maintain one append-only source of truth for all contact attempts to prevent double-contact and power saturation analytics. Polling Engine Integration
Define the fielding, script, and versioning contracts that let channels deliver Polling Engine instruments. Heavy-Prescription Next Moves
Provide a substrate-owned strategic Next Moves queue surfacing fully-specified follow-up actions across channels. Capture Mode Taxonomy
Tag every datum as Self-Report, Observation, or Verified so Aggregate Intelligence weights signal honestly. Compliance Scaffolding
Define abstract cross-channel compliance primitives (DNC propagation, audit, disclosure, pre-check) every channel honors. Field Volunteer Permissions
Constrain field volunteers to minimum data access scoped to their active assignment. Future Channel Extension
Allow new channels to extend the substrate without modifying it, via a governed amendment process.

Conceptual Specification (Substrate)

Module: Campaign Mode → Voter Contact (Substrate) Document type: Conceptual specification (architecture, behavior, and integration) Audience: Politogy VRM development team Status: Draft for development team review Author: Ben Edtl (Politogy LLC) Companion documents: VRM Foundational Data System; VRM Polling Engine; VRM Voter Contact — Field Canvassing; VRM Voter Contact — Phone Banking; VRM Mode Architecture; Message Lane Taxonomy

1. Executive Summary

VRM Voter Contact is the substrate that defines how Politogy VRM deploys humans to talk to voters. It is not a product on its own. It is the architectural foundation underneath every channel-specific contact product Politogy will ever ship — Field Canvassing, Phone Banking, and any future channel where a real human delivers contact to a real voter on behalf of a campaign.

The product thesis is that voter contact is not a logistics problem. It is an intelligence extraction problem disguised as logistics. Every door knock, every phone call, every future contact medium produces structured signal that feeds the Unified Voter Profile and the Aggregate Intelligence layer. The substrate exists to ensure that signal is captured the same way, scored the same way, governed the same way, and integrated the same way regardless of which channel produced it.

The substrate is built on five foundational principles:

One contact architecture, many channels. A door knock and a phone call are different fielding modes of the same system. The Volunteer Worker entity, the Posture distinction, the Session lifecycle, the Cross-Channel Contact Ledger, and the Heavy-Prescription Next Moves contract apply uniformly. Channels diverge only where the operational reality demands it.
Every worker is a measurable, portable instrument. A canvasser working for Account A in 2026 and a phone banker working for Account B in 2028 may be the same person. The Volunteer Worker Performance Profile (VWPP) accumulates across all accounts, all channels, all campaigns. The customer sees their own slice; Politogy sees the unified profile; cross-account intelligence at the Enterprise tier sells the aggregate.
Posture is locked, channel is data, captured signal is honest. Every Session has exactly one Posture — Poll-Fielding or Contact Operation — locked at creation. The Posture determines which script system produces the script, which disposition taxonomy applies, and where collected data writes. Channel is a session field, not a session type. Capture Mode tagging (Self-Report / Observation / Verified) travels with every captured datum so Aggregate Intelligence weights it honestly.
The Cross-Channel Contact Ledger is the single source of truth. Every contact attempt on every channel writes to one channel-agnostic, append-only ledger on the UVP. Pre-assignment checks, cross-channel cooldowns, do-not-contact propagation, and saturation analytics all run off the Ledger. Double-contact is prevented architecturally, not by convention.
Strategic intelligence is substrate, not channel. The Heavy-Prescription Next Moves contract — the mechanism by which the Polling Engine’s Strategic Analyst proposes follow-up contact campaigns based on what a previous Session revealed — is defined here. Channel specs implement channel-specific Next Move types (Walk List Next Move, Call List Next Move). The unified Strategic Next Moves queue is a substrate concern because it is where channels integrate.

The substrate differentiates Politogy VRM in four structural ways:

Channel unification at the architecture layer. Other voter contact tools treat phone and door as separate products with separate data models, separate volunteer rosters, separate reporting, and separate compliance regimes. VRM treats them as channels of one system. Cross-channel coordination is a substrate primitive, not a vendor integration.
Portable worker intelligence. The Volunteer Worker entity outlasts the campaign that recruited the worker. A canvasser who proves reliable for a 2026 House race is a known quantity for a 2028 ballot initiative — and the customer sees only their own slice while Politogy holds the unified record.
Posture as architectural lock. Methodologically rigorous polling data cannot be polluted by lightweight contact operations, and lightweight contact operations cannot be slowed by polling rigor. The Posture distinction enforces this in code, not in process.
Substrate-defined performance dimensions. Every channel’s VWPP must include four substrate-defined shared dimensions (Data Quality, Sentiment Capture Reliability, Polling Fidelity, Channel-Specific Quality), with channel-specific dimensions added on top. Cross-channel worker comparison is architected, not coincidental.

This specification defines V1 substrate scope. Two channel specifications consume this substrate as of V1: Field Canvassing and Phone Banking. Future channels (SMS-as-contact-op, event canvassing, in-person fundraising) extend the substrate without modifying it.

2. Substrate Philosophy and Scope

2.1 What the Substrate Is

The substrate is the architectural contract between Politogy VRM’s Polling Engine, Methodology Agent, Strategic Analyst, UVP, Aggregate Intelligence layer, and any channel-specific Voter Contact product. It defines:

The entities every channel uses (Volunteer Worker, Session, Campaign, Posture, Cross-Channel Contact Ledger)
The contracts every channel honors (Polling Engine fielding contract, Methodology Agent script contract, Heavy-Prescription Next Moves contract, two-tier boundary, Capture Mode taxonomy)
The shared data primitives every channel writes through (VWPP framework + four substrate-defined dimensions, UVP layer routing rules, audit trail requirements)
The shared taxonomies every channel uses (campaign types, message lane mapping, do-not-contact and opt-out propagation)

2.2 What the Substrate Is Not

The substrate is not a product. It does not ship a UI. It does not ship a runtime. It is the architectural specification that channel specs build against. It is read by developers building channel-specific products, by integration engineers connecting the Polling Engine to a channel, and by product reviewers ensuring a new channel proposal honors the substrate’s contracts.

The substrate is also not a refactor target. Channel specs that predate the substrate (Field Canvassing V1) reference the substrate via minimal retrofit — a pointer at the top of the channel spec plus context notes on the relevant sections. The substrate does not require the channel spec to be rewritten.

2.3 The Three Audiences

The substrate serves three readers:

Channel spec authors. When a new contact channel is proposed, the substrate is the first document the author reads. It defines what the channel spec must honor, what it may extend, and what it may not redefine.

Channel implementation engineers. When a developer is implementing a channel spec, the substrate is the contract against which the implementation is validated. Substrate-defined entities cannot be channel-specific; substrate-defined contracts cannot be reinterpreted at the channel layer.

Cross-channel feature authors. When a feature spans channels (the Cross-Channel Contact Ledger, the unified Strategic Next Moves queue, the cross-channel saturation analytics), the feature is specified in the substrate. Channel specs implement the channel-specific surface of the feature.

2.4 The Posture Distinction

Foundational architectural concept that drives the rest of the substrate.

A Session has exactly one Posture for its entire lifetime. Posture determines what kind of contact operation the Session is, which script system produces the script, which disposition taxonomy applies, and how the resulting data writes to the UVP. Posture is locked at Session creation in V1. (Mid-Session posture switching is a V2 question deferred to a future substrate amendment.)

Posture A — Poll-Fielding Session. The Session is a fielding instance of a Polling Engine poll. The script IS the poll questionnaire. Volunteer-collected dispositions for the questionnaire portion are poll responses, written to the four-dimensional scoring model (Support / Confidence / Intensity / Volatility). The Session contributes to the source poll’s Fielding Scorecard. The Methodology Agent owns the script. Disposition taxonomy is constrained — the questionnaire’s questions in order, plus channel-specific connection outcomes. Customers cannot add ad-hoc dispositions that would corrupt response data.

Posture B — Contact Operation Session. Standalone outreach. Voter ID without poll-grade scoring, GOTV, volunteer recruitment, donor cultivation, candidate introduction, petition follow-up, circulator recruitment. Script comes from ScriptBuilder (lighter weight) or, for ID/persuasion subtypes, from the Methodology Agent. Dispositions are operational and write to the UVP’s Campaign Data layer as contact attempts and tags. They do not write to the four-dimensional scoring model.

This Posture distinction is the cross-channel analog of the Polling Engine spec’s Polls vs Surveys distinction. Both exist to keep methodologically rigorous data products from being polluted by lightweight ad-hoc workflows, while letting both products share the same delivery infrastructure.

3. Mode Architecture and Product Positioning

Voter Contact lives exclusively inside Campaign Mode. This is foundational and non-negotiable. Meaningful voter contact requires access to the voter roll; Campaign Mode is the mode that grants voter-roll access; Voter Contact must therefore live there.

Mode	Purpose	Voter Contact Access
Relationship Mode	Opt-in CRM with customer-supplied contacts	Limited — see 3.1
Campaign Mode	Voter-roll access via state voter file	Full — primary home of Voter Contact
Petition Mode	Signature collection / ballot initiatives	Yes (auto-grants Campaign Mode)

3.1 Relationship Mode Outreach

Relationship Mode users do conduct outreach to opt-in contacts (donors, supporters, board members, vendors). Light-touch click-to-call on a contact record is supported in Relationship Mode using the same Telnyx voice infrastructure. This is not Voter Contact. There are no Sessions, no Postures, no Volunteer Workers, no Disposition Taxonomy, no Cross-Channel Contact Ledger writes. Notes log. That is the extent of it.

If a Relationship Mode user wants to run a structured contact operation against their CRM contacts, they upgrade to Campaign Mode. Deliberate upgrade pressure built into the product.

3.2 Petition Mode Inheritance

Petition Mode auto-grants Campaign Mode and therefore Voter Contact. Petition campaigns need to contact signers to confirm signatures, drive turnout to signing events, and recruit circulators. Petition-specific campaign types (signature follow-up, circulator recruitment) are first-class Posture B subtypes in the shared campaign type taxonomy (Section 7).

3.3 Voter Contact and the Polling Engine

Voter Contact and the Polling Engine are integrated peers. Voter Contact channels are fielding modes of the Polling Engine when operating in Posture A. The Polling Engine owns the poll instrument; the channel owns the delivery; the substrate defines the fielding contract.

3.4 Voter Contact and the UVP

Voter Contact channels write to UVP layers as defined in the VRM Foundational Data System. The substrate enforces routing rules so that channel implementations cannot write to the wrong layer:

Campaign Data layer: Session assignments, contact attempt events, dispositions, free-form notes, captured polling responses (in Posture A), Capture Mode tags
Relationship Data layer: Voter-requested do-not-contact flags (account-scoped portion), voter-stated preferences captured during contact
Aggregate Intelligence layer: VWPP scoring inputs, Capture Mode-weighted training signal, sentiment extraction outputs, cross-account contact intelligence, methodology effectiveness telemetry
Identity Core / Contact Info / Vote History / Geographic / Enrichment: Read-only consumers; channels display these through the contact surface but do not write to them

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

4. Foundational Entities

The substrate defines six foundational entities. Channel specs reference these entities by name, extend them where the substrate permits extension, and cannot redefine them.

4.1 The Campaign

The top-level container. Has a name, description, owner (Account Admin or Account Manager), campaign type, active window, active list-building strategy, active set of scripts, and zero or more Sessions. The unit of reporting and the unit of strategic planning. A Campaign is channel-agnostic at the entity level; Sessions inside the Campaign are channel-specific.

4.2 The Session

One shift of one or more Volunteer Workers working a specific list with a specific script in a specific channel. Has a Posture (locked at creation), a Channel (phone | door | future), a Script reference, a List, a roster of assigned Volunteer Workers, a scheduled window, channel-specific session policies, and a state (Draft → Staged → Live → Closed → Archived). Every contact attempt happens inside a Session. Every disposition is logged against a Session. Every report aggregates Sessions.

Channel-specific behaviors (Telnyx for phone, GPS and walk lists for door) attach to their respective channels via channel-specific extension records, not by branching the core Session schema. The substrate Session schema is channel-agnostic.

4.3 The Channel

The medium of contact. V1 ships phone (Phone Banking) and door (Field Canvassing). The data model treats Channel as a first-class field on Session and Contact Attempt. Future channels register by extending the Channel enum and providing a channel spec that honors the substrate’s contracts.

4.4 The Posture

Defined in Section 2.4. Architecturally, Posture is a field on Session with two values (poll_fielding | contact_operation). Posture determines:

Which script system produces the Script (Methodology Agent vs ScriptBuilder)
Which disposition taxonomy applies (poll-question response set vs operational disposition set)
Where collected data writes (four-dimensional scoring model vs Campaign Data layer)
Whether the Session contributes to a Polling Engine poll’s Fielding Scorecard

4.5 The Volunteer Worker

A Politogy-owned, account-portable entity distinct from the User entity. A Volunteer Worker is a role-playing instance of a User. Specializations exist per channel:

Canvasser (Field Canvassing specialization) — defined in the Field Canvassing spec
Caller (Phone Banking specialization) — defined in the Phone Banking spec
Future channel specializations as channels are added

Architectural properties:

A Volunteer Worker working for Account A in 2026 and Account B in 2028 is the same Volunteer Worker entity with one continuous VWPP across both accounts.
The VWPP accumulates continuously across all contact events, all campaigns, all accounts, all channels.
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.

V1 substrate scope:

Volunteer Worker entity created on first contact assignment in any channel
Continuous VWPP accumulation across accounts and channels
Channel-specific specialization records (Canvasser, Caller) attach to the unified Volunteer Worker
Customer-tier slice view per account
Politogy-tier full view
Enterprise-tier aggregated cross-account access

V2 substrate scope (flagged for legal review):

Worker opt-out of cross-account scoring (labor-law implications in some jurisdictions)
Worker-facing visibility into their own VWPP (transparency feature)

4.6 The Cross-Channel Contact Ledger

Channel-agnostic, real-time, append-only log of every contact attempt against every UVP. Sourced from every Voter Contact channel (phone + door + future), the SMS/MMS Blast module, the Polling Engine’s non-human fielding modes (SMS / email / web), and any other contact module that ever touches a UVP. Consulted before every Session list assignment to prevent double-contact and do-not-contact violations. Source of cross-channel saturation analytics. Politogy-tier infrastructure with controlled customer-tier exposure.

Section 9 specifies the Ledger in full.

5. The Continuous Lifecycle

Every channel implementing the substrate follows the same continuous lifecycle. Channel specs add channel-specific phases or sub-steps but cannot remove or reorder substrate phases:

Plan → Build List → Build Script → Stage Session → Field → Disposition → Aggregate → Activate Next

Plan. The Manager defines a Campaign and decides what they need to accomplish. The campaign type and Posture are decided here.

Build List. The Manager pulls voters from the Voter Data Management system using filters. List size targets are scoped to available worker hours and expected channel throughput. The Cross-Channel Contact Ledger is consulted at list-build time to surface cross-channel cooldown candidates.

Build Script. The Manager either selects an existing script or generates a new one. Methodology Agent for Posture A (poll-fielding) and Posture B ID/persuasion subtypes. ScriptBuilder for the remaining Posture B subtypes. Both produce a structured Script object the channel-specific worker interface can render.

Stage Session. The Manager creates a Session inside the Campaign, picks a window, assigns Volunteer Workers, balances the list across them, and the Session moves to Staged state. Workers receive notifications. Channel-specific staging steps (route optimization for door, dialer warm-up for phone) occur here.

Field. Workers log in for their shift, get their queue, work through it. The Cross-Channel Contact Ledger is consulted in real time; voters contacted on another channel within the cooldown window are skipped automatically.

Disposition. Every contact attempt is dispositioned. Auto-advance moves the worker to the next voter. Channel-specific post-disposition behaviors (voicemail drops for phone, GPS-stamped door visit events for door) execute per Session policy.

Aggregate. The Session closes. Manager reports update in real time during the Session and finalize at close. Heatmaps update. The Polling Engine’s Fielding Scorecard updates if the Posture is poll-fielding. The Aggregate Intelligence layer updates per the standard cadence.

Activate Next. The Manager reviews outcomes and decides what comes next. The Heavy-Prescription Next Moves contract (Section 11) surfaces follow-up Sessions and follow-up polls based on what the just-closed Session revealed.

Session states: Draft → Staged → Live → Closed → Archived. Every state transition is auditable and timestamped.

6. The Two-Tier Boundary as Applied to Voter Contact

The two-tier boundary established in the VRM Foundational Data System applies to Voter Contact in full. 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):

Campaign, Session, list, and script work product
Scripts: AI-drafted, user-edited, user-authored
Custom note field schemas defined by the Manager
Captured raw data: contact attempt events, dispositions, free-form notes, polling responses (Posture A), Capture Mode tags, channel-specific captures (GPS for door, recordings for phone where consented)
Operational reporting: worker stats, coverage reports, outcome distribution, session dashboards
Strategic outputs: strategic memos, lane assignments, AI-drafted Next Move artifacts before activation
Customer’s own VWPP slice on workers who have worked for the account
Audit trails of all of the above

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

The Volunteer Worker entity itself
VWPP scoring model: full algorithm, weights, calibration logic, cross-account aggregation
Sentiment Capture Reliability calibration model
Capture Mode disambiguation model: internal logic for routing Self-Report / Observation / Verified into Aggregate Intelligence
AI sentiment extraction pipeline applied to free-form notes
AI script generation models: prompts, fine-tunes, evaluation rubrics
Cross-account aggregate intelligence: contact rate patterns, script effectiveness benchmarks, worker portability data, cross-channel saturation curves, methodology effectiveness telemetry
AI artifact telemetry, override decisions, cross-account override patterns

6.1 Tier-Gated Customer Exposure

Three tiers, mirroring the Polling Engine and Field Canvassing patterns:

Tier	Exposed Capabilities
Free / Basic	Basic operational reporting. Aggregate worker 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 contact-administered poll responses.
Premium	VWPP scores exposed on workers within the customer’s account (substrate-defined dimensions + the channel-specific dimensions defined in the channel spec). Four-dimensional scoring exposed on contact-administered poll respondents (per Polling Engine Premium tier). AI sentiment extraction with underlying scores on customer’s own notes. Cross-channel saturation analytics on the customer’s own data.
Enterprise	Cross-account worker intelligence: benchmarking, predictive worker-effectiveness modeling, portable worker scoring (aggregated, anonymized). Cross-account contactability intelligence. Cross-account script effectiveness benchmarks. Cross-channel saturation benchmarks. Aggregate Intelligence layer access for contact-derived signals.

7. The Shared Campaign Type Taxonomy

Campaign types are substrate-defined and channel-agnostic. Every channel honors the same campaign type enum. Channel specs may add channel-specific subtypes but cannot redefine the substrate types.

V1 substrate campaign types:

Campaign Type	Posture	Description
Voter ID	A or B	Identify a voter’s support level on candidate or issue
Persuasion	A or B	Move a voter from undecided / weak opposition to support
GOTV	B	Get out the vote — turnout activation
Volunteer Recruit	B	Recruit volunteers for campaign activities
Donor Cultivation	B	Solicit or steward donor relationships
Candidate Introduction	B	Candidate-led introduction to voters
Petition Signature Follow-Up	B	Confirm signatures, drive turnout to signing events
Circulator Recruit	B	Recruit petition circulators

Posture A applies only when the script is a Polling Engine poll instrument. Voter ID and Persuasion can be either Posture; the choice depends on whether the campaign wants poll-grade scoring or operational tagging.

8. The Volunteer Worker Performance Profile (VWPP)

8.1 Framework

The VWPP is the substrate-defined performance scoring framework for every Volunteer Worker. Every channel’s worker specialization (Canvasser, Caller, future) must populate a VWPP. The framework defines:

The four substrate-defined shared dimensions (Section 8.2)
The channel-specific dimensions added by each channel spec (Section 8.3)
The cross-account, cross-channel accumulation rule (Section 8.4)
The two-tier exposure rules for the VWPP (Section 8.5)

8.2 Substrate-Defined Shared Dimensions

Every channel’s VWPP must include these four dimensions. They are scored on substrate-defined criteria and are directly comparable across channels.

Dimension	What It Measures
Data Quality	Percentage of dispositions that are complete, internally consistent, and not flagged for review
Sentiment Capture Reliability	Worker-tagged sentiment vs ground-truth signal from later contact (calibrated per the substrate’s reliability model)
Polling Fidelity	For Posture A Sessions, percentage of poll administrations completed in full vs partial, with response distribution sanity-checked
Channel-Specific Quality	The channel’s primary quality dimension — Door Quality for canvassing, Call Quality for phone. Defined per channel; named by the substrate.

8.3 Channel-Specific Dimensions

Each channel spec adds dimensions beyond the four substrate-defined dimensions. Channel-specific dimensions are not directly comparable across channels. They appear in the customer-tier slice for the channels the worker has worked.

Examples (defined in the respective channel specs):

Field Canvassing adds: Response Rate, Geographic Coverage Efficiency, Safety Discipline (in addition to Door Quality as the Channel-Specific Quality dimension)
Phone Banking adds: Connect Rate, Compliance Discipline (in addition to Call Quality as the Channel-Specific Quality dimension)

8.4 Cross-Account, Cross-Channel Accumulation

A worker who has done both door and phone contact across multiple accounts has a single VWPP with dimensions from every channel they have worked. The substrate-defined dimensions accumulate across channels (a worker’s Data Quality score is informed by both door and phone evidence). The channel-specific dimensions accumulate only on the channels they apply to (Connect Rate applies only to phone evidence).

Customer-tier exposure is account-scoped: a customer who has used the worker only for canvassing sees only the canvassing-relevant dimensions plus the substrate-defined shared dimensions populated with canvassing evidence.

8.5 Two-Tier Exposure

VWPP scoring algorithms, weights, and calibration are Politogy-tier IP. Customers never see the underlying logic. Free tier sees aggregate worker stats; Premium tier sees per-worker dimension scores within the account; Enterprise tier sees cross-account aggregated and anonymized portability scores.

9. The Cross-Channel Contact Ledger

9.1 Definition

The Cross-Channel Contact Ledger is the substrate’s single source of truth for “who has been contacted, by whom, on what channel, with what outcome, when.” It is channel-agnostic, real-time, and append-only. Every contact attempt on every channel writes a Ledger entry. Every list-building operation and every in-Session assignment consults the Ledger.

9.2 What Writes to the Ledger

Every contact attempt from every Voter Contact channel (door visit events, phone call attempts, future channels)
Every fielding event from the Polling Engine’s non-human fielding modes (SMS dispatch, email dispatch, web link visit)
Every SMS/MMS Blast event
Any future module that touches a voter

9.3 Ledger Entry Schema

Every Ledger entry includes:

UVP reference
Channel
Posture (if applicable — non-human fielding modes have no Posture)
Session reference (if applicable)
Volunteer Worker reference (if applicable)
Attempt timestamp
Connection outcome (channel-specific enum)
Contact outcome (channel-specific enum, where applicable)
Disposition reference (links to the full disposition record in the originating channel)
Account reference (the originating customer account)

9.4 Pre-Assignment Check

Before a voter is assigned to a Session list, the Ledger is consulted for the voter’s recent contact history. Substrate-defined cooldown defaults apply per channel pair (e.g., “no door knock within 48 hours of any contact”). The substrate ships default cooldowns; Managers may override per Session at staging time. Overrides are logged.

9.5 In-Session Check

When a worker is about to be served the next voter in their queue, the Ledger is re-consulted. If a cross-channel contact has occurred since the Session was staged (e.g., the campaign sent an SMS blast that hit this voter), the voter may be skipped per Session policy.

9.6 Cross-Channel Saturation Analytics

The Ledger is the source for precinct-level and account-level saturation analytics. Heatmaps colored by ”% of voters contacted across all channels” pull from the Ledger. Saturation warnings (“you are approaching contact-fatigue threshold in Precinct 12”) fire from Ledger queries.

9.7 Two-Tier Exposure

Ledger entries within a customer’s account are customer-visible. Cross-account Ledger queries are Politogy-tier only and feed Aggregate Intelligence (cross-account saturation curves, channel effectiveness benchmarks, contactability scoring).

10. The Polling Engine and Methodology Agent Integration Contracts

10.1 Polling Engine Fielding Contract

When a Session is created in Posture A, the Session is a fielding instance of a Polling Engine poll. The substrate defines the contract:

The Polling Engine owns the poll instrument (questionnaire, scoring model, methodology validation)
The channel owns the delivery (worker interface, dispositioning, channel-specific compliance)
Every Posture A disposition writes both to the channel’s Campaign Data layer (as a contact attempt with full provenance) and to the Polling Engine’s four-dimensional scoring model (as a poll response)
The Session contributes to the source poll’s Fielding Scorecard
Partial responses (worker terminated mid-questionnaire) are flagged for confidence-weighting per Polling Engine rules

10.2 Methodology Agent Script Contract

The Methodology Agent generates scripts in headless mode for both Posture A and Posture B ID/persuasion campaigns. The substrate defines the contract:

The Methodology Agent emits a structured Script Object (defined in 10.3)
Channel specs render Script Objects in their channel-specific worker interface
Script Objects are immutable once attached to a Live Session
Editing a Script after a Session goes Live creates Version N+1; the Live Session continues on Version N

10.3 The Script Object

Substrate-defined data structure emitted by the Methodology Agent and (for non-poll-fielding Posture B subtypes) the ScriptBuilder. Every Script Object contains:

Script ID, version, producer (Methodology Agent vs ScriptBuilder), campaign type, languages
Opening (greeting + identification + permission-to-continue language)
Question / Statement Nodes (each with content, branches, and disposition mappings)
Branching logic (response-driven, voter-attribute-driven, previous-disposition-driven)
Closing (thank-you + next-step language + opt-out compliance)
Disposition mapping (which dispositions are valid at which point in the script)
Compliance components (channel-specific compliance hooks — recording-consent for phone, identification disclosures across channels)

Channel specs render the Script Object using channel-specific UI. The Script Object schema is substrate-defined and immutable across channels.

10.4 ScriptBuilder Contract

For Posture B subtypes that do not require Methodology Agent rigor (GOTV, recruit, donor, intro, petition follow-up, circulator recruit), the ScriptBuilder produces Script Objects using a lighter-weight generation pipeline. The substrate contract is the same — the ScriptBuilder emits Script Objects in the same schema. The Methodology Agent’s four-phase consultative negotiation does not apply.

11. The Heavy-Prescription Next Moves Contract

11.1 Definition

Heavy-Prescription Next Moves are substrate-defined strategic recommendations emitted by the Polling Engine’s Strategic Analyst after a Session closes. They propose fully-specified follow-up Sessions or follow-up polls based on what the just-closed Session revealed.

The substrate defines the Next Moves contract; channel specs implement channel-specific Next Move types.

11.2 Channel-Specific Next Move Types

Walk List Next Move (Field Canvassing) — fully-specified follow-up canvass: target voter set, walk list methodology, suggested script, recommended Posture
Call List Next Move (Phone Banking) — fully-specified follow-up phone bank: target voter set, call list filters, suggested script, recommended Posture
Follow-Up Poll Next Move (Polling Engine) — fully-specified follow-up poll instrument with target sample
Future channel-specific Next Move types as channels are added

11.3 The Unified Strategic Next Moves Queue

A substrate-owned queue surfaces Next Moves from every channel and the Polling Engine at the campaign level. The Manager reviews the queue, accepts or rejects proposals, edits accepted proposals, and activates them as new Sessions or new polls.

The queue’s prioritization model is substrate-defined and operates on Next Move type-agnostic signals (strategic urgency, finding strength, lane assignment, time-decay). Channel-specific factors are weighted inputs but do not branch the prioritization logic.

11.4 Override and Audit

Every Next Move acceptance, rejection, or edit is logged with full audit trail. Manager edits to AI-drafted Next Moves are tagged and feed Politogy-tier override pattern intelligence.

12. The Capture Mode Taxonomy

12.1 Definition

Capture Mode is a substrate-defined first-class field-level attribute on every captured datum. It distinguishes what the voter said from what the worker inferred and from what was verified against external data. This produces honestly weighted training signal for Aggregate Intelligence.

12.2 The Three Modes

Self-Report. The voter said it. (“I’m voting for the Republican.“) Highest weight in Aggregate Intelligence for stated positions.
Observation. The worker inferred it from context. (“Lots of Trump signs in the yard; voter wouldn’t talk but partner shouted MAGA from inside.“) Lower weight, but valuable for cluster intelligence.
Verified. Cross-referenced against external data. (“Voter said they’re registered Republican; voter file confirms.“) Highest confidence for factual claims.

12.3 Channel-Specific Application

Self-Report and Verified apply across all channels. Observation is rare on phone (no visual context), common on door, and applies to whatever future channels permit observation. Channel specs define which Capture Modes are surfaced in their worker interface and which are the default for which disposition types.

12.4 Two-Tier Use

Customer-tier sees Capture Mode tags on their own captured data. Politogy-tier uses Capture Mode to weight inputs into Aggregate Intelligence — Self-Report sentiment carries different weight than Observation sentiment in the cross-account models.

13. Compliance Scaffolding

13.1 What Lives in the Substrate

The substrate defines the abstract compliance primitives every channel honors:

Do-not-contact propagation. When a voter opts out on any channel, the opt-out propagates to every channel via the Cross-Channel Contact Ledger. A voter who hangs up and says “do not call me again” cannot be door-knocked by the same campaign the next week.
Cross-account opt-out (platform DNC). Voters who have requested no contact via the Politogy platform mechanism are excluded across all customer accounts. This is a Politogy-tier list.
Audit trail requirements. Every contact attempt, every disposition, every override, every Session state transition is auditable and timestamped. The substrate requires the audit trail; channel specs implement channel-specific audit detail.
Identification disclosure framework. Channel specs implement state-by-state identification disclosure requirements per the channel’s regulatory regime. The substrate requires the framework to exist and to be enforced by the channel’s compliance pre-check.

13.2 What Lives in Channel Specs

Channel-specific compliance lives in the channel spec, not the substrate:

TCPA, state calling hours, recording consent, federal/state DNC registries, predictive-dialer prohibitions — Phone Banking
State-by-state canvassing rules, HOA/private property restrictions, no-knock list, safety architecture compliance — Field Canvassing

13.3 Compliance Pre-Check Contract

Every Script must pass a compliance pre-check before being attached to a Session. The substrate requires the pre-check to exist. Channel specs define channel-specific pre-check rules.

14. Two-Tier Field Volunteer Permissions

Every channel implements a Field Volunteer sub-role of Field User (per the Foundational Data System spec’s permissions matrix). The substrate defines the permission contract:

Workers see voters only when assigned to a current active Session
Workers cannot search
Workers cannot export
Workers cannot view another worker’s notes
Workers cannot view UVP fields beyond what the active Script requires

Channel specs may tighten these permissions but cannot loosen them.

15. Future Channel Extension

15.1 The Substrate Extension Contract

Adding a new contact channel to Voter Contact requires:

A channel spec that honors every substrate contract (entities, lifecycle, two-tier boundary, VWPP framework with four substrate-defined dimensions, Cross-Channel Contact Ledger writes, Posture distinction, Capture Mode taxonomy, Next Moves contract)
A worker specialization extending the Volunteer Worker entity
Channel-specific dimensions for the VWPP (with the Channel-Specific Quality dimension named)
Channel-specific disposition taxonomy (with substrate-required Posture A constraint)
Channel-specific compliance regime
Channel-specific Heavy-Prescription Next Move type
Ledger entry contributions

Anything in the channel spec that contradicts the substrate must be raised to a substrate amendment.

15.2 Substrate Amendments

Substrate amendments are conceptual spec revisions that change a substrate contract. They require:

An explicit amendment document referencing the substrate section being modified
A migration plan for every existing channel spec
A retrofit plan for production systems running against the prior contract

Substrate amendments are rare by design. The substrate is conservative.

16. Architectural Summary and Developer Open Questions

16.1 The Five Architectural Pillars (Recap)

One contact architecture, many channels — Sessions, Postures, Workers, Ledger, Next Moves are channel-agnostic
Every worker is a measurable, portable instrument — VWPP accumulates across accounts and channels
Posture is locked, channel is data, captured signal is honest — Capture Mode tags travel with every datum
The Cross-Channel Contact Ledger is the single source of truth — double-contact prevented architecturally
Strategic intelligence is substrate, not channel — Next Moves contract and unified queue live here

16.2 V1 Substrate Scope

Ships:

Campaign and Session entities with substrate-defined lifecycle
Posture distinction (Poll-Fielding vs Contact Operation), locked at creation
Volunteer Worker entity with channel-specific specialization framework
VWPP framework with four substrate-defined shared dimensions
Cross-Channel Contact Ledger with pre-assignment and in-Session checks
Shared campaign type taxonomy
Polling Engine and Methodology Agent integration contracts
ScriptBuilder contract for Posture B non-ID/persuasion subtypes
Script Object schema
Heavy-Prescription Next Moves contract and unified Strategic Next Moves queue
Capture Mode taxonomy
Compliance scaffolding (do-not-contact propagation, audit trail, identification disclosure framework, compliance pre-check contract)
Two-tier boundary applied to Voter Contact data
Three-tier customer exposure model
Field Volunteer permission contract
Substrate extension contract for future channels

16.3 V2 Substrate Scope

Mid-Session Posture switching (with audit trail and data-integrity rules)
Worker opt-out of cross-account VWPP scoring (post-legal review)
Worker-facing VWPP visibility (transparency feature)
Cross-channel orchestration primitives (“after a failed phone attempt, automatically queue a door knock in the next canvass”)
Cross-channel saturation thresholds as configurable Manager-set policy rather than substrate defaults

16.4 Developer Open Questions

The following questions need resolution before or during V1 build. Organized by domain.

Cross-Channel Contact Ledger

Write-time consistency model — eventually-consistent across channels is probably fine for saturation analytics, but pre-assignment check needs to be strongly consistent. Where exactly is the boundary?
Ledger entry retention — indefinite (per UVP retention rules) or aged out after some window?
Pre-assignment check performance budget — at what voter universe size does the check become a list-build bottleneck?
In-Session check latency budget — sub-second is required; how is this achieved at scale?

Volunteer Worker Entity

Worker identity reconciliation — when the same person volunteers under two slightly different email addresses, how does the system unify them?
First-contact-assignment trigger — does the Volunteer Worker entity get created at Session assignment time or first contact attempt time?
Channel specialization records — single table with channel field, or one table per specialization? Performance and schema-evolution implications.
VWPP cold-start — how many contact events before a worker has a meaningful VWPP across substrate-defined dimensions?

Posture Distinction

Posture A partial responses — does the partial feed the four-dimensional scoring model, or is it set aside? Polling Engine spec hints at confidence flagging; substrate needs to commit on the cross-channel behavior.
Posture B disposition taxonomy extension — substrate allows customer extension; what’s the UI and audit model?
Posture lock enforcement — at what database layer? Application-layer guard plus row-level constraint?

Next Moves Contract

Unified queue prioritization — substrate-defined model needs explicit prioritization signals. Strategic urgency and finding strength are intuitive; what’s the algorithm?
Cross-channel Next Move dependencies — can a Walk List Next Move depend on a prior Call List Next Move completing? Substrate-defined dependency primitives or channel-spec coordination?
Next Move compute attribution — who pays for the Strategic Analyst compute when it generates Next Moves? Per-customer billing? Tier-included?

Capture Mode

Default Capture Mode when worker does not explicitly tag — substrate-defined default per disposition type or channel-spec-defined?
Capture Mode editability post-sync — substrate permits or forbids?
Capture Mode granularity within a free-form note — note-level only or sub-note? Substrate decision before channel specs lock UI.

Compliance Scaffolding

Do-not-contact propagation latency — when a voter opts out on phone, how fast does the opt-out reach a Live canvassing Session? Same Ledger consistency question, but the policy implication is sharper.
Cross-account platform DNC — registration mechanism for voters? Web form? Phone number? Voter-initiated only or also auto-registration on third refusal?
Audit trail retention — substrate-defined retention or channel-spec-defined? Likely substrate-defined per regulatory requirements.

VWPP Framework

Substrate-defined dimension calibration — how does Sentiment Capture Reliability calibrate when the channels generate sentiment differently?
Channel-Specific Quality dimension — substrate names the slot but channel specs define the dimension; should substrate define minimum requirements on what qualifies as a Channel-Specific Quality dimension?
Cross-channel comparability claims — what does it mean for a worker’s Data Quality to be “the same” across phone and door? Substrate needs a calibration commitment.

Substrate Governance

Substrate amendment process — who approves? What review does it require? Who is responsible for production retrofit?
Channel spec compliance review — at what point in a new channel spec’s development does it get substrate compliance review? Pre-draft, post-draft, pre-implementation?

These open questions should drive technical due diligence sprints before V1 lock. They are not blockers to architectural agreement on this conceptual spec.

End of conceptual specification.

🗳️ Politogy VRM — V2 Specs

Explorer