Policy Rules

Rules check AI activity against the behavior your organization expects. Open an application’s Policy tab to review or maintain its rules. The application workspace keeps each task in a separate section:

• Rules: Create rules and review how each rule runs.
• Results: Review policy outcomes for recorded activity.
• Coverage: Review setup progress, application data coverage, and blocking readiness in separate views.
• History: Review the latest 50 rule events, ten at a time.
• Application data: Administrators and Developers confirm customer-provided fields when a rule needs them.

The workspace opens the section that best matches your role. A section can be shared as a link without opening every other policy report on the page.

Application data coverage includes only fields that active rules identify as inputs. VeriProof does not grade unrelated application data. If a rule has no policy data version, a Governance Engineer must select one before VeriProof can confirm coverage or blocking behavior. Administrators and Developers do not receive that policy-authoring action.

Who can author and approve rules

Each organization starts with these defaults. An Administrator can change them for each role.

If you hold several roles, switch to the role that owns the task. Development deployment doesn’t use the Production approval path.

Example: send large refunds for review

This rule sends any refund above $500 to a reviewer before it runs. It assumes the application sends the refund amount as a fact, for example facts={"refund_amount": 750}. VeriProof places application facts at input.snapshot.facts.<name>, so this fact is input.snapshot.facts.refund_amount.

1. Open the application’s Policy tab, select Create policy rule, then Create blank policy rule.
2. Under When the rule runs, choose Before action. Under When the rule matches, choose Send for review.
3. In Review logic, leave Apply “Send for review” when activity set to Meets these conditions. That’s the default for new rules.
4. Add the condition Refund Amount is greater than 500. A fact the application has sent but no one has confirmed appears under Sent by the application, not yet confirmed.
5. In Test, add one case with { "snapshot": { "facts": { "refund_amount": 750 } } } and one with 250. Expect Send for review for 750 and Continue for 250.
6. Save the tested version and activate it in Shadow. Compare the proposed results with real activity, then select Enforce.

The application must also handle the review. See Add human review for the SDK prerequisites.

Start from an application

Open the application that the rule will govern. VeriProof uses the application to choose the correct policy data, compare saved fields with recorded activity, identify the responsible Developer, find related rules, and show the supported before-action policy points. These points are defined by VeriProof’s policy contract; selecting an industry does not add new ones.

When a Developer creates an application, VeriProof assigns that person as its responsible Developer. A Governance Engineer can then author policy for the same application without an Administrator repeating the assignment. If the assignment is later removed, the Administrator receives the assignment action.

During Development, the responsible Developer completes setup in the application workspace. New applications and routine activity do not create tasks for every role. A Governance Engineer receives work only for a requested policy handoff, a required coverage gap, or a rule that needs application data. Administrators, approvers, Compliance Officers, and Business Owners receive only the decisions assigned to their role. Auditors review the completed record and do not receive action-required notifications.

The application summary shows ownership, recorded activity, required fields, rules, approvals, and linked work. Check the item that needs attention before creating a new request.

Create a draft

Start with a Standard control when data that VeriProof already provides can express the intended behavior. A Standard control needs no application fields.

In an application’s Policy tab, select New rule. VeriProof first shows three Standard controls. Choose one that matches the intended behavior, browse more starting points, or create a blank policy rule. When the application has an SDK vocabulary, the expanded view shows up to three relevant examples from that external catalog. Select Browse full template library when you need other universal or regulatory templates. A blank rule starts with Describe policy intent. State the behavior and expected outcome. Add scope and examples when they clarify the boundary. If AI drafting is not available, VeriProof names the Administrator action and lets you continue with the guided editor.

From the organization Policy workspace, select Create rule and choose what the rule applies to. One application opens the same authoring workflow as New rule in the application. An application group and The whole organization open the shared policy builder. See Apply one rule to an application group.

Apply one rule to an application group

Use a group rule when several applications need the same control, such as six invoice agents in an Accounts payable group. You write, test, request Developer confirmation for, and activate the rule once. It applies to every application in the group.

1. In the Policy workspace, select Create rule, choose An application group, and choose the group. You can choose only groups you manage. An Administrator manages every group.
2. The builder uses one application in the group as its sample. Its field catalog includes the fields from the group’s field contract.
3. Save the draft and check readiness. Readiness checks every application in the group and lists any application that is missing data.
4. If fields are missing, select Request group fields. One request goes to the responsible Developer of an application in the group. The Developer confirms the fields once in the group’s field contract, and every application in the group uses them.
5. Activate the tested version in Shadow, then Enforce. Approval, change control, and separation of duties work the same way as for an application rule. You can enforce on a few applications first and the rest run the rule in Shadow.

Which applications a group rule covers

• An application added to the group later is covered as soon as it joins. Its data must match the rule’s fields before the next deployment can pass readiness.
• An application removed from the group stops using the rule.
• During a staged rollout, an application that joins the group runs the rule in Shadow until you enforce it everywhere or widen the stage.

The rule’s details list the applications it covers now, each with a link to that application’s results for the rule. Applications outside your access are counted but not named.

How group rules combine with other rules

Every active rule that applies to an application evaluates: the application’s own rules, its groups’ rules, and organization rules. The most restrictive outcome wins: Deny, then Escalate, then Transform, then Warn, then Allow. Where a rule is defined doesn’t change which outcome wins.

Group fields that conflict

A group field contract can’t give a field a different data type from a member application’s own field with the same path, or from another group that shares an application. VeriProof refuses the change and names the conflicting application or group. If a conflict still reaches an application, readiness names the field so a Developer can fix the types.

Inherited rules in an application

An application’s Policy tab lists the group and organization rules it inherits. They’re read-only there. Select Open group rule to change one for every application it covers.

Start from recorded activity

You can also start from one recorded session or a same-application session selection. Select Create rule from this session or Continue in Policy. VeriProof creates a monitoring draft from the shared recorded signals and opens the same application policy workflow. The draft uses the session_activity@v1 data contract. It flags activity that matches the selected pattern; it does not flag every other session. Review and adjust the generated conditions before testing or activation.

The session decision type describes the overall business workflow. Individual steps retain their own outcomes and policy checks.

Generated Rego v1 stays in Advanced Rego. The guided view shows readable conditions. VeriProof prepares positive, negative, and boundary tests only when you accept the generated draft. Canceling the draft does not change existing tests. Starter controls include three tests. Test definitions stay with the draft, but you must rerun them after reopening or changing the rule.

Choose a Standard control

The template gallery includes three industry-neutral Standard controls:

• Review model inputs sends model inputs for review before the model runs.
• Review agent outputs sends model outputs for review before the application returns them.
• Require identified tool calls blocks a tool request when its tool name is missing.

Each starter also checks the application identity and where the policy runs. Select a starter, review its conditions, and run its tests before activation.

Review application fields

Add application fields only when the policy needs customer-provided data. In Review logic, choose confirmed data or type a plain-language need such as “Risk rating.” VeriProof adds it to the draft and lets you save and test the rule. A Developer must confirm the field before activation.

VeriProof can also find fields in a schema, sample payload, or recorded activity. An Administrator or Developer must review them before saving the field contract. You can leave the field contract empty when policies use VeriProof data only. Those rules still work. An Administrator or Developer must confirm each field’s meaning, source, data type, and whether the application always supplies it. Governance Engineers decide whether a policy rule needs the field. Until the field is confirmed, the rule cannot be activated. Technical paths, versions, hashes, and source details remain in advanced views.

Administrators and Developers can open Application fields for policies in the application’s Policy tab. If the application uses an SDK vocabulary, search its fields and select only those a policy needs. VeriProof brings in each field’s data type, allowed values, SDK source, and catalog version for review. You can also choose a JSON Schema, OpenAPI file, code-annotation schema, or sample JSON payload. VeriProof detects the source, derives both data paths, and shows the fields for review. It does not save fields during import. Developers usually add and confirm these fields. Administrators can also add them. Governance Engineers can review confirmed fields and their source but cannot change their mapping.

If a Developer configures the application with VeriProof SDK fields or a selected industry vocabulary, confirmed fields appear as readable choices during rule authoring. The rule input review shows the SDK definition and available values. The condition editor uses the same values as selections. VeriProof may also show up to three business-intent examples from that external vocabulary. Starting from an example does not import its illustrative Rego, select a framework, or activate a rule. Industry examples and processing rules stay outside the core platform.

Confirm and save a field

Review each needed field. Confirm its meaning, application data path, type, allowed values, example, and whether the application contract requires it. Saving creates a new field contract version. A sample payload or recorded activity can suggest a field, but it cannot confirm the field’s meaning or source. For larger contracts, VeriProof shows fields that need review first and then the first six confirmed fields. Search by meaning, data path, type, or allowed value, or select Show all fields.

Open Technical contract details to copy an example that VeriProof builds from the saved contract. Use it to test the application integration. The example updates when a Developer or Administrator saves a new contract version.

Compare saved fields with activity

Each policy field belongs to a versioned field contract. VeriProof shows these states separately:

• Provided by VeriProof: VeriProof supplies the field.
• Saved and found in activity: the field contract and recorded activity agree.
• Saved, not yet found: the field is in the contract but has not appeared in recorded activity.
• Found, not saved: recorded activity contains the field, but the field contract does not.
• Type does not match: recorded activity uses a different data type from the field contract.

If recorded activity uses another data version, the workspace names both versions. Update the SDK or integration to send the version selected for the policy, then run the application again. VeriProof does not mix fields from different versions.

A field found in activity is not automatically approved for policy use. A rule cannot be activated when it uses an unknown field. VeriProof records these field candidates even when the application has no active monitoring rule. This lets a Developer review representative activity before a Governance Engineer creates the first business-fact rule.

Require policy coverage only when needed

Unused application data does not create Governance Engineer work by default. Open Required policy coverage only when your organization requires an active rule for specific application data or a governed-action point. Select confirmed application data instead of entering its technical path. For a governed-action point, enter the registered point name used by the application.

Saving creates an immutable requirements version. VeriProof adds one Governance Engineer Inbox item for each requirement without an active rule. The item closes automatically when matching active coverage exists and reopens if that coverage is removed. Developer field requests and policy coverage requirements remain separate: Developers supply application data, while Governance Engineers supply the required rule.

Test and prepare activation

Once the draft has the inputs it needs, complete these stages:

1. Describe the business intent, expected outcome, scope, and representative examples.
2. Confirm inputs. Continue immediately for a Standard control, or ask the responsible Developer to confirm required business facts.
3. Review logic in plain language. Standard controls state the matched result and what happens otherwise. Open rule conditions or raw Rego only when needed.
4. Test positive, negative, and boundary cases.
5. Review impact against historical sessions, or confirm that no historical data exists.
6. Activate monitoring for recorded activity, or choose Shadow or Enforced for a before-action rule. Your authority and organization profile determine the available action.

For recorded activity, Evaluate against shows the selected activity source, such as Recent recorded activity. For an active before-action rule, Activate shows the current deployment separately from the selected next step.

Changing conditions or advanced Rego clears stale test and impact evidence. After you change a saved rule, save the draft before checking readiness. VeriProof binds readiness and deployment decisions to the exact saved version. Selecting Review activation from a draft rule opens the Activation stage; it does not bypass readiness.

If a monitoring draft still uses data available only before an action, historical impact tells you to remove those fields or return to Before action.

You can save, compile, and test a draft while application data is missing. Activation remains blocked until a Developer confirms the required data and the current tests pass.

When you add a test, describe the Situation and select the expected result. Open Test details only when you need to change the example application data or list expected reasons. VeriProof checks the JSON before it adds the test.

Write each expected reason as one clear sentence that explains the business outcome. This sentence appears in session evidence and can be returned to an authorized agent or application. Keep field paths and reason codes in technical evidence. For example, use The request exceeds the approved limit. instead of Policy violation.

VeriProof binds an approved response message to the governed rule version for durable enforcement evidence. Runtime values stay in the protected session record rather than being copied into the audit message.

Before-action data is not present in recorded sessions. For these rules, Review impact explains why historical comparison is unavailable and directs you to test both expected results. It does not show comparison controls that cannot produce evidence.

Choose the right rule type

• Use a visual threshold rule for a straightforward measure and limit.
• Use Rego when the decision needs several conditions or reusable policy logic.

Choose the simplest rule that expresses the expected outcome clearly.

Coordinate a missing application input

Developers supply application facts. Governance Engineers own policy behavior. Publishers or approvers authorize deployment.

When readiness reports missing application data, select Request Developer update. Review the request, then select Send request. VeriProof routes one deduplicated request to the responsible Developer. The request includes the environment, contract version, field meanings, source mappings, data types, allowed values, examples, and the blocked activation step. The Developer does not need to interpret the Rego source.

In the Developer request, select Review application data. VeriProof opens the same application’s Application data workspace, selects when the policy uses the data, and prepares each requested field for review. The Developer confirms the field meaning, application path, and data type before saving. Saving creates a new contract version. It does not claim that the application has sent the field. The workspace shows confirmed fields and recorded activity separately. For an Enforced deployment, a confirmed field can still block activation until the application sends compatible test activity. Readiness labels this as missing runtime evidence, not missing Developer confirmation. Select Return to request to open the same Inbox panel after recording a test session.

If no responsible Developer is assigned, an Administrator receives an assignment action. Readiness shows this as Developer assignment · Open · Administrator until a Developer is assigned. Assign developers opens Application Ownership for the selected application. The Administrator assigns a Developer responsible for its code and SDK setup; team access restrictions do not create this assignment. VeriProof resolves the request when the required data arrives and tells the policy owner when the rule can be tested again. Select Policy data is ready in Inbox to open the correlated rule at Test. VeriProof refreshes the confirmed data, readiness, Inbox, and tracked work before the author continues.

For an enforced rule in Production, VeriProof waits for repeated evidence before creating Developer work. One missing value does not create an Inbox item. A qualified request closes when compatible application data returns.

Create and test a monitoring rule

1. Open the application’s Policy tab.
2. Confirm the policy outcome and application scope.
3. Create the rule and explain what it should detect.
4. Test it with representative sessions or a saved test set.
5. Select Monitor after activity.
6. Choose the after-activity response: Record, Notify, or Flag session.
7. Open Activate, check the current evidence, and select Activate monitoring. VeriProof requests approval when the organization profile requires it.

This path evaluates completed evidence. It cannot prevent the completed action.

Create and test a before-action rule

1. Create and test the exact rule version and application scope.
2. Select Before action or the advanced Before and after activity placement.
3. Review the version in Shadow. It records proposed results without changing application behavior, creating reviews or notifications, assigning violation work, or flagging sessions.
4. Select Enforce only when your role permits it. Production can require approval for the exact version, application, and policy digests.

Editing an active rule returns the new version to Shadow and clears the earlier approval and deployment operation. Restoring an earlier version creates a draft and does not delete history.

Available actions depend on your permissions and the application’s environment.

Understand deployment approval

• Streamlined lets an authorized publisher deploy a tested version directly.
• Controlled requires one independent approval for Enforced deployment.
• Regulated requires one independent approval for Shadow and two independent approvals for Enforced deployment.

The requester cannot count as an independent approver. Each approval binds to the exact version, content hash, application, deployment mode, tests, and change summary. A stronger production-write control still applies when configured.

An Auditor can verify the version, readiness evidence, approvals, deployment, restore history, linked work, and audit record without changing the rule. Auditors open Policy > Rules from an application in their active engagement. The rule side panel shows version history and a collapsed Audit history. It does not show authoring, activation, SDK setup, or application configuration actions. Each audit entry identifies the person, role, time, state, and linked record. Exact hashes and deployment generations remain under Technical evidence.

See how roles work together

Review an existing rule

Check its status, scope, recent results, and version history before you change it. If a rule creates too much or too little follow-up, inspect the matching sessions and exceptions before you adjust its conditions.

Rule details show the two latest versions first. Select Show older versions when you need more history. Deployment records show the change summary without internal user identifiers or system timestamps. The audit record retains those technical details.

Governance Engineers can open Versions while editing a saved rule. Compare shows the advanced source changes. Restore creates a new draft from the selected version and keeps the current version in the history. Restored before-action rules must pass readiness and activation again before they can affect application activity.

Open Audit history in the Activation stage to review the records linked to that policy change. The list brings together saved versions, readiness checks, Developer data requests, deployment requests, and approvals. Each entry shows the action, state, person or role, and time. Open Technical evidence only when you need the exact rule version, content hash, or deployment generation.