> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance Policies

> Compliance policies are plain-language rules, managed on the script editor's Policies tab, that the assistant's responses are checked against before they are spoken. A response that breaks a rule is held back and regenerated, and check results are recorded on the call.

## What are Compliance Policies?

Compliance policies are rules you author — in plain language, on the script editor's **Policies** tab — that the assistant's responses must follow. Responses the assistant generates are evaluated against every policy on your script before they reach the caller. A response that fails the check is not spoken: the assistant holds it back, regenerates a compliant answer, and records what happened on the call.

Policies work in two layers:

* **Guidance before generation** — Your policy rules are placed in front of the assistant at the start of every call, so it considers them while composing each response.
* **Enforcement after generation** — Generated responses are then independently checked against every policy before they reach the caller. The check is the backstop: even a well-guided assistant can slip, and a response that fails the check is never heard.

Policies suit hard rules with regulatory or brand consequences — telemarketing consent wording, financial or medical disclaimers, things the assistant must never claim or offer. For softer behavioural steering (tone, how to handle a situation), use [Guidelines](/scripts/guidelines) instead.

Policies can be found under:

**Scripts → *(your script)* → Policies**

***

## Policy Structure

A script can carry any number of policies. Each policy has three parts:

| Field           | Required | Description                                                                                                                                                      |
| --------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**        | No       | A short label, e.g. "TCPA". Shown in the system notes on each call, so choose something recognisable.                                                            |
| **Description** | No       | One sentence of context about what the policy covers, e.g. "Telemarketing consent rules".                                                                        |
| **Rules**       | No       | A list of plain-language rules the response must follow. The editor will save a policy without rules, but there is nothing to enforce until it has at least one. |

Rules are numbered from 1 in the order you list them, and those numbers are used in check results — when a response fails, the note on the call tells you exactly which rule numbers were breached.

### Example

```text theme={null}
Name: TCPA
Description: Telemarketing consent rules
Rules:
  1. Never state that the call is not recorded.
  2. Never offer to remove the customer from lists you cannot access.
```

Within a policy, **all rules must hold** for a response to pass. Across policies, every policy must pass — a response that breaches any rule of any policy is withheld.

***

## Creating a Policy

Open your script and go to the **Policies** tab — it sits between **Guidelines** and **Knowledge Base** in the script editor, and is available on every script. Before you add anything the tab reads: *No policies yet. Add your first policy below.* Click **Add Policy** to create your first policy; it arrives blank, with one empty rule ready to fill in. Once the list has at least one policy, an **Add policy** button at the top of the tab adds more — new policies are appended to the bottom of the list.

Each policy is a card with two text fields and a rules list:

| Setting     | Description                                                                                     | Default        |
| ----------- | ----------------------------------------------------------------------------------------------- | -------------- |
| Name        | The policy's label, shown in the system notes on each call. Placeholder: *e.g. TCPA*.           | Empty          |
| Description | One line of context on what the policy covers. Placeholder: *e.g. Telemarketing consent rules*. | Empty          |
| Rules       | The policy's rules, one per field. Placeholder: *Enter a compliance rule*.                      | One empty rule |

None of the fields is validated — there are no required fields, character limits, or uniqueness checks — so it is up to you to give every policy a recognisable name and at least one meaningful rule.

### Editing rules

Each rule is a numbered field that grows with its text as you type. **Add rule** appends an empty rule to the end of the list; to remove one, hover over it (or focus it) and click the **×** that appears at its right edge. Rules keep the order you entered them in — there is no reordering — and check results reference rules by these numbers, so add them in the order you want them reported. A policy stripped of every rule shows *No rules added to this policy.* — give it rules again, or remove it.

### Removing a policy

Each card ends with a **Remove policy** button, which deletes the policy — rules and all. Removing a rule or a policy is immediate, with no confirmation, but nothing is stored until you save the script, so a mistaken deletion can be undone by reloading the editor without saving.

### Saving

Policy edits mark the script with the **Unsaved Changes** badge like any other change in the editor. Use the header's **Save** button to store them in a draft revision, or **Publish** to put a new version live — you will see *Script saved successfully* when the save goes through. When you are viewing an older version of the script, the Policies tab is read-only; switch back to the latest version to make changes.

***

## When Checks Run

Policy checks run on effectively every response the assistant generates — including the opening line, answers mid-conversation, and regenerated responses during recovery.

Two kinds of response are exempt and pass straight through without a check:

* **Verbatim scripted lines** — Verbatim content in a [voice step](/flows/steps-voice) is spoken exactly as written, so it is not checked. You are responsible for ensuring that wording complies with any organisational policies as authored.
* **Brief acknowledgements** — Short filler acknowledgements ("Sure, one moment") that carry no substantive content.

A small set of auxiliary responses also sits outside the policy gate: idle re-engagement prompts (when the assistant nudges a caller who has gone quiet), answers to incidental off-script questions, and continuations of speech that was already checked before being paused.

Exemptions are silent: nothing is evaluated and no note is written.

***

## What Happens When a Check Fails

When a response breaches a policy, the caller never hears it. Instead:

1. **The response is withheld.** The non-compliant answer is discarded before it is spoken.
2. **The caller hears a short, neutral hold line.** Something like "Bear with me for just a second..." or "One moment...". These are pre-approved fixed phrases, never generated text — so a compliance failure is always voiced by wording that cannot itself breach a policy.
3. **The assistant regenerates.** A new response is composed with extra effort and re-checked against your policies before it is spoken. This typically resolves within a few seconds.
4. **A second attempt if needed.** If the first regeneration also fails, the caller hears another brief hold line and the assistant tries once more with a longer budget.
5. **Continued attempts.** The assistant keeps working toward a compliant answer, which will resolve the situation unless there is a genuine discrepancy between what the script asks the assistant to say and what a policy allows — see [Policies and Script Design](#policies-and-script-design) below.

The checking is **fail-closed**: if a policy check cannot complete for any reason — an evaluation error or timeout — that counts as a failure and the response is withheld anyway. A checked response is only ever spoken once it has been positively verified against every policy.

***

## Policies and Script Design

Policies are important, but they should support good script design rather than compensate for it.

When policies are combined with poorly defined scripting, the assistant can appear to become stuck in a loop by repeatedly attempting to produce a response that the policy does not allow.

Where a policy is triggered during testing, this should generally be treated as an indication that the script needs to be adjusted to handle that particular edge case more explicitly.

With well-designed scripting, it is possible for more than 99.9% of steps to run without triggering a policy.

***

## Reviewing Results on Calls

Every policy evaluation that completes writes a system note on the call — on **pass as well as fail** — giving you an audit trail of checked responses. Notes appear in the call detail alongside the transcript, in the form:

```text theme={null}
0123.45 | Confirm Consent | System - Compliance | [TCPA] result=false trigger=[2] - Response: ... - Reasoning: ...
```

Reading a note:

* **`[TCPA]`** — the policy name you configured.
* **`result`** — `true` when every rule held, `false` when the response was withheld.
* **`trigger`** — the rule numbers that were breached (matching the numbering in your policy), empty on a pass.
* **`Response`** — the candidate response that was checked. On a failure, this is the withheld text the caller never heard.
* **`Reasoning`** — the evaluator's brief explanation of its verdict.

If a policy's evaluation errors, the note reads `check error - failing closed` for that policy and the response is treated as a failure. If the check as a whole cannot complete within its time budget, the response is still withheld — fail-closed — but no per-policy note is recorded for it.

***

## Latency

Policy checking is engineered to add minimal delay to the conversation, and a small, focused set of policies has no noticeable impact on the assistant's responsiveness.

An excessive number of policies, or policies with long and convoluted rule lists, can begin to affect how quickly the assistant responds. Keep the set lean and the rules concise — a compact set of clear rules is also enforced more reliably than a sprawling one.

When a check does fail, the caller hears a brief hold line while the assistant reworks its answer, so repeated failures are what callers will actually notice — another reason to resolve recurring triggers in the script itself rather than leaning on the policy to catch them.

***

## Writing Effective Policies

1. **Make every rule relevant across the entire call** — Policies are checked against responses at every stage of the conversation, not just the steps you had in mind when writing them. A rule that only makes sense in one part of the call can produce unexpected failures elsewhere.
2. **Choose language that does not conflict with any step** — Read your rules against the whole script. If a rule forbids something a step legitimately asks the assistant to say, the two will fight each other on every call that reaches that step — see [Policies and Script Design](#policies-and-script-design).
3. **Phrase rules about the response itself** — The check is asked to judge the response the assistant is about to speak. "Never state the call is not recorded" works; "The caller must have given consent earlier" does not, because it is a fact about the call rather than about the response being judged.
4. **One prohibition or requirement per rule** — Each rule should be independently checkable. Split "never discuss pricing or discounts or competitors" into separate rules so failures point at exactly what went wrong.
5. **Be literal and unambiguous** — Vague rules ("be appropriate") produce inconsistent verdicts; concrete rules ("never quote a dollar figure for legal fees") are enforced reliably.
6. **Group related rules into one named policy** — A policy named for the regulation or theme it covers ("TCPA", "Financial Advice") makes the call notes instantly readable.
7. **Keep scripted lines compliant** — Verbatim content is exempt from checking, and you are responsible for ensuring that wording complies with any organisational policies.
8. **Review the notes** — Notes are written on passes as well as failures, so you can audit real calls to confirm rules are firing as intended, and tighten wording where the reasoning shows near-misses.

***

## Limits and Considerations

* **No fixed cap on policies or rules** — The editor imposes no limit, but every policy adds one evaluation to every checked response, so keep the set focused on rules that genuinely matter.
* **Context is limited** — Alongside the candidate response, the evaluator sees a window of recent conversation, the caller's first name, and the current date and time. Write rules that can be judged from the response itself.
* **No on/off switch** — Policies have no enable/disable toggle in the editor. To stop enforcing one, remove it and save; keep a copy of the wording if you may want it back later.
* **Policies apply per script** — Each script carries its own policies.

***

## Next Steps

* [Guidelines](/scripts/guidelines) — Softer condition–response steering for tone and edge cases
* [Voice Steps](/flows/steps-voice) — Verbatim scripts versus instructional scripts
* [Scripts Overview](/scripts/overview) — All the components of a script

***

## Disclaimer

Compliance policies are evaluated by large language models, which are probabilistic systems. While policy checking is designed to be strict and to fail closed, Voxworks Technologies cannot guarantee that every non-compliant response will be detected, or that every compliant response will pass. Policies are a safeguard, not a substitute for compliant script design, and nothing on this page constitutes legal or regulatory advice.

You are responsible for fully testing your script and policies together — across the range of situations your callers will realistically encounter — before putting them into production, for reviewing call results on an ongoing basis, and for ensuring your use of the platform meets the legal and regulatory obligations that apply to your organisation.