Sunday evening, the system checks what's still open.
It automatically looks at all pending tasks, creative approvals, and billboard sign-offs that haven't been touched since Friday. No one has to remember to check.
Creative Brief Generator
In ProductionAuto-generate production briefs from treatment documents
22
races in WV treatment doc
4
treatment tiers
2
proof variants per race
~44
briefs to generate
Example Generated Brief
AFP-WV: Daniel Linville LD-22 March Awareness
House Digital 1 · Incumbent · Positive Only · $1,500 production
Proof 1
Background: #fdf0d5
Text: #c1121f
Header
Daniel Linville for State Representative
Messaging Pillars
Affordable Living
Less Government
Real Leadership
Visuals
Main Headshot: Daniel Linville
Proof 2
Background: #EFD6AC
Text: #183A37
Header
Daniel Linville for State Representative
Messaging Pillars
Defend School Choice
Affordable Healthcare
Lower Energy Costs
Visuals
Main Headshot: Daniel Linville
Background
WV landscape
Paid for by Americans for Prosperity. Not authorized by any candidate or candidate's committee.
How It Works
Treatment doc goes in
The WV treatment document contains all 22 races with candidate info, messaging pillars, district data, and tier assignments.
AI parses and generates
Extracts per-race data, maps it to the brief template, selects colors and messaging based on tier and tone, and produces a complete creative request brief.
Google Doc comes out
Each brief is saved as a formatted Google Doc and linked in the dashboard. Ready for DMart's team to execute.
What This Replaces
Currently each brief is manually assembled by copying candidate info, colors, messaging pillars, and design specs into individual documents. At 1-2 hours per brief and 22 races in WV alone, this is 30-40+ hours of manual work per cycle. The brief generator reduces this to minutes.
How this works and what we need
The brief generator takes the treatment document that already exists for each state and automatically produces individual creative request briefs for every race. Instead of someone manually copying candidate names, colors, messaging pillars, district info, and design specs into 22 separate documents, the system reads the treatment doc once and generates all 22 briefs in minutes. Each brief comes out as a formatted Google Doc ready for DMart's team to execute against. The output is identical to what the team produces by hand today. Same format, same level of detail, same information. It's just faster.
- Treatment doc format Is the current WV treatment doc the standard format going forward, or will WY and SC use a different structure? We need to know if the parser needs to handle variations or if we can lock to one schema.
- Proof variants How do we decide how many proof variants per race? Is it always two? Does tier level affect this? Right now the Linville brief has two proofs with different color palettes and different messaging pillars. Is that the pattern for all races or does it vary?
- Color assignment Who decides the color palettes per proof variant? Is there a master palette doc, or does the creative team choose per race? If there's a system to it, we can automate the color selection. If it's subjective, we leave it as a manual input field.
- Reference imagery The current briefs reference existing Asana tasks as templates ("follow this template for proof 1"). Should the generator pull these references automatically based on tier/type, or does someone need to manually assign reference templates per race?
- Approval flow Once a brief is generated, who reviews it before it goes to DMart's team? Does Tad see them? Does Jason review state-level accuracy? Or do generated briefs go straight to creative execution?
- Headshot sourcing Where do candidate headshots live? Are they in a shared drive folder? Do we have them for all 22 WV candidates? For WY and SC? The brief references "Main Headshot: Daniel Linville" but doesn't include the actual image. Should the generator attach the image or just reference the file path?
Now
WV pilot with 22 races. Parser built, first brief generated. Validating output quality.
Next
Automate remaining 21 WV briefs. Get team feedback on format. Refine based on DMart's input.
June
WY and SC come online. Same system, new treatment docs. Config-driven, not rebuilt from scratch.
West Virginia Brief Pipeline
22 races · 4 tiers · June 2026 primary · Briefs produced once treatment doc is signed off by Tad
1brief ready
21not started
0approved
What's stuck right now
How we fix this
PlannedSunday automated reminders so nothing falls through the cracks
1
2
Everyone gets a personal checklist.
Each person — Jay, Jonathan, DMart's team — gets a Slack message with just their items: what's waiting, how long it's been sitting, and what they need to do. Clean, scannable, no noise.
3
Monday morning, everyone's already up to speed.
Before standup, the team knows exactly where things stand. No more "did anyone follow up on this?" conversations. Dave can always say "skip this week" if timing isn't right.
Powered by n8n, Asana, and Slack. Same architecture as the FEC monitoring system already in production.
Before we can build this, we need answers to:
- Approval chain Who approves what? Creative concepts (DMart?), strategic direction (Tad?), billboard/placement specifics (Jason?)? What's the escalation path if something sits 3+ days with no response?
- Slack channel Which channel do these reminders go to? An existing channel or a new dedicated one?
- Notification scope Should each person only see their own pending items, or should everyone see the full list? Does Tad and/or DMart get a summary of everything across all assignees?
- Override mechanism How does Dave say "stand down this week, don't send reminders"? Slack command? Just ignore it? We need a simple off-switch that doesn't require touching the workflow.
Precedent
FEC Monitor — LiveThis follows the same architecture as our existing FEC monitoring workflow: cron trigger, API pull, filter logic, Slack delivery. That system has been running in production reliably. This is the same pattern applied to approvals instead of filings.