Policies and the policy simulator

Who this is for

Governance leads and admins who keep the policy register and want to test a policy change before they make it.

Before you start

• The Policies register is at Governance > Policies. Reading it is open to Owners, Admins, Members and Viewers. Creating and editing policies is open to Owners, Admins and Members. Deciding exception requests is limited to Owners and Admins. The register is available from the Business plan. The Governance sidebar item is shown to Owners and Admins.
• The Policy simulation page is at Admin center > Governance & Compliance > Policy simulation. The Admin center opens only for Owners and Admins, so in practice only they reach this page. The entitlement behind it covers drafting and running a simulation for Owners, Admins and Members from the Business plan, and planning a rollout for Owners and Admins on the Enterprise plan.
• A second page, the Policy simulator, replays a proposed change against your audit events. It is available only when it is switched on for your deployment, and only to Owners and Admins.
• Decide what you want to test. The two simulators test different things, and neither one changes what the platform does today.

Policy categories and status

Every policy in the register has a category:

• PII
• Content
• Access
• Cost
• Provider

Every policy has a status. The statuses are Draft, Simulate, Live, Paused and Retired. A new policy starts as Draft. The allowed moves are:

• Draft to Simulate or Live.
• Simulate to Draft or Live.
• Live to Paused or Retired.
• Paused to Live or Retired.
• Retired is final.

Create a policy

1. Open Governance > Policies.
2. Select Create policy. To start from a preset, select "From template" and choose PII redaction, Cost guardrail or Provider approval. A template only fills in the form. Nothing is created until you save.
3. Enter the Name (up to 200 characters), choose the Category, and add a Description (up to 2000 characters).
4. Optionally set a Scope: workspaces, roles, providers or models. Leave every bucket empty for no restriction. A workspace entry here is only a name; workspaces do not scope policies today.
5. Leave the Status as Draft, then select Create policy. The Owner defaults to you.

To change a policy later, open it and use the Definition tab. Field edits are not saved automatically. Select "Save changes" and confirm. Status changes are separate: use the status control on the policy. Moving a policy to Live shows an extra confirmation with a checkbox you must tick.

The policy page has these tabs: Definition, Exceptions, Discussion, Activity and Technical.

• Exceptions: a team member selects "Request an exception" with a Reason and an optional expiry. A different Owner or Admin approves or denies it. You cannot approve your own request.
• Discussion: a free-text comment thread.
• Activity: policy created, updated and deleted events, and exception requests and decisions.
• Technical: policy ID and full scope, for approvers.

Versions and rollback

1. In the policy list, open the row menu and choose "View version history".
2. The Policy versions page shows a timeline. Each version is marked Active, Superseded, Pending rollback or Rejected. The Currently active version is called out at the top.
3. Choose Compare (A) on one version and Compare (B) on another to see a side-by-side diff of added, removed and changed values.
4. To go back, Owners and Admins select "Roll back" on an earlier version. Enter a change reason, up to 2000 characters, then select "Queue rollback request".

A rollback does not take effect straight away. It creates a new pending version and sends an approval request to the Approvals surface (Governance > Approvals & delegation). The current version stays active until an approver accepts. The person who requested the rollback cannot approve it. The reason is recorded in the audit ledger.

Note. The versions page uses a separate versioning service. If it is not enabled for your workspace, the page says versioning is not available yet. If it has no record for a policy, it says no versions are recorded.

Run a simulation

Use this to test a draft rule set before you decide anything.

1. Open Admin center > Governance & Compliance > Policy simulation.
2. On the Policy builder tab, enter a Draft name. Add rules. Each rule has conditions on detector type, severity, source or confidence, a priority from 1 to 100 where higher wins, and one action: FLAG, REDACT, REQUIRE_APPROVAL, QUARANTINE or BLOCK. A rule set can hold up to 200 rules.
3. Set the Replay window: 7, 30, 90, 180 or 365 days. The default is 90.
4. Select "Save draft" if you want to keep it, then select "Run simulation".
5. Read the Impact tab for projected compliance change, false-positive estimate and overhead. Read the Conflicts tab for rules that overlap or contradict. Conflicts update as you type. The replay runs only when you ask.
6. The Rollout tab plans staged steps of 1, 5, 25, 50 and 100 percent, and records the figures you observe at each stage. A rollout plan must cite a saved simulation with a conclusive result.

If the window holds fewer than 50 events, the page warns that the projection is not conclusive.

To test a change to a policy in the register, open the row menu, choose Simulate, and use the Policy simulator. It replays a proposed change against your audit events from a time window you pick and compares simulated decisions to what happened. A policy in the register has no stored rule body, so the editor starts from a template rule. Edit it to match your intent before you trust the result.

What a block looks like

What a person sees depends on the feature that made the call. The product uses plain messages, for example:

• "A workspace content policy blocked this request. A workspace admin can review it, then you can retry."
• "Your workspace's data residency policy blocked this request. A workspace admin can review the policy, then you can retry."
• "This message was blocked by data-loss-prevention policy and was not sent."

Through the API gateway, a block returns an error code and status. Content policy returns blocked_by_content_policy with status 403. Data loss prevention returns blocked_by_dlp with status 403. A spend cap returns spend_cap_exceeded with status 402. A paused workspace (kill switch) returns kill_switch_active with status 423.

Limits and notes

Note. A simulation is a best-effort estimate. It replays past events and cannot show effects caused by the new policy itself. Use it as a direction, not a promise.

• The register stores a policy's name, category, owner, description, scope and status. It does not store a rule body. Controls that act on live traffic are set on their own pages, such as Admin center > Data loss prevention, Admin center > Model entitlements, Governance > Model router and Governance > Kill switch.
• The Live confirmation says it applies the policy's action to matching traffic. Because the register holds no rule body, confirm on the page of the control you rely on that it is set. Do not treat a Live status alone as proof of enforcement. Contact SynapBridge support if you need confirmation for your deployment.
• Rule sets on the Policy simulation page are proposals. The request path does not read them. The Rollout tab records a plan and results you enter. It does not change what the platform enforces.
• Deleting a policy is permanent. It removes the policy, its exceptions and its discussion.