Why we built a DSL, not a drag-and-drop policy builder
When we started designing the policy authoring experience in Sentry, every stakeholder in every meeting had the same first instinct: build a drag-and-drop UI. Non-technical compliance leads should be able to add a rule by picking from a list of pre-built blocks.
We spent two weeks mocking it up. Then we killed it. Here is why.
The audit tells you the answer
Policies are not configuration. They are code. The question an auditor will ask you about a policy is not "what does this policy do" — it is "what did this exact policy do on March 14 at 15:22:08 UTC when it blocked that specific request".
Answering that question requires three properties: the policy must be versionable, diffable, and content-addressable. UI builders fail all three. A policy expressed as a graph of block-UI nodes cannot be stored in Git and cannot be diffed in a pull request. The audit trail of "someone dragged a block from one column to another" is unhelpful testimony.
The regex argument
Half the policies our customers write are variations on "match a specific string pattern, apply a specific action". Regex is the shortest expression of that intent. Attempting to express the same thing in a visual builder adds between 4 and 11 clicks per policy — we measured — without adding any power the regex didn't have.
# This is the entire PII: US Social Security policy.
match: /\b\d{3}-\d{2}-\d{4}\b/
action: deny
reason: US SSN detectedIn SentryDSL, the policy above is four lines. The compiled bytecode is 42 bytes. The content hash is 64 characters. All three are stable until the policy actually changes. A UI builder cannot match any of these guarantees.
The compliance person question
The common objection to a DSL is that non-engineers cannot write it. In practice we found the opposite — compliance leads prefer SentryDSL because they can read it. They can look at a policy source file and understand what it does without a translation layer. A UI builder requires training on the specific UI; the DSL is self-documenting.
Where a compliance lead needs engineering help, it is for the regex itself. We ship a Playground where you paste a prompt and the UI tells you which policies fire. That turned out to be the collaboration surface that mattered — not the authoring step itself.
What a UI builder is actually good for
There is one place where a UI builder beats a DSL: initial authoring by a non-technical user who will never again edit the policy. For that single scenario, we offer a template picker — click an industry preset, Sentry generates the DSL file, and from that moment forward it is a code artifact. The UI is a seed, not an editor.
Policy-as-code is the only compliance-safe path
If you take one thing from this post: compliance teams increasingly expect policy-as-code. The next generation of auditors — the ones hiring now — are coming out of CI/CD cultures and ask for Git history on policy changes. If your platform cannot produce a GitHub pull request showing exactly what changed, when, and by whom, you are already behind. SentryDSL is our bet that this is where the industry is going, and our customers have validated it.