Decision-Capable Components in Practice
Where Execution Responsibility Actually Lives
Where This Series Leads
Article 1 reframed email as a send-time system.
Article 2 showed why render-only components fail once responsibility increases.
This final article answers the architectural consequence:
If email executes decisions at send time,
where does responsibility for correctness actually live?
Not in selection.
Not in campaign setup.
Not in preview.
Responsibility lives at the rendering boundary, where output becomes final.
The Missing Responsibility
Modern CRM systems are excellent at answering:
Which products are relevant?
Which customers should receive a message?
When should a campaign be sent?
But they often leave one question implicit:
Is this exact output valid to send right now,
for this customer, in this context?
That question cannot be fully answered at design time.
At send time:
Catalog data is resolved
Pricing is current
Stock is live
Customer context is known
Campaign metadata is applied
Owning that final validation is the responsibility of a decision-capable component.
The Three Layers of a Send-Time System
To remove ambiguity, responsibilities separate into three layers:
Layer 1: Product Eligibility & Ranking
Handled by the recommendation engine.
Stock. Status. Scope. Discount filters. Ranking.
Layer 2: Selection & Orchestration
Which recommendation to call.
Fallback chains. Campaign-based conditions.
Layer 3: Execution Governance
Structural rules.
Market-specific presentation.
Campaign constraints.
Localization correctness.
The authority to refuse output.
This article is about Layer 3.
Because this is where systems either scale or fragment.
Why “Enforce It Earlier” Fails
A common assumption is:
“Just enforce correctness earlier.”
In catalog preparation
In recommendation logic
In campaign configuration
Those layers make decisions in advance.
But send-time execution introduces variables that are resolved only at that moment:
market and legal context
pricing and availability changes
localization requirements
campaign-specific constraints
data completeness at the moment of render
Upstream systems may behave perfectly, and the final output can still be wrong.
That is the gap.
Example 1: The “Reference Price” Conflict
Scenario:
A global fashion retailer launches a centralized “Mid-Season Sale” campaign across Germany (EU), the UK, and Japan.
Layer 1 (Eligibility): The recommendation engine filters eligible products for this campaign.
Layer 2 (Selection): The orchestration logic identifies which recommendation strategy to call for each market (e.g., fetching the
EU_Spring_Salelist for Germany andAPAC_Seasonalfor Japan).Layer 3 (Execution): The component receives the raw data for a specific product:
Current Price: 50,Original Price: 100.
The Conflict:
Layer 3 now performs two functions:
Localization (currency formatting)
Governance (claim validation)
Governance is where the conflict emerges. Discount comparison rules differ by market:
Germany (EU Omnibus Directive):
The strike-through price must be the lowest price in the previous 30 days.UK (Pricing Guidance):
A “Was/Now” comparison must reflect a genuine prior selling period.Japan (Double-Price Rules):
The original price must have been effective for a significant recent duration.
The catalog provides the numbers. If the component blindly renders:
100 €50 €
The currency is correct.
The math is correct.
The implied claim may not be.
The output may create regulatory exposure in that market.
Decision-Capable Enforcement
At send time, the component must evaluate:
Germany: Does OriginalPrice equal the 30-day low?
UK: Is the comparison still valid relative to price history?
Japan: Does the historical duration satisfy display rules?
If not:
Suppress the strike-through.
Layer 1 selects products.
Layer 2 selects strategy.
Layer 3 governs the claim.
That responsibility exists only at the rendering boundary.
Governance Is Not Only About Compliance
Compliance is external risk.
Scalability is internal risk.
Both are governed at execution.
Example 2: Operational Scalability & The “Update Trap”
While Example 1 focused on External Risk (Legality), this example focuses on Internal ROI (Time and Maintenance). This is where the CRM team moves from manual production to automated architecture.
Scenario:
A CRM team manages:
50+ automated scenarios
A weekly newsletter
10 markets
Templates are cloned. Rows are saved.
Everything works.
Until something changes.
The Update Trap
Brand updates the primary CTA color.
Legal updates an EU disclaimer.
Because templates are static assets:
The CRM team must manually open, edit, and re-QA every campaign.
A 5-minute requirement becomes a 3-day audit.
Each new market multiplies maintenance effort.
This is not a personalization problem.
It is a governance fragmentation problem.
The Decision-Capable Architecture
In a centralized component architecture:
Campaigns reference a master execution block.
Campaigns do not own the logic.
They call it.
When a rule changes:
The logic updates once.
All campaigns inherit the change at next send-time execution.
Maintenance no longer scales with campaign volume.
Execution logic is decoupled from asset duplication.
The Library of Send-Time Decisions
A decision-capable component behaves less like a template fragment
and more like a controlled execution micro-application.
Its rules typically fall into five domains:
1. Context & Localization
Market-based feed resolution
Currency syntax & locale formatting
Localized content resolution
2. Merchandising & Validation
Inventory thresholds
Eligibility gates
Product exclusions based on customer history
3. Campaign Overrides
Manual SKU support with enforcement
Conditional attribute visibility
Discount simulation logic
4. Technical Integrity
Asset validation
Text normalization
Tracking automation
5. Adaptive Presentation
Dynamic layout calculation
Device-aware rendering
Circuit breaker authority (abort when output invalid)
This is not feature expansion.
It is responsibility consolidation.
Architectural Conclusion
Recommendations select products.
Catalog provides data.
Campaign defines intent.
The component governs whether the final rendered output is:
Valid
Compliant
Structurally sound
Operationally consistent
Centralizing that responsibility at the rendering boundary is what allows CRM operations to scale without proportional increases in maintenance overhead.
Closing the Series
Email is not a document.
It is a system that executes decisions at send time.
Render-only components produce output.
Decision-capable components own responsibility for that output.
As CRM programs grow, the decisive question becomes:
Where does execution responsibility live,
and how many places must you configure it?
Rendering is not the final test.
Governance is.
And governance is decided at send time.