Decision-Capable Components in Practice

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.

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.

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.

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.

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_Sale list for Germany and APAC_Seasonal for Japan).

• Layer 3 (Execution): The component receives the raw data for a specific product: Current Price: 50, Original Price: 100.

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.

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.

Compliance is external risk.

Scalability is internal risk.

Both are governed at execution.

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.

A CRM team manages:

• 50+ automated scenarios

• A weekly newsletter

• 10 markets

Templates are cloned. Rows are saved.

Everything works.

Until something changes.

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.

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.

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:

• Market-based feed resolution

• Currency syntax & locale formatting

• Localized content resolution

• Inventory thresholds

• Eligibility gates

• Product exclusions based on customer history

• Manual SKU support with enforcement

• Conditional attribute visibility

• Discount simulation logic

• Asset validation

• Text normalization

• Tracking automation

• Dynamic layout calculation

• Device-aware rendering

• Circuit breaker authority (abort when output invalid)

This is not feature expansion.

It is responsibility consolidation.

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.

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.