← Back to Build Log
build-logengineeringpolicy-engine

Policy format and explainability

Moved away from anything that feels like inventing a new programming language for policies. That direction leads to complexity nobody wants to maintain. Instead, the format stays declarative and the evaluation stays deterministic. Policies are mergeable by default so teams can layer organization-wide rules on top of project-specific ones without conflicts.

Added rule matching output so you can see which rules matched and why a particular decision was reached. This matters because when someone gets a BLOCK and wants to know why, "policy said no" is not an answer. They need to see the specific rule, the specific match, and the reasoning chain.

Also pinned stable policy version references that get attached to every receipt. When you look at a receipt from three months ago, you need to know exactly which version of the policy was in effect. Not "roughly what the policy looked like at the time." The exact version.

The policy surface needs to stay universal and not become tool-specific. A policy that only works for GitHub actions but not Stripe actions is not a policy engine. It is a GitHub plugin.