Rules Builder
Rules Builder is where teams turn policy expectations into enforceable logic. Create visual threshold rules for common use cases or use Rego when you need precise logic, reusable conditions, and versioned policy workflows.
Rules created here drive alerts, review queue routing, and evidence readiness, so treat this workspace as part of your live operating model.
Rules
The Rules Builder is VeriProof’s policy authoring workspace. Rules define the conditions your applications must meet, then drive alerts, review routing, and framework evidence. Two rule types are supported: metric rules for threshold-based checks and Rego policy rules for more advanced logic.
Authoring rights differ significantly by role. Administrators and Governance Engineers can author Rego and metric rules. Compliance Officers have read-only access and can review AI-generated policy suggestions. Business Owners can view active rules only — they do not see the policy suggestions queue. Only Administrators can delete rules permanently.
You are the primary author of Rego policy rules. Validate your logic in the Playground against live session data before activating. On Production applications, activating a rule requires an Administrator or Compliance Officer to approve your request. Your draft appears in their Focus Queue automatically.
You are the only role that can permanently delete rules. Use Draft state to deactivate a rule without losing its version history. You and Compliance Officers are the approval authority for production rule activation requests raised by Governance Engineers — these appear in your Focus Queue with the draft rule context attached.
You can view all active and draft rules, review AI-generated policy suggestions, and flag suggestions for Governance Engineer follow-up. You cannot author rules, but your perspective on which policy suggestions to prioritize directly shapes the governance roadmap.
You can view active policy rules to understand what governance controls are in effect across your applications — without needing to understand the Rego syntax behind them. Policy authoring and the suggestions queue are handled by your Governance Engineers and Compliance Officers.
Rule Types
Metric Rules
Metric rules evaluate structured policy fields against threshold conditions. They are authored with a visual condition builder, so most teams can create useful checks without writing code.
Supported condition fields:
| Field | Type | Example condition |
|---|---|---|
| Risk level | Enum | risk_level is CRITICAL |
| Policy score | Numeric | score is below 60 |
| Decision outcome | Enum | outcome is FAILURE |
| Guardrail action | Enum | guardrail_action is blocked |
| Model confidence | Numeric (0–1) | confidence < 0.7 |
| Intent label | String | intent contains "loan" |
| Has human oversight | Boolean | human_oversight is false |
| Model identifier | String | model equals "gpt-4o" |
| Session step count | Numeric | step_count > 20 |
| Token count | Numeric | total_tokens > 8000 |
Conditions are combined with AND / OR logic. Parenthetical grouping is supported for complex expressions.
Rego Policy Rules
For organizations with more complex policy requirements, VeriProof supports Rego, the policy language of Open Policy Agent (OPA). Rego rules receive the complete session document as input and return a Boolean result (allow) or a violation object.
When to use Rego:
- You need to express policy logic that compares multiple steps in a session
- You want to encode a regulatory requirement as executable policy
- You need to inspect nested annotation structures
- You are already using OPA elsewhere in your infrastructure and want consistent policy authorship
The Rego editor in the portal includes:
- Syntax highlighting and bracket matching
- A Test panel where you can paste sample session documents and evaluate the policy immediately without saving
- An Explain button that shows the OPA trace for your test evaluation
- Version history with diff view
Rego policy rules execute synchronously on every session evaluation. Poorly written policies (e.g., policies that loop over unbounded arrays without guards) can increase evaluation latency. Use the Test panel to validate performance before activating.
Creating a Metric Rule
- Navigate to Rules and click New Rule.
- Select Metric rule.
- Enter a Name and optional Description.
- Set the Scope: All Applications, a specific application, or a filtered subset.
- Build your condition expression using the condition builder.
- Configure Actions (see below).
- Click Save as draft to save without activating, or Save & Activate to put it into immediate effect.
Creating a Rego Policy Rule
- Navigate to Rules and click New Rule.
- Select Rego policy rule.
- Enter a Name and optional Description.
- Set the Scope.
- Write your policy in the Rego editor. Your policy must define an
allowrule that returnstrue(session passes) orfalse(session fails the policy). - Use the Test panel to validate your policy against sample session data.
- Click Save as draft or Save & Activate.
Rule Actions
Every rule has one or more actions that fire when the rule matches a session:
| Action type | Description |
|---|---|
| Email notification | Send an email to one or more addresses |
| Webhook | POST to a configured webhook endpoint |
| In-portal alert | Create a visible alert in the portal notification center |
| Add to review queue | Add the matching session to a named Review Queue |
| Escalate to compliance | Mark the session as requiring compliance officer review |
Actions support throttling: you can configure a minimum interval between repeated firings to prevent notification floods during mass incidents.
Template Gallery
Click Template Gallery to browse pre-built rule templates for common policy scenarios. See Policy Rule Templates for the full catalogue and guidance on applying and customizing them.
Rule Versioning
Every change to a rule — condition edits, action changes, activation or deactivation — is recorded as a new version in the rule’s history. To view history:
- Open the rule detail page.
- Click History in the right panel.
- Select any two versions to see a side-by-side diff.
You can roll back to any previous version by clicking Restore this version.
Use descriptive rule names and the Description field to document why a rule exists, not just what it does. Auditors often review rule configuration as evidence of your risk management process.
Rule Evaluation Order
When multiple rules match the same session, all matching rules fire — there is no priority ordering or short-circuit evaluation. Design rules to be independent; avoid creating rules that depend on the evaluation result of other rules.
Related Documentation
Pre-built templates for common AI risk scenarios across major regulatory frameworks.
Policy Rule TemplatesDetailed guide to conditions, actions, throttling, and notification channel setup.
Alert Rules GuideConfigure human-in-the-loop review workflows triggered by rule actions.
Review QueuesSet up outbound webhook endpoints for rule notification actions.
Webhooks