operator runbooks

Intended Documentation

Simulate Policy Impact

How to simulate policy changes before deploying, including compare mode, drift detection, and blast radius analysis.

intermediate5 min readimplemented

Simulate Policy Impact#

Before deploying a policy change to the Intended runtime, simulate its impact to understand exactly which decisions will change. This runbook covers compare mode, drift detection, and blast radius analysis.

Prerequisites#

The Intended CLI installed and authenticated
A validated policy file (see Author a Policy)
Access to the target workspace decision logs

Tip

Simulation is read-only. It never modifies the active runtime configuration. Run simulations freely and frequently.

Compare Mode#

Compare mode evaluates the differences between the currently active policy set and your proposed changes. It replays recent decision history through both versions and highlights divergence.

Run a Comparison#

$meritt policy simulate compare

Compare current active policies against proposed changes.

--proposed(-p)string *

Path to the proposed policy file or directory

--window(-w)string

Time window of decisions to replay (default: 24h)

--environment(-e)string

Target environment to simulate against

--format(-f)string

Output format: table, json, yaml (default: table)

bash

$ meritt policy simulate compare \
    --proposed policies/restrict-staging-writes.yaml \
    --window 7d \
    --environment staging

Replaying 14,302 decisions from the last 7 days...

COMPARISON SUMMARY
─────────────────────────────────────────────────
Decisions replayed:     14,302
Unchanged:              14,118  (98.7%)
Changed (allow → deny):    147  (1.0%)
Changed (deny → allow):     37  (0.3%)
─────────────────────────────────────────────────

Top affected identities:
  svc:data-pipeline-runner    89 decisions changed
  user:deploy-bot             41 decisions changed
  svc:batch-processor         31 decisions changed
  user:alice                  23 decisions changed

Warning

Pay close attention to allow → deny changes. These represent operations that currently succeed but will be blocked after deployment. Coordinate with affected service owners before proceeding.

Inspect Individual Changes#

Drill into specific decision changes to understand the root cause:

bash

$ meritt policy simulate compare \
    --proposed policies/restrict-staging-writes.yaml \
    --window 7d \
    --environment staging \
    --format json \
    --filter changed \
    --limit 5

[
  {
    "decisionId": "dec_x7k9m2",
    "timestamp": "2026-03-05T14:23:01Z",
    "identity": "svc:data-pipeline-runner",
    "action": "write",
    "resource": "env:staging/service-b",
    "currentResult": "allow",
    "proposedResult": "deny",
    "reason": "New rule requires approval:1 from role:data-lead"
  }
]

Drift Detection#

Drift detection identifies discrepancies between the policies defined in your repository and what is currently active in the runtime.

Check for drift

$meritt policy drift detect

Detect differences between repository policies and the active runtime.

--source(-s)string

Path to the policy directory (default: ./policies)

--environment(-e)string

Target environment to check

bash

$ meritt policy drift detect \
    --source policies/ \
    --environment production

Comparing local policies against production runtime...

DRIFT REPORT
─────────────────────────────────────────────────
Policies in sync:       12
Policies with drift:     2
Policies missing local:  0
Policies missing remote: 1
─────────────────────────────────────────────────

DRIFTED POLICIES:
  restrict-production-writes  (rule count: local=3, remote=2)
  audit-all-deletes           (condition mismatch in rule[0])

MISSING FROM REMOTE:
  restrict-staging-writes     (exists locally, not deployed)

Inspect drift details

bash

$ meritt policy drift diff restrict-production-writes \
    --environment production

--- remote (active)
+++ local (repository)
@@ rules[2] @@
+ - action: escalate
+   effect: deny
+   conditions:
+     - type: trust-level
+       minimum: 0.9

Resolve drift

Decide whether to update the local policy to match the runtime or redeploy the local version. If the runtime was modified outside the standard workflow, investigate why before overwriting.

Danger

Drift often indicates an out-of-band change was made directly to the runtime. This bypasses review and audit controls. Treat drift as a security incident and investigate the root cause before resolving.

bash

# Pull the runtime version to inspect it
$ meritt policy pull restrict-production-writes \
    --environment production \
    --output policies/restrict-production-writes.runtime.yaml

Blast Radius Analysis#

Blast radius analysis quantifies the scope of impact for a proposed change across services, identities, and environments.

$meritt policy simulate blast-radius

Analyze the scope of impact for a proposed policy change.

--proposed(-p)string *

Path to the proposed policy file

--environment(-e)string

Target environment

--threshold(-t)number

Alert threshold for affected decisions as a percentage (default: 5)

bash

$ meritt policy simulate blast-radius \
    --proposed policies/restrict-production-deploys.yaml \
    --environment production \
    --threshold 2

BLAST RADIUS ANALYSIS
─────────────────────────────────────────────────
Environment:            production
Affected services:      3 / 28
Affected identities:    7 / 142
Affected decisions:     4.2% of trailing 30d volume

⚠ THRESHOLD EXCEEDED (4.2% > 2.0%)

SERVICE BREAKDOWN:
  service-a          12 decisions affected
  service-b          89 decisions affected
  batch-processor    46 decisions affected

IDENTITY BREAKDOWN:
  svc:deploy-bot               41
  svc:data-pipeline-runner     38
  user:alice                   23
  user:bob                     18
  svc:batch-processor          14
  user:carol                    8
  svc:monitoring-agent           5

Warning

When the blast radius exceeds your configured threshold, the deployment pipeline will require additional approval. See Deploy and Rollback for approval gate details.

Narrowing the Blast Radius#

If the impact is too broad, refine your policy scope:

bash

# Check which rules contribute most to the blast radius
$ meritt policy simulate blast-radius \
    --proposed policies/restrict-production-deploys.yaml \
    --environment production \
    --verbose \
    --group-by rule

RULE CONTRIBUTION:
  rules[0] (action: deploy, effect: deny)     87% of affected decisions
  rules[1] (action: escalate, effect: deny)   13% of affected decisions

Consider adding exceptions for trusted service accounts or narrowing the scope to specific services before deploying.

Simulation Best Practices#

Practice	Rationale
Simulate against 7 days minimum	Captures weekly patterns (batch jobs, scheduled deploys)
Run blast radius before every deploy	Prevents unexpected service disruption
Investigate all drift before deploying	Ensures repository remains the source of truth
Save simulation reports	Attach to review requests for auditor visibility

Next Steps#

Author a Policy — create or modify policy definitions
Deploy and Rollback — move from simulation to production deployment
Incident Response — investigate when something goes wrong after deployment