FAQ

How much integration is required?

One-time setup at decision points. No code changes after that.Level 1: Hook Points (One-Time)You wrap your existing code at decision points:

// Before
func handlePayment(req PaymentRequest) Response {
    result := paymentService.Process(req)
    return result
}

// After (with LiveOps)
func handlePayment(req PaymentRequest) Response {
    ctx := liveops.BuildContext(req)
    decision := liveops.Evaluate(ctx, "http.request")

    if decision.ShouldBlock() {
        return decision.BlockResponse()
    }
    if decision.HasFallback() {
        return decision.Fallback()
    }

    result := paymentService.Process(req)
    return result
}

This is the only code change. You add it once per hook point.Level 2: Policy Changes (Zero Code)

Scenario	Without LiveOps	With LiveOps
Block a tenant	Code change, PR, Review, Deploy	Update policy JSON, Hot reload
Add timeout override	Code change, Deploy	Update policy JSON
Return fallback response	Code change, Deploy	Update policy JSON
Change retry count	Code change, Deploy	Update policy JSON
Rollback bad change	Rollback deploy	Revert policy JSON

Once hooks are in place, runtime changes require no code changes.

What's the difference from feature flags?

Feature flags toggle pre-coded variants. LiveOps injects new behavior.Feature Flags (LaunchDarkly, etc.)

// You must pre-code ALL variants
if featureFlag.isEnabled("use-new-timeout") {
    timeout = 500  // Hardcoded!
} else {
    timeout = 1000  // Hardcoded!
}

Limited to what you anticipated and coded.LiveOps

// Value comes from policy at runtime
decision := liveops.Evaluate(ctx, "call.before")
timeout := decision.TimeoutOverride()  // ANY value

Not limited to pre-coded variants.

What are Invariants vs Dynamic Values?

This is the core architectural insight behind LiveOps.Invariants (Your Code)Structure, flow, and contracts that don’t change during incidents:

Request validation logic
Database schema and queries
API contracts (input/output shapes)
Business rules
Integration points (which services exist)

Dynamic Values (Policy)Operational parameters that might need to change at runtime:

Which requests to allow/block?
What timeout for this dependency?
What to return when dependency fails?
Who gets the new behavior?
How many retries?

The ProblemMost code mixes invariants and dynamic values. When “dynamic” parts need to change, you change code. That’s a deploy. That’s risk.The SolutionSeparate invariants (code) from dynamic values (policy):

	Invariants	Dynamic
Changes	Monthly	Hourly / Per-incident
Risk	High (deploy)	Low (policy reload)
Rollback	Redeploy	Revert JSON
Owner	Engineers	Engineers + SRE + On-call

Is it safe for production?

Yes. LiveOps is designed with production safety as the primary constraint:

Fail-open: Errors in patch evaluation allow requests through
Hard timeout: Evaluation terminates in under 10ms regardless of policy complexity
Pure evaluation: Engine returns decisions, never performs I/O
Deterministic: Same input always produces same output
Blast radius controls: Canary %, tenant targeting, region filtering

Test before you deploy:

Traffic capture: Record live production traffic for simulation
Policy simulation: Replay captured traffic against new policies to see exactly what would change
Diff reports: See which requests would be blocked, modified, or passed through before deploying
Canary rollouts: Start with 1% of traffic, validate metrics, then gradually increase

You know exactly what a policy will do before it touches production.

How do I promote a policy to production code?

LiveOps policies are meant to be temporary runtime patches, not permanent infrastructure. Here’s the lifecycle:Step 1: Incident ResponseDeploy a policy to mitigate the issue immediately (seconds).Step 2: StabilizationPolicy runs in production. You validate it’s working. Days or weeks pass.Step 3: Code PromotionWrite the equivalent logic in your codebase. Deploy with the policy still active as a safety net.Step 4: Disable PolicyOnce the code is verified, disable the policy:

liveops disable payment-fallback
# or set canary_percent: 0

Takes effect in seconds.Step 5: Code Bug? Instant RollbackIf your new code has issues, re-enable the policy immediately:

liveops enable payment-fallback

You’re back to the known-good behavior in seconds while you fix the code.

Phase	Who handles the behavior
Incident	LiveOps policy (instant)
Stabilization	LiveOps policy (validated)
Code deployment	Both (policy as fallback)
Post-verification	Code only (policy disabled)
Code bug discovered	Re-enable policy instantly

Key insight: LiveOps acts as a safety net during code transitions, not a replacement for code.

See It In Action

20-minute demo. No sales pitch.

Overview

Resources

See It In Action