Email validation and compliance workflow
The first validation workflow ran fine technically and still nobody leaned on it, because it wasn’t checking what Compliance reviews.
What they asked for
Build a spam checker so content is cleaner before it reaches Compliance.
What was underneath
Compliance wasn’t reviewing spam signals. They were reviewing regulatory language and jurisdiction rules, and the workflow had been designed without them.
The starting point
Every lifecycle email went through four to five rounds of review between the lifecycle team and Compliance before it could send. With no self-serve QA, each send became a back-and-forth that added days to production.
The original request was a spam checker, something to flag obvious deliverability risks before content reached Compliance. I built that first version. It worked technically, but the output was inconsistent.
The reason became clear once I put it next to the review itself: the workflow was checking spam signals, while Compliance was reviewing for specific regulatory language, prohibited claims, and jurisdiction-specific disclosure rules. I had designed it without the people who do that reviewing.
The decision
Stop iterating on the technical layer and redesign the workflow outward from the compliance review process, with Compliance as a design partner rather than a downstream approver.
Rebuilding from scratch rather than patching the existing workflow cost time upfront, and it was the only route to something the team would genuinely rely on.
How I measured it
Compliance review cycles per email: how many rounds of back-and-forth before sign-off. That was the friction the workflow existed to remove, and if the number didn’t drop it wasn’t working, whatever it produced technically.
The build
I sat with Compliance before touching the workflow and documented how they actually reviewed content: what they looked for, what triggered a flag, what the rules were per content category, what varied by jurisdiction. That logic became the prompt architecture and validation layer.
It took four versions. V1 checked spam signals: functional, but aimed at the wrong question. V2 added compliance flag categories: better output, still inconsistent, because the model was interpreting rules rather than applying them. V3 brought Compliance in and replaced interpretation with explicit rule sets: reliable, but too verbose to use. V4 restructured the output so results were actionable in seconds.
Built in n8n so the lifecycle team could run validation themselves while drafting. Compliance reviews the output rather than the email, so the compliance question is answered before the email reaches them.
4–5 → 1–2
Compliance review cycles per email
~50%
Fewer compliance review cycles
4
Versions to get it right
What I took from it was less about the tool than about who you design with. The first three versions fell short because I was building a compliance workflow without a compliance expert alongside me. Subject matter experts aren’t approvers. They’re design inputs.
Tech
n8n
Workflow orchestration and self-serve QA
OpenAI API
Content validation and flag classification
Braze
Lifecycle email production pipeline
Confluence
Workflow documentation and rule sets
Previous
AI-powered lead enrichment and routing
Next
Mogo web ecosystem rebuild
Tell me what you’re working on.
If you’re working through a customer journey, system, or operational problem and think my experience might help, I’d like to hear about it.
Consulting on lifecycle, conversion, and automation—and open to the right senior role.