← Back to Build Log
build-logengineeringpolicy-engine

Policy propagation rethink

Ran into an interesting problem this week. When you update a policy, how quickly should it take effect? The obvious answer is "immediately" but that creates a class of surprises where an operator changes a rule and suddenly 50 pending actions get blocked that were going to be allowed.

The better answer is propagation with visibility. When a policy changes, the system evaluates what currently pending actions would be affected and shows that to the operator before applying. Not a confirmation dialog. More like a preview. "This change will affect 12 pending evaluations. 3 will change from ALLOW to BLOCK."

Implemented a dry-run mode for policy updates. You can submit a new policy version and see what would change across all current and recently evaluated intents without actually applying it. This is not a diff of the policy text. It is a diff of the policy behavior.

Also tightened the relationship between policy versions and receipts. Every receipt now includes both the policy version it was evaluated against and a flag indicating whether a newer policy version existed at finalization time. If an action was allowed under policy v3 but executed under policy v5, that is information the operator needs.

Policy changes need to propagate fast but not surprise anyone.