Chapter 15: Review and Deploy

The Problem

AI generated a segment. It looks right. But how do you know it won't accidentally email your entire database? Or target the wrong audience? Or break something in production?

This chapter teaches you to validate, test, and deploy with confidence.

The Key Idea

Core concept

Never push without validation. Every configuration goes through: validate → preview → dry-run → push.

This workflow catches errors before they reach customers.

The Deployment Workflow

Step	What Happens
Pull	Download current state from remote
Edit	Make changes locally (with AI)
Validate	Check syntax with --dry-run
Preview	Verify audience looks right
Push	Go live!

Each step catches different types of problems.

Step 0: Pull

Before editing, pull the current state:

tdx sg pull "Customer 360"

This creates local files in segments/customer-360/:

segments/customer-360/
├── high-value-customers.yml
├── recent-buyers.yml
└── marketing/
    └── email-subscribers.yml

Now you can edit these files or ask AI to create new ones.

Step 1: Validate

Validation checks syntax and references:

> "Validate my segment"

AI runs tdx sg push --dry-run:

Validating: segments/customer-360/high-value-customers.yml

✓ YAML syntax is valid
✓ All attributes exist in parent segment
✓ All operators are valid for field types
✓ All referenced segments exist
✓ All connections exist and are authorized

Validation passed. No changes to push (dry run).

What validation catches:

• Typos in field names (ltv vs lifetime_value)
• Invalid operator/field combinations (Greater on a string field)
• References to non-existent segments
• Missing required fields (unit for TimeWithinPast)

What validation doesn't catch:

• Logic errors (wrong threshold values)
• Business mistakes (targeting wrong audience)

Step 2: Preview

Preview shows who would be affected:

> "Preview the segment"

AI runs tdx sg show "High-Value Customers":

Segment: High-Value Customers
Estimated size: 3,247 customers

Sample members:
┌─────────────┬─────────────────────┬─────────────┐
│ customer_id │ email               │ ltv         │
├─────────────┼─────────────────────┼─────────────┤
│ C-44821     │ sarah@example.com   │ $2,450.00   │
│ C-91023     │ mike@company.org    │ $1,890.00   │
│ C-33892     │ lisa@business.com   │ $1,234.00   │
└─────────────┴─────────────────────┴─────────────┘

You can also query the segment directly:

tdx sg sql "High-Value Customers" | tdx query -

What preview shows:

• Audience size
• Sample members with actual field values

Ask yourself:

• Is the size reasonable?
• Do the sample members look right?
• Are the field values what you expected?

Step 3: Dry Run

Dry run shows exactly what would change:

> "Push the segment with dry run"

AI runs tdx sg push --dry-run:

DRY RUN - No changes will be made

Comparing local files with remote...

segments/customer-360/high-value-customers.yml
  ~ rule.conditions[0].operator.value: 500 → 1000
  + rule.conditions[1]: (TimeWithinPast 30 day)
  ~ activations[0].schedule.type: hourly → daily

Summary:
  Modified: 1 segment

No changes were made. Run without --dry-run to apply.

What dry run shows:

• Line-by-line differences between local and remote
• All fields that would change

Ask yourself:

• Are these the changes I intended?
• Is the impact acceptable?
• Will downstream systems handle this?

Step 4: Push

When everything looks right:

> "Push the segment"

AI runs tdx sg push:

Pushing segments to Customer 360...

segments/customer-360/high-value-customers.yml
  ~ rule.conditions[0].operator.value: 500 → 1000
  + rule.conditions[1]: (TimeWithinPast 30 day)
  ~ activations[0].schedule.type: hourly → daily

Proceed? [y/N] y

✓ Updated: High-Value Customers

Push complete. 1 segment updated.

The segment is live. Customers will be affected by the next activation sync.

Reviewing AI-Generated Code

When AI generates configuration, always verify:

1. Ask AI to explain it:

> "Explain this segment in plain English"

2. Check the logic matches intent:

# AI generated this - does it match "high-value recent buyers"?
name: High-Value Recent Buyers
kind: batch

rule:
  type: And
  conditions:
    - type: Value
      attribute: lifetime_value
      operator:
        type: Greater
        value: 1000           # Is $1000 the right threshold?
    - type: Value
      attribute: last_purchase_date
      operator:
        type: TimeWithinPast
        value: 30             # Is 30 days "recent"?
        unit: day

3. Verify sample data:

> "Show me 5 customers who would be in this segment"

Common Validation Errors

"Attribute not found"

✗ Attribute 'ltv' not found in parent segment
  Available attributes: lifetime_value, total_orders, last_purchase_date...

Fix: Run tdx sg fields to see available field names.

"Invalid operator for type"

✗ Operator 'Greater' cannot be used with string field 'country'
  Valid operators for string: Equal, NotEqual, In, NotIn, Contain, StartWith, EndWith

Fix: Use an appropriate operator for the field type.

"Missing unit for time operator"

✗ TimeWithinPast requires 'unit' field
  Valid units: year, quarter, month, week, day, hour, minute, second

Fix: Add unit: day (singular form, not days).

"Connection not found"

✗ Connection 'salesforce-dev' not found
  Available connections: salesforce-prod, google-ads-main...

Fix: Run tdx connection list to see available connections.

If Something Goes Wrong

Made a mistake after pushing? Your options:

1. Fix and push again:

> "Change the threshold back to 500 and push"

The new push overwrites the current configuration.

2. Pull the current state:

tdx sg pull "Customer 360"

This downloads all segments from the parent segment, so you can see what's currently live and fix it.

3. Disable temporarily:

> "Disable the Salesforce activation while I fix this"

Stops syncing while you correct the issue.

Version Control

For proper rollback with full history, use Git. Chapter 16 shows how to track every change and revert mistakes with a single command.

Mental Model: Local First

Your local files are the source of truth. The workflow is:

1. Pull what's on the server
2. Edit locally (AI helps here)
3. Push when ready

The --dry-run flag lets you see what would change before committing. Use it when you're unsure.

Pitfalls

"I pushed without dry run and it was wrong."

Fix and push again immediately:

> "Change the threshold back to 500 and push"

"Validation passed but the segment is still wrong."

Validation only checks syntax. You must verify logic:

> "Explain why customer X is/isn't in this segment"

"The audience size changed unexpectedly."

Check if underlying data changed:

> "Why did the segment size change from yesterday?"

What You've Learned

• Always follow: validate → preview → dry-run → push
• Validation catches syntax errors, not logic errors
• Preview shows who would be affected
• Dry run shows exactly what would change
• Fix and push again when something goes wrong
• Use Git for proper version history (next chapter)
• You are responsible for verifying AI's work

Next Step

You can deploy safely. For teams, Chapter 16 introduces Git—tracking changes, collaborating, and maintaining history across your marketing configurations.

---

You can ship with confidence. For team collaboration, the next chapter awaits.