The AI Transparency Project

Purpose

This is a structured system for building a transparent, human-reviewed Q&A tool that helps voters quickly access clear, pre-written answers from a candidate.

It is intentionally designed to:

make information easy to browse, not search for
prevent AI from generating or improvising answers
reflect the candidate's actual positions, not approximations
anticipate real voter questions, including uncomfortable or off-topic ones
create a calm, usable alternative to traditional campaign messaging

This system can be used for:

local campaigns
civic education tools
structured public Q&A archives

Phase 1: Build the Question Set

Objective

Create a comprehensive, structured list of voter-relevant questions that a thoughtful resident would want answered before voting.

Core Instruction

Compile a broad and useful question set covering:

the candidate
the role itself
local issues
general policy thinking
anticipated off-topic or higher-level political questions

Question Categories

Organize questions into clear categories such as:

About Don
Experience & Background
Role of Town Supervisor
Local Issues (roads, zoning, services, etc.)
Taxes & Spending
Decision-Making Philosophy
How Government Works
State & National Context

Rules

Prioritize real questions voters actually have, not idealized ones
Include basic questions (for new voters) and nuanced ones (for engaged residents)
Include questions that may be:
skeptical
unclear
outside the strict scope of the role
Do not optimize for message control — optimize for usefulness
Avoid redundancy

Output

Export the full categorized question set into a document for the candidate to answer individually.

Phase 2: Build the Answer System

Objective

Turn the reviewed answers into a structured, non-generative chatbot interface.

Core Principle

The system does not generate answers.

It only retrieves and displays pre-written, human-reviewed responses.

Interaction Model

Question Selection

Users browse questions organized by category
Users select from prewritten questions only
No free-form input unless a controlled system is explicitly added

Answer Display

When a question is selected:

Show a brief typing indicator
Display the answer using a fast typewriter effect
Include one subtle human-like correction:
a typo that is erased and fixed, or
a word replaced with a better one

Animation Rules

The correction should be noticeable but not distracting
The overall response should feel quick and responsive
Respect reduced-motion settings:
if enabled, show the full answer immediately

Layout Behavior

Desktop

Keep the answer window visible
Allow users to browse questions without losing the current answer

Mobile

Scroll to the answer after selection
Provide a clear way to return to the question list

Transparency Requirements

Include a clear, plain-language note:

Answers are written and reviewed by the candidate
The chatbot is a browsing tool, not an AI decision-maker
The system does not generate new responses

Tone should be:

calm
direct
non-defensive

Discoverability Requirements

Add appropriate page metadata
Implement FAQ schema for all questions and answers
Ensure content is crawlable and understandable by search engines and AI systems

Voice and Tone

Useful, not promotional
Clear, not clever
Honest about limits
Consistent with the candidate's real voice

Do not:

simulate personality beyond light interaction cues
imply the system is "thinking" or "deciding"
overuse animation or novelty

Output Requirement

The final product should be:

structured
easy to scan
technically simple
trustworthy

Closing Note

This system does not replace conversation.

It makes the candidate's answers easier to access, understand, and evaluate.

Purpose

This is a structured system for turning a long municipal code document into a plain-English civic reference tool for residents.

It is intentionally designed to:

make local rules easier to understand
surface the questions residents actually ask
connect answers to specific Town Code sections
separate code language from plain-English explanation
identify the Town departments or parties residents may need to contact

This system can be used for:

municipal code guides
resident help tools
civic education projects
local government transparency work

Core Instruction

Analyze the full Town Code document and identify the rules most likely to matter in everyday resident life.

Prioritize questions about:

homes and property
permits and inspections
dogs and animals
garbage and recycling
noise and leaf blowers
parking and snow rules
trees, wetlands, and drainage
tax exemptions
pools, sheds, and accessory structures

Question Extraction Rules

Focus on practical resident questions, not legal completeness.

Good questions should sound like:

Do I need a permit?
Who do I call?
What hours are allowed?
What does the rule mean in practice?
What happens before I act?

Avoid questions that are too obscure, too technical, or unlikely to matter to a normal resident.

Organization

Group questions into clear topic sections.

Each section should be easy to scan and should contain only related questions.

Do not organize around the code’s internal chapter structure if a resident would not think that way.

Answer Structure

Each answer should include:

the relevant Town Code reference
the actual code language or a close summary
a plain-English explanation
the department, board, official, or outside party likely involved
a short reminder that residents should confirm details with the Town before acting

Plain-English Rules

Translate, do not oversimplify.

Answers should be:

accurate
short
useful
non-legalistic
honest about uncertainty

If the code does not fully answer a real-world question, say so clearly.

Interface Requirements

Build the guide as an interactive reference page.

The page should include:

search
topic categories
clickable questions
a readable answer panel
mobile-friendly inline answers
a way to suggest missing topics

Search should include synonyms and common resident phrasing, not just exact code terms.

Accessibility and Discoverability

The guide should include:

semantic HTML
keyboard-accessible controls
reduced-motion support
FAQ schema
crawlable fallback content for search engines and AI systems

Transparency Requirement

The page should explain that AI was used to help analyze, organize, and summarize the Town Code, with human review before publication.

The tool should not pretend to replace the Town, a lawyer, or official code interpretation.

Output Requirement

The final guide should be:

organized by resident need
grounded in specific code references
easy to search
easy to update
clear about its limits

Closing Note

This system does not replace the Town Code.

It makes the code easier to approach, so residents can ask better questions and know where to start.

Purpose

This is a structured system for generating a realistic, multi-image campaign photo series without staging real events.

It is intentionally designed to:

replicate the visual language of modern political campaigns
create images that feel familiar, not fabricated
balance realism with subtle concept-driven humor
maintain consistency across an entire photo series
produce assets that function like real social content

This system can be used for:

campaign storytelling
visual prototyping
media experimentation
low-cost content production

Core Principle

The goal is not to generate "AI images."

The goal is to generate images that read as normal campaign photography at first glance, and only reveal their intent on closer inspection.

Image System Rules

Format

4:5 portrait (1080 × 1350), optimized for Instagram
Must crop cleanly to square for grid use
Subject positioned to remain intact in both formats

Character Consistency

The same fictionalized Don Scott appears in every image

Maintain consistency in:

face
age
build
hair
overall presence

The series should feel like it was shot in a single campaign cycle.

Visual Style

Realistic civic campaign photography
Natural light (no studio look)
Suburban Westchester County tone
Slightly staged, but believable
Calm, restrained expression

Avoid:

exaggerated emotion
visual absurdity
over-stylization

Scene Design Framework

Scenes should reflect familiar local campaign moments, not invented spectacle.

Location Context

Bedford, New York
Tree-lined streets
Small buildings
Local businesses
Residential neighborhoods
Community spaces

Scene Types

Use recognizable campaign patterns:

ribbon cuttings
coffee meetings
sidewalk conversations
small gatherings
local walkthroughs
informal public moments

Tone

Neighborly
Modest
Slightly staged in a familiar way
Never theatrical

Humor should come from recognition, not exaggeration.

Image Constraints

Do not include:

text in images
logos or campaign branding
readable signage
partisan symbols
oversized flags
distorted anatomy or AI artifacts

The image should never "announce" that it is artificial.

Interaction Layer

These images are not static assets. They are presented as a working social feed replica.

Each image supports:

likes (tracked and updated)
sharing (platform-native behavior with correct previews)
downloads (clean asset retrieval)

The system is designed to behave like real social media, not just resemble it.

Share System

Each image is:

individually addressable via its own URL
equipped with its own metadata (title, description, preview image)
optimized for sharing across platforms

The goal is for shared posts to look indistinguishable from real campaign content in messages and feeds.

Output Requirement

Each image in the series must:

stand on its own
fit naturally into the broader sequence
feel consistent with the character and setting
function as a believable campaign moment

Closing Note

This system is not about creating better images.

It's about demonstrating how campaign visuals can be constructed, replicated, and distributed without traditional production — while still feeling familiar enough to be taken seriously.

Best of Bedford Community Picks Survey Builder

Purpose

Build a lightweight civic survey that lets residents choose local favorites during the campaign, stores each response in Google Sheets, and preserves the data needed to publish a resident-powered Best of Bedford list after Election Day.

What This Tool Does

The survey presents a short set of fixed categories, asks residents to choose one favorite in each, and records those selections without requiring a name, email, account, or donation.

It is not a scientific poll, endorsement system, or live contest. It is a simple community input tool designed to make participation easy and preserve responses cleanly for a final tally.

Core Principles

1. Keep Participation Simple
The survey should feel quick, neighborly, and low-friction. Residents should understand what they are doing immediately and should not feel trapped in a long form.

2. Use Clear Categories
Each category should have fixed answer choices, a readable label, and one selected response. The structure should be easy to update, audit, and reuse.

3. Store Only What Matters
Track the minimum useful data:
- timestamp
- category ID
- category label
- selected pick
- session ID
- user agent
- page
- source

Do not collect names, emails, addresses, or unnecessary personal information.

4. Submit Responses Reliably
When the survey is completed, the front end sends a JSON payload to the deployed Google Apps Script web app.

Payload structure:
{
  action: "submitCommunityPicks",
  sessionId,
  userAgent: navigator.userAgent,
  page: location.pathname,
  source: "real",
  votes: [
    { categoryId, category, pick }
  ]
}

Each item in votes represents one completed category.

5. Use Apps Script As The Public Bridge
Google Apps Script receives the submission, validates the required fields, normalizes heading variations, and writes each vote to the CommunityPicksVotes tab in Google Sheets.

The sheet headings are:
Timestamp, CategoryID, Category, Pick, SessionID, UserAgent, Page, Source

This turns a static campaign page into a working civic data tool without a paid backend.

6. Maintain A Campaign-Long Response Log
Each valid response becomes part of a running list throughout the campaign. The sheet can be reviewed, deduplicated, filtered, and tallied at the end of the campaign.

Final results should not be declared before Election Day. Until then, any language should refer to "responses," "running input," or "community picks," not winners.

7. Add Light Abuse Prevention
Use a browser/session ID and local storage or session storage to reduce repeat submissions from the same browser. Do not add login, identity checks, or heavy authentication unless the project truly needs it.

The goal is basic integrity, not bureaucracy.

8. Handle Failure Clearly
If submission fails, show a useful message and allow retry. Do not tell users their responses were recorded unless the submission succeeds or a deliberate best-effort fallback is used.

9. Keep The Design Calm
Match the existing campaign system: cream backgrounds, moss and sage accents, restrained borders, editorial typography, and generous spacing. The tool should feel civic and useful, not like a noisy contest platform.

10. Make It Reusable
Keep the survey categories, options, Apps Script endpoint, and submission logic organized enough that another town could adapt the same pattern.

Build Checklist
- Create a clear hero and survey introduction.
- Render categories from a reusable configuration object.
- Store selected answers in front-end state.
- Generate or retrieve a browser/session ID.
- Submit completed responses to Apps Script.
- Append or update rows in Google Sheets.
- Show a real completion state only after submission.
- Keep final results unresolved until after Election Day.
- Preserve accessibility, keyboard support, and mobile readability.
- Document the workflow so residents can understand how the tool was built.

Output

A public-facing survey page that collects lightweight civic input, stores responses in Google Sheets through Apps Script, and creates the data trail needed to publish a transparent Best of Bedford Community Picks list after the campaign.

Code Red Quiz Builder

Purpose

Build a civic quiz that turns a long, rarely-read public document into something residents will actually engage with.

The tool uses AI to analyze the full Bedford Town Code, identify surprising provisions, and present them as a short interactive quiz with a live leaderboard.

The goal is simple:
Make local government more understandable by making it more approachable.

What This Tool Does
Reads a 700+ page municipal code document
Uses AI to surface unusual, specific, or surprising provisions
Converts those into multiple-choice questions
Reveals the real code after each answer
Tracks scores and displays a lightweight leaderboard

This is not trivia for its own sake.
It is a way to make public information visible.

Core Principles

1. Use Real Source Material
Every correct answer comes directly from the Bedford Town Code.
Nothing is invented or exaggerated.

2. Let AI Do the Heavy Reading
AI is used to scan the full document and identify provisions that are:

real
surprising
understandable
worth showing to residents

A human reviews all outputs before publishing.

3. Make the Code Legible
Each question reveals:

the correct answer
the actual code language
a short plain-English explanation

The value is not just guessing correctly.
It is seeing what is actually written.

4. Keep the Experience Simple

One question at a time
One answer per question
Immediate feedback
No sign-in
No friction

5. Keep the Tone Grounded
The Town Code is treated seriously.
The quiz is curious, not cynical.

How The Quiz Works

Each question includes:

1 real provision from the Town Code
2 invented options designed to be plausible

The challenge is not spotting a joke.
It is recognizing how strange real rules can be.

After submission:

the correct answer is revealed
the real code is shown
a short explanation is provided

Scores are tracked across all questions.

AI + Research Workflow
Load the full Bedford Town Code document
Ask AI to scan for:
unusual rules
oddly specific provisions
things a resident would not expect
Filter results for:
clarity
accuracy
real-world relevance
Convert selected items into quiz questions
Add plausible distractor answers
Review all outputs before publishing

AI is used to find what matters.
Humans decide what gets shown.

Leaderboard System

The quiz includes a simple leaderboard to create light participation.

Users submit:
initials
hamlet
No personal data is collected
Scores are sent to Google Sheets via Apps Script
The leaderboard mirrors the Typing Challenge system

If the backend fails, the quiz still works.

The leaderboard is optional, not required.

Data Flow
Quiz runs entirely in the browser
Score is calculated client-side
On submission:
a payload is sent to Apps Script
Apps Script writes to Google Sheets
Sheet stores:
initials
hamlet
score
timestamp

This creates a lightweight, transparent record of participation.

Design Approach

Match the Uncampaign system:

calm typography
restrained layout
editorial spacing
no game-show styling

The design should feel like civic infrastructure, not entertainment.

Build Checklist
Load Town Code as source document
Use AI to extract candidate provisions
Build structured question set
Implement one-question flow
Reveal real code after each answer
Track score across quiz
Submit scores to leaderboard
Handle failures cleanly
Keep everything readable and copyable

Output

A public-facing quiz that:

turns a long legal document into something usable
shows residents what is actually in their town code
demonstrates how AI can make civic information accessible

Voter Report Card Builder

Purpose

Build a civic participation tool that helps residents understand their own voting history, not someone else's politics.

The tool uses publicly available voter information from the Westchester County Board of Elections, matches it against information entered by the user, applies a simple voting-participation rubric, and returns a personalized voter report card.

The goal is not persuasion.
The goal is to make voting history visible, understandable, and actionable.

What This Tool Does

Searches a public voter information file
Matches a voter using the information they enter
Reviews participation across recent elections
Scores consistency using a clear rubric
Generates a simple report card
Creates a calendar reminder for Election Day
Inserts the voter's polling place into the calendar location

This is a civic utility, not a campaign targeting tool.

Core Principles

1. Use Public Data Carefully
The source data comes from publicly available voter information. The tool should use only what is needed to help a voter find their own record and understand their participation history.

2. Match Conservatively
The lookup should rely on entered voter information and avoid overclaiming. If the tool cannot confidently match a record, it should say so clearly and avoid returning the wrong result.

3. Score Participation, Not Beliefs
The report card evaluates voting consistency. It does not infer ideology, party loyalty, candidate preference, or issue position.

4. Make The Rubric Understandable
The scoring system should be simple enough for a resident to understand at a glance. A user should be able to see why they received a particular rating.

5. Turn Insight Into Action
The tool should not stop at showing a score. It should help the resident make a plan to vote next time.

How The Lookup Works

The user enters identifying information.

The tool checks that information against the public voter file and attempts to locate the matching voter record.

If a reliable match is found, the tool reads the voting history fields and applies the report card rubric.

If no reliable match is found, the tool should provide a calm failure message and avoid guessing.

Report Card Rubric

The rubric should rate voting participation based on actual voting history.

It should prioritize:
consistency
recent participation
local election participation
whether the voter tends to show up when turnout is lower

The score should be presented plainly, without shame or pressure.

The message should feel like:
"Here is what your record shows, and here is how to make the next election easier to remember."

Election Day Calendar Invite

The tool should generate a calendar reminder that includes the practical details a voter needs.

The calendar invite should dynamically include:
the voter's polling place as the event location
the hardcoded Election Day date for this year
polling place hours
a clear event title
a short reminder note

The point is to reduce friction.
A voter should be able to click once and save everything needed to remember when and where to vote.

Data Flow

User enters lookup information
Tool searches the public voter file
Matching record is evaluated against the rubric
Report card is rendered in the browser
Polling place data is passed into the calendar invite
Calendar event is generated for the user to save

Do not collect unnecessary personal information.
Do not use the tool to pressure, rank, or target voters.

Privacy And Tone

This tool should feel useful, not invasive.

Use:
plain explanations
minimal data handling
clear failure states
no shaming language
no partisan framing

The campaign can encourage participation without making the user feel watched.

Design Approach

Match the Uncampaign system:

calm typography
cream backgrounds
moss and sage accents
restrained cards
clear spacing
plain civic language

The report card should feel like a useful public-service artifact, not a political scoring machine.

Build Checklist
Load or reference the public voter file
Build conservative matching logic
Apply a clear voting-participation rubric
Render a readable report card
Show helpful failure states
Generate a calendar invite
Insert polling place into calendar location
Hardcode this year's Election Day date and voting hours
Avoid unnecessary personal data collection
Keep the tool calm, useful, and transparent

Output

A voter report card tool that helps residents understand their own participation history and gives them an easy way to remember the next election.

It turns public election data into a practical civic reminder.

Best of Bedford Pet Contest Builder

Purpose

Build a playful civic participation tool that lets residents submit their pets, browse local entries, and vote for favorites in a friendly, low-pressure way.

The tool combines a public pet submission form, a Google Sheets backend connected through Apps Script, a reviewed publishing workflow, and an interactive voting gallery.

The goal is not just to run a cute contest.
The goal is to create a neighborly reason for residents to interact with a civic campaign.

What This Tool Does

Lets residents submit a pet through a simple form
Sends each submission to Google Sheets through Apps Script
Notifies the campaign when a new pet is submitted
Allows reviewed pets to be turned into public cards
Organizes pets by category
Lets visitors upvote favorites
Stores vote events and totals
Keeps the experience light, local, and easy to share

This is a civic engagement experiment disguised as something people actually want to click.

Core Principles

1. Make Participation Easy
The form should ask only for what is needed to review and publish a pet entry. Keep the tone friendly and the process short.

2. Separate Submission From Publishing
A submitted pet should not automatically appear on the public page. Entries are first stored in the backend spreadsheet, then reviewed before a pet card is added to the site.

3. Use A Lightweight Backend
Google Apps Script acts as the public bridge between the website and Google Sheets. It receives form submissions, stores the data, and can notify the campaign when a new entry arrives.

4. Keep Voting Simple
Visitors should be able to browse pets, expand a card, and upvote a favorite without creating an account or handing over personal information.

5. Organize The Contest Clearly
Use category sections for different types of pets so the page remains easy to scan as entries grow.

6. Make Sharing Neighborly
Sharing should help residents celebrate a pet or invite friends to participate. It should not feel like a growth hack.

How The Submission Flow Works

A resident fills out the pet submission form.

The form sends the entry to Apps Script, which writes the submission into a Google Sheet and pings the campaign.

The campaign can then review the entry, prepare the public pet card, and deploy it to the site.

This keeps the public page curated while still making submission easy.

How Voting Works

Each approved pet appears as a public card.

Cards can be grouped by category and expanded for more detail.

In the expanded state, visitors can upvote and share the pet.

Vote events are sent through Apps Script and stored in Google Sheets, allowing totals to update and persist over time.

Data Flow

Resident submits pet form
Website sends submission to Apps Script
Apps Script writes to Google Sheets
Campaign receives notification
Approved pet is added as a public card
Visitor upvotes a pet
Vote is sent to Apps Script
Sheet stores vote event and updated total
Page displays current vote count

This creates a lightweight contest system without a paid backend.

Fairness And Guardrails

Use simple browser or session-based limits to discourage repeat voting.

Avoid heavy authentication unless the project truly needs it.

The contest should feel playful and fair, not bureaucratic.

Do not use fake urgency, fake scarcity, or inflated vote totals.

Privacy And Moderation

Collect only the information needed to review and publish a pet entry.

Avoid unnecessary personal details.

Review submissions before publishing to prevent spam, inappropriate content, or accidental oversharing.

Keep owner information minimal and display-friendly.

Design Approach

Match the Uncampaign system:

calm typography
cream backgrounds
moss and sage accents
restrained cards
clean category sections
readable expanded states
mobile-friendly voting controls

The page should feel polished and local, not like a generic contest platform.

Build Checklist
Create a friendly contest hero
Present browse-and-vote before submission
Organize pets by category
Make pet cards expandable
Include upvote and share controls
Build a short submission form
Send submissions to Apps Script
Store entries in Google Sheets
Notify the campaign of new submissions
Review entries before publishing
Store vote events and totals
Update visible vote counts
Handle backend failures cleanly
Keep the experience warm, fair, and easy to use

Output

A public-facing pet contest that collects local submissions, powers a category-based voting gallery, and gives residents a lighthearted reason to participate.

It turns campaign technology into something neighborly.