Replay & diff
Edit a policy. Before you save, The Relic replays it against the last 1, 7, or 30 days of your fleet's actual decisions and tells you exactly which verdicts would have changed, with sample run IDs to inspect.
# candidate policy
version: "1"
mode: enforce
rules:
- id: allow-search
target: "web_search"
action: allow
- id: deny-fetch-with-creds
target: "web_fetch"
when: "params.url contains 'token='"
action: deny
Replay · last 7 days
Would deny
42
previously-allowed actions
Would allow
0
previously-denied actions
Unchanged
8,124
verdicts identical
3 sample flipped runs ↓
The trust loop
The replay engine is the same code that enforces policy on the agent's host. No second implementation that could drift. The diff cannot lie about what production will do.
Open the policy editor, draft the rule. Nothing is saved. Your fleet keeps running the old policy.
Pick 1d / 7d / 30d. The Relic re-evaluates every recorded action and reports the deltas, usually under ten seconds.
Click the diff badge. See sample flipped runs side-by-side. Catch unintended consequences before they ship.
What the badge tells you
Would-deny
Actions the rule would have blocked
The headline for tightening changes. The count of previously-allowed actions that would now fail, with sample runs linked.
Would-allow
Actions the rule would have unblocked
For broadening changes. Tells you whether you're letting through denials you didn't intend to.
Unchanged
Verdicts that stay the same
The reassuring number. Zero flips means the edit is a true no-op. Exactly what you want when refactoring.
Engineering note
The replay engine vendors its source from the runtime, and a CI job refuses any drift. The diff badge is computed with the exact bytes that enforce policy on the agent's host.
Your action history is stored alongside your traces. The replay runs against the same Postgres + S3 that the platform uses for live observation, so nothing crosses a trust boundary that the trace data didn't already cross.