Guardrail principles
- Start restrictive, then expand scope as trust increases.
- Put hard limits around spend, excluded campaigns, markets, and action types.
- Require human approval for material budget, pricing, offer, or paywall changes.
- Define rollback triggers before an action runs.
- Treat guardrails as operational policy, not one-time setup.
Core guardrails
| Guardrail | Purpose | Example |
|---|---|---|
| Daily spend cap | Prevents budget overrun | Do not exceed $12k/day across selected campaigns |
| Weekly spend cap | Controls scaling pace | Increase spend no more than 15% week over week |
| Campaign exclusions | Protects sensitive campaigns | Exclude brand, launch, creator, or holdout campaigns |
| Action type permissions | Limits what FloKit can recommend or execute | Allow budget shifts, block offer changes |
| Confidence threshold | Avoids weak-signal actions | Require high confidence for budget changes |
| Approval policy | Defines human review requirements | Require growth lead approval for all write actions |
| Rollback trigger | Protects against regression | Roll back if CAC increases more than 20% over 72 hours |
Setup process
Define ownership
Assign a growth owner for approval decisions and a data owner for metric and source-of-truth questions.
Set spend limits
Configure daily and weekly budget caps. Use conservative limits until payback reports and recommendations have been validated.
Exclude sensitive campaigns
Exclude brand campaigns, launch campaigns, experiments, creator campaigns, contractual campaigns, and any holdout groups.
Choose allowed action types
Start with low-risk recommendations such as creative review and budget reallocation. Keep pricing, offer, and paywall changes under manual product approval.
Set confidence thresholds
Require stronger confidence for higher-impact actions. Low-confidence recommendations can remain visible but should require manual review.
Define rollback triggers
Choose metrics, thresholds, and time windows for rollback. CAC, spend, trial conversion, refund rate, and payback are common triggers.
Recommended starting policy
| Setting | Conservative default |
|---|---|
| Execution mode | Read-only recommendations |
| Budget changes | Human approval required |
| Creative pauses | Human approval required |
| Audience exclusions | Human approval required |
| Pricing changes | Blocked |
| Offer changes | Blocked unless product owner approves |
| Paywall changes | Blocked unless product owner approves |
| Daily spend increase | Max 10-15% for selected campaigns |
| Rollback | Enabled for CAC, conversion, and spend regression |
Rollback design
A rollback rule should include:- The metric to monitor.
- The baseline period.
- The allowed change threshold.
- The observation window.
- The action to reverse.
- The owner to notify.
| Field | Value |
|---|---|
| Metric | CAC |
| Baseline | Previous 7 days |
| Threshold | Increase greater than 20% |
| Window | 72 hours after action |
| Action | Restore previous budget allocation |
| Notify | Growth lead and data owner |
Review cadence
| Cadence | What to review |
|---|---|
| Daily during rollout | New recommendations, held actions, rollback alerts |
| Weekly | Spend caps, excluded campaigns, confidence thresholds |
| Monthly | Action outcomes, automation scope, markets, reporting tolerance |
| After major launch | All guardrails that touch the affected campaigns or offers |
Signs guardrails are too loose
- Recommendations repeatedly touch campaigns that should be excluded.
- Spend grows faster than leadership expects.
- Rollbacks happen often.
- Product or finance learns about changes after they happen.
- Recommendations optimize conversion while hurting payback.
Signs guardrails are too restrictive
- Most useful recommendations are held.
- Campaigns cannot scale despite validated payback.
- Approval queues become operational bottlenecks.
- Growth owners manually execute the same safe actions every week.