Designing an AI-Powered Modular Email Assembly Platform for Regulated Lifecycle Marketing

Executive summary

Scratch needed a way to personalize regulated lifecycle communication without multiplying email variants and Journey Builder branches every time a new customer trait mattered.

I designed an AI-powered modular email assembly platform for that problem.

This was not a generic AI copywriting tool. The platform was designed as regulated content infrastructure: approved content atoms, approved layouts, borrower traits, journey context, selection logic, human review, version history, audit logs, and performance feedback.

The central idea was simple:

Approved content atoms
  +
Approved layouts
  +
Borrower and loan traits
  +
Journey context
  |
  v
Eligibility and trait filtering
  |
  v
AI-assisted selection
  |
  v
HTML assembly
  |
  v
Preview, approval, and testing
  |
  v
SFMC journey delivery
  |
  v
Engagement and payment outcomes

The platform vision was built around control. AI could help select and recommend, but it could not create unapproved regulated claims at send time.

Why branch-based personalization stopped scaling

Scratch sends lifecycle communication connected to lending and payment products.

That creates constraints:

• WebBank review.
• Truth in Lending Act considerations.
• UDAAP considerations.
• Required disclosures.
• Brand standards.
• Audit requirements.
• Version control.
• Approval controls.

The existing personalization model depended too much on manual variants and journey branches.

A single binary trait can create two versions. Add product state and journey state, and the version count grows fast.

2 interest states
x 3 journey states
= 6 variants

5 binary dimensions
= 32 possible combinations

The problem was bigger than production time.

Manual variants create duplicated content, inconsistent updates, harder QA, harder compliance review, limited experimentation, weak component-level reporting, and more engineering dependence.

The business needed to separate:

• Content.
• Layout.
• Customer traits.
• Selection logic.
• Approval.
• Rendering.
• Delivery.
• Measurement.

That separation is what makes personalization scale without losing control.

Separating content, layout, audience, and decisioning

The designed platform had eight major capabilities:

• Asset Library.
• Layout Builder.
• Approval and compliance fabric.
• AI Picker.
• Sandbox and testing.
• Journey awareness.
• Learning loop.
• Insights and recommendations.

The key design decision was to make approved content modular, then let the system assemble emails from approved parts.

Content atom
  |
  +-- metadata
  +-- version
  +-- compliance status
  +-- eligible traits
  +-- layout slot

Layout
  |
  +-- slots
  +-- design tokens
  +-- required regions
  +-- disclosure areas

Borrower profile
  |
  +-- loan type
  +-- plan type
  +-- journey stage
  +-- interest waiver state
  +-- engagement state

That turns the system from "create another email" into "select the right approved components for this customer state."

Designing the Asset Library

The Asset Library stores modular content atoms.

Atoms can include:

• Headlines.
• Introductory copy.
• Main-message blocks.
• Calls to action.
• Alerts.
• Testimonials.
• Frequently asked questions.
• Social proof.
• Disclosure-compatible supporting content.

Each atom carries metadata.

Example metadata includes:

atom_id
atom_type
layout_slot
product_type
journey_stage
plan_type
interest_waiver_state
urgency_level
emergency_or_routine
compliance_status
version
archive_state
created_by
approved_by
approved_at

Metadata is what lets the picker know what can be used.

Without metadata, modular content becomes a messy library of snippets. With metadata, the system can filter by eligibility before it ever thinks about ranking.

Versioning and audit history

Approved content should not be silently edited in place.

Editing an approved atom creates a new version.

The prior version remains preserved for:

• Audit history.
• Rollback.
• Comparison.
• Historical send reconstruction.

The new version must pass through approval before it becomes eligible for selection.

That matters because regulated messaging needs memory. If a borrower received an email six months ago, the business should be able to reconstruct which content version was sent, which layout held it, which traits selected it, and what approval state existed at the time.

AI-assisted variant drafting

Marketers can provide a seed atom and use AI to draft additional variants.

Those variants are drafts.

They are not automatically approved. They have to enter the same review and approval process as manually authored content.

That distinction matters.

AI drafting helps production. Approval controls protect the system. Those are different jobs.

Trait coverage heatmap

The platform also needed a coverage view.

The coverage heatmap answers a practical question: does the approved library have enough usable content for the combinations the platform is expected to support?

Examples:

Emergency + interest waived + approval journey + CTA slot
Routine + standard plan + e-sign journey + main-message slot
Routine + interest waived + e-sign journey + disclosure support slot

The system should identify:

• Empty combinations.
• Sparse combinations.
• Overrepresented segments.
• Content nearing expiration.
• Content marked for archival.
• Slots with too few approved variants.

A picker cannot select relevant content if the approved library has gaps.

Designing the Layout Builder

The Layout Builder lets marketers compose approved email structures without needing engineering for every variant.

Layouts contain defined slots:

1. Hero or headline.
2. Intro.
3. Main message.
4. CTA section.
5. Social proof.
6. Supporting information.
7. Footer and required disclosure area.

Layouts must obey:

• Scratch design tokens.
• Responsive behavior.
• Email-client constraints.
• Compliance formatting.
• Required content placement.

The designed requirements included:

• Drag-and-drop editing.
• Slot definitions.
• Desktop and mobile preview.
• Gmail, Apple Mail, and Outlook rendering.
• Litmus testing.
• Version history.
• Rollback.
• Controlled design tokens.
• Prevention of unsupported layouts.
• PDF review packets with representative combinations.

This should not be described as fully launched unless the implementation evidence supports that claim. The safer framing is that the builder was part of the designed platform architecture and product requirements.

Solving the modular approval problem

The hardest product constraint was compliance approval.

The proposed model was:

• Each atom is approved independently.
• Each layout is approved independently.
• The runtime system assembles approved atoms inside approved layouts.

That avoids reviewing every possible combination.

But the model only works if the platform can guarantee that any permitted combination stays compliant.

The controls matter:

• Slot compatibility rules.
• Required disclosure slots.
• Prohibited atom pairings.
• Plan-specific restrictions.
• Product-specific eligibility.
• Locked content regions.
• Layout validation.
• Combination testing.
• Compliance-safe fallback content.

The approval state machine looked like this:

Draft
  |
  v
Pending approval
  |
  +-- rejected
  |     |
  |     v
  |   revise
  |
  +-- approved
        |
        v
      published and eligible
        |
        v
      archived

Every mutation should record:

• User.
• Timestamp.
• Previous value.
• New value.
• Reason.
• Approval status.
• Reviewer.
• Associated version.

Every send should be reconstructable with:

• Borrower traits.
• Layout version.
• Atom versions.
• Selection result.
• Rendered output.
• Journey.
• Send time.
• Approval state at time of send.

Do not claim WebBank approved this modular model unless that approval is confirmed. The case study should treat it as the central product constraint.

Designing the AI Picker

The AI Picker selects one approved atom for each layout slot based on borrower context.

Potential inputs include:

• Loan type.
• Plan type.
• Interest-waiver state.
• Approval or e-sign stage.
• Urgency.
• Prior engagement.
• Borrower history.
• Journey stage.
• Available eligible content.

The picker must not generate unapproved claims during send-time assembly.

It should select from approved content unless a separate generation-and-review workflow exists.

The selection process looked like this:

Borrower enters journey
  |
  v
Retrieve borrower and loan traits
  |
  v
Determine eligible layout
  |
  v
Retrieve approved atoms for each slot
  |
  v
Apply compliance and eligibility rules
  |
  v
Rank eligible atoms
  |
  v
Select one atom per slot
  |
  v
Assemble rendered email
  |
  v
Log the complete decision

The distinction between retrieval, filtering, ranking, selection, and generation matters.

Retrieval finds candidate content.

Eligibility filtering removes content that cannot be used.

Ranking orders eligible options.

Selection chooses the content for a slot.

Generation creates new language.

A regulated platform should not blur those steps.

Building testing and preview infrastructure

Testing one generic contact is not enough for a combinatorial personalization system.

The sandbox needed representative borrower profiles:

• Emergency loans.
• Routine loans.
• Standard plans.
• Interest-waived plans.
• Approval journey.
• E-sign journey.
• Multi-loan scenarios.
• Different engagement states.

The sandbox should support:

• Rendered HTML preview.
• Mobile preview.
• Atom-selection explanation.
• Manual override.
• Re-rendering.
• Internal test sends.

The goal is to expose problems before the message reaches a borrower:

• Empty slots.
• Incompatible content.
• Disclosure issues.
• Layout failures.
• Unexpected atom selection.
• Repetitive messaging.
• Missing fallbacks.

The platform has to show not only what rendered, but why it rendered.

Making journeys behavior-aware

The platform also needed journey awareness.

Content selected at entry is one layer. Content adapted based on behavior during the journey is another.

Example:

Email 1 sent
  |
  v
Borrower clicks CTA within 24 hours?
  |
  +-- yes
  |     |
  |     v
  |   send more advanced Email 2 variant
  |
  +-- no
        |
        v
      send standard Email 2

Journey awareness could use clicks, opens, replies, product activity, payment behavior, and stage changes.

That adaptation still has to respect:

• Channel consent.
• TCPA rules for SMS paths.
• Frequency controls.
• Suppression.
• Journey exit conditions.
• Regulatory approval.

Behavior-aware does not mean uncontrolled.

Creating the conversion learning loop

The defined conversion was a payment made within seven days of the email send.

Every send should log:

• Borrower profile.
• Loan traits.
• Layout.
• Selected atoms.
• Engagement events.
• Payment outcome.
• Conversion window.
• Journey context.

The platform should separate fast signals from slow signals.

Fast signals include:

• Click within 24 hours.
• Reply.
• Immediate product action.

Fast signals can change the next action inside the current journey.

Slow signals include:

• Payment within seven days.

Slow signals help evaluate content performance and improve future picker decisions.

Those should not be collapsed into one generic "AI learning" idea. Fast signals support in-flight orchestration. Slow signals support evaluation and future optimization.

Insights, confidence, and recommendations

The insights layer should show atom performance:

• Click-through rate.
• Conversion rate.
• Usage volume.
• Trait combination.
• Layout.
• Journey stage.

It should also show audience insights:

• Which borrower traits correlate with conversion.
• Which segments have weak content coverage.
• Which profiles respond differently to certain themes.

Picker confidence matters too:

• Profiles with strong historical evidence.
• Profiles with limited data.
• Combinations with uncertain performance.
• Slots where multiple atoms perform similarly.

Recommendations might include:

• Draft more emergency-loan CTA variants.
• Test a different main-message atom for routine borrowers.
• Retire an underperforming approved atom.
• Increase exploration for a low-data segment.
• Review an atom that performs well on clicks but poorly on payments.

Recommendations still need human review and approval.

Regulatory and operational tradeoffs

The platform had real tradeoffs.

Personalization depth creates operational complexity.

Modular approval reduces review volume, but it increases combination-level risk.

AI selection gives flexibility, but deterministic rules may be safer for some slots.

Click optimization can conflict with payment optimization.

Runtime flexibility can weaken auditability if the logging model is weak.

Marketer autonomy has to sit inside compliance controls.

Reusable atoms can create scale, but message coherence still has to be protected.

Exploration can improve learning, but customers should not receive inconsistent or strange messaging.

Automation helps, but human review remains part of the product.

The architecture has to stay maintainable. A sophisticated system that nobody can operate becomes a different kind of problem.

Lessons learned

Regulated personalization has to start with content governance.

The safest AI pattern here is approved-content selection, not unrestricted send-time generation.

Versioning is not admin overhead. It is what makes the system auditable.

Trait coverage matters before the picker ever runs.

Layouts need rules instead of drag-and-drop freedom alone.

Fast and slow signals should do different jobs.

Human approval is not a blocker to AI adoption. In a regulated environment, it is part of the product.

The bigger idea is that lifecycle personalization should not scale through duplicated templates forever.

It should scale through content infrastructure, decisioning, testing, governance, and measurement.